Microsoft Installer
IntelliMirror, as previously noted, includes software installation and maintenance as a feature used to install and maintain user applications based on group policy. The Microsoft Installer plays a critical role in this process, and it's important to understand how it works. It's also important to understand the client systems to which it is applied, such as available disk space and compliance with the hardware compatibility list (HCL).
Publishing or Assigning Applications
There is a distinct difference between publishing and assigning applications. Publishing makes the application available for installation in a way that Windows 2000 operating systems can understand. Assigned applications are installed automatically and are available to the user to perform their job function.
Published applications are
Available to users after being published.
Installed from Control Panel, Add/Remove Programs.
Installed if a user opens a file that requires the application.
Removable (uninstalled) using Control Panel, Add/Remove Programs.
User assigned applications are
Available to the user from their Start menu after they log on. The software, however, is installed if the user launches the application.
Installed if a user opens a file that requires the application.
Removable (uninstalled) using Control Panel, Add/Remove Programs.
Computer assigned applications are
Installed when the computer starts.
Can be applied using secedit /refreshmachineposlicy without restarting the computer.
Not removable (uninstalled) by the user. Only the local administrator can remove the application.
The user can repair applications that have become corrupt. When assigning applications, it is important to test the application in the lab before going into production. It's also important to understand the impact assigned applications have on the network when the applications are first assigned.
Windows Installer Applications
Windows Installer is a service that is available for Windows 2000, Windows NT 4.0, Windows 98, and Windows 95. The Windows Installer service depends on a Windows Installer Package that contains specific application installation information for the Windows Installer service. Without the Windows Installer Package, the Windows Installer service has no idea how to install and configure an application.
Therefore, a prerequisite for using the Windows Installer service to install and maintain an application is for the application to have a Windows Installer Package. As Windows 2000 becomes more popular, more and more applications are released with Windows Installer Packages. Office 2000, for example, has a native Windows Installer Package. For those applications that do not come with a Windows Installer Package, you can either author or repackage the application for support by the Windows Installer service.
For authoring your own Windows Installer Packages, third-party tools are available from companies like Install Shield Software Corporation and WISE Solutions. These tools enable you to take an application and create a Windows Installer Package.
You can also repackage the application for support by the Windows Installer. Repackaging is the process of taking a clean computer, which only has the operating system installed, and installing the application. The repackaging tool compares the state of the computer, before the installation and after the installation, and records the changes made to the computer. Seagate Software's WinINSTALL LE repackages existing applications for support by the Windows Installer. This tool is available on the Windows 2000 Server CD.
Repackaging is not yet an exact science. It is recommended that packages be authored, if possible, rather than repackaged.
Publishing Non-Windows Installer Applications
It is also possible to publish, not assign, applications that do not have a Windows Installer Package. These applications are available to users through Control Panel, Add/Remove Programs, and they use the application's setup for the installation.
A .ZAP file contains a description of the application, the command line to use for setup, the setup option choices, and the entry points the application should install. The following is the .ZAP file from Microsoft for Microsoft Excel.
; ZAP file for Microsoft Excel 97
[Application]
; Only FriendlyName and SetupCommand are required,
; everything else is optional
; FriendlyName is the name of the application that
; will appear in the software installation snapin
; and the add/remove programs control panel.
; REQUIRED
FriendlyName = "Microsoft Excel 97"
; SetupCommand is the command line that we use to
; Run the applications setup. if it is a relative
; path, it is assumed to be relative to the
; location of the ZAP file.
; Long file name paths need to be quoted. For example:
; SetupCommand = "long foldersetup.exe" /unattend
; or
; SetupCommand = "\serversharelong _
; foldersetup.exe" /unattend
; REQUIRED
SetupCommand = setup.exe
; Version of the application that will appear
; in the software installation snapin and the
; add/remove programs control panel.
; OPTIONAL
DisplayVersion = 8.0
; Publisher of the application that will appear
; in the software installation snapin and the
; add/remove programs control panel.
; OPTIONAL
Publisher = Microsoft
; URL for application information that will appear
; in the software installation snapin and the
; add/remove programs control panel.;
; OPTIONAL
URL = http://www.microsoft.com/office
; Language for the app, in this case US English.
; OPTIONAL
LCID = 1033
; Architecture, in this case, intel.
; OPTIONAL
Architecture = intel
; the [ext] [CLSIDs] and [progIDs] sections are
; all optional
[ext]
; File extensions that this application will
; "auto-install" for. They are not required if you
; do not want the application. This entire section
; is OPTIONAL.
; note you can put a dot in front or not, as you like
; text after the first = is optional and ignored
; but the first = is required (or the whole line
; will be ignored)
XLS=
XLA=
XLB=
XLC=
XLM=
XLV=
XLW=
[CLSIDs]
; CLSIDs that this application will "auto-install"
; for. This entire section is OPTIONAL.
; Format is CLSID with LocalServer32,
; InprocServer32, and/or InprocHandler32 (in a
; comma separated list) after the =.
{00024500-0000-0000-C000-000000000046}=LocalServer32
{00020821-0000-0000-C000-000000000046}=LocalServer32
{00020811-0000-0000-C000-000000000046}=LocalServer32
{00020810-0000-0000-C000-000000000046}=LocalServer32
{00020820-0000-0000-C000-000000000046}=LocalServer32
{00020820-0000-0000-C000-000000000046}=LocalServer32
[progIDs]
; progIDs that this application will "auto-install"
; for. This entire section is OPTIONAL.
; format is a CLSID, with the corresponding progid
; listed after the = sign
{00024500-0000-0000-C000- _
000000000046}=Excel.Application
{00024500-0000-0000-C000- _
000000000046}=Excel.Application.8
{00020821-0000-0000-C000-000000000046}=Excel.Chart
{00020811-0000-0000-C000-000000000046}=Excel.Chart.5
{00020821-0000-0000-C000-000000000046}=Excel.Chart.8
{00020810-0000-0000-C000-000000000046}=Excel.Sheet.5
{00020820-0000-0000-C000-000000000046}=Excel.Sheet.8
{00020820-0000-0000-C000-000000000046}=Excel.Sheet
{00020820-0000-0000-C000-000000000046}=Excel.Template
{00020820-0000-0000-C000-000000000046}=Excel.Workspace
|publishing |applications |non-Windows
|applications |publishing |non-Windows
|applications |non-windows |publishing
|Installer
|applications |Installer
|HCL |Installer
.ZAP files are typically stored in the same network share, or software distribution point, where the application's setup is located.
Software Distribution Points
Software distribution points are strategically located file shares on your network where applications packages are stored for installation by client computers. Software distribution points should be located on one or more areas of the network, approximate to the clients that are going to require the applications that are hosted by the software distribution point.
If, for example, a GPO is applied to a domain that assigns an application to all users in that domain, it is important to provide software distribution points to the locations within that domain.
Figure 12.3. Defining group policies for the domain and for each site.
In the example shown in Figure 12.3, group policies are defined for the domain and for each site, Seattle and Miami. Objects in the Seattle site would be subject to the group policies for both the domain and the Seattle site. Likewise, objects in the Miami site would be subject to the group policies for both the domain and the Miami site. Therefore, the software distribution points for the servers in each location need to be able to provide the applications required by each site and by the domain. It would also be possible to assign policies at a more granular level within the domain's OUs.
Creating a software distribution point is as simple as creating the network share, creating the appropriate folders, copying the Windows Installer Packages and application executables to the appropriate folder, and then setting the appropriate folder permissions. The permissions should restrict everyone's read access, while enabling administrators full control, change, and read permissions. This can be made more efficient by using the Distributed File System (DFS), which redirects a common UNC path to a server within the client's site. This way, \fileshareapplications could be referenced from anywhere on the network, but the actual server that a particular client connects to would be local to the client's Active Directory site.
Configuring Group Policies
After creating the package and software distribution points, all that is left is to create the GPOs. This is done using the Active Directory Users and Computers MMC snap-in. You can also configure the default software distribution points for a given group policy.