I thought there were tool and work-arounds for such issues?  And, wouldn't
it be on those applications to be upgraded/patched for a "new" operating
system?  Because I mean, Windows 7 is a brand new operating system that we
are paying for!  Its certainly not just a "fixed" version of Vista.
I mean, come on...

--
ME2


On Wed, May 6, 2009 at 9:04 PM, Ken Schaefer <k...@adopenstatic.com> wrote:

>  Apparently lots of apps that check version numbers. I personally have
> quite a few that I need to run installers in "Vista compatibility mode"
>
> Also, does it make sense to have Windows Server 2008 R2 as v7.0 given that
> it is currently named an "R2" release?
>
> Cheers
> Ken
>
>  ------------------------------
> *From:* Micheal Espinola Jr [michealespin...@gmail.com]
> *Sent:* Thursday, 7 May 2009 11:01 AM
>
> *To:* NT System Admin Issues
> *Subject:* Re: Memory Dumps on large RAM OS
>
>  I've heard this, but is that a *truly* legit reason to disregard proper
> development/release numbering? What exactly is it going to break that cannot
> be properly compensated for with patching/updates?
>
> --
> ME2
>
>
> On Wed, May 6, 2009 at 8:56 PM, Ken Schaefer <k...@adopenstatic.com> wrote:
>
>>  What dancing around? I thought it was for backwards compat?
>>
>> Windows Server 2008 R2 isn't getting a new version number AFAIK.
>>
>> Cheers
>> Ken
>>
>>  ------------------------------
>>  *From:* Micheal Espinola Jr [michealespin...@gmail.com]
>>  *Sent:* Thursday, 7 May 2009 10:52 AM
>> *To:* NT System Admin Issues
>>   *Subject:* Re: Memory Dumps on large RAM OS
>>
>>    I love how Microsoft has been dancing around why "7" doesn't have a
>> new major release number (i.e 7.0), and is still within the 6.x cycle.
>>  --
>> ME2
>>
>>
>> On Wed, May 6, 2009 at 8:34 PM, Michael B. Smith <
>> mich...@owa.smithcons.com> wrote:
>>
>>>  what you commonly see in the non-public presentations is "why"
>>> something is the way it is and some discussions about tradeoffs.
>>>
>>> in general, microsoft thinks that customers don't want to hear about
>>> implementation tradeoffs. i would say that for your average end-user, that's
>>> true. for your above-average tech., probably not so much.
>>>
>>> however, even in the non-public presentations, the discussions often get
>>> bogged down in "why isn't this optional" and people expressing opinions that
>>> a decision was made improperly. when you have the attention of the people
>>> who wrote the code or can change the code, it's hard not to have an agenda.
>>> microsoft prefers to keep those kinds of discussions under control. i would
>>> too. :-)
>>>
>>> too many knobs to turn and buttons to push makes support impossible,
>>> implementation ridiculously complicated, and code even more bloated than it
>>> already is to meet the feature requests of customers.
>>>
>>> let's take an example: Vista. Vista is what people asked for. Pretty and
>>> glitzy and new and secure and blah blah blah. But to run well, it took much
>>> faster hardware, lots more memory, better graphics cards, etc. etc. People
>>> didn't want to pay for that. Microsoft paid the price for giving the public
>>> what they asked for. (Yes, yes, yes, they made some poor decisions too, but
>>> that doesn't change my core point.)
>>>
>>> Win7 is Vista Reloaded. I don't care what you want to call it. It's
>>> optimized and to reduce the memory footprint, lots of services were made
>>> optional (decoupled), the graphics aren't as glitzy (unless you ask for
>>> them) and the kernel handles multi-cores better. Lots of the knobs and
>>> buttons that Vista exposed are now hidden; still there, but now under the
>>> covers.
>>>
>>> anyway, i'm in a philosophical mood and i digress...
>>>
>>>
>>>  ------------------------------
>>> *From:* Micheal Espinola Jr [michealespin...@gmail.com]
>>> *Sent:* Wednesday, May 06, 2009 5:58 PM
>>> *To:* NT System Admin Issues
>>>  *Subject:* Re: Memory Dumps on large RAM OS
>>>
>>>    That would be most excellent of them to make available.  Do you need
>>> Secret Squirrel level clearance?
>>>
>>> --
>>> ME2
>>>
>>>
>>> On Wed, May 6, 2009 at 4:57 PM, Michael B. Smith <
>>> mich...@owa.smithcons.com> wrote:
>>>
>>>> Yes, and they take a damn long time to transfer too.
>>>>
>>>> Best practice for pagefile size on 64-bit Exchange Servers is RAM + 15
>>>> MB.
>>>>
>>>> And page file space is only loosely correlated to "paging out". I've got
>>>> a great presentation on this topic that was made in a closed forum by Mark
>>>> Russinovich (of sysinternals fame), but I don't think it was ever made
>>>> public.
>>>>
>>>> Regardless, RAM + 15 MB is a good place to start (on x64), then adjust
>>>> as necessary for your environment.
>>>>
>>>> ________________________________________
>>>> From: Don Kuhlman [drkuhl...@yahoo.com]
>>>> Sent: Wednesday, May 06, 2009 1:33 PM
>>>> To: NT System Admin Issues
>>>>  Subject: Memory Dumps on large RAM OS
>>>>
>>>> Ps - just a thought or another question.
>>>> With the RAM capacity of the newer Windows OS - 32 gig of RAM, are
>>>> people generally just setting up the crash dump recovery on Windows to use
>>>> the small memory dump, or some other setting besides a full dump?
>>>>
>>>> In theory, if you have a server with 32 gig of RAM, and if you wanted a
>>>> full dump, you'd need a 32 gig page file which seems like a huge waste of
>>>> space, because (in theory), the server with this much RAM would never be
>>>> paging out especially to a page file that big, right?
>>>>
>>>> So how would you capture a dump?
>>>>
>>>> Don K
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message ----
>>>> From: Christopher Bodnar <christopher_bod...@glic.com>
>>>> To: NT System Admin Issues <ntsysadmin@lyris.sunbelt-software.com>
>>>> Sent: Tuesday, May 5, 2009 7:34:27 AM
>>>> Subject: RE: Frequent crashes on a virtual machine
>>>>
>>>> You might want to check out this:
>>>>
>>>> http://technet.microsoft.com/en-us/sysinternals/bb963887.aspx
>>>>
>>>> Mark Russinovich's webcast on Crash Dump analysis might be of help to
>>>> you.
>>>>
>>>>
>>>>
>>>> Chris Bodnar, MCSE
>>>> Sr. Systems Engineer
>>>> Distributed Systems Service Delivery - Intel Services
>>>> Guardian Life Insurance Company of America
>>>> Email: christopher_bod...@glic.com
>>>> Phone: 610-807-6459
>>>> Fax: 610-807-6003
>>>>
>>>> -----Original Message-----
>>>> From: drkuhl...@yahoo.com [mailto:drkuhl...@yahoo.com]
>>>> Sent: Tuesday, May 05, 2009 8:26 AM
>>>> To: NT System Admin Issues
>>>> Subject: Re: Frequent crashes on a virtual machine
>>>>
>>>> Anyone ever see a situaition where the server doesn't write a mini or
>>>> any
>>>> other dump when it crashes?
>>>>
>>>> Better yet, does someone have a link to some good dump analysis site(s)
>>>> ?
>>>> Thanks
>>>>
>>>> Don k
>>>>
>>>> Sent from my BlackBerryR smartphone with SprintSpeed
>>>>
>>>> -----Original Message-----
>>>> From: Brian Desmond <br...@briandesmond.com>
>>>>
>>>> Date: Tue, 5 May 2009 02:35:20
>>>> To: NT System Admin Issues<ntsysadmin@lyris.sunbelt-software.com>
>>>> Subject: RE: Frequent crashes on a virtual machine
>>>>
>>>>
>>>> A kernel dump is good enough. You'll get a mini for free.
>>>>
>>>> You should do this on one of the crashing guests. Sorry if that wasn't
>>>> clear.
>>>>
>>>> Thanks,
>>>> Brian Desmond
>>>> br...@briandesmond.com
>>>>
>>>> c - 312.731.3132
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Richard Stovall [mailto:richard.stov...@researchdata.com]
>>>> Sent: Monday, May 04, 2009 9:00 PM
>>>> To: NT System Admin Issues
>>>> Subject: RE: Frequent crashes on a virtual machine
>>>>
>>>> I've got tons of minidumps from this issue.  All I know how to do is run
>>>> them through WinDbg, and I always come up with PFN_LIST_CORRUPT.
>>>>
>>>> Per the suggestions here, I will turn on verifier.exe on one of the
>>>> affected servers.  Should I have it create a minidump, kernel dump, or
>>>> full memory dump?  What can I do differently with the dump file to
>>>> pinpoint what's going on?
>>>>
>>>> I'm really at my wit's end with this.  It's been going on ever since I
>>>> began installing Sunbelt's Vipre on our servers.
>>>>
>>>> Thanks very much for the help.
>>>>
>>>> RS
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Ken Schaefer [mailto:k...@adopenstatic.com]
>>>> Sent: Monday, May 04, 2009 9:33 PM
>>>> To: NT System Admin Issues
>>>> Subject: RE: Frequent crashes on a virtual machine
>>>>
>>>> 0x4E is FPN_LIST_CORRUPT. This is unlikely to be caused by the host
>>>> machine, especially if the VM is bluescreening with the same STOP code
>>>> over and over.
>>>>
>>>> Usually 0x4E is a faulty kernel module of some kind (driver, file system
>>>> filter or similar).
>>>>
>>>> Can we get access to a minidump file(s)?
>>>>
>>>> Brian's suggestion of turning on verifier.exe is also a good idea. It
>>>> won't stop the BSODs, but it will catch the culprit in the act (e.g.
>>>> when something writes to memory it shouldn't be) and make the dump files
>>>> much better.
>>>>
>>>> Cheers
>>>> Ken
>>>>
>>>> ________________________________________
>>>> From: mse...@ont.com [mse...@ont.com]
>>>> Sent: Tuesday, 5 May 2009 1:50 AM
>>>> To: NT System Admin Issues
>>>> Subject: RE: Frequent crashes on a virtual machine
>>>>
>>>> Is there anything in under events for that VM? Also, check under
>>>> /var/log
>>>> for that ESX host to see if you have any errors.
>>>>
>>>> Original Message:
>>>> -----------------
>>>> From:  richardmccl...@aspca.org
>>>> Date: Mon, 4 May 2009 10:27:27 -0500
>>>> To: ntsysadmin@lyris.sunbelt-software.com
>>>> Subject: RE: Frequent crashes on a virtual machine
>>>>
>>>>
>>>> Thanks, but it doesn't apply here.  This was a VM "built from scratch"
>>>> from the VM console.  It was never a physical machine.
>>>> --
>>>> Richard
>>>> "mse...@ont.com" <mse...@ont.com> wrote on 05/04/2009 10:14:14 AM:
>>>>
>>>> > Did you do cleanup after you P2V'd your server?
>>>> >
>>>> > Open a command prompt on the Windows VM (Start --> Run --> cmd).
>>>> > set devmgr_show_nonpresent_devices=1
>>>> > devmgmt.msc
>>>> > In the device management console (View --> Show Hidden Devices).
>>>> > Uninstall the devices that are no longer required. Such as old network
>>>> > devices.
>>>> >
>>>> > Mike
>>>> >
>>>> > Original Message:
>>>> > -----------------
>>>> > From:  richardmccl...@aspca.org
>>>> > Date: Mon, 4 May 2009 08:57:39 -0500
>>>> > To: ntsysadmin@lyris.sunbelt-software.com
>>>> > Subject: RE: Frequent crashes on a virtual machine
>>>> >
>>>> >
>>>> > Yes.
>>>> >
>>>> > The crashes do not necessarily coincide with VIPRE scans, etc.
>>>> > --
>>>> > Richard D. McClary
>>>> > Systems Administrator, Information Technology Group
>>>> >
>>>> > ASPCA(r)
>>>> > 1717 S. Philo Rd, Ste 36
>>>> > Urbana, IL  61802
>>>> >
>>>> > richardmccl...@aspca.org
>>>> >
>>>> > P: 217-337-9761
>>>> > C: 217-417-1182
>>>> > F: 217-337-9761
>>>> > www.aspca.org
>>>> >
>>>> > The information contained in this e-mail, and any attachments hereto,
>>>> is
>>>>
>>>> > from The American Society for the Prevention of Cruelty to Animals(r)
>>>> (ASPCA
>>>> > (r)) and is intended only for use by the addressee(s) named herein and
>>>> may
>>>>
>>>> > contain legally privileged and/or confidential information. If you are
>>>> not
>>>> > the intended recipient of this e-mail, you are hereby notified that
>>>> any
>>>> > dissemination, distribution, copying or use of the contents of this
>>>> > e-mail, and any attachments hereto, is strictly prohibited. If you
>>>> have
>>>> > received this e-mail in error, please immediately notify me by reply
>>>> email
>>>> > and permanently delete the original and any copy of this e-mail and
>>>> any
>>>> > printout thereof.
>>>> >
>>>> >
>>>> > "Richard Stovall" <richard.stov...@researchdata.com> wrote on
>>>> 05/04/2009
>>>>
>>>> > 08:50:58 AM:
>>>> >
>>>> > > Do you have Vipre on these VMs?
>>>> > >
>>>> > > From: richardmccl...@aspca.org [mailto:richardmccl...@aspca.org]
>>>> > > Sent: Monday, May 04, 2009 9:43 AM
>>>> > > To: NT System Admin Issues
>>>> > > Subject: Frequent crashes on a virtual machine
>>>> > >
>>>> > >
>>>> > > Greetings!
>>>> > >
>>>> > > Most of our user files are being moved to a VMWare VM.  What is
>>>> > > disturbing is, when I log in, I am frequently greeting with a notice
>>>> > > that the machine re-booted from a crash...
>>>> > >
>>>> > > My users have never noticed anyting amiss as it reboots pretty
>>>> > > quickly (so far).  However, once it did this while it was being
>>>> > > backed up, so a bunch of user files were skipped that day.
>>>> > >
>>>> > > I get this set of messages:
>>>> > >
>>>> > > Category (102)  Event ID:  1003
>>>> > >
>>>> > > Error code 0000004e, parameter1 0000009a, parameter2 00009028,
>>>> > > parameter3 00000006, parameter4 00000002.
>>>> > >
>>>> > > Again, this is a VM.  Google searches pretty much all point to
>>>> > > solutions on a physical machine.
>>>> > >
>>>> > > Thanks!
>>>> > > --
>>>> > > Richard D. McClary
>>>> > > Systems Administrator, Information Technology Group
>>>> > >
>>>> > > ASPCA(r)
>>>> > > 1717 S. Philo Rd, Ste 36
>>>> > > Urbana, IL  61802
>>>> > >
>>>> > > richardmccl...@aspca.org
>>>> > >
>>>> > > P: 217-337-9761
>>>> > > C: 217-417-1182
>>>> > > F: 217-337-9761
>>>> > > www.aspca.org
>>>> > >
>>>> > > The information contained in this e-mail, and any attachments
>>>> > > hereto, is from The American Society for the Prevention of Cruelty
>>>> to
>>>> > Animals(r)
>>>> > > (ASPCA(r)) and is intended only for use by the addressee(s) named
>>>> > > herein and may contain legally privileged and/or confidential
>>>> > > information. If you are not the intended recipient of this e-mail,
>>>> > > you are hereby notified that any dissemination, distribution,
>>>> > > copying or use of the contents of this e-mail, and any attachments
>>>> > > hereto, is strictly prohibited. If you have received this e-mail in
>>>> > > error, please immediately notify me by reply email and permanently
>>>> > > delete the original and any copy of this e-mail and any printout
>>>> > thereof.
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>>> > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>>> >
>>>> > --------------------------------------------------------------------
>>>> > mail2web.com ? What can On Demand Business Solutions do for you?
>>>> > http://link.mail2web.com/Business/SharePoint
>>>> >
>>>> >
>>>> >
>>>> > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>>> > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>>> >
>>>>
>>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>>>
>>>> --------------------------------------------------------------------
>>>> mail2web LIVE - Free email based on Microsoft(r) Exchange technology -
>>>> http://link.mail2web.com/LIVE
>>>>
>>>>
>>>>
>>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>>>
>>>>
>>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>>>
>>>>
>>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>>>
>>>>
>>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>>>
>>>>
>>>> -----------------------------------------
>>>> This message, and any attachments to it, may contain information
>>>> that is privileged, confidential, and exempt from disclosure under
>>>> applicable law.  If the reader of this message is not the intended
>>>> recipient, you are notified that any use, dissemination,
>>>> distribution, copying, or communication of this message is strictly
>>>> prohibited.  If you have received this message in error, please
>>>> notify the sender immediately by return e-mail and delete the
>>>> message and any attachments.  Thank you.
>>>>
>>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>>>
>>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to