Adobe Acrobat Fails to Launch

This post is going to turn into a rant so I’m going to lighten the mood by incorporating as many Jurassic Park references as I can.

 

Have you ever had one of those moments where you hear someone describing an issue and your all like, “Whew, I’m glad that’s not me!” but then it turns out that the IT Gods have decided your week is going to take a immediate dive into what Dr. Sattler is so meticulously examining in the scene below?

Bingo. This is exactly what happened last week when the Help Desk started getting reports of users being unable to launch Adobe Acrobat. The calls started on Monday and by Friday there were 30 documented cases. The issue affected Acrobat X, XI, and DC. If you opened task manager there would be an ‘acrord32.exe’ process for every file the user tried to open. This is when the issue was escalated and dropped in my lap.

I was hoping Adobe had released a bum security patch but couldn’t find any chatter on Reddit about it. I checked recent SCCM Adobe deployments\applications to make sure no one had deployed a test build by mistake or enabled supercedence incorrectly. Nothing there either. We ran through your typical troubleshooting steps: Uninstall/Reinstall; Enable/Disable Protected Mode; delete the users profile; force the EULA acceptance; nothing worked. We’d figured out a temporary fix for users and I called a couple high priority people to get them up and running. While speaking with one of the users they mentioned in passing that this behavior didn’t start until last week when a new piece of software was pushed out that required a reboot. The only active software deployment that required a reboot was a single sign on product named Imprivata. Now Imprivata has caused me some headaches in the past but I didn’t really see how it would cause Acrobat not to launch. Half an hour later we hadn’t made any progress and I just couldn’t shake the idea that somehow Imprivata was involved. I compared the list of computers experiencing the Adobe issue against the list of recent Imprivata installs and wouldn’t you know it… they matched.

I was started to get a little irritated at this point and logged into Imprivata’s knowledge base and searched for Adobe Acrobat. You know that age old IT adage of never upgrading to the latest X.0 version of any product and to wait until at least update 2 so the bugs are worked out? This is a perfect example of why you wait. Apparently this version of Imprivata has a known issue with Acrobat. In order to provide single sign on to multiple applications, Imprivata hooks into all processes running and sometimes can cause issues. Sometimes?? How about 100% of the time!

The KB article stated to create a registry key called ‘HookInit’ under ‘HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SSOProvider\ISXAgent’ and create a null value string named AcroRd32.exe. Imprivata will ignore any process listed. Ok, now we are getting somewhere. I remoted into one of the broken workstations, added the key and tried to open a PDF. Nothing. I opened task manager and there were 30 instances of Acrord32.exe running. The user had gotten irritated and kept clicking the file until it finally opened. I killed all the open Acrord32.exe processes and tried again. Still Nothing.

I opened the registry back up and added every Adobe process that could possibly run and finally, the PDF opens!!!

So now we’ve determined the root cause of the issue and the solution/work around. SCCM 1706 has a new really cool feature that allows you to run scripts against a collection. That would work beautifully except the 1706 client hasn’t been released into production yet. I decided to create a remediation baseline and target all the machines that ran the Imprivata upgrade. I’m going to give some kudos to Adam Bertram here as I utilized one of his powershell discovery scripts (edited for my needs) in my configuration item. His original post can be found here. There are several really good articles on creating and deploying configuration baselines so I won’t delve into the how and just focus on the scripts themselves.

Powershell Discovery Script
The script first determines whether or not its running on a x64 bit machine or x86 bit and adjust the Imprivata registry path as needed. I set the error action to silently continue as any failure will result in non-compliance and kick off the remediation script. Each process that I need Imprivata to ignore is defined in an array and then ran through a foreach loop. As each one is processed the success count is incremented by 1. If the success count matches the number of processes defined in the array (4), then a value of True is returned. Thus the SCCM discovery script is set to require a ‘True’ value to be compliant.

$OSArchitecture = Get-WmiObject -Class Win32_OperatingSystem | Select-Object OSArchitecture
If($OSArchitecture.OSArchitecture -ne "32-bit")
{
$RegPath = "HKLM:\Software\Wow6432Node\SSOProvider\ISXAgent\HookInit"
}
else
{
$RegPath = "HKLM:\Software\SSOProvider\ISXAgent\HookInit"
}

$RegValues = @(
@{ 'Path' = "$RegPath"; 'Name' = 'AcroRd32.exe'}
@{ 'Path' = "$RegPath"; 'Name' = 'Acrobat.exe'}
@{ 'Path' = "$RegPath"; 'Name' = 'acrotray.exe'}
@{ 'Path' = "$RegPath"; 'Name' = 'armsvc.exe'}
)

$ErrorActionPreference = "SilentlyContinue"

$RequiredSuccessfulChecks = $RegValues.Count
$ChecksPassed = 0
$RegValues | foreach {
$Query = Get-ItemProperty -Path $_.Path -ev NoKey -ea 'SilentlyContinue' | Select-Object -ExpandProperty $_.Name -ev NoValue -ea 'SilentlyContinue'
if ($NoKey) {
throw "The registry key '$($_.Path)' does not exist."
} elseif ($NoValue) {
throw "The registry value '$($_.Value)' in key path '$($_.Path)' does not exist"
} else {
Write-Verbose "The registry value '$Query' in key path '$($_.Path)' matches desired data value"
$ChecksPassed++
}
}
if ($RequiredSuccessfulChecks -eq $ChecksPassed) {
Write-Verbose 'All registry values are in compliance'
$true
} else {
Write-Warning "$($RequiredSuccessfulChecks - $ChecksPassed) out of $($RequiredSuccessfulChecks) registry values are out of compliance"
$false
}

Powershell Remediation Script
If the workstation is not compliant then the Remediation Script will run. Once again the architecture is determined and then the required registry key and strings are forcibly written. Looking at the script you will see that I have commented out an option to kill off any running acrobat processes. If I were running this real time (like the run Script feature in SCCM 1706) then I would probably let ‘Stop-Process’ run so that the user wouldn’t have to reboot in order to get Acrobat working again.

$OSArchitecture = Get-WmiObject -Class Win32_OperatingSystem | Select-Object OSArchitecture
  If($OSArchitecture.OSArchitecture -ne "32-bit")

    {
    # Stop-Process -Name acrobat -Force
    $RegKey ="HKLM:\Software\Wow6432Node\SSOProvider\ISXAgent\HookInit"
    New-Item -Path HKLM:\Software\Wow6432Node\SSOProvider\ISXAgent -Name HookInit -Force
    Set-ItemProperty -path $RegKey -name AcroRd32.exe -value '' -Force
    Set-ItemProperty -path $RegKey -name Acrobat.exe -value '' -Force
    Set-ItemProperty -path $RegKey -name acrotray.exe -value '' -Force
    Set-ItemProperty -path $RegKey -name armsvc.exe -value '' -Force
    }

Else {
    # Stop-Process -Name acrobat -Force
    $RegKey ="HKLM:\Software\SSOProvider\ISXAgent\HookInit"
    New-Item -Path HKLM:\Software\SSOProvider\ISXAgent -Name HookInit -Force
    Set-ItemProperty -path $RegKey -name AcroRd32.exe -value '' -Force
    Set-ItemProperty -path $RegKey -name Acrobat.exe -value '' -Force
    Set-ItemProperty -path $RegKey -name acrotray.exe -value '' -Force
    Set-ItemProperty -path $RegKey -name armsvc.exe -value '' -Force 
    }

Now deploy the baseline and hope we haven’t missed any Adobe processes.

 

This process will correct the Adobe issue for computers that have already installed Imprivata but what about the remaining devices that still need the Imprivata client upgrade? We could script the install and build custom discovery methods, we could utilize the Powershell App Deployment kit and write the registry entries as post install tasks, or we could edit the installation media and add in our needed registry additions. It’s not everyday you get or need to edit a MSI so lets take that route. Using a Microsoft product called ORCA you can open most MSI files and edit as needed. Typically you would open the MSI file, make your changes, save your changes to a MST file, and then apply the MST file as part of your install string. I have found that adding registry entries to MSI’s and saving on top of the existing file works out just fine in most cases. However, it will immediately break the certificate chain if you save changes to the original file. If you try to import it into SCCM you will get an error about an unsigned file. Try it both ways and go with whatever you are comfortable with.

Making Custom Changes to the MSI Install File

  • Right click the install file and select Edit with Orca
  • Click on the tables column header to sort alphabetically and click on Registry.
    Click on the Property column header to the Right and scroll down till you reach the end of the properties labeled Registry##.
    Right click choose Add Row.

  • Manually enter the values you require. The Add Row window isn’t your typical text editor. You will need to click on each row and then enter your data in the field towards the  bottom.
    It will also tell you if the field is required.

  • Your window should resemble this once all 4 rows are added. Save the file or generate a MST.

  • Here is the registry of a test machine after successfully installing the newly edited MSI.

 

That should take care of any future deployments. Just make sure to edit the x86 installer if you have any 32 bit machines left in your environment. I glossed over a bunch of small details but you should always test, test, test before you deploy anything. Even when taking the appropriate testing steps, weird issues such as the one above can still crop up. This has been one of my longest posts and I revisited it several times so if there are any errors or you have any questions let me know.

 

Leave a Reply