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.?

Answer 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.

Answer 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.

Answer 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.

Answer 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

Answer 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.

Answer 6

I have found this option in the internet security zones to disable the 'extention validation'. Don't run antimalware programs against ActiveX controls

set this option to 'disable' for the moment, hopefully MS en Adobe volve this together :)