As part of your Windows® installation process, you will likely be installing additional applications and device drivers during Windows Setup. The following sections detail some of the methods that we recommend for preinstalling applications.

Note:

For more information about installing device drivers, see Understanding Device Drivers and Deployment.

Recommendations for Preinstalling Applications

The following sections include recommendations and guidelines for preinstalling applications, based on your organization's size and classification.

General Preinstallation Considerations

Review the following considerations before determining when and how you intend to install applications during an unattended installation.

  • You should not preinstall your applications by using the RunSynchronous setting in the specialize configuration pass, as not all services are running during that phase of Windows Setup.

  • Ensure that all application prerequisites are met. For example, many applications require the latest version of the .NET framework.

  • Many application installation technologies include a “silent” option. A silent installation does not prompt a user-interface page during installation. This makes it ideal for scripted, automated, installations. In addition, some installation technologies provide macros that can automate some of the user-interface prompts during installation.

    Note:

    If the application cannot be silently installed, you should talk to the application's vendor. In some cases, the vendor might have two versions of an application, one that is intended for the public, and another that is intended for the OEMs, which can be installed silently.

  • Applications should be written to the default user profile during the preinstallation process, due to the potential for severe issues. One such issue is overwriting the profile information, which can occur if the installation writes to a specific user profile. If you intend to install an application during the auditUser configuration pass, you should use the CopyProfile commands to replicate your changes to the default user profile.

    Note:

    For more information about CopyProfile commands, see the CopyProfile topic, located in the Unattended Windows Setup reference topic.

  • Applications must not store Windows Installer files (.msi) in any of the %TEMP% locations of the downlevel operating system. Any Windows installer files that are stored in the %TEMP% directory, such as in the C:\Users\<USERNAME>\AppData\Local\Temp\ directory, will not be migrated during the operating system upgrade process, and might cause the application to no longer work, or to provide a suboptimal user experience. Instead, we recommend that you store your .msi files in a location under the %SystemDrive% directory, such as in the C:\OEM\My_MSI folder.

    Note:

    For more information about best practices for Windows Installer files, see the Windows Installer Best Practices topic on MSDN. For more information about source resiliency and policy, see the Source Resiliency topic on MSDN.

  • If an application requires changes to the Boot Configuration Data (BCD) file, it must occur after running Sysprep, during the first boot process. Sysprep automatically removes customizations made to the BCD file. Therefore, any modifications you make will be undone prior to running Sysprep during the first boot process.

  • If you intend to run the Sysprep command-line tool with the /generalize option to create a reference Windows image, you must test your applications after running sysprep /generalize. You must verify that no changes occurred during the generalize process that would affect your applications. For example, verify that the drive lettering did not change, because this could affect an application that relies on a specific volume or drive to function.

    Important:

    The generalize configuration pass removes system-specific information, which includes the unique security ID (SID) and other hardware-specific settings, from the image. In some cases, the generalize configuration pass can cause a preinstalled application to behave unexpectedly. For example, if you preinstall an application that grants its license to the system volume, and then you copy that image by using a file-based program (such as ImageX), the license might be removed. This would result in the application not functioning properly because creating a new system volume by copying an image would overwrite the original license.

Preinstallation Recommendations for OEMs and System Builders

Depending on your manufacturing environment, you can preinstall applications in one of two ways:

  • Install applications to the reference Windows image.

    In this scenario, you install your applications to the baseline Windows image, and then capture that image to use on all of the computers in your environment. By installing applications to the reference Windows image, you can ensure that all of your computers will include the application.

  • Install applications to the Windows image you intend to ship to a customer.

    In this scenario, you install your applications directly to a computer that will be shipped to a customer. This installation process enables you to customize a computer with the specific applications selected by a customer. You can also customize a computer for the specific computer model.

We recommend that OEMs and system builders preinstall applications in audit mode. In audit mode, you automatically log on as the built-in administrator account and have elevated user privileges. You can access a network, run scripts, configure applications to be installed by using the RunSynchronous commands in an answer file, and test the validity of the Windows installation. Audit mode does not require Windows Welcome settings to be applied, such as creating a user account or creating a computer name.

Note:

For more information about audit mode, see Customize Windows in Audit Mode. For more information about RunSynchronous commands, see the RunSynchronousCommand topic, located in the Unattended Windows Setup reference topic.

Preinstallation Recommendations for IT Professionals

We recommend that IT Professionals and enterprise organizations preinstall their applications while in audit mode, or after completing Windows Welcome. Completing Windows Welcome enables you to preconfigure the time-zone and language settings for your end users. Preinstalling your applications during audit mode requires an end user to configure the time-zone and language settings through the Windows Welcome process. You can continue to configure your computers by using additional deployment options, such as those available in the Microsoft Deployment Toolkit.

Important:

Preinstalling your applications while in audit mode enables you to more quickly reach the Windows desktop, install applications, and then prepare the computer for the end user. If the default values are not acceptable to your organization, you can modify the values after the installation completes, or by installing your applications after Windows Welcome.

Preinstallation Processes

There are several ways in which you can make applications available to be installed during an unattended installation:

  • In networked environments, you can create a distribution share. Distribution shares are Universal Naming Convention (UNC) paths that are located on a network drive, which can be accessed by a destination computer during Windows Setup. When you create your answer file, you must specify the UNC paths of the applications and drivers you want to install from the distribution share. The benefit of using a distribution share is that you can create a single location that includes the latest applications and driver versions. However, for this strategy to work, you must ensure that you have network connectivity with the destination computers and that you can potentially troubleshoot networking and authentication issues.

    Note:

    You can save hard drive space by not copying the source files of the application to the destination computer.

  • In non-networked environments, or in environments where you need only a subset of the content located on a distribution share, you can create a configuration set. A configuration set copies all of the applications and drivers referenced by a distribution share to media, such as a USB flash drive (UFD). The benefit of using a configuration set is that it is ideal for field offices, or locations that do not have access to a central server. However, you must verify that you have network-adapter driver support and you must review your application redistribution rights with the application vendor.

    Important:

    To verify that your network card is supported, you must boot into the Windows Preinstallation Environment (Windows PE), and then at the command prompt, type netcfg -v -s n to return a verbose list of the supported network cards.

  • Create a data .wim file that contains all of the applications, drivers, and other resources that you want to make available on the destination computer. During unattended installation, you can configure the data .wim file to be applied to the Windows installation. However, you must review your application redistribution rights with the application vendor.

Note:

For more information about distribution shares and configuration sets, see Understanding Distribution Shares and Configuration Sets. For more information about building your configuration sets or data images, see Build Configuration Sets or Data Images.

Creating and Using Sysprep Providers

Software and hardware developers, including a company’s internal developers, Independent Software Vendors (ISVs), and Independent Hardware Vendors (IHVs), can create Sysprep providers that enable their applications to support imaging and deployment scenarios. If an application does not currently support generalize operations via the Sysprep tool, you can create a provider that will remove all software-specific and hardware-specific information from the application.

To create a Sysprep provider, you must:

  1. Determine which configuration phase (Cleanup, Generalize, or Specialize) your Sysprep provider addresses.

  2. Create the appropriate entry point for your Sysprep provider, based on your choice of configuration phase.

  3. Register the Sysprep provider for use by the Sysprep tool.

  4. Test your Sysprep provider to validate that it functions properly, reviewing the log files for warnings and errors.

Note:

For more information about Sysprep providers, see the Sysprep Provider Developer’s Guide for Windows 7

Preinstalling Device Driver Application Packages

Not all device drivers are available as individual .inf files. Some driver packages are not available outside of an application installation. In addition, some devices might require additional application support required for end users. For example, many video drivers include custom applications that provide additional functionality and capability.

We recommend that you install driver applications during audit mode. This enables you to quickly boot to the desktop, install the driver application as a RunSynchronous command, and then test the functionality of the device.

Troubleshooting Application Preinstallation

Review the Windows Setup log files to determine which application did not install. The log files provide information about the status of Windows Setup and where errors might have occurred. For the location of the log files, see Windows Setup Installation Process. Many of the common problems when installing applications are due to network configuration issues. If you are installing applications from a network, ensure that you are providing the proper credentials to access the share and that Domain Name Services (DNS) is configured correctly.

Important:

To verify that your network card is supported, you must boot into Windows PE, and then at the command prompt, type netcfg -v -s n to return a verbose list of the supported network cards.

For local application installation from removable media, ensure that the drive letters specified in the answer file match the drive letter of the media. In some cases, the drive letters might differ from the reference computer to the destination computer.

See Also