Last fall, the Outlook documentation team approached me about using an Outlook Social Connector provider I built for an internal social network we have here at Microsoft (called OfficeTalk) as an example for a Visual How-To series on MSDN. It took a few months to get it all done, but you can check out the series here: Developing a Real Outlook Social Connector Provider
The Office 2010 PIAs are finally available for download:
We’ve been seeing some cases over the past year where customers are using CDOEX or EXOLEDB in managed code on Windows Server 2008 and Exchange 2007 and are randomly getting RPC_S_UNKNOWN_IF (0x800706B5) errors. The issue only seems to occur under load. The same code worked fine on Windows Server 2003.
While we still don’t know the root cause, here’s essentially what’s going wrong: In the Exchange Information Store (“store”) we have our COM server for EXOLEDB which services remote calls to it’s interfaces. When you call SaveToContainer or SaveTo, under the hood, CDOEX leverages the ITransactionLocal interface of its OLEDB implementation to do a transactional commit to the store. If you have lots of these transactions going on, at some point what happens is that you release a reference to one of these objects and that drops the ref count on the store-side to 0. Shortly after that, if msado15 is loaded into store, the COM subsystem running in store will ask all the COM DLLs if they’re ready to unload. MSADO15 (which also implements ITransactionLocal) answers “yes” and is unloaded. As part of that process, it unregisters the ITransactionLocal interface from RPC and the next call your client makes on that interface fails with the above error. You’d have to restart the store to get back to a good state. What has made this so tricky is that all the release calls look valid and appropriate. When you’re talking about a scenario that only occurs under load, you’re talking about a lot of release calls. It’s the proverbial needle-in-a-haystack.
So what do you do?
Here are a few options from most immediate relief to more long-term:
Choosing option number 3 is probably your best option for the long term. For one, that guy you hate might go postal if he has to man the Services console for too long. For two, we never recommend as a rule that you should go back to a previous version of a product simply because you lose out on the great security and feature enhancements of the more recent version. That leaves number three, which should be something on your future plan list anyway.
CDOEX along with all the other web store technologies like WebDAV and EXOLEDB don’t even exist in Exchange 2010 and beyond so your application can’t work against the current and future versions of Exchange. These technologies were deemphasized in Exchange 2007 which makes it very difficult to get the product team to agree to invest time creating a fix – especially when the workaround is “easy” (use EWS instead). Your only option is to use EWS in place of your CDOEX code. This does a few things for you. You can support Exchange 2007 and beyond using a highly tested and powerful technology. You now have the option (and it’s recommended) to run your application on a different server than your Exchange Server. Exchange admins will love this. As I mentioned, I’m sure all of you were planning to move to EWS for Exchange 2010 anyway, maybe this problem just pushes those plans up on the list a bit.
Are any of you using CDOEX and getting this error? If so, do you have a consistent repro (the shorter and simpler the better)? If you’re moving your CDOEX code to EWS and have questions about how to do in EWS what you’re currently doing in CDOEX, lets hear them!
You may remember when I unveiled the Outlook Social Connector Provider Proxy. Well, good news – I have updated the OSC Provider Proxy Library to now support OSC v1.1 and also built it for .NET v3.5 in addition to the v4.0 build available with the original release. Check it out!
Starting in Silverlight 3, the algorithm that SL uses to determine the hosting URL of the SL control doesn’t work properly when the page is viewed as part of an Outlook Folder Home Page. This is actually a known issue and is being looked at for Silverlight 5 but was not discovered early enough to make it into Silverlight 4.
If you are developing a solution that includes the use of Outlook Folder Home Pages, I’d recommend you consider another option if you plan on doing any advanced things in your solution. Folder homepages are good for hosting plain ol’ HTML and an occasional Outlook View Control, but because of the security lock-downs that are added in each new version of Outlook, the flexibility you have for using various techniques inside OFHPs is limited. Depending on what you are trying to accomplish, you may want to consider using Form Regions and Ribbon customization or else simply providing a link to your high-complexity web page instead of providing the content inside Outlook itself.