Virtualization

What you have selected as "supported OS" in the Sequencer's deployment settings -screen actually does not have any relationship to what the app itself requires from the system.
So having said that, the way to get them to show up on x64 XP is to either add additional <OS VALUE="WinXP64" /> -element in to the package's OSD files or remove all the OS -elements altogether. After that, you can add your OSD manually (Add application in App-V Client Management Console) to the x64 machine, followed by import or load of SFT, and possibly manual "Add shortcut" operation to have actual shortcut for it.

If you are using Management Server and testing shows that app can be deployed to x64 as-is, you just need to update those OSD files on your content share and clients will automatically pick up new version on next publishing refresh.

Please note that perhaps the biggest issue in deploying 32-bit originated package to 64-bit system will be the registry; 32-bit App-V Sequencer will store all detected registry entries on HKLM or HKCU\Software\... branches but this will be 64-bit portion of the registry on x64 client machines. Whereas if the virtualized application itself if 32-bit executable, it tries to read from HKLM\Software\Wow6432Node\... and won't see its own registry entries! So for applications that are very registry intensive, moving 32-bit package to 64-bit system might mean non-working app.

Hi,

To update the OSD as per Kalle's post; check out this page for a couple of tools you could use:
http://kirxblog.wordpress.com/2010/07/22/freeware-tool-to-control-app-vs-os-values-within-osd-files/

Cheers,
Danny

Thanks, that gives me a good direction.
Also thanks for the registry tip, I didn't think of that. Of course that would mean that most of my apps will likely not work as nearly all keep config data in the registry... but at least now I know why they they misbehave and need to be resequenced.

On the bright side, this will put an end to my sequencing staff's griping about the recipe documentation I make them produce with each sequence. It's an excellent "I told you so". :-)

Also thanks for the registry tip, I didn't think of that.  Of course that would mean that most of my apps will likely not work as nearly all keep config data in the registry... but at least now I know why they they misbehave and need to be resequenced.

On the bright side, this will put an end to my sequencing staff's griping about the recipe documentation I make them produce with each sequence.  It's an excellent "I told you so".  :-)


My apologies, I was actually wrong on this (because my earlier findings based on faulty packages) and 32-bit package's registry will show correctly on 64-bit client IF the original sequence does come from 32-bit world; the client will do Wow64 redirection for the registry. See my recent blog post on the matter: http://blog.gridmetric.com/2011/09/26/possible-caveats-in-mixing-32-bit-and-64-bit-app-v-packages-and-environments/

Sorry for any confusion caused!

A customer has taken one of our 32 bit apps and sequenced it on 32 bit WinXp with app-v 4.6. They're running it on Win764 with app-v 4.6. The app interfaces to COM applications ArcMap and GoogleEarth. In the app-v environment it seems like the registry redirection isn't happening. It can't find the COM classes for those apps. So, as a test, the customer copied the keys from HKCR\Wow6432Node\CLSID to HKCR\CLSID and everything works.

As you might suspect, if our app is installed normally on Win764 (outside of app-v), it has no problem finding the COM classes as the registry redirection is working. But in the app-v bubble, it doesn't work. What are we missing?