Virtualization

Sounds like a problem with AppStream if the layer works natively.
Contact Appstream to see if they having some further information on how to solve this.

I'll move this thread to the correct forum.

That is certainly strange behavior that I have not seen before, and I would like to get this fixed for you. I encourage you, and anyone else that encounters strange behavior with AppStream, to contact us immediately to resolve any issues that arise. Use the information below to contact us at your earliest convenience. If you would like to talk to me directly, you are welcome to send me an email through this forum.

Are you a current customer, or are you evaluating our software for your company? We may be able to provide a resource to help you in your efforts.

Support:
http://www.appstream.com/services-support.html
support@appstream.com
877-898-2770 (Toll Free)

Thank you for helping to keep our product of the highest quality.

Best regards,
Brian

I believe we have solved the problem. Microsoft was using shortcuts that pointed to the GUID of the app as opposed to the actual .exe files. We had to re-compile the Appstream packages with correct shortcuts.

I'm guessing that maybe AppStream sees this GUID/icon combo as something that doesn't need to come down during the initial stream deploy the first time and comes down as needed the next time it is launched.

What you are seeing is an advertised shortcut, the GUID of the component having the exe file as keypath.
This isn't a problem with SVS and I guess you having this issue with AppStream as you didn't launch it during your creation of the appstream package process. I spoke with some of the AppStream people at my visit to ManageFusion at Las Vegas and one import thing is to launch the executable files you want get streamed when launched.

Don't recall what AppStream call this process but with SoftGrid it's called Sequencing.
If I were you I would contact AppStream or Brian to either show or help you how to solve this. As if you will be AppStream:ing alot of MSI package you will most certain get alot of advertised shortcuts and doing this workaround is more a time killer then doing the "right" way.

We are currently going through a conversion from Novell's ZENworks to SVS / AppStream for our packaging and deployment. Of the 300-400 apps converted we've only had one other than the Office apps to have this behavior, mostly because our ZENworks packages had icons delivered by NAL as opposed to a standard shortcut.

It is something we will have to remember for future apps though.

you should probably also be aware you could possibly be breaking the self healing functionality of the applications as well by doing this.

these shortcuts are the trigger point for msi self healing. if the app has no others you lose one of the main features of windows installer.

John,

Considering how SVS works I would remove any metadata from the MSI after capturing. A user repair (profile-fix) wouldn't be required for any MSI as the info will be used from the "USER_TEMPLATE", thus any On-Demand installation (advertising) would not work if the metadata was removed so that is something to consider.

Another thing to consider if one would remove the metadata would be that if you want to update the layer using ex. SVSADMIN or SVSCMD by a patch or another MSI removing the metadata wouldn't be recommended.