Oh man, I cannot believe that the old issue kind of came back to haunt us. Back in the last year we fixed an issue in our App-V -related products that caused all App-V 4.6 packages to be flagged as 64-bit packages, now it was the reverse.
You see, we had a condition in our App-V package handling library, Lib-V, which resulted the situation wherein the library flagged output packages to be 64-bit regardless of if it really was 64-bit or 32-bit in nature (e.g. coming from 32-bit Sequencer or 64-bit Sequencer). For 32-bit packages this caused no other harm besides that the fact that App-V Client would not apply any registry redirection for HKLM|HKCU\Software and selected other branches when that package was executed on a 64-bit client system. Registry branches would be taken as literal and so 32-bit virtualized applications would not see any registry entries they expect to see in redirected 32-bit registry portion.
Eventually this condition was fixed in all of our products once we became aware of the bug’s existence, we even released a 32-bit fixer tool to revert accidentally-became-64-bit packages back to 32-bit state.
Fast-forward to this day, and we got an issue report from one of our customers, noticing that AVE displayed re-opened saved package as 32-bit, even though it originally was 64-bit. It’s, btw, really strange that nobody has noticed this before, since the very fix we originally built for 64-bit flagging had a bug of its own which now caused all packages (or so I believe) to be marked 32-bit, regardless of the original bitness. So in essence, this was an exact reverse of the earlier situation! Although it has to be said that if the package has explicit Wow6432Node in the virtual registry, it might be that the App-V does not try to do redirection, which may mean that not all 64-bit packages necessarily exhibit issues on a client system.
Long story short, we immediately fixed this issue (again) in all of our products, and that’s why you see released updates to Lib-V, Virtualization Encoder and AVE all at the same day.
So if you have 64-bit App-V environment, I urge you to upgrade to the latest build of the respective Gridmetric product. If needed, we will provide a new 64-bit fixer tool to re-flag those existing packages that you might already have in your environment that act fully in the client with regards to how app sees the settings; please be in contact with our support to have the tool (starting from tomorrow).
Trackbacks/Pingbacks
[…] a while (to correct issues in App-V 4.6 packages saved out from AVE prior to version 2.2.6), but since the recent events there appeared to be a need to do the opposite as […]