In order to utilize this feature, you must use a Microsoft Windows Installer Package (.MSI). You’ve probably seen these little beasties. If you install a recent version of most Microsoft software, an .MSI file was probably involved. The new Office XP CD contains two .MSIs, one for the Office Web Components (OWC10.msi), and the one for Office XP Professional (PROTRI.msi). But what if the software you want to deploy doesn’t have an .MSI? Well, Microsoft thoughtfully included a utility with which you can create one. It is called WinInstall LE and is included on the Windows 2000 Server CD. It is located on the CD at \ValueAdd\3rdParty\MGMT\WINSTLE. Install this on your server from the CD. It will wind up in a folder on your server called Program Files\Veritas Software\WININSTALL. You should share this folder to make the rest of the process easier.

Once WinInstall LE has been loaded, you can then proceed to the next step in creating a Windows Installer Package. This involves setting up a prototype Windows 2000 Professional workstation. This workstation should not yet be loaded with the software you want to make the package for. We must first take a “snapshot” of what the prototype looks like before the software is installed. We do this by running the Discover program, DiscoZ, from the WinInstall share over the network. Do this on the prototype workstation. At the end of the Discovery process, the routine will ask you to start the installation of the new software. From here you would install and configure the new software as you normally would. Once that is complete, you again run DiscoZ to create an “after” snapshot of the prototype. The difference of course is the result of installing the new software and is included in the “package”. This will include not only the program files, but registry entries, new folders, and files like .DLLs in their proper locations. It can even include adding the new program to the users Startup folder so it can be started each time the user logs on. This package can be used “as is” to install the software on other workstations. This can be handy if you have non-Windows 2000 workstations like NT 4.0.

However, with Active Directory and Windows 2000 Professional workstations, we can automate the installation using the package and Group Policies. First we must create a Group Policy for our users or the workstations. If we assign the package to a Group Policy assigned to a group of users, then the software will be installed the next time those users log on. If we assign it to a group of workstations, then the installation will take place the next time those PCs are rebooted. These Group Policies can be assigned to Organizational Units (OUs) in your network. For instance you may have an Accounting OU, an Admin OU, and a Sales OU. You can then place users in the appropriate OU. Your CPAs would be in the Accounting OU, the President and his staff in Admin, and the salesmen in Sales. The Accounting folks no doubt need access to the accounting software; the Admin group probably has a big need for Microsoft Office; while the Sales guys probably depend on GoldMine. We can add the accounting program Windows Installer Package to a Group Policy assigned to the Accounting OU. When someone new joins the company in accounting, the accounting package will be installed on their PC the first time they log on. If they then move to Admin, then perhaps the accounting software would be automatically uninstalled and MS Office installed instead. This can be easily accomplished by simply moving them from one OU to another in Active Directory. We can also uninstall old programs or apply updates in the same manner. And all of this is accomplished without the network administrator having to visit each PC!

I used the term “Assign” a bit loosely above. Actually, Assign has a specific meaning in this process. If you Assign a package, then it will be automatically installed when the user logs on. The user has little choice in the matter. However, we might want to just make a package available and let the user install it if they want. To do this we would “Publish” it instead. When a package is Published, it will appear in a list of available programs to install when the user goes into Control Panel and runs the Add/Remove Programs applet. The user can then select the package to install it.

Using Group Policies and Windows Installer Packages is a great way to deploy software within an organization and can make life much easier for the system administrators. (But let’s not tell their bosses… shhhhh….)