So, I am off doing a desktop migration for a customer of approximately 5,000 desktops.
Unfortunately there are forces at work that will not allow us to do wipe-and-loads of desktops, like Microsoft recommends. So, me and Mike Vrabel from INS are having to work through an OS upgrade scenario. This causes us to upgrade a few corporate applications before we can upgrade the OS, because they just won’t work after the upgrade. Mike is primarily of storming the beach head of application remediation, while I work on unattend files and drivers.
I ran into some serious issues trying to upgrade drivers so that the NIC, Sound and Display would still work after an upgrade. Here were my approaches:
- Upgrade Drivers while still in Windows 2000 to the XP version. Since most drivers are compatible, this should work. WRONG – the closest I got was the “Windows has found new hardware” once the box was upgraded to XP. Since this needs to be completely scripted, this isn’t an option
- Use the Windows Unattend file to specify new drivers. I have used unattend files a million times before when building out big datacenters, so I have a really high level of confidence when it comes to unattend files. But, the upgrade scenario is different than a bare metal install or sysprep. It appears that Windows doesn’t care about the drivers I specify in the Unattend, and won’t even copy the ones I place in the \i386\$oem$\$1\drivers\yadayada folders. From what I can tell, these drivers are only copied during text mode (which does not occur in an upgrade), and it never looks in the unattend file for the drivers during an upgrade.
- Upgrade the drivers once the upgrade is done. Ya, but how do you do it from the command line without user interaction? Well, DEVCON is your friend. Devcon.exe is a command line version of Device Manager, and the latest version is included in the Windows Server 2003 Service Pack 1 Support Tools.
The thing I learned about devcon, thanks to Scott McArthur from Microsoft Support, is that when you specify a device to update, use the “base” id. If you run:
Devcon driverdetails * > drivers.txt
You will get a list of all devices with their associate drivers. The devices are very specific like:
There are other devices associated with this device, so if you try and update the specific device, it usually comes back with a “devcon failed”. You need to broaden the device path, and take the “base” device like this:
So the command that I end up running to update the drivers:
devcon updateni “C:\DRIVERS\Intel10.3\PRO1000\WS03XP2K\e1000325.inf” PCI\VEN_8086&DEV_100E
So hopefully this great little devcon tool will help you out, and make sure to be generic when specifying device drivers.