I was asked a question the other day about determining is the version of a particular application that is installed was package internally for enterprise distribution, or installed out of the box by the user with the MSI.
To do this, we will need to perform the following tasks…
- Create an MSI transform (MST) file for our installation MSI
- Add registry keys and values that we will refer to with DCM in ConfigMgr (CI and Baseline)
- Add properties to the Property Table within the transform to populate registry values during installation
- Create the Application Deployment in the ConfigMgr 2012 console
- Modify the command-line for the deployment type to include our transform
- Create the CI and the Configuration Baseline
- Create a Collection for the machines that will evaluate compliance with the baseline
- Deploy the Configuration Baseline to the collection we created
- Use the Baseline deployment to generate a collection of non-compliant machines (machines without our packaged application, or have the application installed out of the box)
- Remediation of the non-compliance using a required deployment that removes the unpackaged version and then installed the enterprise version we want.
Step 1 – Create the transform (MST)
To create our transform (MST) file, we will use Flexera AdminStudio Configuration Manager Edition. This utility is free to those who have a licensed version of System Center Configuration Manager within their environment, and can be downloaded HERE. You will need to register for a serial number to enable this software as well.
Once installed, perform the following actions to generate the MST file.
- Launch the Tuner Application
All Programs -> AdminStudio -> AdminStudio 10.0 Tools -> Tuner
- Once the Tuner application is open:
- When the installation wizard begins, enter the choices that you wish all future installs of this application to have. Once completed click finish at the end of the wizard.
- NOTE: There may be other items within the transform that need to be edited for enterprise distribution, but I am not going to cover those here. If anyone would like, please let me know in comments and I can try to blog about common items to edit in MST files.
- After you’ve clicked finish and the wizard closes, you will see the results in the turner application.
Step 2 – Create the registry entries
- In the navigation pane, select “Registry” from the list.
- Ensure that the “[ProductName]” key is selected, then in the “Destination Computer Registry Data” view, Right-Click and create five (5) new string values.
- Rename and modify each of the string values as follows by right-clicking on each.
You may also add the uninstall command to this registry hive by adding the following string value.
- Uninstall-Command = msiexec.exe /x [ProductCode] /qb-!
Step 3 – Add needed properties to the property table
In Step 2 above we created registry entries that utilize MS Installer properties to populate their values. Two of them are custom properties that we will need to add to the property table within the MST file so that they are populated and do not cause our install to fail. The properties are “ITBuild” and “ITRevision”.
These properties refer to the internal IT Organization’s build and revision number of the package. Using these, we will later be able to ensure that only the intended version of software is installed on client machines.
To add the properties to the property table, perform the following tasks:
- Navigate to the Property Table by:
- Using the steps above add a second property and rename both of the properties added and give them both a value of 1.
- Save and close your MST file
The last thing we need to do is test our installation. For this example, we used the Cisco VPN client.
To test the install we will use the following command line.
- msiexec.exe /i <pathtomsi>\vpnclient_setup.msi TRANSFORMS=<pathtoMST>\Demo_vpnclient_setup.mst /qb
Once the installation has completed, we can then look to see what has been written to the registry of the test client. You should see something similar to the screenshot below.
In part 2, we will publish the package in ConfigMgr using the new Application Model, then create a configuration baseline that uses the registry keys, and finally collections based on compliance to that baseline.