Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

The Case of the Missing SharePoint “Connect to Outlook” Action

Posted by William Diaz on December 1, 2011

This one originally came to me as a complaint from a single user about his inability to connect one of his SharePoint calendars to Outlook 2003. In most SharePoint lists, there is an Actions menu that should contain this option:
Often, this problem is resolved by installing the SharePoint Services Support for Office and/or simply repairing Office. You can also find a good guide to troubleshooting this issue here. But none of these options were resolving the issue. Additionally, as I began to investigate to see if the problem could be recreated on various tech workstations, I realized that the impact was not isolated to a single workstation, but almost all workstations in our helpdesk. Of the systems that were not affected, one of them resided on my desk, a lab PC that had since departed from the standard Windows XP Pro image we deploy firm-wide.

I needed to find the difference between those workstations where the “Connect to Outlook” feature was working and those where it wasn’t. To start, I would need to find the name of the component involved that implemented this feature and then use Process Monitor to capture a trace of Internet Explorer activity when visiting a SharePoint list and opening the Actions menu.

I already knew from earlier troubleshooting that OWSSUPP.DLL was involved, and after a little research I found this tidbit of information:

Client File: OWSSUPP.DLL
Also Known As: SharePoint Stssynch Handler
Function: Connect to Outlook to synchronize lists

Armed with that, I started up Process Monitor on one of the problem workstations, set a filter for iexplore.exe, opened a SharePoint Calendar, selected the Actions menu, and stopped the trace. Next, I started a search via CTRL+F, using Stssync as as the criteria in the procmon log. I’m ignoring the hits in HKCU and focusing on those in HKCR only:
From here, I can right-click one of the operations above and jump to it in the registry automatically from the context menu, which takes me to the SharePoint.StssyncHandler.2 key, where we have a class identifier:
You can find CLSID keys in HKCR\CLSID\, and in {BDEADEF4-C265-11D0-00A0C90AB50F} there is the expected reference to the OWSSUPP.DLL for Office 2003 (Office11 folder):
Something catches my eye, though, while examining the other sub-keys: it’s the presence of the TreatAs sub-key, it’s pointing to another CLSID right below it. But looking at this sub-key, I can see it’s empty. Like the key above it, it should have the same corresponding sub-keys.
I need to compare this key against a couple different workstations where the “Connect to Outlook” feature is working to see what is different. As expected, on the workstations where the feature works, there is no TreatAs key pointing to the {BDEADEF5…} key. On all the workstations where the feature is not working, the TreatAs key is present and pointing to {BDEADEF5…}, which is empty.

So, where is {BDEADEF5-C265-11D0-00A0C90AB50F} coming from? The answer is on a lab computer that was not having the problem but did, in fact, contain the correctly populated key and sub-keys. And upon examining InProcServer32, I can see it points to a version of OWSSUPP.DLL for an Office 2010 installation (Office14 folder):
And here it hits me, all the affected workstations have Office 2010 App-V installed. The majority of the company is still using Office 2003, but a good portion of our techs and various users need to be able to work with Office 2007/2010 files natively (that means not using the Office 2003 compatibility pack). So that both Office 2003 and Office 2010 (Outlook 2010 is not included) can co-exist peacefully side-by-side, Office 2010 is deployed via App-V, which is the product that is responsible for creating CLSID {BDEADEF5-C265-11D0-00A0C90AB50F}.

But why was this key not being properly populated in all cases where App-V Office 2010 was deployed (with the exception of the lone lab PC)? Well, knowing that we are dealing with App-V and SharePoint’s “Connect to Outlook” action, a search of these two terms revealed Microsoft KB 2481474: Known issues and limitations when using virtualized Office 2010 applications on App-V 4.6 and App-V 4.5 SP2 clients. Here, it goes onto to state:

The “Connect to Outlook” feature is not available when viewing a calendar on a SharePoint site
If you view a calendar on a SharePoint site and select the Calendar option under Calendar Tools, the “Connect to Outlook” option is not available.”

OK, fair enough. But I am not interested in connecting SharePoint to Outlook 2010 App-V. As I mentioned, we do not deploy Outlook 2010 with the App-V package. I just needed to get it to work with the local installation of Outlook 2003. Well, this wasn’t too difficult: it simply entailed deleting the TreatAs key in HKCR\CLSID\{BDEADEF4-C265-11D0-00A0C90AB50F}, which prevented it from pointing to OWSSUPP.DLL for Office 2010.

However, there was still the minor case of why this feature was working on the lab PC sitting on my desk. It had local Office 2003 and App-V 2010, but there was a something here that corrected the problem with the registry key not being properly populated. After poking around in the Office 2003 folder in the Programs menu, I noticed Microsoft Project 2010 was sitting in there. I had installed this a couple months earlier as a local installed app, not as an App-V. I guessed that installing any Office 2010 product locally also created {BDEADEF5-C265-11D0-00A0C90AB50F} with all the correct sub-keys and values. To test this, I installed Project 2010 on one of the workstations and after checking the registry saw that this was, in fact, the case, and thus the reason why the lab PC’s “Connect to Outlook” action was working.

Always interested in the internals of Office and Windows, I wanted to look a little deeper into the lab PC where the “Connect to Outlook” feature was working to see what was different between Office 2010 and Office 2003 Stssync, and for the most part it’s a difference of versions of the StssyncHandler protocol:
StssyncHander.3 is synonymous with the version of OWSSUPP.DLL located in the Office14 folder, the same way that StssyncHandler.2 points to the earlier version of this dll in the Office11 folder. And, Finally, they key that ties it altogether resides in HKCR\TypeLib\:
Which is also missing on the problem workstations where App-V Office 2010 is installed:
With this bit of info, alternatively (and just for the heck of it), you could also work around the issue by creating the missing reg keys above and including the latest version of OWSSUPP.DLL in the office14 folder, although I doubt that would serve any useful purpose since you couldn’t use Outlook 2010 App-V with SharePoint anyways.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: