Acrobat Reader XI addon gets disabled periodically in Internet Explorer within Windows domain

Question

We have a followig problem that happens on new workstations with Windows 7 x64 and Acrobat Reader XI only.

Every few days the following key is automatically added to registry:

HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{CA8A9780-280D-11CF-A24D-444553540000}

This key has the effect that Acrobat Reader XI gets disabled in Internet Explorer add-ons. So when user opens PDF in IE (or SAP or other Windows software using IE), it is not opened within IE but in a new separate window.

---

All the client workstations use Microsoft System Center 2012 R2 and Microsoft System Center Endpoint protection as antivirus solution.

Can you please suggest what can be the reason for this, like group policy, antivirus etc.?

Solution 1

Reproducing the problem

Assuming you have installed

• Microsoft Windows 7+ / Server 2008 R2+
• Microsoft Internet Explorer 11+ (IE)
• Adobe PDF Reader 11+ (Reader)
• Microsoft System Center Endpoint Protection / Microsoft Malware Protection (MalwareProtection)

the following seems to happen here:

MalwareProtection registers a component named Microsoft Antimalware IOfficeAntiVirus implementation (MpOAv) for Extension Validation with IE.

IExtensionValidation interface

For Internet Explorer 11, specifies an interface the anti-malware vendors can implement. Vendors that register support for this interface may be called by IE11 to validate that an ActiveX control is safe to instantiate.

MpOAv registers as a CLSID of {2781761E-28E1-4109-99FE-B9D127C57AFE}.

[HKLM\SOFTWARE\Microsoft\Internet Explorer\Extension Validation\{2781761E-28E1-4109-99FE-B9D127C57AFE}]
[HKLM\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Extension Validation\{2781761E-28E1-4109-99FE-B9D127C57AFE}]

You can inspect the detailed properties of MpOAv in the registry. The associated DLL usually resides at C:\Program Files (x86)\Microsoft Security Client\MpOAv.dll

[HKCR\CLSID\{2781761E-28E1-4109-99FE-B9D127C57AFE}]
[HKCR\Wow6432Node\CLSID\{2781761E-28E1-4109-99FE-B9D127C57AFE}]

Now everytime IE wants to run an ActiveX control, the registered MpOAv is being called before that and sometimes misbehaves or simply thinks that the Reader ActiveX control is not safe. I have no idea what its behavior really depends on.

This all results in IE (iexplore.exe) writing 2 keys to the registry: The CLSIDs of MpOAv {2781761E-28E1-4109-99FE-B9D127C57AFE} and Reader {CA8A9780-280D-11CF-A24D-444553540000}.

[HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{2781761E-28E1-4109-99FE-B9D127C57AFE}]
[HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{CA8A9780-280D-11CF-A24D-444553540000}]

From this point on IE will not run the Reader ActiveX control until someone manually removes its CLSID from there. This is the observed problem.

Workarounds

• Stop IE from calling the Extension Validation component in the first place: Remove CLSID of MpOAv from the Extension Validation keys [HKLM\…\Internet Explorer\Extension Validation]. This requires adminstrative rights and can be distributed via Group Policy. Be careful: Future updates of MalwareProtection might recreate the registry entry.

• Uninstall Microsoft System Center Endpoint Protection / Microsoft Malware Protection. Use a different product.

Long term solution

• File a bug with Microsoft and/or Adobe? I fear they will blame each other. ;)
• Maybe better wait for Microsoft Spartan with integrated PDF support.

Solution 2

Group Policy could be adding that registry value. The gpresult tool can give you insight into the settings being applied via Group Policy.

Any program running as the user could be doing it, because users have rights to modify that part of the registry by default. Being that it's changing "Every few days" I suspect it's not Group Policy that's doing it (since policy refresh happens more frequently than that).

I'd consider enabling auditing on the HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings registry key and watching the Security Event Log to catch the modification. (I don't hasten to link to blogs, however the procedure in this entry is nice because it doesn't involve making changes to audit policy via Group Policy, which most of Microsoft's official examples do.)

You'll probably also want to enable process tracking auditing to get a clear picture of what processes are involved in the modification.

Solution 3

While oleschri's answer is quite comprehensive, I want to add some additional detail.

In my observations, I do not see MpOAv impacting or being related to this issue. Removing the Extension Validation key also does not change any behaviors I experience - the rest of the post got me to dig further...

When using Internet Explorer 11 and visiting many Google webpages (Google Images, for example), an error is generated on the Javascript:

{var c=function(a){try{return new window.ActiveXObject(a),!0}catch(c){return!1}}

just after attempting the return new window.ActiveXObject(a) segment.

This causes IE to make the \Ext\Settings\{CA8A9780-280D-11CF-A24D-444553540000} registry changes, and disabling Adobe PDF Reader Add-On. This is observed using the Sysinternals tool Procmon and filtering the path to our registry location.

As of IE 11, the window.ActiveXObject property is hidden from the DOM. https://msdn.microsoft.com/library/dn423948(v=vs.85).aspx

Bad/outdated code from Google? Certainly doesn't mean that Microsoft can't handle the exception better.

Solution 4

Oleschri's explination is highly accurate.

One MS Support explanation was this a few days ago:

"After internal analysis and working with partners, we believe we’ve identified the root cause as a problem with how Adobe is using our registry key in IE, resulting in Adobe behaving as if it is blocked or not installed even though it is. The problem has been reported, and should be addressed in the next quarterly update of the Adobe PDF product. SCEP exposes the issue by activating the IE plug in scan functionality, but does not cause the issue. This also explains why we are not seeing similar issues with other IE plug ins."

There is no solution which is completely adequate. Short term solutions include including running a group policy client side preference to delete the Adobe CLSID key every so often if found, or modifying a IE shortcut to delete the CLSID before launching. Disabling Malware scanning in IE11, either per client or Group policy setting, via Internet Security Zone Settings, "Run Antimalware Software on ActiveX controls" is far from a wise choice I think most would agree.

Completely not recommended

GP location for setting is: "Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page\Internet Zone\"Don't run antimalware programs against ActiveX controls"

Adobe Resolved Issue

Fortunately, Adobe released v 11.0.14 on January 12th, 2016 which resolves this issue. As well, Adobe Reader DC, of the same release, date does not have this issue as well.

http://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotes/11/11.0.14.html

Here is a little VB script you can make a shortcut out of and deploy. This will delete the Adobe Reader CSLID then launch IE and go to Google.

Set WshShell = WScript.CreateObject("WScript.Shell")
On Error Resume Next
Key = "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{CA8A9780-280D-11CF-A24D-444553540000}"
WshShell.RegDelete Key & "\" 


CreateObject("WScript.Shell").Run "https://www.google.com"

Wscript.quit

Regards

Solution 5

Thanks to both oleschri and Jair for the information; it has been extremely helpful.

One thing I would like to add is that this issue only affects my users that have UAC turned off. If you watch Procmon while forcing the issue to occur (by going to google images...) you will notice that IE is looking for the below key and failing with the result "NAME NOT FOUND":

HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{CA8A9780-280D-11CF-A24D-444553540000}

If the user's UAC is on, this is all that happens. Procmon shows IE looking for the key a few more times and then nothing. However, if UAC is turned off you should see "RegCreateKey" operations from IE (like oleschri explained in his post). It looks like IE is not finding the keys it wants, so it is creating them. I think UAC is stopping IE from creating the keys, which is why only my users who have it off are experiencing the problem.

View more solutions

Comments

[Vojtěch Dohnal]

We use SCCM to deploy Acrobat Reader, but I am not the domain admin, I develop some apps using AR XI and solve some user's problems. I have even added "Enable Acrobat XI" menu command to my app and I feel that our domain admins will not solve this problem unless I tell them exactly what to do. Though I can use registry monitoring as local admin so I will try it.

[Adel Bassiony]

@vojtech Do you still experience the reappearing key or have you found a solution or workaround?

[Adel Bassiony]

@VojtěchDohnal And which exact version of Adobe Reader (10.0.xx) is deployed in your environment?

[Vojtěch Dohnal]

It still happens, users have to run a script that fixes the problem for the next several weeks. Unfortunatelly I have not find a way how to monitor adding a subkey to registry. We use Adobe Reader XI, which version exactly I am not sure now.

[Adel Bassiony]

@jscott Have you been able to find a real fix to this?

[jscott]

@oleschri I've not found resolution. We put in place a user Group Policy preference to delete the registry key. This isn't perfect, but it ended a lot of user frustration. Should you, or anyone else, identify the true cause, I'd be happy to reward a bounty.

[Adel Bassiony]

@jscott, Vojtech: I may have found the root cause. Any chance you guys are (like us) using Microsoft Malware Protection / System Center Endpoint Protection?

[jscott]

@oleschri Yes, these clients use Microsoft's Endpoint Protection. Please do post an answer if you've a solution to share.

[Vojtěch Dohnal]

@oleschri Yes we use Microsoft Endpoint Protection too.

[Vojtěch Dohnal]

Thanks for this useful suggestion, I will try that and give the feedback.

[Vojtěch Dohnal]

But in fact I have even not found the event for deleting the key but I can be quite sure it was deleted and that the deletion gets logged when done via regedit...

[Vojtěch Dohnal]

I confirm the existence of metioned registry keys, looks promising!

[Vojtěch Dohnal]

But I fear that removing MpOAv from validation extensions completely will result in less secure browsing for users.

[Adel Bassiony]

@VojtěchDohnal We do not allow our users to install any ActiveX controls by themselves and we restrict Browser Add-Ons to a specific list via Group Policy. So this is not a real problem to us.

[Vojtěch Dohnal]

You are right, this is also our case.

[Jair]

Internet Explorer 11 Security Settings - Internet Zone (or desired zone) ActiveX controls and plug-ins Run antimalware software on ActiveX controls: disable

[Adel Bassiony]

I will definitely have a look at this in case our current workaround breaks down.