IntelliMirror makes short work of deploying updates and service packs

IntelliMirror can do more than just distribute applications; it can also distribute updates and service packs throughout your network. In this Daily Drill Down, we'll show you how IntelliMirror can simplify managing updates and service packs.

IntelliMirror allows you to deploy operating systems and applications automatically through a combination of technologies, including group policy. Not only can it help you initially install operating systems and applications, it can also help you deploy updates and service packs for those installations. This can be a big time-saver when you have to quickly apply the latest updates to a large number of workstations. In this Daily Drill Down, I’ll explore how IntelliMirror can simplify the process of upgrading applications and applying operating system updates.

Patching and updating applications
In many ways, change is good. Unfortunately, change in the IT world typically means more work for already overworked system and network administrators. When a new version of an application is released, you can experience some real headaches in deploying the new version if you’ve been relying on manual deployment methods. How do you make the new version available to users? How do you ensure that the users upgrade the appropriate application components? How do you handle situations in which the users have different versions of applications?

IntelliMirror answers all of these questions for you by automating the update process and allowing you to define how existing applications and components are handled during the upgrade. Best of all, you can apply the upgrades to specific groups of users or across the entire organization as needed, giving you a precise degree of control over the upgrade process. Best of all, it isn’t necessary that you have previously used IntelliMirror to install the application. For example, assume you deployed Office 2000 manually and now you want to upgrade the enterprise to Office XP. As long as your clients are running Windows 2000, you can use IntelliMirror to deploy the upgrade automatically.

The only real difference between deploying patches and updating applications through IntelliMirror is in how you deploy the application. You can assign an application, which causes it to be installed automatically when the user logs on. The other option is to publish the application, which makes it available through the Add/Remove Programs object but does not automatically install it. Instead, the user can choose to install the application at his or her convenience.

In most cases, you’ll probably want to assign patches to ensure that they are applied for all users who use the application. Application updates are a different story, however. Although you can certainly assign the updates to ensure that all users’ applications are updated, often a better option is to publish the updates to give users flexibility in when and how to perform an upgrade. For example, certain users won’t be able to upgrade right away because they have requirements for a specific version of an application. Publish the upgrade rather than assign it and give users the option of upgrading specific components rather than performing a wholesale upgrade to ensure that users have the control they need over the upgrade process.

I explained the process for publishing and assigning applications in the Daily Drill Down "Automate your application deployment with IntelliMirror." Rather than repeat the information contained in that article, I’ll just touch on the high points. First, you’ll need to create the network share that will contain the application’s files. How you accomplish this depends in part on the application. For example, you use the /a switch with the Microsoft Office Setup application to create the administrative share. You can then create the distribution share based on the application’s requirements and documentation.

In all cases, you’ll need a Windows Installer package for the application. If the application doesn’t include an MSI file, you’ll need to use an authoring package, such as Wise for Windows Installer, to create one. Once you have the MSI file in the distribution share, you can begin customizing the installation to define upgrade options, such as how to handle upgrades of specific components and which options are available to users during installation. The result is a transform file that defines the available installation options and behavior. You can use a packaging application to accomplish the customization, and, in the case of Microsoft Office, you can use the Custom Installation Wizard (CIW) that is included with the Microsoft Office Resource Kit to create the transform file. For more information about the CIW and how to obtain it, see my Daily Feature “Centralize Office 2000 installations using IntelliMirror.”

After you’ve created the custom Installer package and readied the installation share, you can configure the group policy objects that will control application deployment. You can apply the policy at the site, domain, or organizational unit (OU) level, and the hardest part of the process is deciding where to apply the policy. Examine your domain structure with an eye on how the application needs to be deployed. If necessary, rearrange users into new or different OUs to apply the logical structure required to deploy the application according to your users' needs.

Then, open the Active Directory Users And Groups console, open the properties for the container where you want to apply the policy, and click the Group Policy tab in the object’s properties sheet. Open an existing group policy object (GPO) or create a new one to contain the application deployment policy. Expand the User Configuration/Software Settings | Software Installation branch. Right-click in the right pane and choose New, Package. Locate and select the MSI file for the application and then choose either Published or Assigned depending on how you want the application made available. You can choose Advanced Published or Assigned to configure additional options, if needed.

After you create the package, open its properties sheet and click the Upgrades tab. If the GPO includes a package for the previous version, you should see the previous version listed in the Upgrades tab. If not, you can click Add to select a package from the current GPO or another GPO where the package is defined. The dialog box offers two options that control how the application is upgraded:
  • Uninstall The Existing Package, Then Install The Upgrade Package. Choose this option if you want the Installer to remove the existing application before installing the upgrade.
  • Package Can Upgrade Over The Existing Package. Choose this option if you want the Installer to apply the upgrade to the existing installation.

As with any change to policies, you should perform a test deployment prior to rolling out the application. In most cases, this means applying the GPO in a test OU and then running through the installation process with an account in that OU. It’s better to identify and address problems now rather than perform a wide-scale rollout and have to scramble to fix installation problems across the entire enterprise.

Installing Windows 2000 service packs
You can install Windows 2000 service packs through IntelliMirror in addition to installing application patches and updates. IntelliMirror offers an excellent means of ensuring that your operating systems are up to date. As with applications, however, you should explore how the application of a service pack (SP) will affect each user and plan accordingly. It’s rare that an SP causes problems instead of fixing them, but you should be aware of any potential problems and any post-SP fixes that address those problems so you can deploy them at the same time.

The process for deploying an SP is much the same as for an application upgrade, with two main exceptions: You’ll assign the package rather than publish it, and you’ll apply the GPO through the Computer Configuration branch rather than the User Configuration branch.

Start by preparing the distribution share for the SP. Create the folder that will contain the SP files, configure permissions on the folder, and share it. Then, assuming you’re applying SP2, drop to a command prompt, switch to your CD-ROM’s drive letter, and then run W2KSP2.EXE –X from the SP CD. Setup will prompt you for the location of the distribution share and then extract the SP files to the share.

Once the files are in place, you can define the GPO that will cause the SP to be deployed. Open the Active Directory Users And Groups console. Open the properties for the container to which you want the policy applied. For example, to apply the policy at the domain level, right-click the domain and choose Properties. Then, click the Group Policy tab, select an existing GPO or create a new one, and then click Edit to open the Group Policy Editor.

In the editor, open the Computer Configuration | Software Settings | Software Installation branch. Right-click in the right pane and choose New, Package. Browse to the share where the SP files are installed, open the i386\Upgrade folder, select the file Update.msi, and click Open. When the Deploy Software dialog box appears, leave the Assigned option selected and click OK to create the package.

With the package in place, you can begin deploying the SP. Keep in mind that the group policy refresh interval will control how soon the SP will be applied. While you can change this refresh value (the default is 90 minutes), in most cases, it’s more trouble than it’s worth. Simply allow the policy to refresh as scheduled. Reboot the client systems to have the change take effect and the SP installed. Also, note that if you define the policy at the domain level, the change will not always occur as you expect it to. It has been my experience that you must sometimes reboot the clients more than once before the domain-wide policy changes are applied. When applying the policy at the OU level, the change typically happens the first time you reboot after the policy refreshes.

Here’s one final bit of advice on planning and deploying application updates and SPs through IntelliMirror: Consider the impact on your servers and availability issues when deploying the software. A typical upgrade can generate a significant amount of network traffic. This potential problem is magnified as the number of systems being upgraded increases. For example, you wouldn’t want several hundred users all deploying an SP at the same time—your network would probably slow to a crawl.

To keep this from happening, stagger the upgrade by deploying it through multiple OUs at varying times. Link the applicable GPO to one OU and allow the policy to apply the upgrade to those users. Then, when the majority of users in that OU have had their systems upgraded, link the GPO to the next OU to repeat the process for its users. Continue linking the GPO to the remaining OUs one at a time until the deployment is complete. An alternative to this method, if you have sufficient servers and network segmentation to make it feasible, is to create multiple distribution points and GPOs to distribute the upgrade load across multiple servers.

Managing applications means more than just installing them on a user’s workstation and then walking away. You also have to apply patches and upgrade applications as well. The same is true of operating systems. Fortunately, IntelliMirror can save you time maintaining applications the same way it does deploying applications. Create the share, configure the appropriate policies, and let IntelliMirror do the work for you rather than having to run around to each workstation on your network.

Editor's Picks