Using GPOs to install packages in the AD domain

• Concepts
• GPO Model 3
• Creating Packages with Admin Studio
• Creating a Clean Machine
• Upgrading Packages with GPOs
• Needs
• Notes
• Terms
• References

• There is a software repository location that is shared to Everyone
• In the software repository share there is a directory for each software package. These directories are set to only allow full access to Domain Admins and allow Domain Computers Read and Read & Execute permission. This allows computers in the AD domain to install assigned software packages but deny install access to users.

• One GPO per application
• Use a special GPO for all core apps?
• Use GPO group security to control GPO application to a computer
• Assign apps (advanced assign for .mst)
• Use computer configuration and disable user configuration in each GPO
• Use groups to organize computers
• Put application groups in a Groups OU

• There is a group for each application.
• Each application group contains all the computers that need such application installed.
• There is a GPO for each application.
• Each application GPO has the corresponding application group listed in its security tab.
• Each application GPO has the Apply Group Policy security allowed for the corresponding application group.
• Each application GPO has the Apply Group Policy security not allowed for Authenticated Users.
• The core apps GPO does not use group security and has Apply Group Policy allowed for Authenticated Users.

There must be at least three computers involved in this process.

• The first is a server (e.g. aocpfsa) containing a packages share. This share will be called, for example, packages.

• The second is a computer (e.g. aoctsa) that has the Admin Studio software installed. Then share the
  \Program Files\Macrovision\AdminStudio\8.0\Repackager directory. This share will be called, for example, repackager.

• The third is the clean machine (e.g. mulligan-vmw-clean) which is a basic install of the Windows operating system with no added software. VMWare can be used for this as well, especially utilizing the snapshot feature.

Once these three computers are in place and ready, we can begin the MSI creation process.

1. From mulligan-vmw-clean, map the packages share to a network drive (e.g. P:).

2. From mulligan-vmw-clean, map the repackager share to a network drive (e.g. R:).

3. From mulligan-vmw-clean, launch the repackager with R:\islc.exe and click on Capture an Installation Using Repackaging Wizard and answer the following in the windows to come...

4. Welcome to InstallShield Repackaging Wizard
   Next

5. Method Selection

   Installation Monitoring (Recommended)

   Collect Product Information Program File: path to software installation program Product Name: Program name Version: version number The version number should start with 1 and increment each time a new package is made for that version of the software. In practice, most version numbers will remain 1, but if we ever have to recreate a package because of mistakes or patches then the version number would let us track that. Next

   Snapshot

   Snapshot Method Multiple Steps (Classic Style) Summary Finish Now install the software like you normally would. Be careful not to do anything that is not necessary to the installation as these changes may appear in the resulting package. However, if the software requires a reboot or to be launched the first time, now is the time to do this. From mulligan-vmw-clean, launch the repackager again with R:\islc.exe and click on Capture an Installation Using Repackaging Wizard and answer the following in the windows to come... Welcome to InstallShield Repackaging Wizard Next Method Selection Snapshot Snapshot Method Multiple Steps (Classic Style) Analyze system status changes Collect Product Information Product Name: Program name Version: version number The version number should start with 1 and increment each time a new package is made for that version of the software. In practice, most version numbers will remain 1, but if we ever have to recreate a package because of mistakes or patches then the version number would let us track that. Next

   • Set Target Project Information and Capture Settings
     P:\program name-version number (e.g. p:\mainsaver-8.2.002)
     Start

   • Summary
     Finish

6. The repackager window should now come up. This provides an opportunity to double check the files, and registry entries that will be in the package. You can exclude registry entries by right clicking on them and selecting Exclude All. Common things to exclude from the msi registry are...
   
   • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
   • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer

7. When ready, select Build -> Build from the top menu.
   If using vmware, do not lock the screen. Doing so may stop the vmware machine.

8. Be sure to test the msi on different versions of Windows (e.g. 2000, XP) for compatibility.

HKCU and Repairing Packages the first time

If there are any entries in HKCU then when a user runs the program for the first time it will have to contact its source msi to repair itself. This can be annoying if the source msi is not available. Look in the Windows Application Log and find the corrosponding error with a really long like '{141BEAD3-3708-47D9-95D7-EF21CDA0E076}'. Then open Developer and open Organization -> Setup Design and look through the components like CreateFolder_Help and check the Component Code for a match. These components can be removed from the package by right-clicking on the component and selecting Remove from feature.

To convert HKCU to HKU (.default) when making and MSI package, a copy of the MSI is kept in c:\windows\installer (its hidden) and when a new user logs in the msi is executed and settings applied to that user. This is how the repair process works.

Version Numbers

Using the InstallShield Repackager Wizard, at the Collect Product Information window, the Version number must be in the format of major.minor.build.revision where major and minor are numbers between 0 and 255 and the build and revision numbers are between 0 and 65535. This is one of the lamest limitations of which I have ever heard.

How to install an MSI manually

The documentation for msiexec lies (as usual with MS) the /T DOES NOT apply a .MST. In order to do that you have to do something like this...

msiexec /i <file.msi> [TRANSFORMS=<file.mst>[;<file.mst>]] /qb

• turn off system restore
• turn off automatic windows updates
• install the VMWare tools

This requires a break from the one-GPO-per-package-version idea that we had evolved. It would now be something like one-GPO-per-package. For example, just have a GPO and group called AOCputty and apply the putty-0.56 and or putty-0.53b package to that GPO.

1. Right click on the OU and select Properties.
2. Click on the Group Policy tab.
3. Select the GPO containing the package you wish to be upgraded and select Edit.
4. Right click on Computer Configuration -> Software Settings -> Software installation and select New -> Package and choose the MSI.
5. Now, right click on the MSI and select Properties and then the Upgrades tab and click Add.
6. Select Current Group Policy Object (GPO) (I still don't know how to upgrade packages selecting A specific GPO. It should allow us to keep our model of one GPO per package version but I have yet to get it to work. Basicly, it never uninstalls the old package.)
7. Select the package you wish be be upgraded from the list under Package to upgrade.
   • To replace an application with a completely different application (perhaps an application from a different vendor), select Uninstall the existing packages, then install the upgrade package. In my test using putty, the personal settings were retained after the upgrade but this may be because I think putty just puts a file in your documents and settings, of which the MSI shouldn't know.
   • To install a newer version of the same product while retaining the user's application preferences, document type associations and so on, select Package can upgrade over the existing package.
   • Which method you choose may depend on the package and how it keeps its settings. I have had success with Putty and Mozilla using the first option; Uninstall...

Selecting the A Specific GPO doesn't work. Here is what happens...

• selecting Uninstall the existing packages, then install the upgrade package does not remove the previous package(files, directories, registry settings, etc are all left in tact) and settings (with putty at least) were kept for the new version.

• selecting Package can upgrade over the existing package does not remove the previous package(files, directories, registry settings, etc are all left in tact) and settings (with putty at least) were kept for the new version.

• In fact, I have yet to see a difference between those two options.

• Some way to do reverse lookups in the GPOs. In other words given a computer, what GPOs allow that computer access. This will tell us what software each computer has installed.

• We might want to add Administrator to every software repository directory so that packages can be installed manually.
• Assigning packages to a machine allows any user on that machine to use the package. The package is installed at boot time before any user logs in.
• Unlinking the GPO does not necessarily affect the software installed on the machine. However, if the Uninstall this application ... management box is checed, unlinking the GPO will uninstall the package.
• For a computer to be effected by a GPO that computer must be in the OU associated with the GPO. For example NM\Computing instead of just Computing.
• When you make a GPO, select the Unselect this application ... management
• After a package is installed the first time which can take minutes for large packages like Office, the next time the machine reboots it does NOT take that long. Windows must be doing some checksumming or something smart (good for windows).
• Use secedit to force immediate refresh of GPOs. (e.g. secedit /refreshpolicy machine_policy /enforce) or use gpupdate if you are using WinXP.
• We want to use Windows Installer (.msi) packages instead of WinINSTALL (.nai) packages.
• Kevin has a gateway E-4200 with a 3com 905B that has to be plugged into a hub, otherwise it cannot DHCP its address. We don't know why.
• With groups linked to a GPO, you can remove an application from a computer by simply taking that computer out of the necessary group.
• you can use the Msiexec /i command to do a silent install of the .msi file from the command line.
• It is not clear to me that you can do anything with an .mst that you cannot do with an .msi. The .mst may be easier to create and apply to many .msi's but I don't think it provides any more functionality. However, changing the vendor supplied MSI may be a violation of the EULA, so .mst's may be useful for this situation.
• You can use GPO's to apply mst's to msi's. You have to right-click the packages, go to properties and select Modifications tab to add mst's.
• There appears to be about a 15 minute time period between when applications are put in GPOs and when the clients will install said applications.
• msiexec can be used with an INSTALLDIR= option to change the location of the installation of the package.

Time it took to install OfficeXP and Putty MSI's via GPO assignment.

Machine	Processor	time
bud	PII 450 MHz	13 min.
mulligan	P4 3 GHz	8 min.
spaten	Celeron 2GHz	8 min.

• Publish application: requires a logoff for the app to appeare in Add Remove programs. It also allows the user to remove the application.
• Assign application: You can assign to either a user or a computer. If assigned to a user, this will put the application in the start menu or on the desktop for that user. If assigned to a computer this will install the application after a reboot.

• The Microsoft Installer
• Creating Windows Installer Packages and Repackaging Software
• Software Installation and Maintenance
• c|net
• purdue