In most cases I do not recommend virtualizing Reader – your mileage may vary, but because of the additional administrative overhead and the change in the user experience, you should invest your time in other areas. Because Reader is used so often, managing DSC links is something that could get out of hand very quickly. Virtualised applications: Additionally, if you need to provide other virtualised applications with Reader support, you will need to maintain Dynamic Suite Composition links to the Reader package for each primary package that requires it. If you do that, what happens when you want IE to launch inside the environment of another package? App-V doesn’t handle integration with these entry points elegantly today. You could solve this my launching Internet Explorer inside the Reader package, but this will require covering all of the ways a user can launch Internet Explorer. Launching Reader inside IE or viewing a PDF embedded in a web page will not be possible. Internet Explorer: if Reader is isolated from Windows, Internet Explorer will be able to download PDFs which can then be opened with the virtualised Reader however IE will have no knowledge of any application that is handling the PDF file type or MIME type. Let me illustrate with a couple of examples: If you are using a virtualisation solution that isolates an application from other applications and the operating system, integration can be a challenge. Adobe Reader is often a common component of any desktop deployment and like Microsoft Office and Internet Explorer, it usually becomes a core application on which other applications depend. Don’t Virtualize Readerīefore I get to the details I would like you to first consider the implications of virtualising Reader. This post details virtualizing Adobe Reader X with Microsoft Application Virtualization 4.6 however the same basic steps should apply to virtualizing Reader with any other application virtualisation product.

How to download adobe reader x