cluberti

Given that I had this problem on Vista with Creative drivers for the Audigy, and they went away after switching to the onboard realtek chip, I've got to imagine that this hotfix is meant to address bad drivers, and not a code problem (per se) in audiodg.exe. It's heavily prevalent with Creative drivers (and very old SoundMax drivers seemed to be bad at this too, at least in Vista while I was testing), it would seem.Also, given that redistributing Microsoft binaries is technically a violation of the EULA, you just need to open a support case from the link in the KB and get a support person to send you the binary. It will be a free case as it's about a hotfix, anyway.

Yes, the powershell script should also work on XP/2003 with powershell 1.0 installed.

Looks like the binary isn't available anymore (I now get a "you must call support" link instead of a hotfix request page). Odd, but maybe that's why you didn't get a mail.

If it really needs elevation, it might be worthwile manifesting the app as requireAdministrator so it runs elevated.

Any particular reason you aren't simply using a simple consumer-grade router with a switch?

The link from my previous post: http://blogs.technet.com/tmintner/archive/2006/07/07/440729.aspx

Does it repro in safe mode? I cannot get my XP VM to produce these results, so I'm wondering if something installed on your system (explorer file extension, video driver, etc) could be causing it...

Done.

You should get an email within 5 minutes of making the request (I got mine in about 60 seconds).

It would actually probably be more reliable outside the file - using slmgr as a task to run once the image is deployed.

As you said: "Note: A registry key does not exist to validate the presence of this update." Windows Vista and Win7 use CBS to install updates, hence information about updates are stored in the CBS database (you could read the CBS log if you want to try), or you could use WindowsUpdate.log in the %windir% to try and piecemeal it out. However, it's not just a simple list anymore, so using Powershell and COM objects are probably the easiest way to coax out update lists. There's a very basic set of commands here, but if you want something cleaner that should be pretty easy to do as well. Also note that Microsoft also created WMI Code Creator, which might be a bit easier to use than that tool once you know what you're doing at least with the WMI classes.

You missed my point - DCs go into a separate OU from the rest of the machines (by default), so making sure it's actually applying to that OU is a good start. This is one of the many reasons to use GPMC exclusively for creation and application of GPOs, rather than using the policies on servers or the DCs directly.

At what level in the AD tree did you apply the policy? If you look at it in GPMC, where is it being applied? You might want to link it directly to the domain controllers OU.

The problem with doing it that way, is that the page file will report usage of not just committed bytes, but anything reserved as well - even though there's no data in the page, the way the Windows memory manager works is that ALL pages that are committed OR reserved have to have a backing page somewhere (either in RAM or in the paging file, or in some cases, both!), just in case all apps on the system "cash in their chips" and want those reservations allocated. The task manager in Windows 7 is a little better about showing this, but not much. If you really want to see what your system is actually using and has committed (versus reporting committed + reserved + standby) you really need to use perfmon and look at the memory object's counters like available bytes, cache bytes, committed bytes, and page reads/sec (to determine how many memory faults are "hard" faults that require "faulting" from disk, aka reading into pages in RAM from the paging file). If you want to know what is being used by each process, you can look at each counter under the process object for memory (private bytes, virtual bytes, and the working set counters). In looking at your screenshot, it actually isn't clear if there is actual usage of 1.5GB of paging file, because we don't know if it's counting pages that have already been consumed, or are just reserved for future consumption. Also, your commit charge shows that 1.5GB of VA has been charged for use, but again that is because all memory allocations must have a physical page in memory backing either in RAM or in the paging file (if there's a paging file to back them, of course) and this is because the memory manager is designed such that all memory allocations, including simple reservations, MUST have somewhere to go at all times "just in case". If you were to actually break this out, it may actually be an overcommitted box, but again, it might not . At this point, using the task manager to determine an accurate memory count of a system is fairly useless - it is never granular enough to show you what you want to know (unless all you want to know is how many committed pages you have, and you don't care if they're actually allocated and thus used or not).

Well, run gpresult /z to see what's actually being applied, and perhaps use GPMC to do an RSOP to see what settings are actually being applied (and by which policy), and go from there.

There is a tool from one of our smods right here on MSFN for doing this sort of thing. Also, there are non-free tools like Driver Magician, and we have a whole section devoted to Device Drivers that you probably want to check out (read the "read-me first" sticky first, of course).

Both are correct - Win7 will only install drivers onto a system that are needed, either if you integrate them into the WIM or use a DriverPath and folder. It will treat drivers at either location just like it would any other inbox integrated driver - this is a change from Windows XP, where if you imaged a system with a driver installed it would be installed when you placed the image back on another machine in some instances.

VMs for testing until you re-test on hardware? Seems like this would be something that would be perfect for VM testing.

http://technet.microsoft.com/en-us/library/dd799258(WS.10).aspx http://technet.microsoft.com/en-us/library/dd744355(WS.10).aspx http://www.microsoft.com/downloads/details.aspx?familyid=886CD1DD-91AA-4BF4-8557-DECEDEF7FA5D&displaylang=en

http://technet.microsoft.com/en-us/library/cc749588(WS.10).aspx

Moved.

Not sure, but unless you're using WINS on your domain you probably should be using the FQDN anyway.

April fools?

I'm aware of the workaround, it's just that it exists in the first place (and wasn't fixed in 7, when it was an issue with Vista and reported). I guess the build labs must do it that way and it can't easily be changed.

I believe most (all?) of these options are under Organize > Layout.