One of the more arduous tasks of an administrator is r= olling out a new application to a large number of desktops. The prospect of sending out desktop support techs to go machine by machine to install and configure software is a huge drain on resources. The time spent deploying the softwar= e is often greater than the expense of the software itself.
Applications like Ghost have existed for a number of y= ears to speed the process of deploying new computers. These programs allow you to quickly apply a standard image that has been created to a computer, which l= oads an OS and any applications you have included in your image. Simply change t= he computer name at the end of the image process in most cases, and your syste= m is set. The downside to Ghost and its brethren is that they are only good for imaging an entire hard drive. That is, they wipe out the existing data when applying an image. Therefore, there is no way to apply a single application with them.
Other software arose to deal with this situation, such= as Seagate’s WinInstall and Microsoft’s SMS Installer. Both functi= on very similarly. WinInstall (now owned by Veritas) and SMS Installer take “snapshots” of your computer, noting every file on the hard dri= ve and every Registry setting. With a baseline snapshot, the program then inst= alls the application that you choose. You install the program as normal through = its setup utility, and configure the software as you would want it to be deploy= ed to all users. When the installation finishes, WinInstall or SMS Installer t= akes a second snapshot of your system, and notes all of the file and Registry changes that have occurred since the first snapshot was taken. These change= s in the past were rolled up into .EXE files, that when executed would apply the configuration changes directly to a machine without having to take the user through the normal setup program.
The benefits of this are two-fold. First, the installa= tion time is much faster since the files and Registry settings are copied direct= ly where they need to go. No extra information need be supplied. Second, the packages can be deployed through SMS or through a batch file sent in email, and ordinary users can safely install the programs because t= hey will not have to make any choices during the installation. Deploying softwa= re in this manner can dramatically lower the TCO associated with buying new software.
With Windows 2000, Microsoft has included its Windows Installer technology with the operating system. If you’ve ever instal= led Office 2000 or Outlook 2000 as a standalone, you’ve seen the Windows Installer in action. Windows Installer packages are packaged into .MSI file= s, which is a database file that describes the configuration settings of the application. Windows Installer runs .MSI packages natively, as the OS norma= lly runs .EXE files. The advantage to MSI files, however, is with the Windows Installer they are much more flexible. Unlike EXE installations, Windows Installer installations can monitor the state of the installation and even = roll it back should something go wrong. That flexibil= ity is not afforded using traditional EXE files.
The SMS Installer utility has recently been upgraded to support MSI packaging rather than EXE packaging, but it is a utility that i= s probably on its way out. The reason being is that Microsoft has licensed WinInstall = from Veritas, and WinInstall LE can be installed from the Windows 2000 Server CD= . To install WinInstall, navigate to the \VALUEADD\3RDPARTY\MGMT\WINSTLE directo= ry on the Windows 2000 CD. Double click the SWIADMLE.MSI Windows Installer pac= kage to install. WinInstall LE packages its installations at Windows Installer (= MSI) files.
When creating a snapshot, it is very important to use a “clean” system. That is, a system that has only the base operat= ing system installed. The reason for this is that if you have installed any applications that might not be on other computers that this package would be destined for, there might be .DLL files or other files on your system that = won’t be overwritten by the program you are installing. In other words, files essential to the proper operation of your application would not be included with the package, and the application would fail to work properly once depl= oyed on a user’s workstation. Ideally, the hardware the image is created on will mimic what is in general use by employees as well.
After installing WinInstall, you will notice a new Ver= itas Software group on your Start menu, with two programs inside. Veritas Discov= er is the WinInstall LE program, and the Veritas software console contains the Windows Installer Package Editor, which lets you modify or create Windows Installer packages to install applications on your client computers. Using = the Windows Installer Package Editor, you can open any existing MSI package for modification. This is used typically after you have created the initial MSI packages for your applications using Veritas Discover.
One the MSI package is created and modified to suit yo= ur needs, you are ready to deploy it. A popular option for software deployment is Microsoft Systems Management Server (SMS). Check out David Watts’ March 2000 article on software distribution to learn more about distributing software with SMS. Another option is to store the MSI packages in a shared network folder, and give users Read access to the fold= er. You can then create a batch file to map the drive, execute the MSI file, and disconnect the drive when finished. If you were installing a program called MyApp.msi, a batch file might look something like this:
&nbs=
p; net use z:
\\server\appshare
&= nbsp; z:\myapp\MyApp.m= si
&nbs= p; net use z: /d
In the above I use a myapp subdirectory underneath the shared folder. I’m a strong believer in organization, and that you shouldn’t simply lump all of your application installations into a si= ngle directory.
With the batch file created, you can distribute it thr= ough email or attach it to a login script. With Windows 2000 Group Policy you ha= ve even more flexibility to install the software.
Group Policy uses the concept of a Group Policy Object (GPO), which can be linked to sites, domains, or organizational units (OUs)= in Windows 2000. Group Policy only works with Windows 2000 clients, so keep th= at in mind if you have a mixed environment of Windows 2000 and non-Windows 200= 0 systems. It is beyond the scope of this article to provide a primer on Group Policy,= but if there is enough interest we can do that in a future article.
Once you have opened the desired GPO in the Group Poli= cy Editor, you can open the Software Installation folder under the Software Settings node in either the Computer Configuration or User Configuration no= des. Software Installation exists in both places since software can be assigned = to computer accounts as well user accounts (and of course groups of both). For= our purposes, we’ll assume you already have a Windows Installer package t= hat you want to deploy and have copied the source file to a distribution point = (a shared network location).
Simply right click on Software Installation and choose New->Package. Select the package you want and click OK, which brings up a dialog box asking how you want to deploy the software. For user accounts, software can either be published or assigned. For computer accounts, softwa= re can only be assigned. Once you’ve deployed a new package, chances are= you might want to modify some of its properties. To access the properties of a package once you've deployed it, simply right click on the package and click Properties. There are a number of property sheets containing settings for t= he package. An overview of them is as follows:
* = General -- Contains product information such as the name and version number, as wel= l as contact information
* = Deployment -- Defines the deployment type (assigned or published), which can also be changed here. In addition, this property sheet contains settings for deploy= ment options, including whether the package should be uninstalled if it falls outside the scope of management and if it should be displayed in the Add/Re= move Programs applet. Advanced deployment options determine whether the language setting should be ignored when installing the software and whether previous installations of the product should be uninstalled if it wasn't installed through Group Policy.
* = Upgrades -- Defines the applications that are to be upgraded by this package, and wh= ich packages can upgrade this package.
* = Categories -- Determines the categories that the software will be displayed under in t= he Add/Remove Programs applet
* = Modifications -- Allows you to apply modifications or transforms to the package in order = to customize the deployment
* = Security -- Determines who has what level of access to the package. It is through the Security property sheet that you control the deployment of the software to computers, users, and groups.
These are the basics of the Software Installation exte= nsion, and should give you an idea of what Windows 2000 is capable of with regards= to software deployment. The beauty of this type of deployment is the administrative headaches it solves. By utilizing Group Policy, you can stri= ctly control what users, computers, and groups have access to the package through GPO settings. You can assign the software to one department, publish it to another, and prevent still another from having it altogether. This flexibil= ity will allow you as an administrator greater control over software licensing issues in your environment, a traditional source of frustration.