Since I’m the newbie in the Deployment Guys, I thought I’d take a step back to Windows Vista to discuss an issue that is not strictly deployment, but affects a deployment, and the steady state of an environment.
I should also add that most of the investigative work was done by one of my clients – I just validated their findings, and we’ve had a successful outcome for them and all of you. So here’s another real example of how we collaborate with our customers to improve everyone’s experience.
Early in the design, the team chose to use driver hosting (see TechNet for how to do this) to provide a central location for devices that were connected by users. This was introduced in Windows Vista, and persists in Windows 7. When a device is plugged in, the system checks the driver hosting path, and enumerates the share to find an appropriate driver without prompting the user for a driver or elevation (unless the driver is not inbox or in the hosting location).
Now consider what happens if you are constantly plugging in a new device? Vista obeys accordingly, and enumerates the location each time. That’s perhaps acceptable if you have only 2 or 3 small drivers, or you have a high speed LAN. But if you are hosting hundreds of megabytes of drivers or traversing a WAN link… you see the problem? The network guys are all over you for messing with their top-talker list!
It turns out that there was a scenario where this occurred for this customer, and can for you as well. A single device was causing this behaviour!
Windows Vista (and later) all have IPv6 enabled by default. However, in Windows Vista/Server 2008 (SP2 or earlier) the IPv6 adapter is reinstalled in some scenarios. Combined with driver hosting, Windows Vista will enumerate the remote driver store each time this occurs. So now you have the network guys complaining that Windows Vista systems are utilising the network excessively.
Depending on when this scenario occurs, the system may:
1. Generate excessive network traffic;
2. Exhibit reduced performance while the device is installed;
3. Have a longer than expected boot or resume time.
So this was recognised, and Microsoft has published a fix that can be found at: http://support.microsoft.com/kb/960670. There is a workaround document in the article as well which is to disable IPv6 adapter if they are not used. But, before you consider disabling IPv6, it is worth reading The Cable Guy’s note.
Happy investigating if it affects your deployment or planned deployment. Network packets never lie – they are just mis-interpreted 🙂
For those of you deploying Windows 7 or Server 2008 R2 – rest easy! We found this sufficiently early that the fix was integrated into these products prior to RTM.
This post was contributed by Samesh Singh a Principal Consultant with Microsoft Services, Australia.