70-240 in 15 minutes a week: Software Distribution, Terminal Services, and IIS Page 2

By ServerWatch Staff (Send Email)
Posted Apr 30, 2001


Publishing software to users: This method adds the application to the Add/Remove programs section of control panel, allowing the user to install the application if necessary. It does not appear to be installed as software assigned to a user does. A published application can also be installed via document invocation. For example, if a user clicked on a zip file, WinZip would install if it had been published to the user.

When choosing to distribute an application via group policy, the application must be in a packaged format, an .msi file. Many new applications now ship with an msi file already included. An msi file includes instructions on how an application is to be installed, along with all system modifications it will make. If you wish to distribute an application that is not in .msi format, you can create your own msi by using WinInstall LE, a repackaging application included on the Windows 2000 CD. Essentially you use it to take a 'before' snapshot of the system configuration, then install the software, after which you take an 'after' snapshot. The differences are recorded, and the necessary files and .msi file are stored to whatever directory you have specified. This directory should be shared, and then chosen as the location of the application you wish to distribute via group policy. When software is distributed via group policy, the user does not need any special privileges (such as being an administrator) to install the software. Instead, the software is installed using the elevated privileges of group policy. Another benefit of software distributed using an msi file is its resilience - if the software becomes damaged in any way, it will go back to its source files and automatically fix itself the next time you try to run it (assuming the source files are still available, of course).

If an msi file does not exist or cannot be created, it is still possible to publish the software to a user using something called a .zap file. Basically this is a text file containing the instructions necessary to install the software. The downside of this method is that the installation of the software requires that the user have an appropriate level of access to install software on the system - it will not install under the elevated privileges of group policy. Note that a .zap file is only used for publishing, and only to users (since you cant publish software to a computer, remember!). For a look at a zap file, click here.

When you choose to distribute a piece of software via group policy, you will be presented with the screen shown below:

The path to the package should be provided in a manner that will allow network clients to connect, for example the UNC path to the .msi file location. The screen shot below outlines a package that will be assigned to users in a domain:

An important note with respect to distributing software via group policy - be careful with respect to how you apply policy for the purpose of software distribution. If the above example were assigning software to all users in a domain, every installation would obtain the package from the \\laptop server, even those in other physical sites. A better practice is to design for the assignment and publishing of software such that a local package is used and unnecessary WAN traffic is avoided. 

You can also control what happens to software once a package is removed from group policy, as shown below:



Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.