Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1514
  • Last Modified:

Need to identify CLSID's of IE Browser Add-Ons necessary for OWA 2007 functionality.

The title pretty much says it all.

We block all browser plug-ins via GPO with specific exceptions. Unfortunately, I have been unable to find a definitive list of what Brower Add-Ons MUST be enabled for OWA to function correctly.

If anyone can tell me even just which add-ons are required, I'll happily search out the CLSID's on my own!

We have a select few user accounts that don't apply the IE Add-On restricting GPO, and they can access and utilise OWA without any problem. Users who are not blocked from applying that GPO, and who use Vista or Windows 7 encounter Browsing Errors whenever they try to make use of OWA, especially when replying or trying to set/view Options.

Additionally, the problem does not appear to manifest on XP, regardless of whomever is trying to access OWA.

Anyway, if I add the affected users to the global group that prevents them from applying the GPO, and then update their group-policies, the problem disappears. The downside being that doing so essentially obviates our intention to restrict access only to specific IE Add-Ons.

Pls Help!

1 Solution
I'd Guess these 2 CLSID's


Taken from these 2 lines:

("MimeNSe2k3", "D801B381-B81D-47a7-8EC4-EFC111666AC0", "MIMEe2k3", "mimeLogoffE2k3");
("MimeNSe2k7sp1", "833aa5fb-7aca-4708-9d7b-c982bf57469a", "MIMEe2k7sp1","mimeLogoffE2k7sp1");
("MimeNSe2k9", "4F40839A-C1E5-47E3-804D-A2A17F42DA21", "MIMEe2k9", "mimeLogoffE2k9");

Go to your OWA using an account which has complete access.
View > Source
Search for CLSID

You will come across these above.

I didnt see a kb / Technet article on that. That's funny..
Let me know if that works. I am really curious + there is no MSFT documentation on this.
BleusAuthor Commented:
Are you sure you're using OWA from Exchange 2007?

For additional clarification, we've upgraded to Service Pack 3, Rollup 1.

I ask because on the main OWA screen (the one designed to look like Outlook), when viewing source, I am unable to find any CLSID's in the source for the page...

On the OWA Options page, however, I found:

<object id="dlgHlpr" classid="clsid:3050f819-98b5-11cf-bb82-00aa00bdce0b" width="0px" height="0px" viewastext></object>

But I'd already enabled that class-id in the GPO (it's for the dialog helper object I believe).

Nevertheless, I've added the 3 CLSID's you mentioned anyway... but I won't be able to actually test it now until tomorrow when I can get access to an on-site Windows 7 machine...

Thanks for your insight! -- We'll see what tomorrow brings! :)

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

I tested this from the OWA Login page (not post login page)

On Exchange 207 SP1
IMO, there is not Iexplore 8 Add-ons required for the OWA to function.
(as per my machine)

OWA is designed to work most of the browsers.... if the sufficient options are not available the OWA form will decide the same and select the option for "OWA Light"

IMO, the above CLSIDs are 3 options available in the OWA logon-code...so based on the browser version one of the CLSID\object is going to be loaded\used...but not necessarily be the Add-ons.

1. Try disabling the max. possible add-ons and see if you are able to use OWA-premium
if yes, then there is not need for the add-ons

2. If any of the Add-on is interrupting the scripting\processing of the browser..then that add=on shouldn't be allowed to be removed.
reason: that means you are forcing all the OWA users for the OWA-light

BleusAuthor Commented:
Hmm... well, to re-state what I said above:


We have a GPO that enforces blocking of IE Add-Ons and it is applied to all but a few users who are restricted (prevented) from applying this GPO. Given the nature of GPO's, I would expect that this setting overrides any other with regard to Add-Ons being permitted to run (or being blocked).


In Vista/Windows 7, any user who is restricted from applying the GPO has no issue with OWA.


In Vista/Windows 7, any user who has the GPO enforced, sees the "Add-On Blocked" icon when they are logged into OWA. (A little cog on the bottom status-bar with a do-not-enter sign tagged onto it.)


The result is a myriad number of errors that crop up ("Web browsing error") on certain areas of the interface, including the Options page, and the Reply-To window, which prevents OWA from being used properly.


Putting a user who applies the GPO, and who had been experiencing the problem, into the exclusion group eliminates the errors, and the "Add-On Blocked" icon. Taking them out again (and I'm using "GPUPDATE /FORCE" and a re-logging-on for each of these actions) brings the error back.
I tried looking at the source of the Reply-To form, but I wasn't able to find a means to "Show Source" on that window.

On a side note, this process would be a LOT easier if IE simply showed you a list of what Add-Ons were being blocked!

BleusAuthor Commented:
Update: Adding those three CLSID's doesn't appear to have made any difference. :(

On the "for more information" topic...

A common source of errors is the uglobal.js file. One of the major errors is "Unable to create object", and the relevant line from the file is:
function getXmlDoc(){return new ActiveXObject("MSXML2.DomDocument");}
Clearly an ActiveX call... however the site is placed in the "Trusted Sites" zone, and ActiveX is not prohibited or disabled for that zone (for each of the options in IE, it is set to either Enabled, or Prompt).

But I'm wondering if there's a necessary CLSID for "ActiveX" controls...

And another point (which is probably a complete red-herring): the javascript above references "MSXML2.DomDocument", and I noted that one of the (GPO-enabled) IE Add-Ons is "XML DOM Document" from Microsoft, however the referenced DLL for that add-on is "MSXML3.DLL". I haven't seen any references to an "MSXML2.DLL" in IE... was that file updated in Vista/7?
This shouldnt be so hard...

will post back if I figure out something.
BleusAuthor Commented:
This shouldnt be so hard...
rofl -- I completely agree! -- and yet... :P

What 2007 SP and Update rollup is installed ?
BleusAuthor Commented:
From above...
For additional clarification, we've upgraded to Service Pack 3, Rollup 1.
Installed and fully updated as of Thurs night last week (I was hoping applying all those updates would address this issue)...


This shouldnt be hard at all...

Makes it even more wierd, is that starting IE without Addons, I an access OWA just fine...... All of the areas mentioned above dont give me those errorrs.....

Both on XP/IE8, and Windows 7..... Wondering if it is in fact a red herring of an error?

I remember a single control referenced in the followoing....

You receive an error message when you try to perform any editing tasks, or you must click to enable the compose frame in Outlook Web Access

Only reason I bring this up, is because it looks to me like I can access OWA regardless of having ANY addons enabled...... Which makes me wonder whats really happening? Maybe thats why it isnt this simple?
BleusAuthor Commented:
I've seen a lot of text wrt that error while working this problem, and it always seems to reference an ActiveX control for the editting suite whose "normal" operation wasn't compatible with the security models of Vista and IE7/IE8 (allowing that Win7 is essentially Vista w/ a UI upgrade).

The fix was to apply a specific KB patch to the Exchange Server that replaced the outdated ActiveX control with a new control (javascript perhaps?) that would be accepted by the new os/browsers.

Also, IIRC it primarily related to Exchange 2003 (unless you have more up to date information?)

Lastly, having now patched our Exch2k7 to be as up-to-date as I can make it, I have been assuming such things as (replaced) legacy ActiveX controls are also at their most recent iteration...

Thanks for posting the solution. Let us know what kb you used.

I was stuck with CLSID side of things and figure out something which I wanted to share.

Let's say you have a XXX CLSID which is getting blocked by group policy, because of which OWA or some other site is not loading properly.
Question is how do you find out what CLSID it is ?

a) Download procmon.

Actually we just need the regmon part of procmon. Since regmon is no longer available stand-alone, hence procmon.

b) start procmon.
On the procmon toolbar - deselect everything other than registry icon.

c) Filter
Process Name - IEXPLORE.EXE
path - contains CLSID
Now the third filter should be filter by RESULT > and enter the string from the results column with FAILURE / BLOCKED/ whatever pops-up

I didnt apply a GPO to test this, so i didnt get that string. I searched for NAME not found and lot of stuff popped-up.

My guess is if you are looking for some CLSID which is blocked you should be able to find out from here.
Maybe you can try it out and see if that works.

My $.02


This question has been classified as abandoned and is being closed as part of the Cleanup Program. See my comment at the end of the question for more details.

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now