Export (0) Print
Expand All

Migrating Applications to a Managed Environment

Updated: March 28, 2003

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

When you decide to migrate your users and computers from an unmanaged environment to a managed environment, you must also choose a method to migrate your unmanaged applications. Figure 8.6 shows this phase in the Group Policy-based application-deployment process.

Figure 8.6   Migrating Applications Stage of Deployment

Migrating Applications Stage of Deployment

The two most common methods of migration are the following:

  • Deploy applications to Windows NT 4.0 for transition to a managed Windows Server 2003 environment. Use this method if you are using a version of Windows that is earlier than Windows 2000.

  • Use RIS to deploy software, and use the software installation extension of Group Policy to manage it. Use this method if you run Windows 2000 Server or Windows Server 2003. This method is recommended for deploying the operating system and standard applications to a large group of users or computers.

In either case, you can use the software installation extension of Group Policy to manage your applications.

Deploying Applications for Transition to a Managed Windows Server 2003 Environment

If you have plans to migrate to Windows Server 2003, you can deploy applications in a Windows NT 4.0 environment now, and then migrate to the Group Policy–based, managed Windows Server 2003 environment later. By planning ahead for a migration from Windows NT 4.0 to Windows 2000 Server or Windows Server 2003, you do not have to remove and reinstall applications later.

Planning for Future Migration Example

A software administrator at an organization wants to deploy Office 2000 in a Windows NT 4.0 environment. Management wants to deploy the Windows 2000 Server or Windows Server 2003 operating system, and then use Group Policy to manage Office 2000. With that in mind, the administrator anticipates moving computers that have the unmanaged Office 2000 to the managed environment. This is to make sure that the administrator will not have to remove and then reinstall Office 2000.

Use a Windows Installer package, a transform (if you must have one) for the package, and a software distribution point that is exactly the same as the Windows Installer package and transform combination that you plan to use when it is managed.

You can create the software distribution points now for use after you successfully transition to the new software.

To make sure that the future transition is successful

  1. Create the software distribution points, and then install one or more Windows Installer package and transforms in the same shared folder.

  2. Install the software by using the Windows Installer with the following parameters:

    \>msiexec /I \\servername\share\<software.msi> TRANSFORMS = \\servername\share\<software.mst> /qb
    
    

In this example, Software.msi is the Windows Installer package that you are installing, and Software.mst is the transform that you want applied at deployment time.

After Windows 2000 Server or Windows Server 2003 is in place, including the Active Directory and Group Policy infrastructure, you can perform the following tasks:

  1. Assign the software in the appropriate GPO, using the same software distribution point, Windows Installer package, and transform.

  2. Move the computer object into an Active Directory container with the associated GPO, or link the GPO to the Active Directory container with the computer object.

Important

  • Use the original Windows Installer package, the same transform, and the same software distribution point and shared folder when you redeploy the application in the managed environment. In this case, the software will not be removed and then reinstalled. Instead, the software installation extension of Group Policy detects that the software is the same and does only what is necessary to continue to manage the software in the new environment.

Using RIS to Deploy Software and Group Policy to Manage Applications

You can use RIS to deploy the operating systems and specific applications to client computers, and then use the software installation extension of Group Policy to manage the applications.

When an organization first acquires new computers, IT administrators spend a lot of time preparing them for the users. Many highly managed organizations format the hard drives of new computers to configuring them to their organization’s standard configuration.

To save time, you can use RIS to create a customized image of a Windows XP Professional desktop on a source computer. Then you can save that desktop image to the RIS server. That image can include only the operating system, or it can be a preconfigured desktop image that includes the operating system and standard locally-installed desktop applications. You can use that preconfigured image to set up multiple desktops. You can create as many desktop images as required to meet the needs of all types of users in your organization.

You can rapidly and efficiently deploy the operating system and standard applications by using RIS, and then bring the software into a state where you can manage it by using the software installation extension of Group Policy.

For more information about using RIS to deploy software, see "Designing RIS Installations" in Automating and Customizing Installations.

Migrating Software to a Managed Environment Example

An organization continuously acquires new computers for new users and to replace old computers. The administrator saves valuable time by installing and customizing the operating system and standard software, which in this case includes Office XP. The administrator uses RIS to deploy the software, and then uses Group Policy to manage the applications after deployment. To accomplish this, the administrator performed the following tasks:

  1. Set up and configures a RIS server.

  2. Created a RIPrep image.

  3. Used the Group Policy snap-in to create a GPO to manage the computers that are associated with the RIPrep image. Because this is an effort to standardize all desktops in the organization, this GPO applies to all computers in the organization.

  4. Placed and sets up a software distribution point file server for Office XP.

    Note

    • Office XP includes a native Windows Installer package (.msi). Therefore, the administrator did not have to obtain a package for this application.

  5. Used the Custom Installation wizard (in Office XP) to customize Office XP based on the users’ needs. This produced a transform.

  6. Used Group Policy–based software deployment to assign Office XP to the computers in the organization-wide GPO.

  7. Installed Windows XP Professional on a new source computer, and then configured the operating system. The source computer does not need to have the same hardware, but it must use the same Hardware Abstraction Layer (HAL) as the computers that the image is installed on.

  8. Added the computer to the Active Directory container where it remains when it is deployed. This container holds the GPO that has Office XP assigned to the computer associated with it.

  9. Restarted the source computer. When the computer restarted, the software that the administrator assigned to the computer (by using the software installation extension) installed.

After installing the software on the RIS server, the administrator used the RIPrep tool of RIS to build a desktop image of the source computer that has Windows XP Professional and Office XP installed, and then put this image on the RIS server.

When the image becomes available, a user who receives a new, PXE-enabled, client computer that supports the RIS server only has to connect to the network (connect a cable from the network card to the hub), connect the keyboard, the mouse, and the monitor, and turn on the computer.

The client computer locates the RIS server, and then downloads the Windows XP Professional operating system and Office XP. When the computer restarts after installing Windows XP Professional remotely, Windows Installer determines that Office XP is already installed on the computer, and then updates only the advertisement information. The advertisement update takes only a few seconds.

The user logs on to the computer, and then selects the first Office XP application. This causes Windows Installer to start. Although Office XP is already installed, Windows Installer properly separates the installation from the user configuration. To complete the small amount of configuration that is required for each user, Windows Installer starts each time a new user starts Office XP. This happens in Office XP regardless of whether Office XP is assigned to the user, assigned to the computer, published for the user, or installed by using of RIS.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft