Application Considerations When Upgrading to Windows Server 2008

  • Article

So how do servers upgrade themselves to Windows Server 2008, and how does data, that is not part of the operating system get handled?

One of the interesting point to note is that in Windows Server 2008 the data that is part of the operating system, the registry and certain file locations are recreated during the upgrade. Secondly data that is not part of the operating system that is found in certain directories is quarantined. Details at the bottom.

I recommend that you make a clean install of Windows Server 2008, so that you have a good reference point and then go through you system testing from there. While the upgrade process has become more consistent with Windows Server 2008, there are still small paths that the migration could take which could make your OS install unique, and give you no reference point for testing ( which is what all ITPROs really do not want ).

The details below comes from a few white papers on the subject which I think will be interesting for those special cases when you need to do the upgrade.

......

 

Changes When Upgrading to Windows Server 2008

Upgrading to Windows Vista and Windows Server 2008 is more complex than in previous versions of the operating system. Instead of just installing new versions of binaries over those of an existing computer, the new operating system is installed side-by-side with the older operating system. Then the data and settings are migrated from the older version to the newer version, and then the source is deleted. While this is architecturally more correct and certainly build a clean OS install, this does cause some obvious complications that you should be aware of.  Secondly in Windows Server 2008 the upgrade process is destructive to the pre-existing operating system state.

The upgrade engine removes all previous data from the operating system (including executable files, settings, the Windows registry, and operating system data files) and creates an entirely new Windows installation. For components and server roles within the operating system, there are upgrade manifests which control the process. The upgrade manifests have metadata for each component that details how to transfer the settings and data files into their new locations. Non-operating system entries in the registry are persisted forward and merged with the new registry in the destination install.

Upgrade Process

Here are roughly the steps the operating systems goes through

  1. Copies Setup sources to the local hard drive.
  2. Dynamic update runs to check for updated setup files and compatibility database updates.
  3. Checks to ensure that the source operating system is supported for an upgrade.
  4. Presents the compatibility report to the user. The report provides details about any applications that must be uninstalled or that may cause problems after upgrading. The report also recommends backing up the server before continuing.
  5. Dynamic update runs to check for updated system components and drivers.
  6. Unpacks the image file to the local hard drive.
  7. Identifies system data including operating system state, user files, and drivers. The operating system state is identified based on upgrade manifests that are authored by Microsoft.
  8. Extracts the WinPE boot files to the local drive.
  9. Restarts the server.

The upgrade engine performs the following actions from within WinPE:

  1. The server boots into WinPE
  2. Files marked for gathering are moved to an in-place transport directory.
  3. Moves operating system binaries from the source operating system into quarantine.
  4. Collects SID and local account data.
  5. Installs a language-neutral version of the operating system.
  6. Installs a language-specific MUI package.
  7. Installs any optional components that are needed for parity with the source operating system.
  8. Configures access control lists.
  9. Installs any updates collected by dynamic update.
  10. Apply SIDs, computer name, and local accounts to the server.

Specialization phase

  1. Installs Plug and Play drivers.
  2. Creates user profiles for the user accounts on the source computer.
  3. Applies machine-specific operating system state.
  4. The upgrade engine migrates data to the new installation including the following:
  5. Applies the operating system state that was captured by the upgrade manifests
  6. Applies settings from the unattend file (if an unattend file was provided to Setup).
  7. Deletes files from the quarantine directory that were from the source operating system.

Restarts the server.

Application Compatibility Checks

Because upgrading to Windows Server 2008 may cause problems for certain applications, a message is presented to all users through the compatibility report that is shown after you initiate the upgrade. If necessary, the report will recommend the appropriate action before upgrading. To verify software compatibility on the Windows Server Catalog and to download tools and documentation, go to https://go.microsoft.com/fwlink/?LinkID=85172.

If software isn’t supported on Windows Server 2008, or if the software vendor does not support software that is installed during the upgrade of the operating system, uninstall that software before you upgrade. If you do not uninstall the software, your system will be unsupported, the software might not work, and software settings or other information might be lost.

There are several different types of upgrade blocks within the compatibility report. The database used to identify applications to block is shared with Windows Vista and does not generally cover server applications.

The types of blocks that you may see are:

  • Upgrade hard block: These blocks prevent the upgrade from continuing until the issue causing the block is resolved, which may be a bad driver, incompatible source operating system or known bad applications (malware, for example). Users can not circumvent a hard block.
  • Upgrade soft block: These blocks recommend against upgrading without taking preventative measures or validating that a software vendor has provided an upgraded version for the new operating system. Users can choose to continue past a soft block, because there is no known risk of upgrade failing with the application installed.
  • Program Compatibility Assistant hard block: The Program Compatibility Assistant is a runtime mechanism which can prevent applications from running on the system. The process is prevented from loading, and the user can not circumvent the block.
  • Program Compatibility Assistant soft block: The Program Compatibility Assistant can also provide a soft block which advises the user that the application may not run successfully without being updated. Users can still choose to run the application and continue with the upgrade.

Changes that May Impact Your Applications

Because of the differences in the upgrade process in Windows Server 2008, it is possible that pre-existing applications will not be authored in such a way that they function predictably post-upgrade. Most will just work, but there are specific changes that application developers should be aware of, and which may necessitate testing or patching.

The Quarantine Directory

During the collection phase, the upgrade engine goes through all system folders that need to be recreated in the new operating system. When booted into WinPE, the upgrade engine moves files into the quarantine directory that 1) are not listed in upgrade manifests and 2) are located in places that conflict with the new operating system (for example, %SystemRoot% and %ProgramFiles%). These files remain in this directory throughout the upgrade, so that they can be restored in case of a rollback.

However, in addition to making a rollback possible, the quarantine also serves as a safety net. It prevents permanent data loss of any files that have been gathered by the upgrade engine. When the upgrade is complete and the rollback has been disabled, the quarantine is purged -- that is, files are deleted from quarantine if the upgrade engine determines that they were from the source operating system (user data files in the quarantine directory will not be deleted).

Consequently, if an application is unable to find particular files, they may have been moved to the quarantine directory during the upgrade process. The structure of the quarantine folder (%SystemDrive%\$WINDOWS.~Q) mirrors that of the source operating system, beneath a subfolder called “Data”. For example, user profiles are stored at %SystemDrive%\$WINDOWS.~Q\Data\users\<username>. Application developers should expect that files installed to common system locations may end up in the quarantine directory after the upgrade.

Folder Hierarchy and Names

Windows Server 2008 has a different default folder hierarchy than any of the previous operating systems that you can upgrade. Specifically, note the following two changes:

  • Windows Shell. Many of the standard Windows folders are now under different paths. For example, the path for My Documents in Windows Server 2003 is C:\Documents and Settings\username\My Documents while the path for the same folder in Windows Server 2008 C:\users\username\Documents. The new folder structure is determined by querying the system for constant special item ID lists (CSIDLs). CSIDLs are a system-independent way of checking where a special folder is located. CSIDLs have been supplanted in Windows Server 2008 by KNOWNFOLDERID, but are still used when upgrading from a previous operating system.
  • English folder names. Non-English versions of Windows Server 2003 sometimes contain folders with CSIDLs that have localized folder names. In Windows Server 2008, the same language installation will now have English language folder names.

These changes are mitigated by directory junctions. Directory junctions are hidden redirectors that translate requests for the old system folders to the new directory structure. This process is typically seamless to applications that rely on the old paths, but you should test this to ensure the hidden directors work for your application.

If the source operating system is not English, directory junctions will be written to remap the English namespace. For example, a German operating system which once pointed to C:\Dokumente und Einstellungen\<username>\Eigene Dateien will now utilize an equivalent folder in Windows Server 2008 found at C:\users\<username>\documents. Consequently, a directory junction will redirect any requests for the original folder. So, in English and non-English computers, the junction will have the same target folder, but the source folder may be different.

The upgrade engine will also write additional directory junctions in some situations. For example, if a user upgraded to Windows Server 2003 from Windows Server 2000, the operating system folder may be called \WinNT, so calls to \WinNT would be redirected to the correct system folder in the new installation.

Unsigned Software in x64

In the x64 version of Windows Server 2008, any kernel-mode software (for example, drivers) that runs on the computer must have a signature, which is referenced each time the operating system is started. If a piece of software is not signed, it will not be loaded. This prevents unknown kernel-mode software, such as many low-level viruses, from compromising a computer.

Previous x64 versions of Windows Server did not require signed drivers, which creates a challenge when upgrading to Windows Server 2008. Because security is a primary concern, the upgrade process for the x64 version of Windows Server 2008 contains additional steps and considerations . The upgrade engine performs the following actions in addition to those in the initial phase (Step 1 in the Detailed process section):

1. Copies any necessary in-box signed drivers to the local hard drive.

2. Dynamic Update downloads a list of available signed x64 drivers that are not available in-box. The actual driver packages are not yet downloaded.

3. Scans kernel-mode software on the source operating system to determine whether each is signed. Unsigned drivers are compared against a local catalog file to see if Windows Server 2008 contains a signature that can be used to validate the driver.

4. If unsigned kernel-mode software are found, they are displayed in the compatibility report. The upgrade may be blocked, but you can provide signed drivers to the setup engine at this time.

5. Downloads any driver packages (which were identified in Step 2)

6. Gathers any valid driver packages in the source operating system for installation during the specialization phase (Step 3 in the Detailed process section). Valid packages are any that have either been signed or are unsigned but have a valid signature in the operating system catalog file.

Because of how upgrade works with x64, one risk for software developers is the disabling of kernel-mode application drivers, as used by many firewall, file system, antivirus and copy protection vendors. These drivers will typically block the upgrade until the application is uninstalled. If an application does not uninstall cleanly, it may continue to block Setup. For drivers that are not Plug and Play, vendors should distribute a version of the driver where the signature is embedded in a file rather than in an external catalog file. Boot start drivers must be signed using this embedded method. Plug and Play does not recognize embedded signed drivers, which are new in Windows Server 2008. For details on how to sign drivers for Windows Server 2008, or to see what drivers have passed the certification, go here.