How to ThinApp Adobe Acrobat, Flash and Java

I am running VMWare Horizon 6 with ThinApp v5.1. I am trying to figure out how to best and most efficiently package a few applications - namely Adobe Reader, Adobe Flash, and Java.

I have no problems creating install packages for them. However, browser integration does not work. For example, if you try to open a PDF file within Internet Explorer, it asks to open the program rather than displaying it in the browser. When you go to a website that utilizes Java, it says it's not installed.

I've tried doing this with both a natively installed Internet Explorer 9 (which we're forced to run due to our vendors) and a ThinApp'ed IE. I am not having luck with either. I've tried adding entry points to package.ini and visiting sites with Java applications and PDFs prior to post-scanning. No luck.

The KBs and forum posts available on Google and VMWare's site do not work properly.

I'd like to package this in a way that isn't incredibly tedicious (i.e, telling me to package Adobe, Java, Flash and IE into a single package, which one post suggested, won't fly)

Can I get someone experienced with ThinApp'ing these applications and getting them to work in IE create a detailed check list of what needs to be done to get these types of applications to work?
LVL 1
FirstcomAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Squidly_ManCommented:
A Higher Look:
Let me first take a step back and ask the reason for packaging the applications with ThinApp (rhetorically of course).  This is simply to understand the higher objective.

As an example, ThinApp is an Application Virtualization product.  Application Virtualization is (in this context) technology which encapsulates the Windows application in order to make it Windows OS agnostic and transferable.  This ultimately can resolve such things as...
Application Conflicts
Application Deployment Issues
Application Update Issues
Application Support Issues (for those flakey apps which crash a lot)
Legacy Application Needs

The reason why I bring all of this up is it sounds like you are using ThinApp to mainly address deployment and update scenarios and don't really have conflicting applications (unless there are specific versions of Java and Flash needed to work with a specific browser which are not mentioned here).

VMware has recently released a newer product called App Volumes which addresses the deployment and update scenarios with greater ease and flexibility than what ThinApp does.  And while this is a little bit of overlap, the products work very well together otherwise to deliver the dynamic desktop for end users in the even you do have application conflicts.

You may already have App Volumes!

Since you already have Horizon 6 and ThinApp 5.1, I wouldn't be surprised if you also had App Volumes. But if not, you can take App Volumes for a spin at http://vmware.com/go/avlab or download a demo from the product site (http://www.vmware.com/products/appvolumes/).


Addressing The Technical Questions:
All of that aside, to the technical part of your questions:

In order to get browser integration to work with, for example, Adobe Reader, then you simply need to ensure the following:
1. Ensure your all parts of your applications installed - including items such as browser integrations - work during the capture process before conducting your post-setup capture. See the ThinApp Troubleshooting blog post for more information here.
2. Ensure not only filetypes are registered in the PACKAGE.INI but also protocols and objects.  This will happen automatically setup capture is done on a clean PC (generally meaning a fresh install of Windows but there is some variety here).  See VMware's PACKAGE.INI Reference Guide for more details on the PACKAGE.INI file and the "What is a Clean PC?" blog post for more information on capturing on a Clean VM.
3. The ThinApp packaged application is properly registered to the user or system so the filetype, protocols, objects, and shortcuts are created for the user or system).  Reference the ThinApp PACKAGE.INI PDF guide linked above for more info on these items.

Once these are done, following the ThinApp Troubleshooting Tips, you should be able to do the "Clean Test" on a different VM by registering the ThinApp packaged application and launching it directly, then launching the browser and testing a PDF link to see if it uses the ThinApp packaged Adobe Reader.

If that works, shut both Adobe Reader and the IE browser down and reopen the browser and navigate to the URL with the PDF again and see if it opens the Adobe Reader ThinApp Package.

If this last part works, you are good.  Now test in production.  Issues found in production will be environmental and can be isolated with a bit of work.

If this does not solve your issue, then this should give you some solid info to contact VMware Support with.  Remember, if you own Horizon 6 and ThinApp 5.x, you have free support and can call them up!  Don't let that go to waste!  ;-)

Hope this helps!


Additional Resources:
ThinApp Product Resources - http://www.vmware.com/products/thinapp/resources.html
ThinApp Hands On Lab - http://labs.hol.vmware.com/HOL/catalogs/lab/1487
Horizon 6 - A-Z Hands On Lab - http://labs.hol.vmware.com/HOL/catalogs/lab/1453
0
FirstcomAuthor Commented:
Hi Squidly Man! Your comment has been very helpful. To give you further background, when I captured Adobe, I natively installed IE prior to the capture, since that is how the base image is. I then performed the pre-scan. Then I installed Adobe, disabled protected mode and the Adobe ARM from "Run", opened the native IE browser and went to to a website that had a PDF. The PDF loaded just fine in the browser. I then closed the browser and performed a capture.

However, when I actually deploy Adobe in this state, IE asks to open the file externally with Adobe Reader, rather than displaying it in the browser like it should.

What failed with my process? Are there any steps I forgot or need to manually perform?
0
Squidly_ManCommented:
Hmmm.... I don't know off the top of my head.  Let me test it in my lab.

Additional details:
What version of Windows are you capturing on (OS and bit-level)?
What version of Adobe Reader (product version including bit-level)?
What version of Windows are you testing on, if different (OS and bit-level)?
If the Adobe version is 32-bit, have you tried capturing with ThinApp 4.7.2?
What version of Internet Explorer?


Other Applications:
For the time being, the other stuff, such as Java and Flash should work fine.  You can choose to capture IE with Java and/or Flash if you so choose, or you can just capture those web components by themselves.  If you choose the later, the one trick to testing those packages is launching Internet Explorer THROUGH the ThinApp package.  To do this, enable the IEXPLORE.EXE entry point in the PACKAGE.INI file by changing it's "Disabled=1" value to "Disabled=0" (or just delete it outright).  Then save the PACKAGE.INI, and rebuild the package by running BUILD.BAT.

In the off chance the IEXPLORE.EXE does not exist, you'll need to create one.  For that, you'll want something like below - where you change the SHORTCUT to equal your data container name (reference any other entry point in that PACKAGE.INI).

[IEXPLORE.EXE]
Disabled=0
Shortcut=<PACKAGE SOURCE FILE>
Source=%ProgramFilesDir%\Internet Explorer\iexplore.exe

Open in new window


NOTE:  The above would also work for your Adobe Reader issue but ThinApp Packaged Application Objects should be registered natively with the application if they are defined....so this shouldn't (in theory) be necessary to kick the native IE over to the virtual application since we're letting Windows handle the OLE/Object hand-off to the application from the browser - only difference here being the application is a ThinApp packaged application instead of a natively installed one.

Additional Resources:
The ThinApp PACKAGE.INI Reference on the ThinApp Documentation page and the ThinApp Blogs also contain examples.
ThinApp Documentation Page
Creating Windows Entry Points for Troubleshooting ThinApp Packages
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

FirstcomAuthor Commented:
I'd like to package things separately so that when Java, Adobe, etc release security updates, it'll be easier to update and deploy.

I've already tried to add the [iexplore] entry. I've tried using both %ProgramFilesDir% and a static path (since it's natively installed) but neither worked.

What version of Windows are you capturing on (OS and bit-level)? Windows 7 32 bit
What version of Adobe Reader (product version including bit-level)? Adobe Reader 11
What version of Windows are you testing on, if different (OS and bit-level)? Professional
If the Adobe version is 32-bit, have you tried capturing with ThinApp 4.7.2? No. We have 5.1. I'd like to use that as a consistent version.
What version of Internet Explorer? IE9
0
Squidly_ManCommented:
Sorry...one more question.  You may have already mentioned this but I don't see it specifically listed (my old eyes).

Are you packaging IE9 separately (and AppLinking) or together with Adobe?  Or is IE9 natively installed in the Win7 32-bit OS?
0
FirstcomAuthor Commented:
IE8 is installed natively.

I'm natively installing IE9, separately.
0
FirstcomAuthor Commented:
My intended outcome is to have IE9 installed natively on the VM/golden image, but be able to ThinApp Adobe, Java, etc and have it work with the natively-installed IE9.
0
Squidly_ManCommented:
Ok...cool... I will test in my lab when I get a chance in the next couple of days and let you know my outcomes.
0
FirstcomAuthor Commented:
Thank you!
0
Squidly_ManCommented:
Ok...I had some free time while waiting for VMs to migrate so I tested this.

It turns out during the capture process I had to enable two secondary entry points (ACROBROKER (1) and ACRORD32INFO (1)).  See images attached.

Once I did that, it enabled the object accessibility options which then allowed me to properly register the ThinApp package and use it with a natively installed IE9.

One thing to note, if IE9 is launched natively, browsing to any PDF URL will show the OPEN | SAVE | SAVE AS option instead of viewing through the IE9 browser because the of the ThinApp runtime isolation.  In short, upon launch of the NATIVE IE9, the NATIVE IE9 doesn't know to load the VIRTUAL ADOBE READER components (nor can it) unless we reconfigure the ThinApp'ed Adobe Reader package to basically disable all isolation (which basically disables ThinApp).

Launching the native IE9 through the ThinApp package of Adobe Reader allows all functionality to work (i.e. Creating an IEXPLORE.EXE entry point in the Adobe Reader package) as then the native IE9 (being launched through the virtual bubble of the Adobe Reader package) can then see the Adobe Reader components to load them into memory with IE and allow for full functionality.

Also note, I used the full MSI of the ThinApp to register the package to the system and ensure all objects, protocols, filetypes and shortcut appeared and worked properly.  You may use a streamed MSI with the package through the Horizon 6 (View) Admin console or THINREG.EXE within a login script if you so desire - the end results will still be the same so long as the package settings regarding object, protocol, and filetype are not changed or disabled.

NOTE:  See the ThinApp Blogs for a login script with THINREG examples.

I took the liberty of screen capturing all the major steps and numbering the images in order so you have them as a reference. See the attached ZIP file.

Hope this helps.
AdobeReaderEntryPoints-1.png
AdobeReaderEntryPoints-2.png
Adobe-Reader-11-Capture.zip
0
FirstcomAuthor Commented:
Thank you for the very informative response!

We definitely need to get IE to show documents within the browser. Can you provide the steps you took to properly load native IE within the ThinApp?

That said, wouldn't launching native IE from the ThinApp'ed Adobe Reader force another IE window to open? We have some applications (i.e. a receipt viewing application) that opens up the PDF within an internal IE window.

Would ThinApp'ing IE9 along with everything else and force-redirecting all websites via ThinDirect allow us to better integrate things such as Adobe Reader, Java, and Flash?

I'm trying to determine what the most efficient method of getting these applications to interact and integrate is. A lot of what our company does is web-based, so having that seamlessness once applications are deployed through ThinApp is important.
0
Squidly_ManCommented:
Any of the following would work.
ThinApp'ing IE9 with Adobe
ThinApp'ing IE9 separately and then AppLinking to the Adobe ThinApp packaged application
Enabling the native ThinApp to launch through the Adobe package

ThinApping IE9 with Adobe is just a complete recapture, doing the ThinApp prescan, then installing both IE9 then Adobe in that order, then the ThinApp postscan.

For the AppLink option, simply capture IE9 by itself then set optional (or required) AppLinks in both the IE9 package and the Adobe Reader package.  Specifically you'll want to see the blog post, "How to Deploy AppLink Packages in the Enterprise".  Additional AppLink articles may be found here.

For adding the IEXPLORE.EXE entry point to the Adobe Reader ThinApp package, see my comment in the above thread on how to do so.  It's the one with the PACKAGE.INI mod under the "Other Applications" section above. :-)

Would ThinApp'ing IE9 along with everything else and force-redirecting all websites via ThinDirect allow us to better integrate things such as Adobe Reader, Java, and Flash?
To answer this last question, it might work but to me it sounds cumbersome and not as seamless as you might want.  You'll definitely want to test this and see what it looks like before deploying.  Honestly though, this takes me back to the questions of "Why?" and "What is it you are really trying to accomplish?" since it sounds like dynamic application deployment is the overall goal for easier administration while maintaining seamless, flexible applications and desktops for end users.  This is where I would suggest giving a look at App Volumes instead of or in conjunction with ThinApp (assuming Virtual Desktops or Remote Desktops/Apps running on vSphere or Hyper-V) as this would provide greater administrative control and flexibility while allowing for easy, seamless applications for end users.  Just my two cents!

Happy I could help!
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
FirstcomAuthor Commented:
Squidly Man,

We are currently attempting this in an evaluation of VMWare Horizon. I've requested to see a demo of App Volumes per your advice.
0
FirstcomAuthor Commented:
Thank you!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Virtualization

From novice to tech pro — start learning today.