Windows 2000 to XP Upgrade Nuances
In the process of helping a customer upgrade their remaining 5,000 desktops from Windows 2000 to XP, I have found a couple entertaining and frustrating issues with the upgrade process.
First of all, this only applies to an unattended upgrade of Windows 2000 Professional but it might also affect servers as our internal bugs indicate. Second, Microsoft does not recommend that corporate desktop us the Upgrade process, rather we recommend “wipe and load”. But, in a customer scenario where you don’t have applications packaged and easily deployable to 5,000 users, upgrades are the way to go.
In our specific scenario, we are using various Dell desktops and laptops. Through testing, we discovered that two of the desktop models completely loose their NIC’s during the upgrade. So, we tried to upgrade the drivers for the NIC’s before the upgrade. No dice, once the OS is Windows XP the system has an error with the Network Adapter in Device Manager.
We then tried to use the Microsoft provided means to upgrade the drivers during Windows Installation in the unattended file (below).
[Unattended]
Oempreinstall=yes
OEMSkipWelcome=yes
This tells setup to look in the SourceFiles\i386\$oem$\ folder for drivers and copy them over during the install process.
The only problem is that we are using the UPGRADE flag in the unattended file that negates much of the settings. When you set NTUpgrade=Yes, Windows ignores most of the Unattend file. In fact, Microsoft officially only supports and tests the following flags when NTUpgrade=Yes:
Productkey =
AutoActivate =
DuDisable =
DuShare=
DuStopOnError=
This means that we can’t use any of the cool $oem$ functionality like upgrading the drivers or even running the $oem$\cmdlines.txt which would allow us to kick off a script before Windows logs in. The idea being that we could upgrade the drivers with a batch file before the user logs in. What a nightmare!
I did find that although Microsoft doesn’t support the entries, there are more settings that the unattended process will honor, these include:
[GuiRunOnce]
Command0="C:\upgrade\apf\CmdLines.cmd"
Command1="C:\upgrade\apf\PostOS.cmd 1"
[WindowsFirewall]
Profiles=WindowsFirewall.TurnOffFirewall
[WindowsFirewall.TurnOffFirewall]
Mode=0
So, how did I get around these challenges? I did a bunch of scripting before the upgrade and after the upgrade. Basically, here are the steps:
1) Download all the Windows XP source files and drivers to the workstation hard drive
2) Run a script that prepares the box for an upgrade
a. Disable Wired/Wireless NICS (see my blog on devcon on how to automate this)
b. Removes LegalNoticeText to ensure AutoAdmin logons
c. Resets Local administrator password
d. Sets AutoAdmin logon settings
3) Starts Windows Unattended Setup and uses local source files
4) After the OS is upgraded, it does a GUIRunOnce that I specified
Command0="C:\upgrade\apf\CmdLines.cmd"
Command1="C:\upgrade\apf\PostOS.cmd 1"
This kicks off a PostOS scripting engine call APF (automated purposing framework) that can be found as part of MSA 2.0.
5) The APF engine does the following
a. Phase 1 – HotFixes
b. Phase 2 – Dell Drivers
c. Phase 3 – Enable Dell NICS
d. Phase 4 – Update GPO’s
e. Phase 5 – Finish
i. Set RunOnce (sets user profile settings)
ii. Copies “Default User” profile
iii. Clears AutoAdminLogon Settings
iv. Deletes Source bits
f. Phase 6 – Reboot
6) Once a user logs in for the first time, we fire the RunOnce script that sets some corporate standard user experience settings
I guess the overall advice I can lay down for upgrades are, “This isn’t as easy as running winnt32.exe and then upgrading drivers”. This can be a very complex process to get right, especially when you want to do it for thousands of machines. Wipe and load is still the preferred mechanism, and there is good justification for getting your application packaging strategy working first before you tackle upgrading OS’s,