Fixing the name.dll ActiveX Problem the Mossman Way

UPDATE: Are you using SharePoint 2010? See my newer post about the name ActiveX message in SharePoint 2010.

Have you seen this message on public facing SharePoint sites:

The Web site wants to run the following add-on: ‘Name ActiveX Control’ from ‘Microsoft Corporation’. If you trust the Web site and the add-on and want to allow it to run, click here…

For an example of one (at least until they fix it), check out:

http://www.viacom.com/pages/default.aspx

There are quite a few nice examples of internet facing SharePoint 2007 sites on the interwebs these days, however many of them seem to be plagued by this minor annoyance that seems to have slipped through the Microsoft cracks. The problem is compounded by the fact that most developers won’t even notice the issue until their portal is available to internet users. This is due to the fact that the problem is seen only in Internet Explorer 7 and only when you are visiting a WSS v3 website that is NOT in your trusted site list for IE. You will not see the message most of the time in your local environment because, by default IE knows you are visiting an intranet site and auto-magically puts the site in your trusted list… then as soon as you visit the site with an external domain name, boom, your see the warning pop up.

Apparently, SharePoint is trying to access “Presence” information that is available in Office, and for some reason they decided to name this ActiveX “name.dll”, which really couldn’t sound more like a trojan horse. Asking for more information on the ActiveX control doesn’t help either. Most end users get immediately turned off to your website, and generally its just not a very professional way to present your portal.

So, I’m sure your thinking “Mossman, how do I correct this problem?” Microsoft has a knowledgebase article on the topic here: http://support.microsoft.com/kb/931509. But, at least for me, this never works, since the “InitNoPresence.js” seems to always load after my custom .js in a SharePoint publishing site. What I do instead is include my own custom javascript file in the PlaceHolderAdditionalPageHead of my master page which overrides the offending out of the box javascript line. This ensure2 that our javascript is always loaded last in the chain (which is key). I have no idea if this is an approved way of tackling the problem, but it effectively does the same thing described in the kb article, only it actually works. So, without further fanfare, I will show you my code. You are free to use it in your sites but please leave in my comments.

In your master page, place a reference to my custom javascript file in your

section after a PlaceHolderAdditionalPageHead, like this:

Now upload the following javascript file to the “_catalogs/masterpage” directory of your SharePoint site. Also, you might as well Publish and Approve the uploaded file as well (since anonymous users won’t be able to see it otherwise).

custom_activex_override.js

Basically, this javascript file overrides the out of the box “ProcessDefaultOnLoad” and comments out the call to “ProcessImn()” which causes the ActiveX to be called.

Please, feel free to try it out and let me know if you experience any problems or if you have any suggestions on better ways to tackle this problem.