after a lot of looking and quite a bit of testing and customization, i think i have finally found a replacement for adobe acrobat reader.

why replace acrobat reader? off the top of my head:

  1. security issues. everywhere. frequently.
  2. and hence because of the security issues, you have to patch often. very often. which requires time, testing, and a fair amount of good luck to not break *anything*.
  3. and lastly, i was interested in replacing adobe because of its tendency to crash, specifically in our AD environment (see this post for more details). its not often, but often enough that i get some calls

so here is what i did. i searched. a bunch. i of course found foxit, and i tested foxit pretty heavily. i like foxit, and it was very close to what i was looking for, but then i ran across tracker software’s pdf xchange viewer. not only was it small and fast like foxit, i could mod the heck out of it to get it to look the way i wanted, and it could modify pdf’s, all for free.

heres how i turned this:

into this:


read more

i initially was just going to post a fix i had found (via google) to resolve a rediculous problem that adobe acrobat reader 9.x has in it. after reviewing my fix and seeing how ugly the code/logic was, i ended up rewriting the script.

so there are two lessons in this post
1.    adobe will never get their act together (at least with acrobat reader 9)

2.    the fear of peer code review is good, and it forced me to reevaluate some sloppy scripts that “just work”, but do it in a half-baked manor
so here we go, adobe acrobat reader 9.x and its issues with redirected application data on a server 2008 terminal server
so the real problem here is not that adobe writes crappy code. the real problem is that adobe wrote some crappy code and has not fixed it.

here is the problem: if you are running redirected folders in an AD environment and you redirect your application data folder, adobe acrobat reader 9 will give you a c++ runtime error if you are not an administrator. i have seen several people come up with fixes, one works for some, but not for others, so ymmv.

the three fixes i have seen have been:
1.    give list folder / read data permissions on the root level (applied to this folder only) of your users or homes share
2.    create the local low folder
3.    lastly, and the one that i use with a vbscript, is do delete a particular registry key
here was my original code:

Option Explicit

Dim objShell
Set objShell = WScript.CreateObject(“WScript.Shell”)

On Error Resume Next

objShell.RegDelete “HKCUSoftwareMicrosoftActive SetupInstalled Components{89820200-ECBD-11cf-8B85-00AA005B4340}Version”

so, no error checking, and technically speaking it worked, but its ugly. i went back and fixed this to do some logic to see if the key existed before it tried to delete it, and came up with the following:

On Error Resume Next

Const HKEY_CURRENT_USER = &H80000001
strComputer = “.”

Set objRegistry = GetObject(“winmgmts:\” & strComputer & “rootdefault:StdRegProv”)
strKeyPath = “SoftwareMicrosoftActive SetupInstalled Components{89820200-ECBD-11cf-8B85-00AA005B4340}”
strValueName = “Version”
objRegistry.GetStringValue HKEY_CURRENT_USER,strKeyPath,strValueName,strValue

If (IsNull(strValue) = False) Then
     objRegistry.DeleteValue HKEY_CURRENT_USER, strKeyPath, strValueName
End If

for us, running server 2008 terminal servers, this fixed the problem. users are now successfully running the latest version of adobe acrobat reader 9 with no errors.

if you want to see details of the problem, or look at some of the other solutions (the root share permissions fix or the local low fix), you can look at some of the following threads/links. they go into a lot more detail and explain what is happening and what to try to fix it

http://support.microsoft.com/kb/955555/en-us
http://forums.adobe.com/thread/391738?tstart=0
http://forums.adobe.com/thread/303079


read more