{"id":1311,"date":"2013-04-06T10:46:39","date_gmt":"2013-04-06T14:46:39","guid":{"rendered":"https:\/\/www.tmurgent.com\/TmBlog\/?p=1311"},"modified":"2013-04-06T12:01:19","modified_gmt":"2013-04-06T16:01:19","slug":"the-return-of-the-duplicate-package-id-in-app-v-5","status":"publish","type":"post","link":"https:\/\/www.tmurgent.com\/TmBlog\/?p=1311","title":{"rendered":"The return of the Duplicate Package ID in App-V 5"},"content":{"rendered":"

It haunts me still! In every release of App-V since 4.0 there has been a new and unique way to generate apps with duplicate GUIDS. I have blogged about this both here<\/a> and here<\/a>. Granted, each time it was a case of wanting to be efficient with MY time and it was solved by careful setup of my snapshots. But I was hoping that we were past all that with version 5. <\/p>\n

It’s baaaaaaaaaack!<\/p>\n

Quick technical primer stuff.<\/h3>\n

A GUID, which is an acronym for a G<\/b>lobally U<\/b>nique ID<\/b>entifier<\/i>, is generated on demand by a Microsoft library function when code wants one. This 32 character identifier uses 16 letters in each position, allowing for the generation of 16**32 possible values, which is over 340000000000000000000000000000000000000 values. To make it globally unique, no matter when or where it is generated, the algorithm uses both time and local hardware-ish information to create the seed to generate the random number. The problem is that seed is generated at boot time. The “randomization” isn’t all that random. Once the seed is set, the next GUID generated by that seed is fixed. Generating a random number changes the seed again, so the following GUID request would be random again. <\/p>\n

When you take a VM snapshot with the OS running, you freeze the current seed. So if you revert the image, and quickly generate a new GUID (before anything else on the system generates one), you will get the same GUID when you revert and quickly do it again.<\/p>\n

While the App-V team could solve this in the sequencer by re-priming the pump before asking for a GUID the first time, they still don’t get it. So I have moved to a practice of always making my snapshots with the OS shut down to make sure that I can’t generate a duplicate package GUID. Well, almost always…<\/p>\n

How I did it in App-V 5<\/h3>\n

I was sequencing Paint.Net and wanted to use Connection Groups to bring in the various plugins as separate packages.<\/p>\n

My base sequencer image was correctly created, meaning the snapshot was taken with the OS shut down.<\/p>\n

But Paint.Net has a VC runtime dependency that needs to be installed prior to it’s installation. Knowing that I was going to do a lot of packaging with that dependency, I installed the dependency, copied down all of the installers for the program and all of the plug-ins to the desktop, and took a snapshot. Wanting to work fast, I didn’t log out or shutdown the OS, I took the shortcut of snapping it while logged in. Good thing I don’t have a CSO to report to.<\/p>\n

So I sequence Paint.Net. I revert. And then for each of the 10 plug-ins I revert and then sequence the plug-in using the “expand to local system” option for the base package.<\/p>\n

I then go to my test client and (using my AppV_Manage tool) click on the packages to add and publish them. I didn’t even get to the point of making the connection group. I had a big problem. I could add all of the packages. But sometimes when I publish one, it un-publishes a bunch of the others. But not all of them.<\/p>\n

For example, when I published the MadJik effect plugin, shown below:<\/p>\n

<\/p>\n

If would un-publish the EffectsV38 plugin:<\/p>\n

<\/p>\n

If you look close at those two packages, you can see the duplicate GUID in the PackageID. Each as a unique VersionID (indicating that the sequencer must request the PackageID first, which re-primes the pump.<\/p>\n

So why didn’t all of the packages have the same PackageID? Pure luck and timing. I had to start the sequencer quick enough after the revert to beat out other background “system things” that also generate GUIDs.<\/p>\n

In App-V, the client uses a duplicate package ID as an indication of packages that are different versions of each other. Prior to App-V 5, the client also looked at the package name also. If two packages had the same PackageID, but different PackageNames, it generated an error about a duplicate GUID. App-V 5 works differently, so no obvious error, just a little frustration until you figure out what is going on.<\/p>\n

App-V 5 notices the duplicate GUID and assumes that these must be different versions of the same base package. Because both of the packages are Version “0.0.0.1”, I am guessing that the client couldn’t determine which of the two was the newer update package, so whichever VersionID gets published last wins, bumping out the other one.<\/p>\n

Conclusion<\/h3>\n

Another release, another manifestation of the problem. If you never take shortcuts with your snapshots, or just take a long. sloooooooooow, sip of your favorite beverage before launching the sequencer, you should be OK.<\/p>\n","protected":false},"excerpt":{"rendered":"

It haunts me still! In every release of App-V since 4.0 there has been a new and unique way to generate apps with duplicate GUIDS. I have blogged about this both here and here. Granted, each time it was a case of wanting to be efficient with MY time and it was solved by careful… Continue reading The return of the Duplicate Package ID in App-V 5<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[36,47,48],"tags":[33,31,17,13],"class_list":["post-1311","post","type-post","status-publish","format-standard","hentry","category-all","category-appv5","category-sequencing","tag-appv","tag-appv5","tag-guid","tag-sequencing","entry"],"_links":{"self":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts\/1311","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1311"}],"version-history":[{"count":15,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts\/1311\/revisions"}],"predecessor-version":[{"id":1387,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts\/1311\/revisions\/1387"}],"wp:attachment":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1311"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1311"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1311"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}