Geeks With Blogs
derekf's blog On C#, repackaging applications, and deploying via group policy...

It looks like this is going to be the first in a series on app distribution with group policy.

I'm not going to go into the full-on basics of app distribution; if you're in a position to need to know this stuff, you're likely to have already seen GPMC and know how to publish or assign, if you're just curious then there's lots of good info on publishing/assigning apps in group policy out there on the web.

Behind the scenes, however, is interesting (to me, anyway).  When you publish or assign an app, not only is an entry created in AD (which we'll get into later) but additionally an AAS (Application Advertisement Script) is created on the Sysvol of the DC, which is replicated to the other domain controllers. 

The path for the AAS file is tucked way up under the Sysvol folder.  For now, just click the Advanced button on the Deployment tab for one of your apps.  Here's a sample from mine:

You'll note that there's a couple of GUIDs in the path to the AAS file.  The first is specific to the policy the app is in (which only matters if you've got multiple app policies), the second is specific to this particular app.  We'll go into finding the policy GUID in a few days, and with that, we can get AD to tell us the app GUID.

Go ahead and take a look at the associated AAS file in Notepad.  It's full of gibberish, with only a few human-readable bits.  Up towards the top, if you're paying close attention, you might notice that the first GUID is the MSI's Product Code, followed by the Display Name, and then the next GUID is the MSI's Package Code.  (If you're curious, the MSI's Upgrade Code is the last GUID, right before the install path).

This is not the best way to read the AAS, if you haven't guessed.  We'll get to the better ways later.

Now, it's unavoidable in a corporate environment -- some group is going to want their app modified, be it that they want to add files or change an INI entry, or even more substantial changes.  There's really four options for putting an updated MSI in production:

  • Just overlay the new MSI over the old one and make no changes to policy.
  • Remove the app from policy and republish (selecting the "Immediately Remove" option)
  • Remove the app from policy and republish (selecting the "Allow Users to Continue" option)
  • Overlay the MSI and trigger a Redeploy (right-click, All Tasks, Redeploy Application)

Most of these have their own problems -- the simple overlay and the Redeploy require that several parts of the package not change.  The product and package codes must remain the same; and while I haven't done any testing to verify, we've been told that no shortcuts can have been added or removed nor can any components or features have been added or removed. 

On the other hand, the two "Remove from policy" options have their own issues.  While there are no real limits in these cases to the changes that can be made to the MSI, once a package has been removed you've lost the ability to administer that package -- if you remove it today with "Allow Users to Continue", and next week you're given the task of removing it from all workstations, well, good luck to you -- you no longer have that option.  For this reason, I'm not much of a fan of these two options.

There's really a fifth option -- mandatory upgrade of the new package over the old, but we've run into enough problems with that method that it's really not used all that much.

Group Policy uses the MSI name, the Product Code, and the Package Code to identify a given package.  If the Package Code is changed and the old GP entry remains, when users attempt to install the package they'll receive this error:

and obviously they won't be able to install.

Similarly, if the Product Code is changed, users will get this error:

and in both cases they'll get this error after hitting Cancel:

So in the past, I'd written an app that just looked at those three spots in the AAS file and compared them against the codes in the MSI, letting me know if there was a discrepancy.

We'll look at a better way to check the AAS file tomorrow.

Posted on Thursday, December 28, 2006 3:35 AM | Back to top

Comments on this post: App Distribution with Group Policy

# re: App Distribution with Group Policy
Requesting Gravatar...
If you've got to install or remove an unmanaged app across the entire network, psexec (from Sysinternals, now owned by Microsoft) is a godsend.

psexec @computers.txt msiexec /x {...} /q

This is great for all those old JRE's Sun tends to leave lying around.

Left by Barry Burns on Sep 12, 2007 6:25 PM

Your comment:
 (will show your gravatar)

Copyright © derekf | Powered by: