Adobe Reader 9 Customization Tool Bug

I would like to take a few minutes to relay a story of a bug in Adobe’s Customization Wizard version 9 that causes Adobe Reader 9.x browser integration to fail. If you are seeing the symptom in the screenshot below (“The Adobe Acrobat/Reader that is running can not be used to view PDF files in a Web Browser. Adobe Acrobat/Reader version 8 or 9 is required. Please exit and try again.“), then please read on:

Adobe Reader 9 Error

Adobe Reader 9 Error

———————————————————————————————————

Recently, I put together a package to deploy Adobe Reader 9.1 (now updated to 9.1.1) to our Windows clients (using ConfigMgr). I deployed this package successfully to a couple thousand workstations. After this deployment though, we had a couple of complaints, from users that had a license for Adobe Acrobat, that Adobe Reader had taken over as the default PDF software. As a result from this feedback, we went back and changed an option, for future deployments, to leave Acrobat as the default PDF software if it is installed (“Make Acrobat the default viewer if both Acrobat and Reader are installed.“).

Not thinking much of the change we made, using this newly tweaked package, we continued our deployment to the enterprise. After deploying to about 600 more workstations, that’s when the bad news began. Reports of an error message coming up (see introductory paragraph / image) began streaming in from our on-site technicians, because our users in those locations heavily relied upon Adobe Reader’s browser integration to open and print PDF documents.

It took quite a while of trial and error to figure out, but eventually we discovered that the setting under “Installation Options –> Default viewer for PDF files” was causing the issue. By reverting this option back to the default value of “Installer will decide which product will be the default,” we successfully worked around this problem.

Adobe Reader Customization Wizard - Installation Options

Adobe Reader Customization Wizard - Installation Options

———————————————————————————————————

As best I can tell, this is a bug with Adobe’s Customization Wizard software. It has caused a lot of headache, a lot of wasted time, and a couple of very late nights at the office for me last week, but eventually we got it resolved.

Thanks Adobe.

If you have any questions, feel free to e-mail me on Gmail at pcgeek86.

Update (2009-06-02): Fixed text rendering errors around images

Windows 7 Remote Desktop Client

I just found a really cool, yet subtle, feature of the Windows 7 Remote Desktop Client!

If you open a remote desktop (terminal services) session to a remote system, and go into full-screen mode, you can now click and drag the title bar at the top of the screen! It’s quite convenient if you didn’t like the legacy, centered-only position of this UI element! :)

Enjoy!

[Lack of] .NET Support in WinPE 3.0

So, I downloaded the Release Candidate of the Windows 7 Automated Installation Kit (AIK) this morning and installed it on one of my spare systems. I was excited to see that a new version of WinPE was available! I hope that they have made improvements to it, much as WinPE 2.0 was a huge improvement over WinPE 2005.

One of the first things I looked for upon installation of the AIK was a WinPE “package” that enabled .NET support in WinPE. For a long time, discussions have been had on .NET support in WinPE, and the only method of making this work that I know of, is to virtualize the framework in a VMware Thinapp package. This technique was first invented by Johan Arwidmark on his blog.

http://www.deployvista.com/Blog/tabid/70/EntryID/57/language/en-US/Default.aspx

Unfortunately, after reviewing the documentation and installation folder for the Win7 AIK, I cannot find anything stating that there is .NET support in WinPE. We’re all still stuck with the legacy VBscript automation tool, and C++ if I want anything beyond that (and no, I don’t write C++, just C#).

If you feel strongly on this topic, please show your support in the Windows 7 forums on Microsoft Technet. Thanks!

http://social.technet.microsoft.com/Forums/en/w7itproinstall/thread/61a7b6e9-2190-4672-bac5-cb6a0bb52b7e

Virtual Server and Internet Explorer

I am using Microsoft Virtual Server 2005 R2 to build a base Windows XP image for our client imaging process. I am using the Windows 7 64-bit Release Candidate with Internet Explorer 8 to access the Virtual Server web interface. Unfortunately, I was having an issue where the mouse acted quite oddly in the ActiveX control used to remotely control the guest OS running on the remote Virtual Server. This made the mouse unusable, and it was a pain to work on the remote system.

I didn’t have this issue on IE 6 on XP, so I just used that. I finally figured out what was causing the issue on IE 8 / Win7 though. It turns out that disabling Protected Mode for the Intranet zone, which is the zone that I put the Virtual Server web URL into, fixed the problem. Yay!