Dave Ginn recently tried out my name.dll fix (read more about it in my previous post) and ran into a problem with some users not being able to access the Site Actions menu. Personally, I have deployed the code to several external MOSS sites and not run into the problem. Let me know in the comments if you have used my fix code successfully or not, as I’m trying to determine what sort of setup causes it to occur.

Note: Dave fixed his problem with some code modifications and posted it to his site. I may end up rolling this code back into my source here at this blog.

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.