re: Awesome feature with a catch

Monty Carter — Tue, 22 Dec 2009 00:58:17 GMT

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.