If a new Windows service pack were released tomorrow, how long would it take you to deploy it to all of your machines? Even after the new service pack was deployed, how could you be sure that no machines were accidentally skipped? If these issues sound familiar, you’ll be happy to know that Windows 2000 has automated the software distribution process to make your next software rollout go more smoothly.
Create a distribution point
You must begin the software distribution automation process by creating a software distribution point. A distribution point is a location where a copy of the software’s installer package exists. You can create such a distribution point by creating a folder for the software and then copying the entire contents of an installation CD into the folder. The folder must be shared so you can access it through a universal naming convention path.
Control distribution through the MMC
Once you’ve created distribution points for all the software you need to automate, you must create a group policy that controls the automation process. Go to a domain controller and open an empty Microsoft Management Console (MMC) session by entering the MMC command at the Run prompt. When the console opens, select Add/Remove Snap-In from the Console menu. You’ll see the Add/Remove Snap-In properties sheet.
|Once you open the Microsoft Management Console, you will need to add the Group Policy snap-in.|
Next, click the Add button on the properties sheet’s Standalone tab to reveal a list of all the available snap-ins. Select Group Policy from the list and click the Add button (see Figure A). You’ll then see a screen asking which group policy you want to load. Click the Browse button and select Default Domain Policy from the list (unless another policy is more appropriate). Click OK, Finish, Close, and then OK. You can then edit the default domain policy.
When the console opens, you’ll notice that it is divided into two main sections, users and computers. You can actually assign software distribution policies to either users or computers. In most cases, I recommend assigning the policy on a computer basis, but there are times when you’ll want to assign it via the user method instead. For example, if you wanted only employees in the finance department to have a new accounting software package, you would create a user-based distribution policy.
Whether you distribute a software package by user or by computer, you can distribute the package to a select group by creating an organizational unit (OU) and then assigning the policy to that OU. For example, if you wanted to distribute the accounting package to the finance department, you could create an OU consisting only of finance employees. Likewise, if you wanted to distribute Service Pack 6A only to computers running Windows NT 4.0, you could create an OU containing those computers.
Whether you’re deploying an application based on a user or a computer, navigate to the appropriate section and expand the Software Settings container. Right-click on the Software Installation container and select New | Package from the resulting menus (see Figure B). When you do, Windows will allow you to browse the network to track down the software you want to install. Keep in mind that you’ll only be able to automate software that has a corresponding Windows Installer package (.msi file). Click here for more information on Windows Installer.
Select the .msi file and click Open. When you do, Windows will ask if you want to publish or assign the application. There will also be an option to perform an advanced publish or assign.
Publishing vs. assigning an application
Publishing an application means that after their next login, users will have the option of installing the application via the Control Panel’s Add/Remove Programs icon. Assigning an application works a bit differently. If you assign an application to a user, Windows will create Start menu links and/or desktop icons to the application upon the user’s next logon. The first time that the user attempts to use the menu option or icon, Windows will install the application for the user.
However, if you assign an application to a computer, the application will be automatically installed onto the computer without any user intervention. This type of installation is considered mandatory and, as such, only an administrator can uninstall applications that have been assigned to a computer. You would install things like service packs, hot fixes, and other critical updates in this way.
When you assign applications to a PC, Windows usually monitors the application’s health. So if an application fails, becomes damaged, or if the end user accidentally erases some of the application’s files, Windows can usually detect the failure and automatically repair or reinstall the application automatically without the user ever having to make a call to the help desk.
You might notice a couple of things when Windows asks if you want to publish or assign applications. First, if you’re deploying applications on a computer basis, the option to publish the application will be grayed out. Remember that publishing an application places the option to install the application into the user’s hands. Since a computer can’t make a conscious decision to install an application, the Publish option isn’t available for computer-based deployment.
When you select the Publish or Assign radio button and click OK, Windows will automatically publish or assign the software. Your software installation is then ready to go (see Figure C).
There are times, however, when you’ll want to gain more control over the process. For example, if you were installing Office XP onto a system that already had Office 2000, you would probably want Office XP to replace Office 2000 rather than keeping both versions. The Advanced Publish Or Assign option allows you to do this and more. I’ll discuss this option in my next article.