Home > Blogs > VMware ThinApp Blog


Notes and Considerations on Deploying ThinApp Packaged Applications via Active Directory Group Policies

We recently did some research on how to best deploy a ThinApp packaged application by pushing the ThinApp packaged MSI out to workstations via an Active Directory Group Policy Ojbect.

GPO Deployements of ThinApp MSIs 

When deploying MSI's via an Active Directory Group Policy, there are a number of options that can come into play. Solid consideration of which options to utilize and the proper configuration of those options to allow for a GPO Package to deliver a ThinApp MSI Package will be the key in utilizing a GPO to deliver ThinApp packaged apps to your PCs.

Disregarding ThinApp for a moment, what we've got to remember here is that with our network environment we have a very large puzzle with vast number of multi-faceted pieces of technology where each piece can fit into large number of other pieces. The question we must keep asking ourselves is, "Is this piece of technology the best fit – not just the best fit into the network puzzle, but the right fit into this specific section of the puzzle?"

Bringing ThinApp back into the equation, we now have more options all around because we can now separate pieces which were previously forced together with regards to applications being tied to operating systems.

GPO Assignment – User or Computer and How?

When setting the GPO up to push applications, you'll need to consider how your environment is configured and how your users work. Things which should be considered are:

Is there only one user per workstation?
Are users given local admin permissions on their workstations?
Do users roam between workstations?
How are user and computer objects arranged within Active Directory?
    Are there clearly defined OUs by…
        …department?
        …geography?
        …a combination of departments and geography?
What other settings are defined by Group Policies which might conflict?
Are you implementing a VDI solution?
    Will users be given local admin permissions on their VDI workstations?
    Will users be getting a non-persistent desktop?

After considering the above items, let's first knock out the VDI solution. While it is technically possible to deploy applications to a VDI desktop environment via GPOs, I have my doubts that using Active Directory Group Policies to deploy ThinApp MSI packages is the best way to deploy applications to end user desktops. This is primarily because it is more time consuming to deploy MSIs than other options (i.e. ThinReg in a login script) and not as friendly to the end-user experience where some of those other means are. That's not to say there isn't a specific use-case for this type of configuration. I'm sure there is. But let's face the facts here. Who wants to sit and wait for a computer to install apps during the login process anyways? J

After taking the VDI solution out of the above mix, we're left with physical PCs which are either shared or not shared and end users who are static or roaming. Pretty simple, right? Well…maybe not quite yet. J

Now we're stuck with the Active Directory organizational structure. At this point we have two options. We can stick with what we have and create GPOs around the setup or we can modify the Active Directory organizational structure to fit our needs. Remember here that the Active Directory structure is truly what we make it – and the right way to configure it is the way that works best for our administrative needs and environment. Back in my consulting days I remember being asked time and again by customers who were just getting into Active Directory and needing assistance with setting it up, "What's the best way to configure Active Directory?" Microsoft has this huge document on Active Directory configuration theory (actually multiple documents on this), and after you read through it you can boil it all down to one simple conclusion, "The best way to configure Active Directory is what works best for myself and my environment."

At the risk of jumping into a side conversation, my point here is this.

The right way to configure your network is whatever way works best for you and your environment. The best way to configure your network is that way which keeps end users most happy, most productive, and support calls at a minimum.

Why bring this up here? Because it is this same philosophy which should be applied to the use ThinApp as well. ThinApp has a bunch of little pieces in it which may (or may not) be utilized to bring forth the best overall user experience. And making each end user's experience the best it can be is what our jobs are all about.

At this point, we're going to assume that you network administrators are appropriately familiar with configuring the Active Directory organizational structure and so if you need to change it to meet your needs, we'll assume you will know best since it is your network environment (a.k.a. "network puzzle") and you are the ones who will have to work in it.

To address the "How?" question, we want to specifically bring up two points with regards to configuring software deployment GPOs.

Should the GPO be applied to an Active Directory Organizational Unit which contains user objects or should the GPO be applied to an Active Directory Organizational Unit which contains computer objects? This is another question you'll have to answer with regards to what will work best for your environment as there may be a requirement in your environment where your users need to have the same applications no matter which workstation they log into. Or you may wish to have a subset of applications installed on a group of workstations. None of these ways are incorrect as it just boils down to what configuration works best for the environment.

User Permissions on the PC

So, what about user permissions on the PC? Well, here we have two pretty simple choices; is the user a local admin or not? Actually, we could add in a third choice for power users but that is irrelevant for the most part since users will either be able to install a ThinApp packaged application via its MSI or not.

What needs to be noted is whether the user is a local administrator or not since you will need to configure the MSI settings for the ThinApp packaged application within the project's PACKAGE.INI appropriately.

Configuration of your application package to allow user installation

When configuring your ThinApp PACKAGE.INI to generate an MSI, keep in mind whether you will be publishing or assigning the MSI to the user PCs as that will affect what you select in the PACKAGE.INI MSI Options.

For example, if you are going to "Assign" the GPO package, and your users do not have admin privileges on their own workstations, you will need to set the following:

MSIDefaultInstallAllUsers=1
MSIRequireElevatedPrivileges=0

The MSI Default Install All Users setting will need to be enabled so that it automatically is installed to the whole system. This is because the "Assign" option in the GPO will automatically install the application to the system but not to any specific user.

The MSI Require Elevate Privileges will need to be disabled, however, so that your non-admin users can install the application without issue. This setting is going to be required whether you assign or publish an application unless your users are local admins.

If you wish to only publish the GPO package which the ThinApp application's MSI is assigned to (vs. Assign) then the MSI Default Install All Users option does not need to be enabled and can be set to a value of "0" in the ThinApp project's PACKAGE.INI. This is because if the user wishes to utilize ADD/REMOVE PROGRAMS to install the ThinApp packaged application, then the application will likely only need be installed for that user. Disabling this option will allow the specified ThinApp packaged application be installed only to that user's profile on that workstation and no one else.

Upgrade options – what are they and which should be used?

As you may know, the use of ThinApp brings forth some upgrade options which you would not have available otherwise. In addition, using an Active Directory Group Policy Object to deploy applications – regardless of ThinApp – whether they are assigned or published to the user also provide some means of updating the previously deployed applications which were deployed in the same manner (i.e. GPO).

In this specific scenario, there are a couple of ways which a ThinApp packaged application deployed via MSI can be updated when deployed via a GPO.

  1. The original ThinApp packaged application can have AppSync parameters enabled and updated ThinApp packaged applications can be put on an internal (or external) web server or SMB file share which the original ThinApp packaged application is set to look to. In this scenario a newer MSI is not needed – only a newer/updated packaged application is needed (specifically just the data container) at the location where the original ThinApp packaged application will see it.
  2. The updated ThinApp project can be configured with the MSI options enabled so that when the package is built, an MSI is also created. That MSI can then be deployed via a modification to the Active Directory GPO.
  3. The updated ThinApp project can be configured with the MSI options enabled so that when the package is built, an MSI is also created. That MSI can then be deployed via any other means deemed viable (i.e. SMS, SVS/Altiris, Login Script, etc.).

MSI Settings which must be specified in a ThinApp PACKAGE.INI in order to update an older ThinApp packaged application deployed by an MSI

Options 2 and 3 above require the use of an updated ThinApp package MSI so let's discuss what modifications are needed within the updated ThinApp project's PACKAGE.INI in order to create an MSI which will overwrite an older ThinApp packaged application deployed with an MSI.

NOTE: For the purposes of this segment, we are not going to discuss how to update the ThinApp project here and will assume you know how to create an updated ThinApp project via existing methods such as SBMERGE, direct project modification (file and/or registry modifications to the project), or complete capture of a newer application.

The following are the items which must be modified in the PACKAGE.INI of the updated ThinApp project (or newer captured application ThinApp project).

  1. MSIFilename – The MSIFilename parameter must be set to a valid file name but can be set to one of your choosing. This means that you can set this to be something other than the name of the package or any of its entry points. A common practice is to set this parameter with the name and the version number to easily determine which version of the application is being installed.
  2. MSIProductVersion – The MSI Product Version number is a dotted numerical value used to determine the version information inside the MSI. By default, it is set to a value of 1.0 by the ThinApp Setup Capture.
    1. The first decimal location is the Major Version number and can be a numerical value from 0 to 255.
    2. The second decimal location is the Minor Version number and can be a numerical value from 0 to 255.
    3. The third decimal location is the Version Build number and can be a numerical value from 0 to 65,535.

      The MSI Product Version number must be modified specifically in the newer package to be a numerical value higher than that of the older package.
      NOTE: This does not need to equate to the application version number in any way. It just needs to be set to a higher numerical value than what is set in the original ThinApp packaged application's project.

  3. MSIProductCode – The MSIProductCode must be unique between the older and newer packages and must be a valid MSI Global Unique Identifier or GUID not in use. A product GUID is set from ThinApp's Setup Capture utility by default but may sometimes require modification in the event the older product GUID and newer product GUID are the same. To generate a new valid GUID we can use any number of utilities freely available out on the Internet such as GUID GEN. There are a number of web sites which offer free GUID generators and can be found by your favorite search engine.
  4. MSIUpgradeCode – The MSIUpgradeCode is used to define the application in the Windows Application Install Database for Windows operating system and must be identical between the older and newer packages so that application installation will properly detect itself.

While there are definitely other PACKAGE.INI options for use with creating an MSI, the above four items are what specifically need to be assigned in order a newer MSI created by ThinApp to replace an application deployed via an older MSI. Please see the ThinApp Online Documentation for additional information on the MSI parameters within the ThinApp project's PACKAGE.INI file.

Examples:

MSI Section of PACKAGE.INI for Mozilla Firefox 2.0.0.16
[BuildOptions]
;——– MSI Parameters ———-
;Enable MSIFilename if you want to generate a Windows Installer package.
MSIFilename=Mozilla Firefox (2.0.0.16).msi
MSIManufacturer=VMware Inc.
MSIProductVersion=2.0.0160
MSIDefaultInstallAllUsers=1
MSIRequireElevatedPrivileges=0
MSIInstallDirectory=Mozilla Firefox (VMware ThinApp)
MSIProductCode={DE77163A-D91B-E3FA-A9A4-7316A9BF0138}
MSIUpgradeCode={A5B0490E-6C52-42FA-A982-8488D1055A76}
MSIUseCabs=1
MSIArpProductIcon=%ProgramFilesDir%\Mozilla Firefox\mozilla firefox.exe,0

MSI Section of PACKAGE.INI for Mozilla Firefox 2.0.0.18
[BuildOptions]
;——– MSI Parameters ———-
;Enable MSIFilename if you want to generate a Windows Installer package.
MSIFilename=Mozilla Firefox (2.0.0.18).msi
MSIManufacturer=VMware Inc. – Dean Flaming
MSIProductVersion=2.0.0180
MSIDefaultInstallAllUsers=1
MSIRequireElevatedPrivileges=0
MSIInstallDirectory=Mozilla Firefox (VMware ThinApp)
MSIProductCode={EC34BA1D-A4F9-4AED-BD2A-A30F95CADCC9}
MSIUpgradeCode={A5B0490E-6C52-42FA-A982-8488D1055A76}
MSIUseCabs=1
MSIArpProductIcon=%ProgramFilesDir%\Mozilla Firefox\mozilla firefox.exe,0

You can see the differences between the two examples above are the MSIProductCode, the MSIProductVersion, and the MSIFilename. And while the MSIFilename does not need to be different (it can certainly help), the MSIProductVersion and MSIProductCode parameters must be different.

Once these settings are correctly set, you can then proceed with deploying the new MSI (created by building the ThinApp project) via the Active Directory Group Policy Object.

Virtual Application Safeguarding

Now that we've pushed the application to the end point (i.e. the workstation), how do we safeguard that application from being inappropriately copied off to a USB device and taken home?

It should be noted that with ThinApp we cannot actually guard against the copying of the packaged application onto a drive. We can, however, prevent that application from running on other, unauthorized systems.

Active Directory Groups
Assigning an Active Directory Group is one valid option. While it won't prevent a user from copying a the packaged application to a USB device or other removable media, it will prevent users from executing it on an unauthorized system as it is virtually impossible for a regular user to fake an Active Directory Domain and Group SID in their home.

One thing to keep in mind is to ensure you add the Domain Admins and potentially the local Administrators groups to the packaged application for ease of administration (no need to make things harder on yourself than necessary). And, of course, don't add the local Administrators group if your users are local administrators on their respective workstations.

Scripting
Now, you might think that assigning Active Directory Groups to the ThinApp packaged application would be a good valid option to keep users from walking away with your applications for their personal use. But what if you want that app to self destruct? Or maybe you want it to "phone home" to let you know it was taken off-site and what IP address it's calling in from? That would be a pretty cool option indeed! And you can do all of that with VBS scripting. Even cooler is the fact that your scripts are entirely hidden from the end user who is executing them – no matter who they are!

Sadly, we're not going to go into scripting here. For good validation scripting examples, see the ThinApp Blog articles on scripting and the ThinApp Online Help Manual for tips.

Group Policies
Oh yes…and we cannot forget about Group Policies, since that is a major part of this topic. While security through obscurity is not really security, a GPO can be used to hide access as well as prevent access to the file system where the ThinApp package applications are installed (i.e. That is wherever "%PROGRAMFILES%" resolves to).

Specifically, the two options you will want to look into setting are:
    Hide these specified drives in My Computer
    Prevent access to drives from My Computer

They are located in User Configuration | Administrative Templates | Windows Components | Windows Explorer inside the Group Policy Editor.

And now you have everything you need to deploy ThinApp packaged applications through an Active Directory Group Policy Object by use of the ThinApp packaged MSI.

This entry was posted in FAQs, Integration, MSI and tagged , , , on by .
Dean Flaming

About Dean Flaming

Dean is currently an EUC Architect and member of the VMware End User Computing Enablement and Lighthouse Support teams, working to develop communications and IP around VMware End User Computing products and solutions as well as support many various Lighthouse accounts with their own EUC practices. Prior to this, from 2008 through 2012 Dean was one of VMware's End User Computing Specialists. Throughout his time at VMware, Dean has also written and published various articles, videos, and podcasts regarding VMware's EUC Solutions.