3. Add Or Remove Programs in Control Panel
Add
Or Remove Programs in Control Panel enables users to install, modify,
or remove an existing published application or repair a damaged
application. You can control which software is available to users
within Add Or Remove Programs in Control Panel by using Group Policy
settings. Users no longer need to look for a network share, use a
CD-ROM, or install, fix, and upgrade software themselves.
4. Software Deployment Approaches
Given
that software can be either assigned or published, and targeted to
users or computers, you can establish a workable combination to meet
your software management goals. Table 1 details the different software deployment approaches.
Table 1. Software Deployment Approaches
| Publish (user only) | Assign (user) | Assign (computer) |
---|
After deployment, the software is available for installation: | The next time a user logs on. | The next time a user logs on. | The next time the computer starts. |
Typically, the user installs the software from: | Add Or Remove Programs in Control Panel. | Start menu or desktop shortcut. | The software is already installed. (The software automatically installs when the computer reboots.) |
If the software is not installed and the user opens a file associated with the software, does the software install? | Yes (if auto-install is turned on). | Yes. | Does not apply; the software is already installed. |
Can the user remove the software by using Add Or Remove Programs in Control Panel? | Yes, and the user can choose to install it again from Add Or Remove Programs in Control Panel. | Yes, and the software is available for installation again from the typical install points. | No. Only the local administrator can remove the software; a user can run a repair on the software. |
Supported installation files: | Windows Installer packages (.msi files), .zap files. | Windows Installer packages (.msi files). | Windows Installer packages (.msi files). |
Modifications
(.mst or .msp files) are customizations applied to Windows Installer
packages. A modification must be applied at the time of assignment or
publication, not at the time of installation.
Software Deployment Processes
The
steps in software deployment vary, depending on whether the application
is published or assigned and whether the application is automatically
installed by activating a document associated with the application.
Software Deployment Process for Published Applications
The following sequence shows the installation process for published applications:
1. | The user logs on to a client computer running Windows 2000 or later.
|
2. | The user opens Add Or Remove Programs in Control Panel.
|
3. | Add Or Remove Programs obtains the list of published software from Active Directory.
|
4. | The user selects the desired application.
|
5. | Add Or Remove Programs obtains the location of published software from Active Directory.
|
6. | A request for the software is sent to the SDP.
|
7. | The Windows Installer service is started, and it installs the requested Windows Installer package.
|
8. | The user opens the newly-installed application.
|
Software Deployment Process for Assigned Applications
The following sequence shows the installation process for assigned applications:
The user logs on to a client computer running Windows 2000 or later.
The WinLogon process advertises applications on the user’s desktop or on the Start menu.
The user selects the desired application from the desktop or the Start menu.
The Windows Installer service gets the Windows Installer package.
A request for the software is sent to the SDP.
The Windows Installer service is started, it installs the requested Windows Installer package, and it opens the application.
Software Deployment Process for Automatically Installed Applications
The following sequence shows the installation process for automatically installed applications, whether published or assigned:
1. | The user logs on to a client computer running Windows 2000 or later.
|
2. | The user double-clicks a document with an unknown filename extension.
|
3. | Windows Server 2003 looks for information about the application in the local computer registry.
|
4. | One of the following steps is taken:
If
information about the application is found in the local computer
registry, the registry points to the location of the application on the
SDP and the corresponding Windows Installer package is started. The
Windows Installer service installs the package for the user and opens
the application. If information about
the application is not found in the local computer registry, Windows
Server 2003 looks for information in Active Directory. If information
about the application is found in Active Directory, it points to the
location of the application on the SDP. The Windows Installer service
installs the package for the user and opens the application.
|
5. Distributing Windows Installer Packages
Because
the Windows Installer service is part of the operating system, it does
not matter how Windows Installer packages get to the client computer.
If you are deploying software to many users in a large organization
that is using Windows 2000 Server or later and Active Directory, and
all the workstations are using Windows 2000 Professional or later, you
can deploy software with Group Policy. For large-scale deployments or
deployments with computers running pre–Windows 2000 operating systems,
you might also consider using the Microsoft Systems Management Server
(SMS) along with Group Policy to handle software deployment.
Software deployment with Group Policy uses a pull model,
which makes software available to users as it is needed. Applications
are fully installed when a user chooses to use a user-assigned
application for the first time or selects a file by choosing the
filename extension of an application. For a satisfactory end-user
experience, software deployment with Group Policy requires a high-speed
local area network (LAN) connection between the client computer and the
distribution server containing the SDP.
SMS
supports a robust distribution model that you can use when deploying
software with Group Policy. You can use SMS to analyze your network
infrastructure for software distribution and then use Group Policy to
target users and computers and to install the software. SMS is a
particularly useful tool if you are deploying software to many users in
a large organization. It includes desktop management and software
distribution features that significantly automate the task of upgrading
software on client computers.
SMS uses a push model
for software deployment, which you can use to coordinate and schedule
software deployments—even arranging for off-hours distribution and
installation—and to plan a single- or multiple-phase rollout of
software. It provides you with the ability to control and synchronize
software deployments over multiple sites, helping to reduce
compatibility issues that might otherwise occur.
The following are some areas where you might want to supplement software deployment with Group Policy by using SMS:
Non–Windows 2000–based clients
SMS can distribute Windows Installer–based software to computers
running Microsoft Windows 95 or later. Although you cannot centrally
manage the non–Windows 2000–based computers with Group Policy settings,
SMS allows these computers to benefit from the capabilities built into
the Windows Installer service, such as self-repairing applications.
Deploying software over slow links
By default, software deployment with Group Policy does not operate over
slow network or dial-up connections. SMS provides options for deploying
software to users who can connect only over slow network links, such as
mobile users.
Software licensing and metering Software deployment with Group Policy does not have the ability to license or meter software.
Identification of computer configurations
Before you distribute a managed application, you can use SMS to
determine current computer configurations to make sure that the
appropriate computers have the necessary system requirements to run the
application.