Courtesy of www.simple-talk.com – Joseph Moody
When you have a large number of PCs in the domain on which to deploy software, based on the role of the user within the organization, and you haven’t a large budget, then Group Policy Software Installation is a good and simple way to do it.
Being able to deploy and manage software is a critical skill for any administrator. After all, who wants to install software manually! This article will walk through each step of this process, from extraction through installation, by using Group Policy.
To Use or Not to Use?
The pace of technology has always amazed me. No matter the tool or technology, we are still solving the same core problems. One main issue has always been connecting people to the software they need. Methods of accomplishing this vary from basic batch files with limited functionality to complex software management systems with mountains of features. Sitting right in the middle of this range is Group Policy Software Installation (GPSI).
GPSI is made simple by being natively available in any Active Directory Domain Services environment, which means no additional server components are required. A Domain Controller paired (or combDeplined) with a File Server constitute the only requirement. Because the Group Policy service handles the client side, your users and computers do not require anything extra.
Simple in nature, GPSI does lack certain features found in dedicated software management systems (such as System Center Configuration Manager). First, GPSI does not have a central reporting component. The logs, though detailed, are stored on clients. Also, GPSI can only deploy two file types (MSI and ZAP). Finally, installation requires either a logoff or restart; it is a foreground only installation system.
If your organization needs a solid (but free) way to manage software, GPSI is the way to go. If you want to ensure certain software are available immediately on new domain machines, GPSI accomplishes that perfectly as Group Policy processes on first boot. Because it is built on top of Active Directory, you can use it to manage some or all of your software needs. Likely, you can take advantage of GPSI in some way.
A majority of enterprise software comes in a MSI format that is wrapped inside of an executable. Most of the time, the trick is getting that MSI out. The first step is to determine if the application actually contains an MSI. This is easily accomplished by launching task manager and running the executable. If the application contains an MSI, task manager will show the Windows installer process (MSIEXEC).
From the picture above, we know that our software contains an MSI. Let’s get it out now. Method 1 of doing this is opening the EXE as an archive. Using a file compression program, we can attempt to open the EXE like a compressed folder. My favorite program for this is 7Zip. In the example below, I was able to open the iTunes setup executable by righting clicking on it and selecting Open Archive. As you can see, MSI galore!
Every MSI registers itself with your computer. Knowing this, you can use this information as your second method of retrieving the file. Open up REGEDIT and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products. Search for the name of the application and expand the source list key. Copy the contents of the LastUsedSource entry and open that folder on a local machine. With any luck, your MSI should reside there.
If your MSI is not there, you can also search a local computer for the PackageName value. Be sure to enable hidden and protected files before searching.
If your MSI is still missing, head on over to ITNinja.com (formally appdeploy.com). Likely, someone has found it and posted tips on getting it. Just search for your application (without a version number) to find helpful hints.
But what if your software isn’t an MSI? Check with the manufacturer first – it is not uncommon for one to be provided at request. If you are still stuck with an executable, it is time to repackage it to a GPSI friendly format!
Repackaging is the art of taking the entire executable (or the installed components of the software) and embedding it into an MSI. There are two schools of thought on doing this:
- Wrapping the EXE into an empty MSI. The MSI essentially calls the EXE and runs the application silently.
- Capturing all new files/registry keys that a particular software installs. Once captured, these settings are stored within an MSI for installation.
If given the choice, I prefer method 2 for repackaging. When using method 1, you are limited to software that can be installed with silent commands (/q, /silent, etc). Normally, software without an MSI lack other standard features such as these commands. Method 1 also prevents you from easily editing the MSI. By capturing an installation into an MSI, you can simply remove files (like a desktop shortcut) that you do not want in the final package.
Capturing an installation is fairly simple. With a clean machine, use a repackaging tool to look at the difference between a before snapshot and after (the installation) snapshot. My favorite tool for doing this is WinInstall LE (free edition). While you can certainly purchase heavy duty repacking programs, I have yet to find a software that couldn’t be repackaged with the free edition.
Editing the MSI
In all likelihood, your extracted MSI will need to be customized for your organization or edited for deployment. By editing an MSI, you can:
- Remove unnecessary files/registry entries
- Disable automatic updating
- Alter Launch Conditions (such as minimum Hardware, Software, or Operating System requirements)
To edit an MSI, download Orca from Microsoft Support. After installation, you can right click on any MSI and view it as a simple database.
From here, specific attributes of the MSI can be modified or removed. In the picture above, we are looking at the Shortcut table. By deleting any entry in this table, we can remove a shortcut. Two other common tables are the LaunchCondition and Property tables. The LaunchCondition table contains restrictions on the MSI execution. As an example, this table would limit execution of the MSI to Windows 7 and below. The Property table contains options for the MSI installation. If a software requires a serial number to install, you can probably paste that value into the serial number entry under the Property table.
As a best practice, avoid editing MSIs directly. By using Orca, you can select Transform and then Generate Transform. This will create an MST file that will apply your changes (without directly making edits).
Saving to Share
Once edited, the next step is to save your MSI to a network share. When we create our Group Policy Object (GPO) for deployment, this share will be our distribution point. Because you will likely store all of your deployed software in a central location, it is best to configure you Share/Folder permissions in a way that supports multiple deployment types.
Generally, your share name should be something simple and short (ex: \\SERVER\MSI or \\SERVER\APPS). If you prefer a little more obsecurity (i.e. Security through Obscurity), it is perfectly fine to hide the Share with a $ value.
For your share permissions, it is acceptable to give Everyone Full Control or to give Authenticated Users Read permission and Administrators Full Control. For the folder permissions, give Authenticated Users Read/Execute and Administrators Full Control. Remember that Authenticated Users includes both Domain Computers and Domain Users. Finally, create specific folders for each manufacturer or piece of software. In the picture below, you can see a sample hierarchy organization.
Creating the GPO
Now that the MSI is on the network, let’s link it to a GPO. Create a new unlinked GPO. As a best practice, give the GPO a specific name (usually with a related starting prefix). In our environment, all deployment GPOs start with “APP_”. This allows for easy filtering, sorting, and scripting.
Now decide whether to install the software to the computer or link it to a user. Generally, if the software is static (used consistently at one or many locations), large, or requires regular updates – deploy it on the computer side. If the software is small and used by specific users, deploy it on the user side.
In this example, we are going to create a GPO named APP_7Zip and we will create a corresponding security group named after the GPO. We will then edit the Scope options on the GPO to remove Authenticated Users and to add in our new security group. If you plan on deploying a lot of software, it is best to store these groups in a central location such as a top level OU or physical site level/department OU.
As a general recommendation, avoid extremely detailed GPO and Security Group names (ex: APP-7Zip_v9.00.1.2). Version information, language, and OS type can all be found (or commented) within the GPO itself. Using a general name will keep you from constantly renaming policies.
Edit the GPO. We are going to deploy this MSI to the computer side so we will navigate to Computer Configuration\Policies\Software Settings\Software Installation within the Group Policy Management Console.
Right click on Software installation and select New Package. Browse to the UNC where you stored the MSI.
After selecting Open, choose the Advanced Option and press Ok. Select the Deployment Tab and then Advanced. Check “Ignore language when deploying this package”. This will ensure that if an MSI doesn’t have a language set, deployment will still continue. If you created an MST with ORCA, select the Modifications tab and add the MST. Press OK, make any other changes needed to your GPO, and link it to an OU. Be sure to add any computers to the software security group. Finally, restart the computer twice. After two restarts, your software will install!
But What if it Doesn’t?
Like anything made by man, GPSI can break. Most of the time, it is a pretty easy fix though. Below are the troubleshooting steps I take when faced with an installation problem.
- Does the MSI install normally if I run it on a computer? If it won’t install this way, I know Group Policy isn’t at fault.
- Can you run the MSI silently? EX: msiexec /I MSI-FILE.msi /qb. If the file can’t install silently, I know Group Policy isn’t at fault.
- Am I deploying the MSI to the correct object (user or computer)? Some MSIs can’t install to a user and some only want to be installed to a user.
- Do I see any errors in the event log under application?
- Is the policy being applied correctly? Running GPRESULT /h Report.htm /f will generate a detailed Group Policy Result.