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:
- Determine which configuration phase (Cleanup, Generalize, or
Specialize) your Sysprep provider addresses.
- Create the appropriate entry point for your Sysprep provider,
based on your choice of configuration phase.
- Register the Sysprep provider for use by the Sysprep tool.
- 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.