Examples of database "tables" within an MSI OSS file include
component
class
Registry
RemoveRegistry
file
RemoveFile
property
InstallUISequence
Figure 8 shows a view into this table and column structure using a tool called ORCA. ORCA is available within the Windows Installer SDK, and lets you edit an .msi file using a raw OSS view of the database. When you build an MSI file, these tables and columns are populated by the packaging tool and used to describe the parts of the application in an intelligent way.
The second side to software installation, the Windows Installer service, is just that — an NT service that is installed on every Win2K device by default. The executable that comprises the Installer service is msiexec.exe. The Installer service is the piece of code that does all the actual installation work when an application is published or assigned. The Installer service runs in LocalSystem security context by default. As such, it has the ability to perform any system changes that a normal user account would not have sufficient rights to perform. But the Installer service has another unique ability. That is, when a user clicks on a shortcut representing an application that has been deployed using a GPO, the Installer service can not only perform the install on LocalSystem’s behalf, but also perform parts of the install on the user’s behalf.
Where does this come in handy? Well, in NT 4.0, an application that made changes to the Registry in both HKLM and HKCU would have to be packaged in two pieces. One piece would make the changes to HKLM and those parts of the system to which the normal, non-power, non-administrative user lacked access. That piece was usually delivered to the machine via a system service like the AT scheduler or a third-party tool, such as those included in the Microsoft Systems Management Server. Then, at some later time, perhaps at logon or application startup, the HKCU changes for that application would be delivered to the user under their security context using logon scripts, system policies, or application startup "wrappers."
This two-part process was disconnected, and therefore difficult to manage in a large environment. With the advent of the Windows Installer service and MSI, you can deliver an application to users as a single event that they initiate when they need the application. And, as the next section makes clear, you can also define an MSI package so that only certain features (e.g., required pieces such as Word functionality or optional pieces such as spell checker) within an application need be installed when the user clicks the icon or activates the extension. I review more about how the Installer service interacts with the Registry to install applications later in the chapter.
In addition to installing MSI packages, the Installer service is responsible for determining when an application is broken — and fixing it. It does this through the use of key files, as I explain later in this chapter. The Installer service can also roll back an application installation if it fails at some point before completing. While an application is installing, temporary files are created in the temporary folder %systemdrive%\config.msi. These files are used to undo what has been done when a rollback occurs.
Using MSIEXEC from the Command Line
Even though the Windows Installer is a service, it can be invoked interactively against an MSI package. Note that when you invoke an application install from the command-line msiexec.exe, you don’t, by default, get the elevation of privileges that occur when you’ve published or assigned an application via Group Policy. That is, if you’re not a Power User or Administrator on the machine where you’ve triggered the install, it may fail with insufficient privileges. When you want to install an MSI package, you have numerous command-line options, several of which are shown in the listing in Figure 9.
Note: In the listing in Figure 9, the options marked with asterisks (*) have additional suboptions available. Check out Microsoft’s MSDN Online Library (http://msdn.microsoft.com) for full details of these additional options.
Products, Features, and Components
MSI and the Windows Installer provide the capability to package an application so that users install only those portions of the application that they need and use. Other optional portions, however, get faulted in when users first invoke them. An example of this from the pre-Win2K days is the option within most setup routines to choose a custom setup. The custom option generally lets you install only those components that you really want. For example, in Microsoft Word, you could choose to not install clip art or WordPerfect Help if you didn’t plan to use them. If you later decided you wanted those options, you had to find the media and rerun setup to add them.
The MSI way of doing things is much more modular and therefore more adaptive to adding and removing components. Specifically, an MSI package specifies a three-tiered hierarchy to define applications. The three tiers are
product
feature
component
A product is the coarsest distinction for an application. Microsoft Word and Excel are products. When you install a product, you are installing an application — the terms are synonymous. Products, however, are made up of features — for example, Word’s spell-check feature and Excel’s SQL database access. Features, which are specific to the product, contain components — the lowest and most granular portion of the MSI hierarchy. Components can be shared across multiple products and their associated features.
A component is a set of files and Registry entries that define a feature’s function. Using our example of the spell-check feature, a component may contain the spell-check .dll and associated Registry entries that enable it. The intention is that a component contains only one .exe, .dll, ActiveX Control, or Help file. In that way, you can properly compartmentalize component function and ease sharing of components across features and products. Likewise, if you have a file that is, for example, a .dll, that same version of the file should not occur in more than one component. (If it does, it can be difficult to maintain portability of components across other features and products.)
Note: MSI components are not the same as COM components (e.g., the spell check .dll may be a COM component). MSI components can include COM components, but they are not the same things. Figure 10 illustrates the relationship between the product, feature, and component.
When you build an MSI setup package, you specify the product, features, and components that comprise your application. Within each component, you can specify what is known as a key path. The name can be misleading because a key path can actually be a file or a Registry entry that you decide is an important dependency for your application. Information about the key file or Registry entry for a given installer component is actually stored in the Registry. If that key file or entry is missing when the application starts, then the Installer service reinstalls the component with the missing key path. Figure 11 shows how — using InstallShield Corporation’s InstallShield for Windows Installer packaging application — I can specify a key file within my MSI package.
The example emphasizes the importance of "featurizing" your application in a way that makes sense. For example, suppose you created an MSI package of a 10 MB application and created only one feature and one component within that feature that contained all of the files and Registry entries that compose that application. Now, you decide that the main executable for the application is your key path for that one component. Somehow, you then delete that executable. The next time you start the application, the Installer service detects the missing key file and reinstalls the component, which in this case is the entire application. Now, if you had created several features, each with one or more components containing key paths, then only those components whose key paths had been deleted would be reinstalled.
Note: Transforms (introduced with the Windows Installer technology) are modifications to a base MSI package that let you customize an application installation at install time. For example, if you have purchased a third-party application that already has its own MSI file but you want to customize the default settings to meet your environment, you can use transforms. If you ever modified those ACME setup STF files that came with older versions of Office, then you can appreciate the functionality that transforms provide. You define a transform when you publish or assign an application within the Group Policy tool. The Modifications tab within the application’s properties lets you add transforms. Transform files end in .mst extensions. Transforms also let you define which features for a product are installed initially and which are faulted in on first use.
The Mechanics of Products, Features, and Components
Now that we have taken a high-level look at how MSI packages are broken down, let’s look at some of the interactions between MSI packages and the Registry. The first thing to understand is how products, features, and components are identified. Both products and components are named using a unique 128-bit GUID. Features, however, are given simple names that help identify what function they provide. There are two main keys in the Registry, identified below, via which products, features, and components are tracked.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer — This area contains details about all currently installed products, features, and components (Figure 12), including component names and showing which components are associated with which features.
HKEY_CLASSES_ROOT\Installer — This area also contains information about installed products, features, and components, including the name of the network or media share from which the MSI product and feature was installed. This key also contains information about COM components that have been advertised by MSI packages but not yet installed. This information can be used to fault in these components when a calling application needs them. (Figure 13).
The Installer service uses these Registry keys to determine whether and when an application is incomplete, and if needed, where to get the install media in the event of a reinstall.
THE EXPLORER SHELL AND THE INSTALLER SERVICE
Now that we have looked at the process of packaging and installing applications using the Windows Installer, let’s look at how the Explorer shell interacts with the Installer service to know when it is time to fault-in your assigned applications. As I mentioned previously, when you assign an application, three things (as defined within the MSI file) can happen: a shortcut can be placed on the user’s desktop, a file association can be made, and any COM classes that are included in the application can be registered. When I click on an assigned shortcut or open a document with an assigned file association, how does the Explorer shell know to go to the AD and find out where the MSI package for that application is? It uses "installer tokens," special tags that the shell interprets to discover that it is dealing with an assigned (or published) application. Win2K changes to the Explorer shell and COM let these applications identify installer tokens for what they really are. Shortcuts delivered by assignment also contain installer tokens, but if you try to view them by examining a .lnk file’s properties, you don’t see any meaningful information. Figure 14 shows an example of an installer token on a file association — in this case, the Excel file extension .xls.
The Registry value called "command" contains the installer token that tells the shell that this application has been assigned. The same method is used on COM objects that have been assigned as part of an application (Figure 15). In this case, the value InprocServer32 under the InprocServer32 key contains the token instead of the path to the actual DLL or OCX.
Note: In both Figure 14 and Figure 15, the application has already been installed, so the actual Executable or .dll path has also been registered in the key.
Once the Explorer shell detects an installer token, it passes the token to the Installer service, which is its cue to communicate with the Registry to determine where the MSI package for the application physically resides. Once that information is secured, the Installer service begins the install.
THE ACTIVE DIRECTORY CLASS STORE AND THE REGISTRY
The Registry plays a key role in keeping information related to applications and COM components installed on a system. Indeed, HKEY_CLASSES_ROOT could be considered the application Registry, because it keeps all the information related to how and from what location machines and users run installed applications. The downside of the Registry is that it resides on each individual machine within your network. If you have 10,000 workstations, then you have 10,000 local Registries.
To make matters worse, there has been no easy way to ensure that over time the registries contain the same information. For that matter, there has been no easy way to determine whether all 10,000 were the same at any point. If you wanted to push a change to all 10,000, you had to figure out a way to "touch" each of those 10,000 local Registries with your change.
With Win2K comes the great invention called the AD, a global repository of interesting objects, like users, groups and, of course — applications! The Class Store is another kind of object in the AD. The Class Store is associated with GPOs. That is, when you publish or assign an application within a GPO, a Class Store is created that reflects the COM Classes that the application has registered. Figure 16 shows an example of a set of classes, identified by their GUIDs, which an application has registered
I can view this information by using the Active Directory Manager MMC snap-in, and selecting the View option for Advanced features. Under the System container is a Policies sub-container where all of the policies defined for my domain are stored. As you can see, the Class Store can be either machine or user specific, depending upon whether I have defined application deployment for machine or user. When I publish or assign an application, the MSI package is interrogated by the Software Installation Policy Editor (ADE) to determine all COM classes defined within that package. These classes are then stored by GUID in the Class Store.
When an application at a client workstation calls an interface belonging to a COM component for an application that has been deployed using Group Policy, the COM code on the client notices the installer token in the Registry for that GUID. This information came from the Class Store when the application advertisement was delivered to the workstation. Information stored in the Registry about the component in question then tells the application where to find the msi package that contains the component, and it is faulted in the first time it’s used.
In Win2K, the Class Store is really a kind of "centralized Registry." You can use it as a repository for shared components to which you want to provide access for all users. Of course, the Class Store is only a centralized Registry for a portion of the Registry’s total functionality — primarily, it is a centralized HKEY_CLASSES_ROOT. But, given the size and complexity of Registry-based shared components in a large environment, it still provides a big advantage.
The MMC offers a good example of how you can use this powerful feature. MMC snap-ins are really COM "servers" that provide management functionality within the context of the MMC. Additionally, with the MMC, you can create pre-designed "tools," which are MMC .msc files with a set of snap-ins, loaded in a particular view. The advantage of creating tools is that you can give these to your administrators to perform specific, predefined tasks without exposing other areas of administration for which they have no responsibility.
An MMC snap-in usually comprises one or more .dlls and their related HKCR Registry entries. However, not all of Win2K’s management snap-ins are installed on client computers. For example, the Active Directory Manager snap-in is only installed on domain controllers by default. However, if you were to create an MSI package for this snap-in DLL and publish or assign it in a Group Policy, then other users would have access to it and have it faulted in when they launch the MMC tool that you have built for them. Clearly, the Class Store opens up a way to centralize the registration of COM components. This alone goes a long way towards easing the burden of maintaining hundreds or thousands of decentralized Registries.
SUMMARY
In this chapter, you have seen how such new features as Group Policy-based Administrative Templates and Software Installation interact with and use the Registry. The chapter explored how the Windows Installer and MSI packages work together to install applications to the Registry and file system in both system and user security contexts. I introduced the installer token, which is a new way of representing a path to an assigned or published executable or .dll, one that works with the Explorer shell and COM to inform the Installer service that the AD contains the information needed. Finally, I reviewed the Group Policy-based Class Store, a kind of centralized version of HKEY_CLASSES_ROOT that lets you publish COM class registrations in the AD.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
