As I write this, the vast majority of developers are running as administrators on their own machines as they develop code (WhatIsANonPrivilegedUser). If a developer needs a new software application, she just pops in the installation disk and installs it herself. This leads some developers to think that this is how software is installed everywhere. I just want to point out that this isn't the case in many enterprises.

In a secure domain environment, to prevent chaos and accidental (or even purposeful) security breaches, most users don't have administrative rights on the machines they use. The domain administrator is in charge. So how does software get installed throughout an enterprise if the users themselves don't install it? Does the domain administrator roll around on his chair to each workstation installing the software manually using the power of his administrative login? I hope not! As of Windows 2000, a feature known as "IntelliMirror" makes deploying software thoughout a domain (or an entire enterprise) considerably easier. This feature is designed to work with the Microsoft Installer, so to get the most out of it you really need to deploy software using MSI files.

IntelliMirror works through group policy (WhatIsGroupPolicy). There's a folder in each group policy object called Software Settings; well, actually, there are two of these: one under the Computer Configuration section and one under the User Configuration section. If you drill into either of these folders for a group policy object in Active Directory, you'll find a node called Software Installation. If you have an MSI file you'd like to deploy, you have three options. You can "publish" the file, in which case it becomes available to users from the control panel via Add/Remove Programs. Or you can "assign" the file, which is a little more functional. If you assign the file to a user, a link to the application shows up on that user's Start menu the next time she logs in. The first time she clicks the link, the Windows installer installs the application. The Windows installer runs as SYSTEM, so you have plenty of privilege (arguably too much in many cases!) to install whatever files are necessary. Finally, you can assign the file to a computer and, the next time the computer boots, your MSI file will be run by the installer, once again as SYSTEM. I've shown an example of this in Figure 75.1. This is how many companies deploy patches, service packs, and also .NET Framework code access security policy.

Figure 75.1 Deploying software via group policy

Why am I telling you this? Well, for two reasons. First, if you have some piece of software that you need to install throughout a domain or enterprise, you should make sure you build an MSI installation so you can take advantage of this feature. Just knowing that this feature exists is useful! Second, you need to realize that if your software is deployed this way, it will be installed under one security context (and a highly privileged one at that) and run under a different (restricted) security context: the user of the workstation where your software is installed. So, as I discussed toward the end of HowToDevelopCodeAsANonAdmin, be sure you design your application with these two security contexts in mind. Your installer program shouldn't be messing with any settings in the user profile (WhatIsAUserProfile), for example, because it won't be running in the security context of any legitimate user who will be using the application. It will most likely be running as SYSTEM. Keep these deployments in mind when writing installers.

PortedBy WestonBinford