Freigeben über

Awesome feature with a catch

  • Artikel

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: https://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.

Samesh.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

This post was contributed by Samesh Singh a Principal Consultant with Microsoft Services, Australia.

Comments

  • Anonymous
    January 01, 2003
    Aside from the IPv6 issue, which looks to have a fix now, there are additional ways to minimize network traffic related to driver discovery/installation during day-to-day operational use (as opposed to actively deploying). Windows always checks the local driver store first, and only moves to a remote driver path if no driver is found locally. ( http://technet.microsoft.com/en-us/library/cc770927(WS.10).aspx ) By adding the most commonly used drivers in your environment to the local driver store during initial deployment, you can minimize the number of devices that will cause Windows to search the remote driver paths. For example, if you have 5 standard printers that satellite offices can choose from, you can add the drivers for all five printers to the local driver store at deployment time. For new models of devices that are added to the fleet after a workstation has been deployed, a package containing the new drivers, and a script to add them to the local driver store of each machine (or a subset of machines that are most likely to use the new device), can be pushed out using a management tool such as SCCM or Altiris, making the drivers locally available on those workstations.  The advantage here is that bandwidth throttling and download scheduling can be used to minimize WAN traffic during peak hours. WAN traffic associated with driver queries can also be minimized by using DFS.  This way, new drivers are replicated to each local server over the WAN only once, and queries from client machines at remote sites go to their local server with the driver queries. The ability to offer drivers from a network source is a great addition, however, may be best suited for centralized organizations, without many remote sites with slower WAN links.