Managing software on client computers can be a
tedious task. Fortunately, Microsoft Windows Server 2003 integrates
several technologies that can make managing computers more efficient.
You can use Group Policy to deploy applications automatically. You can
use Software Restriction Policies to block unauthorized programs and
scripts. Finally, you can use Remote Installation Services (RIS) to boot
client and server computers from a network connection and easily
install Microsoft Windows. Although these features are not as powerful
as those provided by dedicated management programs such as Microsoft
Systems Management Server (SMS), they are easy to use and provide a
basic set of management capabilities.
Using the Group Policy Software Installation Extension
The Group
Policy Software Installation extension enables you to deploy
applications to computers in the domain or forest using Group Policy and
includes the capability to do the following:
Publish applications so that users can view and install programs from the network
Assign
applications to users or computers so that the applications are
installed automatically when users need them or on the next restart or
logon
Target applications to different groups using Group Policy
View installation status using Group Policy Results
To deploy an application,
create or edit the appropriate Group Policy Object (GPO) and add the
application’s Windows Installer package to either the user or computer
policy, depending on whether you want it to apply to users or computers.
The next time the user logs on or the computer restarts, Windows
applies the relevant policy to the user or computer depending on the
package settings you specify in the GPO. (See Table 1.)
Windows Installer handles the automatic installation or removal of all programs, as well as any upgrades or repairs.
Table 1. GPO settings needed for specific actions
| Action | Setting Required |
|---|
| Automatically install the application | Install This Application At Logon |
| Add the application to a list of installable programs in Add/Remove Programs | Publish |
| Add a shortcut to the application in the Start menu and install it on first use | Assign The Application (Note: Do not use the Install This Application At Logon setting.) |
IntelliMirror is a
set of technologies that allows users’ data, settings, and applications
to follow them to other computers running Windows 2000, Windows XP, or
Windows Server 2003 on the network—or even off the network, in the case
of laptops. The components of IntelliMirror are as follows:
User Data Management
Allows users to access their documents and data from any computer on or
off the network (in the case of synchronized laptops). This is done by
redirecting the My Documents folder to a network share and then using
the offline folders feature to ensure the ability to access the data
when offline.
User Settings Management More simply known as roaming profiles,
this feature allows users to log on to any computer on the network as
if it were their own computer, with all their application and Windows
settings intact.
Software Installation and Maintenance Allows administrators to deploy applications automatically to users using Group Policy.
Remote Installation Services (RIS)
Allows users to start a computer with no functioning operating system
from the network, logon, and then select an approved operating system
that Windows installs automatically.
Finding the Right Mix of Services
Look at the following details of the technologies (and Table 2) to determine the best mix of services for your type of network:
RIS (Remote
Installation Services) permits a user to start a computer (with or
without an operating system) from a RIS server over the network and then
automatically install Windows 2000 Professional, Windows XP
Professional, or Windows Server 2003. RIS works much like using
unattended answer files and disk imaging, but with greater ease of use.
Group
Policy allows users to access their data, settings, and applications
from any computer on the network running Windows 2000, Windows XP
Professional, or Windows Server 2003. Group Policy distributes data,
software, and settings using a pull
approach, meaning that the client requests data from Active Directory
as needed. This approach works best when connectivity between the client
and the nearest domain controller or software distribution server is at
LAN speeds.
SMS
manages the deployment of software and operating systems on complex
networks and networks with sophisticated software management
requirements. SMS controls the deployment schedule, and it provides
software inventorying and license tracking, as well as planning and
diagnostic tools. SMS can push software to clients using almost any
version of Windows. It can also push software to distribution points
from which Group Policy either installs the software or allows users to
do so. SMS includes rich reporting and inventory capabilities so that
you can determine which installations were successful. SMS requires a
significant investment of resources to install and configure on a
complex network, so it is appropriate only for networks with
sophisticated software deployment and management needs.
Microsoft
Operations Manager (MOM) provides an overarching management layer to
Microsoft servers (including SMS), allowing you to monitor the network
and determine what tasks need to be done. MOM is a powerful tool to use
when the network gets so large that you need a way to manage your
management tools.
Table 2. Technologies to use based on network type and client environment
| Client Type | Simple LAN and Simple Requirements | Complex Network or Complex Requirements |
|---|
| Windows Server 2003, Windows XP, Windows 2000 | Group Policy, RIS | SMS, Group Policy, RIS, MOM |
| Mixed Windows environment with some earlier systems | SMS, Group Policy | SMS, Group Policy, MOM |
| Earlier Windows clients (Microsoft Windows 3.x, Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows Me, Microsoft Windows NT) | SMS | SMS, MOM |
Note
Although most
documentation insists that only SMS can perform managed Windows
upgrades, you can also use Group Policy to perform them.
Note
For users with a
persistent network connection and without processor-intensive or highly
graphical applications, deploy Terminal Services to centralize
application maintenance and make it easier to provide a reliable and
secure desktop environment.
Natively Authored Windows Installer Packages
A native Windows
Installer package created by the software manufacturer for use with
Group Policy is usually the best option for deploying software.
Deployment is relatively simple and requires no user intervention, and
natively authored Windows Installer packages can repair themselves if a
key file is inadvertently deleted or corrupted. You can also create
transform files for some packages. For example, you can create a
transform file to customize a Microsoft Office installation so that only
Microsoft Word and Microsoft Outlook are installed rather than the
entire suite.
More Info
To customize a Microsoft Office installation, pick up a copy of the Microsoft Office 2003 Resource Kit (Microsoft Press, 2003), which includes an Installation Customization tool.
Zap Files
The easiest way to
deploy applications that are not natively authored for Windows Installer
is to create a .zap file. A .zap file is a text file that points to the
32-bit or 64-bit setup program for the application and can optionally
run automated setup scripts. (Microsoft Windows Small Business Server
2003 uses a similar approach to application deployment.)
Although .zap files are simple and easy to create, .zap files cannot do the following:
Assign applications to particular users or computers, though you can use a .zap file to publish applications
Install
applications with elevated permissions (Windows Installer gives higher
permissions to installation programs so that a local administrator
account isn’t needed to install software.)
Install applications automatically on first use
Perform partial installations of applications, with advanced features installed when needed
Perform a complete rollback of an unsuccessful installation or enable applications to repair themselves
Despite these
limitations, most users find that using .zap files to deploy earlier
applications is more reliable than repackaging applications, because
.zap files make use of the original installation program. (It’s unlikely
that you can write a better setup routine than the original, especially
without access to more in-depth information about the program.)
Note
Windows hides
published applications that use 32-bit .zap files from 64-bit clients by
default because 32-bit .zap files fail more often on 64-bit versions of
Windows.
Repackaged Applications
If an application does not
use Windows Installer to install itself, you can automate setup using
an installation script and a .zap file, as discussed earlier, or
repackage it into a Windows Installer package. When you repackage an
application, you take “snapshots” of a computer before the application
is installed using a commercial authoring package and then again after
installing the application. The authoring package compares the two
snapshots to determine what changes the application made during setup
and then bundles the changes into a new Windows Installer package.
More Info
To repackage an
application, use a commercial authoring package such as one from
Macrovision (which acquired InstallShield) or WISE Solutions; or you can
use the light version of the Veritas Software WinInstall program, which
is included with Windows 2000 Server (but unfortunately not with
Windows Server 2003). WinInstall LE is discussed in the Microsoft
Windows 2000 Server Administrator’s Companion.
Repackaged
applications convey many of the advantages inherent in natively authored
Windows Installer packages; however, a number of hazards are involved
as well. If the client system differs from the reference system used to
repackage the application, problems can occur because the repackaged
application has only very limited means of resolving differences.
Repackaged applications occasionally copy .DLL files to the wrong
locations or they break shortcuts. Additionally, the All Users folder
can potentially be deleted after uninstalling
a repackaged application. Technically speaking, poorly tested
repackaged applications can trash the system. Also, repackaged
applications aren’t easily upgraded—uninstall the existing version to
install the new version.
Although there
are potential problems, repackaging applications is a powerful way to
deploy software if the repackaged application is thoroughly tested in a
lab and pilot rollout before widespread deployment.
More Info
For more on
the support boundaries and technical difficulties inherent in
repackaging applications, see Microsoft Knowledge Base Articles 264478,
320539, and 305955.
Deciding Whether to Publish or Assign Applications
An application
published in Active Directory becomes available from Add/Remove Programs
for the users to whom the Group Policy Object (GPO) applies. (As
described earlier, applications are published to users, not computers.)
An assigned
application, on the other hand, can be assigned to either users or
computers and is installed without any action on the user’s part.
Assigned applications appear on the Start menu and are installed on
first use, unless you specify that they should be fully installed at the
next logon.
Assign essential
applications to users or computers so that these applications are always
available, and publish optional programs to make it easy for users to
find applications when they need them. Do not assign or publish an
application to both computers and users. Table 3 summarizes the differences between publishing and assigning applications.
Table 3. Differences between publishing and assigning deployed applications
| | Published Applications | Applications Assigned to Users | Applications Assigned to Computers |
|---|
| When after deployment is the software available for installation? | Immediately, or after replication to the nearest DC | After the next logon | After the next reboot. |
| How is the software installed? | Through Add/Remove Programs in Control Panel | Automatically on first use, or after the next logon event (Icons are present on the Start menu or the desktop.) | The software is automatically installed on reboot. |
| Is the software installed when a file associated with the application is opened? | Yes | Yes | The software is already installed. |
| Can the user remove the software? | Yes, by using Add/Remove Programs (Reinstallation is also supported.) | Yes, although the software becomes available again after the next logon event | No, although software repairs are permitted. Local administrators can uninstall software. |
| What package types are supported? | Windows Installer packages and .zap files | Windows Installer packages | Windows Installer packages. |
Updating Applications Deployed via Group Policy
The
Group Policy Software Installation extension does not explicitly
support updating applications. To update Microsoft applications, use
Windows Server Update Services (WSUS). To update applications that WSUS
does not support, use a third-party patch management application that
supports the necessary applications, deploy the patches via login
scripts, or instruct users to install the software updates from a
network share (assuming the users are local administrators).
There are two
other noteworthy methods of updating applications using Group Policy.
The simplest method is to update the administrative installation or
setup files in the software distribution point, and then redeploy the
application . However, this method
can cause the client computers to become out of sync if users use the
Install On Demand or Detect And Repair features before reinstalling the
application. When using this method, promptly update Group Policy for
all affected users and computers so that the application is reinstalled
before it can get out of sync. Be prepared for a surge in network
traffic as the computers reinstall the application from the network.
When a client computer is out of sync with the software distribution
point, Windows might prompt users for an installation CD and refuse to
install the updated version. To resolve this condition, try logging off
or restarting the computer, or use a local administrator account to
uninstall the application and then reinstall it using Group Policy. You
can also use the Install This Application At Logon setting when
assigning applications to users.
Another way to
update applications using Group Policy is to make a copy of the
administrative install or folder in the software distribution point
containing the setup files. Update this copy and then add the updated
application to the GPO as an upgrade to the existing application. This
enables existing clients to continue to access the original installation
files until
Windows applies the GPO and upgrades the application. When using this
method, copy the original GPO and use the copy for testing and pilot
deployment. (Make sure that the copy has a lower link order than the
original so that Windows applies it instead of the original.) Once you
verify that the upgrade works properly, disable the original GPO (and
eventually delete it).
Whichever method is
used to update applications, test the method thoroughly in a lab before
implementing it on a production network, and perform pilot deployments
of updates or staged rollouts to mitigate risk.
