Bleus
asked on
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!
-Brett
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!
-Brett
Brett
Let me know if that works. I am really curious + there is no MSFT documentation on this.
Let me know if that works. I am really curious + there is no MSFT documentation on this.
ASKER
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:
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! :)
-Brett
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-bb 82-00aa00b dce0b" 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! :)
-Brett
I tested this from the OWA Login page (not post login page)
On Exchange 207 SP1
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.
work-around:
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
(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.
work-around:
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
ASKER
Hmm... well, to re-state what I said above:
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!
-Brett
1
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).2
In Vista/Windows 7, any user who is restricted from applying the GPO has no issue with OWA.3
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.)4
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.5
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!
-Brett
ASKER
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:
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?
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.DomDClearly 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).ocument"); }
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.
will post back if I figure out something.
ASKER
This shouldnt be so hard...rofl -- I completely agree! -- and yet... :P
-Brett
What 2007 SP and Update rollup is installed ?
ASKER
From above...
-Brett
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)...
-Brett
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
http://support.microsoft.com/kb/911829
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?
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
http://support.microsoft.com/kb/911829
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Brett
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.
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
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
thanks
clsid.jpg
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.
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
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
thanks
clsid.jpg
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.
"D801B381-B81D-47a7-8EC4-E
"833aa5fb-7aca-4708-9d7b-c
"4F40839A-C1E5-47E3-804D-A
Taken from these 2 lines:
("MimeNSe2k3", "D801B381-B81D-47a7-8EC4-E
("MimeNSe2k7sp1", "833aa5fb-7aca-4708-9d7b-c
("MimeNSe2k9", "4F40839A-C1E5-47E3-804D-A
OPEN IE
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..