Application Considerations When Upgrading to Windows Server 2008

Applies To: Windows Server 2008

This document contains the information that you need if you have line-of-business (LOB) or non-Microsoft® applications and you are upgrading to the Windows Server® 2008 operating system. If you do not take the precautions outlined in this document, your upgrade may be blocked or your applications may not work after the upgrade.

This document discusses how the upgrade process manages data that is not part of the operating system when you are upgrading servers to Windows Server 2008. It is intended for companies and third-party independent software vendors (ISVs) who are upgrading their servers and who are using LOB or non-Microsoft applications.

You may experience problems with these applications during the upgrade process. While the upgrade process handles data that is part of the operating system, the registry and some file locations are recreated. Data found in these recreated directories that is not part of the operating system is saved to a temporary storage directory.

Note

The upgrade engine creates log files that contain a complete record of the actions that the engine performed and any errors it encountered during the installation phase. To view these logs, see the Setupact.log and Setuperr.log files in C:\Windows\Panther. For a complete list of log files generated during all the phases of setup, see article 927521 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=162887).

In This Document

  • Changes in How the Server Is Upgraded

    • Upgrade Process

    • Application Compatibility Checks

  • What to Do Before You Upgrade

    • Check the Temporary Storage Directory for Missing Files

    • Ensure That Directory Junctions Are Working for Your Application

    • Ensure That All x64 Kernel-Mode Software Is Signed

Changes in How the Server Is Upgraded

Upgrading to Windows Vista® and Windows Server 2008 is more complex than upgrading to previous versions of Windows Server. In previous versions of Windows Server, the older operating system state persisted after the upgrade. In other words, the operating system kept all settings when it was upgraded, including user settings, file settings, registry keys, and so on. The upgrade engine left behind data files and settings, while placing new executable files and data files on the computer. The data files and settings were then converted, if necessary, leaving the previous state information untouched.

In Windows Server 2008, however, the upgrade engine completely redesigns the preexisting operating system state into the Windows Server 2008 format. The upgrade engine does the following:

  • Installs the new operating system side-by-side with the older operating system, enabling you to roll back to the older system if there is a problem.

  • Parses the older operating system for data and settings that it recognizes (including executable files, settings, operating system entries in the Windows registry, and operating system data files) and converts it into the correct format for Windows Server 2008.

    The upgrade engine places any files not listed in upgrade manifests or in locations that conflict with the new operating system in a temporary storage directory. You can check this directory for missing application files after the upgrade is completed. For more information, see the section Check the Temporary Storage Directory for Missing Files.

  • Deletes the old operating system.

  • Migrates the newly formatted data and settings into a clean installation of the new operating system.

Microsoft has authored upgrade manifests to control how components and server roles within the operating system are migrated to the new installation. Upgrade manifests are metadata that control how to transfer the settings and data files into their new locations. Non-operating-system entries in the registry are carried forward and merged with the new registry.

The upgrade process parses the following information when determining what to migrate to the new operating system:

  • Operating system state — that is, any changes made to the operating system's default settings, such as the desktop background, screen resolution, enabled or disabled features or services, and so on

  • Applications

  • User data (all data located in the C:\Users\<username> directory)

  • Drivers

  • Operating system binary files

Upgrade Process

Upgrading to Windows Server 2008 consists of three phases, as described in the following table.

Phase Description

Collection

The upgrade engine collects information from the source operating system, including user data, registry keys, and application data.

Installation

The upgrade engine performs a clean installation from within the Windows preinstallation environment (Windows PE) of the Windows Server 2008 image to the hard disk.

Application

The upgrade engine applies the information collected in the collection phase to the new operating system.

The following steps describe the upgrade process in detail.

  1. To begin the Collection phase, the upgrade engine performs the following actions on the source operating system:

    1. Copies Setup binary files to the local hard disk.

    2. Dynamic update checks the Web for updated setup files and updates to the compatibility database, which holds information about compatible applications.

    3. Ensures that an upgrade is supported for the source operating system.

    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.

    5. Dynamic update checks for updated system components and drivers.

    6. Extracts the Windows binary files from the image file to the local hard disk.

    7. Identifies system data, including the 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 Windows PE setup files to the local hard disk, which starts the Installation phase.

    9. Restarts the server.

  2. The upgrade engine performs the following actions from within Windows PE:

    1. Boots the server into Windows PE.

    2. Moves files marked for gathering (in step 1g) to a temporary storage directory.

    3. Moves operating system binaries from the source operating system into the temporary storage directory (specified in step 2-B).

    4. Collects security identifier (SID) and local account data.

    5. Installs a language-neutral version of the operating system.

    6. Installs a language-specific Multilingual User Interface (MUI) package.

    7. Installs any optional components that are needed for parity with the source operating system.

    8. Configures access control lists (ACLs).

    9. Installs any updates collected by dynamic update (in step 1e).

    10. Applies SIDs, the computer name, and local accounts to the server, which starts the Application phase.

  3. The upgrade engine enters the specialization phase, during which it customizes the standard Windows installation with the following steps:

    1. Installs Plug and Play drivers.

    2. Creates user profiles for the user accounts on the source computer.

    3. Applies the operating system state.

  4. The upgrade engine migrates data from the temporary storage directory to the new installation, performing the following steps:

    1. Applies the operating system state captured by the upgrade manifests (see step 1g.)

    2. Applies settings from the unattend file (if an unattend file was provided to Setup).

    3. Deletes files from the temporary storage directory that were from the source operating system.

    4. Restarts the server.

Application Compatibility Checks

When you initiate an upgrade, the upgrade engine performs compatibility checks on the computer to verify that all of the applications installed on the computer can be upgraded. The upgrade engine uses the same logic employed in Windows Vista®; that is, applications that would block a Windows Vista upgrade will also block a Windows Server 2008 upgrade.

If there are problems identified during the compatibility checks, the compatibility report will notify you about what you need to do before you upgrade. The report includes a link to a Web site that outlines the status of applications that you may have installed. The report does not block the upgrade; it merely recommends actions to be performed before upgrading.

Note, however, that because the report uses a database that is also used by Windows Vista, it does not contain information about many of the applications that are typically installed on servers. For this reason, it is imperative that you take precautions to make sure that your applications will function correctly after the upgrade.

What to Do Before You Upgrade

You should be aware of the Windows Server 2008 upgrade process changes discussed in this section. Because these changes may require you to make changes to your applications before upgrading, it is imperative that you thoroughly test all of your upgrade scenarios.

Check the Temporary Storage Directory for Missing Files

It is possible that files that your application uses will be moved or deleted during the upgrade. For example, a file your application uses may be dependent on a Windows system file. If the Windows system file is deleted, then the file your application uses will be moved. For this reason, if you discover during testing that your applications do not work after the upgrade, you should check the temporary storage location (%SystemDrive%\$WINDOWS.~Q\Data) for missing files and then develop tools to fix the applications. The rest of this section discusses how and why the upgrade engine moves files to this location.

During the collection phase, the upgrade engine scans all system folders that will be recreated in the Windows Server 2008 installation. When the upgrade engine starts in Windows PE, it moves the following file types into a temporary storage directory:

  • Files that are not listed in the upgrade manifests

  • Files in locations that conflict with the new operating system (for example, %SystemRoot% and %ProgramFiles%)

    These files remain in this directory throughout the upgrade, so they can be restored if the upgrade is unsuccessful and the operating system is rolled back.

    In addition to making a rollback possible, the temporary storage also serves as a safety net by preventing permanent data loss of any files gathered by the upgrade engine. When the upgrade is complete and the rollback has been disabled, the upgrade engine deletes files in the temporary storage directory if it determines that they were from the source operating system. However, any user data files in the temporary storage directory will not be deleted.

  • As a result, any files that an application cannot locate after the upgrade process may have been moved to the temporary storage directory. This is particularly true if the files were installed in common system locations. The structure of the temporary directory (%SystemDrive%\$WINDOWS.~Q) mirrors that of the source operating system, under the Data subfolder. For example, user profiles are stored at %SystemDrive%\$WINDOWS.~Q\Data\users\<username>.

Ensure That Directory Junctions Are Working for Your Application

Some aspects of the folder hierarchy in Windows Server 2008 differ from the hierarchy in previous Windows operating systems. These differences have been mitigated by directory junctions, which are hidden redirectors that translate requests for the old folders to the new location. This process is typically seamless for applications that rely on the old paths, but you should run tests to verify that anything currently behind a hidden redirector is correctly accessed by your applications.

The specific changes in folder structure in Windows Server 2008 are as follows:

  • Windows Shell. The paths for many standard Windows folders have changed. For example, the path for the My Documents folder in Windows Server 2003 is: C:\Documents and Settings\username\My Documents. The path for the same folder in Windows Server 2008 is: C:\users\username\Documents.

    The upgrade engine determines the new folder structure by querying the system for constant special item ID lists (CSIDLs). CSIDLs are a system-independent method for checking a special folder's location. Although CSIDLs have been supplanted in Windows Server 2008 by KNOWNFOLDERID, they are still used when upgrading from an earlier operating system.

    The constants are defined in knownfolders.h. For a complete list of KNOWNFOLDERIDs and their CSIDL equivalents, see KNOWNFOLDERID (https://go.microsoft.com/fwlink/?LinkId=109818).

  • English folder names for non-English versions of Windows. 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. For example: C:\Program Files.

    If the source operating system is not English, the upgrade engine will write directory junctions to remap the English namespace. For example, assume that you are upgrading a German operating system that points to C:\Dokumente und Einstellungen\<username>\Eigene Dateien. In Windows Server 2008, an equivalent folder is created at C:\users\<username>\documents. Consequently, a directory junction will redirect any requests for the original folder. For English and non-English operating systems, then, the junction will have the same target folder; note, however, that the source folder may differ.

In most cases that we have encountered, the directory junctions correctly redirect calls to the new locations, but again, you should verify that this is the case for your applications.

Note that the upgrade engine will 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.

Ensure That All x64 Kernel-Mode Software Is Signed

Previous x64 versions of Windows Server did not require drivers to be signed. However, in the x64 version of Windows Server 2008, all kernel-mode software (including drivers and a number of low-level viruses) that runs on the computer must have a signature. The operating system references these signatures each time it starts, and any unsigned pieces of software are not loaded by the operating system. This prevents unknown kernel-mode software — such as a virus — from compromising a computer. However, this also means that if your applications use unsigned kernel-mode software (which is common in many firewall and antivirus programs), the upgrade may be blocked until you uninstall the application. And, if an application does not uninstall cleanly, it may continue to block the upgrade. This section describes the additional steps that the upgrade engine takes, and what you need to do to work around this issue.

In addition to the actions involved in the initial phase of an upgrade to Windows Server 2008 (described in step 1 in the numbered list under Upgrade Process, the upgrade engine performs the following actions on x64 based computers:

  1. Copies the applicable signed drivers from the installation media to the local hard disk.

  2. Downloads a list of available signed x64 drivers that are not on the media. (The actual driver packages are not yet downloaded.)

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

  4. Displays any unsigned kernel-mode software that was found in the compatibility report. If the upgrade is blocked, you can provide signed drivers to the upgrade engine to proceed with the installation.

  5. Downloads any driver packages identified in step 2 in this list.

  6. Gathers any valid driver packages in the source operating system for installation during the specialization phase, which is described in step 3 in the numbered list under Upgrade Process. A valid package is one that has been signed, or one that is unsigned but has a valid signature in the operating system catalog file.

Because of how upgrades work with x64, kernel-mode application drivers are a risk for software developers. Kernel-mode application drivers are used by many firewall, file system, and copy protection applications, as well as by antivirus programs. These drivers will typically block the upgrade until the application using them is uninstalled. If an application is not uninstalled cleanly, it may continue to block the upgrade.

You should distribute a version of non-Plug-and-Play drivers in which the signature is embedded in a local catalog file rather than in an external catalog file. Boot start drivers must be signed using this embedded method. Note that Plug and Play functionality does not recognize embedded signed drivers, which are new in Windows Server 2008. For details on how to sign drivers for Windows Server 2008, see Driver Signing Requirements for Windows (https://go.microsoft.com/fwlink/?LinkId=109848).