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

Sorry about the delay.

Last time I dug into the SYSVOL portion of app distribution via Group Policy.  This time, the Active Directory side.

I'm sure you already know that the net result of GP distribution is that if the user is in the appropriate group, the app appears in Add/Remove programs.  The file on the Sysvol is important -- we've seen cases where for some reason the .AAS file disappeared; when it did, the app stopped appearing in Add/Remove Programs.

The other half is, of course, in Active Directory.  If you've done any playing with AD, you know that all the access to the contents is done via LDAP queries. 

Lots of data about a given app is stored in AD.  Here's a sample of the data stored about one application:

packageflags =     -1610610632
distinguishedname =     CN=42d7f80d-a031-49cf-8f39-c1f8cb9ed71b,CN=Packages,CN=Class Store,CN=User,CN={2137E375-D8FC-4CBB-9245-4219DBBAC43F},CN=Policies,CN=System,DC=MY,DC=COMPANY,DC=com
upgradeproductcode =     System.Byte[]
versionnumberlo =     0
whencreated =     12/21/2006 11:45:54 AM
packagetype =     5
localeid =     1033
packagename =     !dgfTest
revision =     0
name =     42d7f80d-a031-49cf-8f39-c1f8cb9ed71b
usnchanged =     3733596
lastupdatesequence =     20061221114659
objectcategory =     CN=Package-Registration,CN=Schema,CN=Configuration,DC=COMPANY,DC=com
showinadvancedviewonly =     True
msiscriptpath =     \\MY.COMPANY.COM\sysvol\MY.COMPANY.COM\Policies\{2537E375-D8FC-4CBB-9245-4219DBBAC43F}\User\Applications\{0A75EB3E-6003-46A3-A8CB-B102C9A19BDC}.aas
instancetype =     4
comclassid =     00000000-0000-0000-0000-000000000000:0
cn =     42d7f80d-a031-49cf-8f39-c1f8cb9ed71b
installuilevel =     5
msiscriptname =     P
objectclass =     top
    packageRegistration
usncreated =     3701378
objectguid =     System.Byte[]
displayname =     !TestApp
productcode =     System.Byte[]
msifilelist =     0:\\server\share\TestApp\TestApp.msi
whenchanged =     12/21/2006 4:20:04 PM
machinearchitecture =     1282
versionnumberhi =     1
adspath =     LDAP://CN=42d7f80d-a031-49cf-8f39-c1f8cb9ed71b,CN=Packages,CN=Class Store,CN=User,CN={2137E375-D8FC-4CBB-9245-4219DBBAC43F},CN=Policies,CN=System,DC=MY,DC=COMPANY,DC=com

A lot of this is self-explanatory:

WhenCreated is just that -- when the entry was created.

PackageName is the displayed name in Add/Remove.

MSIScriptPath is the path to the AAS.

WhenChanged is when the entry was touched - to do a Redeploy, change the displayed name, or similar.

MSIScriptName is not what it looks like - if it's P, the package is Published.  If it's A, the package is Assigned, and if it's R, the package has been Removed.  The details as to how it was removed ("Immediately uninstall" or "Allow users to continue") are stored in the PackageFlags, detailed later.

The Deployment Count is stored in "Revision" -- if you redeploy an app, this is incremented and the update times are updated.. that's all a Redeploy does.

The ProductCode and UpgradeCode should match the contents of the AAS and the MSI itself.  We haven't had a case where they differed, or at least not one where we noticed; so I can't specify what happens if they don't.

I've got another app that I published with the "Include COM Information" checked.. there's no difference in the AAS files, they always include the COM information, but there was a list of all the objects in AD when that was checked:

comprogid =     crystal.crystalreport (and a bunch of other stuff under comprogid)
comclassid =     0002560a-0000-0000-c000-000000000046:       1   (and a bunch more GUIDs). 

Our standard is to not include the COM information as to avoid bloating AD -- as you've can tell, removing a record doesn't clean up the used space.

The package flags were interesting - as the name suggests, they're bitflags.

I couldn't tell what values 1, 2, 4, 16, 32768, and 262144 meant, but I didn't find anything that had 16 set.

32 is "Display in Add/Remove Programs" (set for true)

64 is "Auto-Install by File Extension Activation"

128 is Removed with "Allow Users to Continue" option

256 is Removed with "Immediately Uninstall" option.  Go figure, 128 and 256 shouldn't both be set.  I don't know what happens if they are.

If PackageType is R, bits 128 and 256 specify what happens with existing installations.  I didn't see any examples where it was wrong.

512 shows that there is an Upgrade.

1024 is set when the app is Assigned.

2048 is "Uninstall when falls out of the scope of management" if it's false.

4096 should be the opposite of 2048.

If an app is a User Assigned app (automatic install per-user at logon), 8192 should be set.

16384 seemed to have two meanings: either a Per-Machine assignment (Computer Configuration) or a published app that was a Required Upgrade.

65536 selects whether an app is available to IA64 users - false for yes.

131072 is "Ignore Language"

524288 is UI Level "Basic".

So, if you've got a normal published app, the AD entries would look similar to this:

packageflags =     -1610610568
distinguishedname =     CN=6cbb5c46-d523-42a6-8a1c-8765c168721a,CN=Packages,CN=Class Store,CN=User,CN={2137E375-D8FC-4CBB-9245-4219DBBAC43F},CN=Policies,CN=System,DC=MY,DC=COMPANY,DC=com
upgradeproductcode =     System.Byte[]
versionnumberlo =     0
whencreated =     12/21/2006 11:47:09 AM
packagetype =     5
localeid =     1033
packagename =     !Test2
revision =     0
name =     6cbb5c46-d523-42a6-8a1c-8765c168721a
lastupdatesequence =     20061221114725
objectcategory =     CN=Package-Registration,CN=Schema,CN=Configuration,DC=COMPANY,DC=com
showinadvancedviewonly =     True
msiscriptpath =     file://MY.COMPANY.COM/sysvol/MY.COMPANY.COM/Policies/%7B2137E375-D8FC-4CBB-9245-4219DBBAC43F%7D/User/Applications/%7B99FF6442-0179-4961-B5D6-F5C56AFC3FE3%7D.aas
instancetype =     4
usnchanged =     3733588
installuilevel =     5
msiscriptname =     P
objectclass =     top
    packageRegistration
usncreated =     3701383
objectguid =     System.Byte[]
displayname =     !Test2
productcode =     System.Byte[]
msifilelist =     0:\\server\share\test2\test2.msi
whenchanged =     12/21/2006 4:20:04 PM
cn =     6cbb5c46-d523-42a6-8a1c-8765c168721a
machinearchitecture =     1282
versionnumberhi =     1
adspath =     ldap://CN=6cbb5c46-d523-42a6-8a1c-8765c168721a,CN=Packages,CN=Class/ Store,CN=User,CN={2137E375-D8FC-4CBB-9245-4219DBBAC43F},CN=Policies,CN=System,DC=MY,DC=COMPANY,DC=com

and then you go ahead and Remove with the "Immediately Uninstall" option, these are the items that would change:

packageflags =     -1610612464
lastupdatesequence =     20061221195037
usnchanged =     3758829
msiscriptname =     R
whenchanged =     12/21/2006 8:00:41 PM

Go figure the three changed counters would be updated.  MSIScriptName predictably changes to an R, and the package flags have a difference in 1024, 512, 256, 64, 32, and 8.

As mentioned, I don't know what 8 does.  Unsetting 32 hides the app in Add/Remove.  Unsetting 64 turns of the Auto-Install by Extension.  Turning off 256 is the "Immediately Uninstall" that we specified.  512 turns off any upgrades, and 1024 specifically unassigns the app.  My theory is that undoing these changes would stop an unintentional removal or redeploy but I haven't had a chance to do any testing on that (yet; but it's on my list).  No code today; I've got code that extracts all this stuff from AD but it's at work, and I'm not.  I'll try to get it posted this week.

Posted on Thursday, February 22, 2007 2:17 AM | Back to top


Comments on this post: My, how time flies.

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © derekf | Powered by: GeeksWithBlogs.net