I have many apps sequenced with App-V 4.6 x86 for XP x86. We now have an unexpected need to make many these apps available on XP x64. During sequencing only XP x86 was checked as supported OS, not XP x64.

As I understand it, at least some of these apps will run on XP x64 if sequenced with v4.6 x86. What is the easiest way to get these icons to appear on XP x64 so they can be tested? If they test OK, what is the easiest way to update the publishing server so that the apps will appear on all XP x64 desktops?
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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.
Answered 09/19/2011 by: ksaunam
Orange Senior Belt

Please log in to comment
0
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
Answered 09/19/2011 by: DannyC
Orange Belt

Please log in to comment
0
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". :-)
Answered 09/19/2011 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
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!
Answered 09/27/2011 by: ksaunam
Orange Senior Belt

Please log in to comment
0
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?
Answered 12/08/2011 by: wjeral
Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity