(Read Post 1: Introduction, Post 2: Useful Cmdlets, Post 3: Organizing Your Code, Post 4: Authoring Cmdlets and Working with REST APIs, Post 5: Working with WMI, Post 6: Enforcing Absence of an Application)
In last week’s installment, we reviewed a method of ensuring the absence of an application and the difficulties introduced by the overall Windows environment. This week we will discuss how MSI Installers can simplify your efforts and why, when possible, you should always choose them over other installers.
What is an MSI?
Microsoft Installers, commonly known as MSI installers, are a component of the Windows operating system used for the installation, maintenance, and removal of software. Prior to the introduction of the Windows Store and “Modern” Applications with the release of Windows 8, Microsoft encouraged third party vendors to utilize MSI installers to ensure consistency of the Windows operating system’s internal database of installed products. Unfortunately, since this was not a mandate, many third-party vendors went with other installers, promoting the necessity of last week’s installment.
What are the advantages?
MSIs provide a variety of benefits over executable installers, the primary being standardization across multiple vendors. This allows administrators to effectively support a variety of installations without the need of domain knowledge specific to each application. Many components contribute to this, but some of the key ones are listed below:
Standardized exit codes
Exit codes for all MSI installations are well documented and generally do not change. These can be found here.
Standardized state management
One of the most difficult parts about managing software in any environment is determining its state on any given endpoint. Since all MSI installs create an instance of the Win32_Product class, determining the presence of an application is as easy as a one-liner in PowerShell.
Product codes
MSI installations all have a unique GUID identifier that can be used to identify specific installations. This GUID identifier is generally referred to as the Product Code.
Transactional operations
All MSI operations are transactional. This means that for every action an MSI installer takes there is an equivalent rollback action. Whenever an error occurs, the MSI installer will revert any changes it has already made preventing partial installation and corrupt states.
Real-world scenario #5: Managing MSI installations
So, we know MSIs are awesome, but how do we work with them? This week’s scenario will be a handful of small examples demonstrating how to manage MSI installs. Let’s dive right in!
Detecting Install State
Detecting the installation state of an application installed with an MSI is as simple as reading from a WMI class, specifically Win32_Product.
The IdentifyingNumber property is the same as the Product Code which we mentioned earlier. Because this is unique to the installation, we want to use it to accomplish any other tasks we may need to complete. As such, we are also going to use it for our evaluation script. If you are planning on using this inside an Automox Custom Policy, remember to exit with a 1 or a 0, dependent on the need to remediate.
Installation Using MSI
Now that we have the evaluation script, we can start working on remediation. The good news is that this is also a small effort. The first step is to acquire the MSI file from the vendor. Using Automox Custom Policies, you can upload this file which will be distributed to the endpoints that require remediation. This file will be placed in the same folder from which your remediation script will execute. When referencing the file, you can use the PSScriptRoot variable as shown below:
You’ll notice that there seem to be some extra quotations in the assignment of the $path variable. Essentially, we are wrapping the value of the $path variable in quotations to prevent any errors that may occur from spaces in the path or filename. As you may have guessed, the ` character is treated as the escape character in PowerShell:
Another thing to point out is the arguments that we use in the Start-Process call. When installing MSI products through the command line, msiexec is your best friend. This tool facilitates most MSI operations and supports a variety of command line switches which you can reference here. In our instance, we only used two:
- \I - Installs or configures a product
- \qn - Indicates the installation will be ‘quiet’ with no interface
- \L*v <log path> - Bones. While not used in this example, it is still worth noting. You can use this switch to have the installer generate a verbose log of the installation in the specified location which can make it easier to troubleshoot any failed installations in the future.
Once the installation is complete, the script will exit with a 0 status indicating to Automox that the remediation was successful. It’s important to wrap your execution code in a try-catch and return 1 in the catch block in case any errors are thrown.
Uninstallation Using MSI
For the uninstallation of an MSI product, be sure to modify the above evaluation script to return 1 instead of 0 when the desired application is found. This will tell Automox to remediate when the application is present. You can then use the same code in the remediation script to get the desired Product Code. Uninstallation of the product is then as simple as passing the product code to msiexec with the /X switch, which indicates the uninstallation of a product. As in the previous remediation script, you also want to return 1 or 0 as the exit code of the script to let Automox know whether or not the operation was successful.
Next Week
PowerShell provides a variety of tools that can be used for error handling, the most important of which you just saw used above (Try-Catch). Next week, we will dive into best practices and standards that should be followed with error handling in your scripts.
Automox for Easy IT Operations
Automox is the cloud-native IT operations platform for modern organizations. It makes it easy to keep every endpoint automatically configured, patched, and secured – anywhere in the world. With the push of a button, IT admins can fix critical vulnerabilities faster, slash cost and complexity, and win back hours in their day.
Grab your free trial of Automox and join thousands of companies transforming IT operations into a strategic business driver.
