JasonJoh's [MSFT] WebLog

Ch-ch-ch-ch-changes!

jasonjoh — Sat, 09 Feb 2008 05:02:23 GMT

It's been almost 2 years since I joined the Premier Field Engineering team here at Microsoft to support the HMC solution. A lot has changed since that day. We've seen a new version of Exchange roll out, and a new version of HMC to go along with it. Today marks yet another change for me. Today was my last day with the Premier Field Engineering team. I'm joining the Exchange UA team to help in the effort to document the "over-the-wire" protocols between Outlook and Exchange.

Supporting HMC has been a great experience. Chris Vandenberg and his team are doing great work on HMC, and they've got even greater things planned. My old team under Janie Gray is made up of some of the greatest folks in PFE. While I'm excited to start in my new role, I'm a little saddened to be leaving such a great group of people. Best of luck guys, not that you'll need it!

As far as the blog goes, it'll probably get more development-oriented. Stay tuned and we'll see where it goes.

Exchange 2007 SP1 and HMC 4.0

jasonjoh — Fri, 30 Nov 2007 18:48:00 GMT

~~Yes,~~ ~~Exchange 2007 SP1 is out. No, it has not been cleared with HMC 4.0 yet. At this point you should not install SP1. We are working on getting this tested and should have an update soon. Until then please be patient!~~

I am pleased to announce that the HMC Product team has finished a full regression test on HMC 4.0 with Exchange Server 2007 Service Pack 1, and not found any problems. It is therefore safe for customers running or deploying HMC 4.0 to install SP1. In fact it is recommended that HMC 4.0 customers upgrade to SP1 as soon as possible. As always they should first test carefully in their own test environment.

An HMC whitepaper will be made available for download from the HMC website in the coming weeks. The whitepaper describes the benefits to hosters and their customers available in SP1, and also gives you important information about the installation, including required and recommended hotfixes.

The whitepaper does not repeat all of the SP1 information published by Exchange. Make sure you read the release notes! There is also a wealth of explanatory information on SP1 available on TechNet.

Note that the Product Team's testing was not done on the original build of HMC 4.0, but on a system which had also had the important HMC rollup fixes installed. Prior to installing SP1 you should be running these fixes:

The "HMC Exchange Rollup" (942100)
The "HMC SharePoint Rollup" (943837)

See my previous post for more info on the fixes.

IMPORTANT NOTE: - All future HMC4.* features and hotfixes will be built assuming SP1 is installed. An early hotfix which will be available under KB 944021 takes advantage of an Exchange fix included in SP1. The hotfix greatly improves provisioning performance in environments with many MAPI-enabled organizations.

Making Sense of Patching HMC 4.0

jasonjoh — Thu, 29 Nov 2007 18:24:18 GMT

Patching HMC has never been a fun process. Unlike most Microsoft products, HMC patches don't come in nice neat installer packages that can just be installed on top of your existing setup. This causes some consternation, since we're used to being able to run a hotfix installer and trusting the Windows installer technology to handle updating the needed components if they needed to be updated, or letting us know we've already got a newer version if they don't.

HMC patches are different. There are good reasons for this (maybe I'll cover them in another post). For better or worse, it causes a number of calls to us to help sort through the confusion. From a simple "exactly what patches do I need?" to a complicated error caused by mismatched versions, I've dealt with enough calls to inspire this post.

So here's my attempt to make sense of things. This is my suggestion for patching an RTM deployment of HMC with the latest fixes.

Windows 2003 Service Pack 2 and 939216

Of course you followed the deployment guide to the letter, and you only have Service Pack 1 installed on your MPS engine server, right? Good! There's a very good reason for this. The version of MPS that shipped with the RTM of HMC 4.0 was incompatible with SP2. However, we released a hotfix for MPS that resolves this incompatibility. So go ahead and install SP2, then install the hotfix from the following article:

Some provisioning requests do not work, and you receive a "0xc220140b" error message after you install Windows Server 2003 Service Pack 2 on a server that is running Microsoft Solution for Hosted Messaging and Collaboration version 4.0

This is the easiest hotfix you'll find for HMC! It's just like most hotfixes you're used to. You just run the package and step through the wizard. This update only applies to MPS engine servers.

936086 (The Multiple Results Fix)

One of the first problems we encountered were some issues in our namespaces when multiple results were supposed to be returned. The namespaces were returning only a single result. This fix addresses that.

This is one of those complicated hotfixes, and unfortunately the knowledge base article that gives detailed instructions on installing it is stuck in limbo. So for the meantime I've posted instructions here.

NOTE: This fix includes HostedSharePoint2007NS.msi and HostedSharePoint2007WS.msi. These will be superseded by the Windows SharePoint Services Provisioning Rollup below. So if you wish you can skip doing those here.

943792 (The Multiple Results Fix Part II)

We discovered a similar issue to 936086 in the Managed Plans namespace as well. This fix addresses it. Find instructions here.

942100 (The Exchange Provisioning Rollup)

Taking a page from the Exchange team's release strategy, we decided to package up the hotfixes made to the Exchange namespaces and web services into a rollup. This fix addresses a number of issues which I won't go into here. When the KB article gets released it will have all those details. For now, find the instructions to install here.

943837 (The Windows SharePoint Services Provisioning Rollup)

The same idea as 942100, but this time for WSS. Find installation instructions for this one here.

WSS 3.0 Security Fix causes Performance Issue for Hosters

jasonjoh — Wed, 10 Oct 2007 17:29:00 GMT

I was notified this morning that a recently released security fix for WSS 3.0 has some severe performance issues for folks using host-header mode with a large number of sites (sound like anyone you know?). Read below for the official announcement:

Important known performance issues about security update MS07-059 when deployed in hosting scenarios with multiple host-named site collections

Microsoft has released, on October 9, a security bulletin, describing an important security update for Microsoft Windows SharePoint Services 3.0, which resolves a publicly reported vulnerability. The vulnerability could result in elevation of privilege within SharePoint sites.

If you do not use host-named site collections in your Windows SharePoint Services 3.0 deployment, you can, and should, already proceed applying this important security update MS07-059. You can also disregard the rest of this message.

On the other hand, if your Windows SharePoint Services 3.0 deployment uses host-named site collections, previously known as “host header” sites, you may experience severe performance issues while applying this security update, particularly if you have many of such host-named site collections. For example, this issue may occur when there are more than 50 host-named site collections in your deployment. In that case, we recommend that you do not apply this security update at this point. The described performance known issue is currently being addressed and Microsoft will shortly issue a complementary hot fix, which will enable the proper installation of security updates contained in the MS07-059 bulletin.

In order to obtain this upcoming hotfix, contact Microsoft Product Support Services. For a complete list of Microsoft Product Support Services telephone numbers, visit the following Microsoft Web site: http://support.microsoft.com/contactus/?ws=support

To read more details about the security bulletin, addressed vulnerability and known issues in deployments with many host-named sites, visit the following links:

· Microsoft Security Bulletin MS07-059 - Important Vulnerability in Windows SharePoint Services 3.0 and Office SharePoint Server 2007 Could Result in Elevation of Privilege Within the SharePoint Site (942017): http://www.microsoft.com/technet/security/bulletin/ms07-059.mspx

· KB article about the vulnerability in Windows SharePoint Services 3.0 that could result in elevation of privilege within the SharePoint site: http://support.microsoft.com/kb/942017

· Description of known issues while applying the MS07-059 security update for Windows SharePoint Services 3.0: http://support.microsoft.com/kb/934525/

We appreciate your consideration.

Adding Users to WSS 3.0 Site in HMC 4.0 Exposes Users in All Organizations

jasonjoh — Tue, 11 Sep 2007 20:54:00 GMT

If you followed our deployment guide to the letter, then chance are your WSS 3.0 setup isn't 100%. There's a big problem with the deployment guide for WSS that can break "multi-tenancy." Here's how you can check if you are broken and how you can fix the problem.

The Test

Log into an MPS-provisioned WSS site as the organization admin.
Click the Site Actions drop-down and choose Site Settings
Click People and Groups.
Click New.
Underneath the text box labeled "Users/Groups" click the little book icon (the Browse button)
Type something generic like 'a' and hit Enter

If you see users from other organizations, you've got a problem. What you should see is only users in the organization that owns the WSS site, as well as some of the built-in accounts and groups (unfortunately WSS is limited so we can't filter out those built-in accounts).

The Fix

This problem is created by the unneeded and incorrect Step 8 in procedure DWSH.1 in the HMC 4.0 deployment guide. That procedure instructs you to add the SharePoint_AppID, SharePointSrchSvc, and SharePointSrchCrl accounts to the Windows-based Hosting Service Accounts group. So to fix the problem you will need to remove these accounts from the Windows-based Hosting Service Accounts group and then restart IIS on your WSS front ends.

Quick and Easy Ways to Break your Provisioning Engine

jasonjoh — Thu, 30 Aug 2007 17:54:00 GMT

By now most people have discovered that installing Windows 2003 SP2 on your Provisioning Engine servers (MPS01 and MPS02 in the reference architecture) breaks provisioning completely. The problem is that SP2 includes some updates to the MSXML parser that breaks the way MPS transforms XML during its processing of provisioning requests.

Well as it turns out there's a number of security updates that get advertised by Microsoft Update that also include these fixes for folks that don't install SP2. So you can quickly get yourself into the same situation by blindly installing all of the security updates that are offered.

To be clear, Microsoft certainly wants you to install security updates in a timely fashion. However, we strongly recommend that hosters have a lab environment that mirrors production, and that any updates are tested in the lab before being installed in production. We all agree downtime is bad, and it's better to discover these things in a lab instead of production.

That being said, here's a list of updates we've run into problems with in support. The HMC product group is aware of all of these and we are investigating fixing them as we speak. I'll update this post as we uncover more patches or as we fix the ones we already know about.

Patches with Known Problems on MPS

~~Description of the security update for Microsoft XML Core Services 3.0: August 14, 2007: This one will impact both HMC 3.5 and HMC 4.0 environments. We're currently investigating fixes for this. You will see errors like "Only one top level element is allowed in an XML document."~~ UPDATE: This has been resolved. A hotfix for MPS has been released. You can obtain this fix by contacting Microsoft CSS and requesting the fix for 939216. As of this posting the KB article for the fix has not been published, but it is currently in the process.

~~Description of the security update for the .NET Framework 2.0 for Windows Server 2003, Windows XP, and Windows 2000: July 10, 2007~~: This one should only impact HMC 4.0 as it is an update for the 2.0 framework, and 2.0 isn't installed on MPS servers in a 3.5 deployment. This one is also being investigated. You will see an error like "Unable to generate a temporary class (result=1)." UPDATE: This has been resolved. A hotfix for the Exchange 2007 Provider has been released. You can obtain this fix by contacting Microsoft CSS and requesting the fix for 942100. As of this posting the KB article for the fix has not been published, but it is currently in the process.

I strongly urge you to contact support if have any questions about installing a particular patch. If you do install a patch and find it breaks provisioning, please report it through support channels so we can properly investigate it!

More than 1000 OAB's in Your HMC 3.5 Environment?

jasonjoh — Fri, 01 Jun 2007 03:48:00 GMT

Have you seen any OAB's mysteriously disappear? Then you're going to want to check out this knowledge base article, then call support to get them to send you the hotfix.

Users cannot download offline address books in Exchange Server 2003 when you use Microsoft Solution for Hosted Messaging and Collaboration version 3.5

Problems changing password in the HMC Consolidated Sample Control Panel

jasonjoh — Thu, 29 Jun 2006 17:33:00 GMT

A lot of folks have hit this apparently, so I wanted to share my findings and how to fix it.

PROBLEM

If a non-admin user logs in to the Sample Control Panel that comes with the HMC 3.5 Consolidated Server Deployment Guide (MPSSampleCP), they cannot change their password. The error received is:

An error encountered while processing object 'LDAP://ad01.fabrikam.com/CN=someguy@alpineskihouse.com,OU=alpineskihouse, OU=consolidatedmessenger,OU=Hosting,DC=fabrikam,DC=com'./Access is denied./UserSetPassword

CAUSE

The first clue is in the error message itself. It tells us that the error happened in UserSetPassword. It may not be immediately obvious, but UserSetPassword is NOT what we should be executing here!

First, some background. There are 2 different ways to change a user's password. The first is what any user should be able to do: change their own password. This is similar to changing your password in Windows. You're prompted for your old password, then your new password (twice, just to make sure). This is accomplished in the provisioning world via the ChangeUserPassword method in the Managed Active Directory namespace.

The second method is an administrator-only method: resetting a user's password. This is similar to right-clicking a user in Active Directory Users and Computers and choosing "Reset Password..." You're not prompted for the old password, since in most cases you shouldn't know it. This is accomplished via the SetUserPassword method in the Managed Active Directory namespace.

So that text in the error kind of tips us off that we're not doing the right thing here. Another clue is the UI that's presented to us in the Control Panel. The title of the page is "Reset Password," and we're only asked for the new password, not the old! A TraceView trace confirms it: we're calling the SetUserPassword method, not the ChangeUserPassword method! Since the user is not an administrator, they're not allowed to reset passwords.

RESOLUTION

Fixing it is fairly simple, assuming that you're somewhat familiar with Visual Studio. The whole password UI/logic in the Sample Control Panel is contained within a DLL called CorePlugins.dll. You'll find this DLL in %Program Files%\Microsoft Hosting\Provisioning\Samples\MPSSampleCP\bin. We need to rebuild this DLL using Visual Studio.NET 2003.

You'll find the source code for this DLL in %Program Files%\Microsoft Hosting\Provisioning\Samples\MPSSampleCP\CorePlugins. In that directory you should see a solution file called CorePlugins.sln. (If you don't, it's OK...look for CorePlugins.csproj instead). Open this with Visual Studio.

Now all you need to do is rebuild. No code changes are needed. Just make sure that you're doing a Release build. Go to the Build menu and select Configuration Manager. For Active Solution Configuration, choose Release and click OK. Then on the Build menu, choose Rebuild CorePlugins. This will rebuild the DLL. If it all works, the Output window should show this:

---------------------- Done ----------------------

Rebuild All: 1 succeeded, 0 failed, 0 skipped

From the CorePlugins directory, go to the .\bin\Release directory and you should see your new CorePlugins.dll. Rename the one in %Program Files%\Microsoft Hosting\Provisioning\Samples\MPSSampleCP\bin and drop this new one in.

You should now see that if a non-admin users logs in to the Sample Control Panel and chooses the Change Password option, that the page title is now "Change Password," and that you have 3 input boxes: one for the old password, 2 for the new. Best of all, when the user submits the request, it should work ;-)

Special thanks to dfrauzel for independently verifying this! I agree with his theory that most likely what happened was a last minute code change to the sample happened, and the binaries weren't rebuilt for the installer package.

I'm Outta Here

jasonjoh — Sat, 08 Apr 2006 01:01:00 GMT

Ok, not really, but I am moving to a new role here at Microsoft. I've been doing Messaging developer support for over 5 years now, and it's been great. The team I've worked with over the years is made up of some greatest folks I've ever met, and it was really hard to leave.

On October 21, 2005, Graham Scott Johnston was born, and my whole world changed. With the new addition to our family, my priorities changed. When this opportunity came along, I couldn't pass it up.

I'm moving to Florida and joining our Premier Field Engineering team. This will put us a lot closer to the rest of our families. I'll still be doing Exchange-related stuff: I'll be supporting Hosted Messaging and Collaboration.

So, this blog will be changing focus. I might still talk about Extended MAPI from time to time (I'll still be involved with MFCMapi), but I'll be primarily blogging about HMC. I'm a total n00b right now, but as I learn I'll post the interesting things I come across. ;-)

Yet another IExchangeManageStore incarnation

jasonjoh — Wed, 29 Mar 2006 22:46:00 GMT

Yep, that's right: IExchangeManageStore5 is upon us. And this is the coolest one yet!

I'm intrigued...what does it do?

The cool new feature in this interface is the ability to retrieve a mailbox table (or public folder table) that contains only mailboxes in a particular information store. Prior versions of the IExchangeManageStore interfaces would always return a table that contained all mailboxes (or public folders) across all stores on a particular server.

Big deal...I can query the Active Directory to find out what store a mailbox is in. Why should I care about this new interface?

Well, if avoiding the AD lookup isn't enough, there's one scenario where an AD lookup won't help you: the Recovery Storage Group. We recently documented how to connect to mailboxes in the RSG with MAPI. The kicker here is that when you have an RSG mounted, and you call one of the earlier GetMailboxTable variations, you would get two entries for mailboxes that existed in both the real storage group and the recovery storage group, with no way to tell them apart! (Yes, you can detect there are two identical entries and then assume that means the mailbox exists in the RSG, but all that table processing could get tedious)

Ok...I'm sold. How does it work?

The IExchangeManageStore5 interface includes 2 new functions.

IExchangeManageStore5::GetMailboxTableEx

The GetMailboxTableEx method obtains information about all of the mailboxes on a server in a particular store.

HRESULT GetMailboxTableEx(
  LPSTR lpszServerName,   
  LPGUID lpguidMdb,    
  LPMAPITABLE FAR * lppTable,  
  ULONG ulFlags,
  UINT uOffset
);

Parameters

lpszServerName
   Input parameter. Points to a string that contains the distinguished name (DN) of the server.
lpguidMdb
   Input parameter. Points to a GUID that contains the value of the objectGUID attribute of the information store.
lppTable
   Output parameter. Points to a MAPI IMAPITable interface containing the information about all of the mailboxes on the server specified in lpszServerName.
ulFlags
   Input parameter. A defined value that specifies whether the server name is Unicode:
      MAPI_UNICODE
      The server name is in Unicode format.
      0
      (Zero) The server name is in ASCII format.
uOffset
   Input parameter. Indicates the offset to start the table from. This is used for stores that have over 64K mailboxes in them.

IExchangeManageStore5::GetPublicFolderTableEx

The GetPublicFolderTableEx method obtains information about all of the public folders on a server in a particular store.

HRESULT GetPublicFolderTableEx(
  LPSTR lpszServerName,   
  LPGUID lpguidMdb,    
  LPMAPITABLE FAR * lppTable,  
  ULONG ulFlags,
  UINT uOffset
);

Parameters

lpszServerName
   Input parameter. Points to a string that contains the distinguished name (DN) of the server.
lpguidMdb
   Input parameter. Points to a GUID that contains the value of the objectGUID attribute of the information store.
lppTable
   Output parameter. Points to a MAPI IMAPITable interface containing the information about all of the public folders on the server specified in lpszServerName.
ulFlags
   Input parameter. A defined value that specifies whether the server name is Unicode:
      MAPI_UNICODE
      The server name is in Unicode format.
      0
      (Zero) The server name is in ASCII format.
uOffset
   Input parameter. Indicates the offset to start the table from. This is used for stores that have over 64K public folders in them.

Sweet! Where do I get this new interface from?

It's only available in Exchange 2003's version of EMSMDB32.DLL. You'll need Exchange 2003 Service Pack 2 installed, and the hotfix documented in Knowledge Base article 908072. (As of this posting, this article is not yet available on http://support.microsoft.com. You can still contact MS support and request the hotfix by referencing the article number though)

Once you have the hotfix, you'll need the interface definition and IID. These aren't in the headers yet, so you'll need to add them yourself.

In edkmdb.h, add:

/*------------------------------------------------------------------------
 *
 *	"IExchangeManageStore5" Interface Declaration
 *
 *	Used for store management functions.
 *
 *-----------------------------------------------------------------------*/

#define EXCHANGE_IEXCHANGEMANAGESTORE5_METHODS(IPURE)					\
	MAPIMETHOD(GetMailboxTableEx)			\
		(THIS_	LPSTR		lpszServerName,   \
			LPGUID		lpguidMdb,        \
			LPMAPITABLE FAR *	lppTable,	         \
			ULONG		ulFlags,	         \
			UINT		uOffset) IPURE;	\
	MAPIMETHOD(GetPublicFolderTableEx)			\
		(THIS_	LPSTR		lpszServerName,	\
			LPGUID		lpguidMdb,	\
			LPMAPITABLE FAR *	lppTable,		\
			ULONG		ulFlags,		\
			UINT		uOffset) IPURE;	\

#undef		 INTERFACE
#define		 INTERFACE  IExchangeManageStore5
DECLARE_MAPI_INTERFACE_(IExchangeManageStore5, IUnknown)
{
	MAPI_IUNKNOWN_METHODS(PURE)
	EXCHANGE_IEXCHANGEMANAGESTORE_METHODS(PURE)
	EXCHANGE_IEXCHANGEMANAGESTORE2_METHODS(PURE)
	EXCHANGE_IEXCHANGEMANAGESTORE3_METHODS(PURE)
	EXCHANGE_IEXCHANGEMANAGESTORE4_METHODS(PURE)
	EXCHANGE_IEXCHANGEMANAGESTORE5_METHODS(PURE)
};
#undef	IMPL
#define IMPL

DECLARE_MAPI_INTERFACE_PTR(IExchangeManageStore5, LPEXCHANGEMANAGESTORE5);

In edkguid.h, add:

DEFINE_GUID(IID_IExchangeManageStore5,0x7907dd18, 0xf141, 0x4676, 0xb1, 0x02, 0x37, 0xc9, 0xd9, 0x36, 0x34, 0x30);

Then you should be all set. Enjoy!

(Edit: fixed cut/paste typo in GetPublicFolderTableEx description)

Outlook Account Management API Sample

jasonjoh — Tue, 27 Dec 2005 21:37:00 GMT

Just a quick entry to post this sample. A few folks have had trouble getting the Account Management API to work correctly. This is a simple sample I wrote to enumerate the accounts in a profile that hopefully will help. Download it here.

CreateMHTMLBody Won't Read Web Pages Compressed with GZIP

jasonjoh — Fri, 09 Dec 2005 00:43:00 GMT

The title says it all. If you've got a web page hosted on a site that does GZIP compression, you can't point CDO's CreateMHTMLBody at it. You'll get back one of a few different errors, depending on your IE setup. The ones I've seen are (with IE 6.0 SP1 installed):

"Invalid Syntax" (if you don't have "Automatically Detect Settings" checked in your LAN Settings)
"Interface not registered" (if you do have it checked).

Both of these problems stem from one of CDO's dependencies: URLMON.DLL. CDO uses this component to manage all of the work to actually fetch the web content. We just pass the URL off to URLMON and wait for it to provide us back the HTML. The problem is URLMON handles this through an asynchronous call, so it spins off a worker thread to do the actual work. When this thread gets the content back from the server, it sees that it is GZIP-compressed. It then tries to create a COM object (that URLMON implements) to decompress the content. This is where the fun begins.

URLMON never calls CoInitialize on this worker thread. So of course we run into problems. The two different errors are just different flavors of COM problems. The first error is caused by a failure to create an IClassFactory interface (COM's not initialized, remember?). The second error results from COM having been initialize by the process, but not on that specific thread. Unfortunately this COM object responsible for decompressing GZIP stuff works only on the STA thread.

All is not lost though! CDO developers can get around this. You have a number of options. You could disable compression on your website (assuming that the site you're using is under your control). You could turn off HTTP 1.1 (1.1 allows for compression, 1.0 doesn't) in your IE settings (assuming that your app is running in a user's context). Or, you could fix it the right way ;-)

You can disable HTTP 1.1 for just your process using InternetSetOption. If you do this before making your CreateMHTMLBody call, it will work like a champ.

In case your interested, here's how to do it in VB.NET:

    Private Const INTERNET_OPTION_HTTP_VERSION = 59

    <StructLayout(LayoutKind.Sequential, CharSet:=CharSet.Auto)> _
    Private Class INTERNET_VERSION_INFO
        Public dwMajorVersion As Int32
        Public dwMinorVersion As Int32
    End Class

    <DllImport("wininet.dll")> _
    Private Shared Function InternetSetOption(ByVal hInternet As IntPtr, _
        ByVal dwOption As Integer, _
        ByVal lpBuffer As INTERNET_VERSION_INFO, _
        ByVal dwBufferLength As Integer) As Boolean
    End Function

    Private Sub DisableHTTP1_1()
        Dim verInfo As New INTERNET_VERSION_INFO

        verInfo.dwMajorVersion = 1
        verInfo.dwMinorVersion = 0

        Dim bRet As Boolean
        bRet = InternetSetOption(IntPtr.Zero, INTERNET_OPTION_HTTP_VERSION, _
            verInfo, Marshal.SizeOf(verInfo))

        If bRet = True Then
            MessageBox.Show("HTTP Version set to 1.0", "Success")
        Else
            MessageBox.Show("HTTP Version option not set!", "Error")
        End If
    End Sub

New Sample Transport Provider

jasonjoh — Fri, 04 Nov 2005 22:37:00 GMT

I've been working with MAPI for over 5 years now. In that 5 years I've supported my share of developers writing their own MAPI providers (message store, transport, address book), but I've never actually sat down and written one myself. Until now ;-)

I decided to do a transport, since we already *kinda* have a message store, and we don't really get a lot of support cases for address book providers.

So, here it is. I based the actual delivery mechanism on the PeerXP sample from way back. Messages are stored as files on disk, and e-mail addresses are UNC share paths.

Development was done with Visual Studio 2003 (unmanaged C++ of course!) and testing was done with Outlook 2003 SP2. I included my development notes with the source, and there's a README on basic installation and usage.

Feedback is welcome!

Subject Sorting in Outlook

jasonjoh — Wed, 07 Sep 2005 21:19:00 GMT

I just recently worked through an issue where messages in a custom message store would not sort on the Subject field. Other text properties sorted fine, just not Subject.

The problem was because Outlook doesn't sort the Subject field on PR_SUBJECT. It actually uses PR_NORMALIZED_SUBJECT, which should filter out any prefixes from the subject (like RE:, FWD:, etc). So the problem boiled down to the store provider not supplying PR_NORMALIZED_SUBJECT in its contents tables.

It seemed fairly straightforward. However, when I loaded the provider with MFCMapi, I saw that PR_NORMALIZED_SUBJECT wasn't in the table by default, but if I did a SetColumns on the table to add it, it showed up fine. So what gives?

It turns out that Outlook is assuming that the message store provider will support sorting on a property that is not in the current column set on the table. The provider did not add PR_NORMALIZED_SUBJECT to the underlying data in the table when it first created it, but it would add it dynamically to the table if it was explicitly asked for in a SetColumns. So if Outlook had include PR_NORMALIZED_SUBJECT in its call to SetColumns, this would have worked.

At first I thought this was a problem with Outlook, but after reading MSDN documentation and Inside MAPI, I realized that it isn't. A store can choose not to support sorting on properties that aren't in the current column set (by returning MAPI_E_TOO_COMPLEX) but this store did not. Outlook may have still not retried the sort anyway though.

The solution here was to include PR_NORMALIZED_SUBJECT in the data used to create the table. The provider was using MAPI's implementation of IMAPITable instead of implementing their own, and MAPI's implementation does support sorting on a property that is not in the current column set as long as that property is present in the underlying data.

PR_MAPPING_SIGNATURE and custom message stores

jasonjoh — Wed, 05 Jan 2005 21:02:00 GMT

I was pulled into a neat little issue with a custom message store that didn't behave correctly with appointments in Outlook. It seems that everything was created fine, and Outlook set all of the named properties correctly on appointments. The custom store was supporting named properties correctly and exposing them in their contents tables, so Outlook was happy. Different calendar views worked great.

However, things got weird once you started a new MAPI session. For reasons specific to the custom store, it decided to change it's named property-to-proptag mapping. Of course, this is perfectly legal, no reason they shouldn't be able to do that. The thing is, it totally hosed Outlook's calendar views. All of the sudden, appointments lost their start times, end times, etc!!

We started debugging Outlook, and the weird thing was that Outlook didn't seem to be calling GetIDsFromNames on these subsequent sessions. The first time we logon to a new profile it does (and everything works), but subsequent times we don't. So you see why changing the named property mappings breaks things: if Outlook believes that the named property for the start time is 0x8000, and it's been changed to 0x8001, then things break. Everything would be great if Outlook just called GetIDsFromNames every time (or at least once every new session), but it doesn't. So what gives?

It all comes down to PR_MAPPING_SIGNATURE. Go read the MSDN notes on this property. It doesn't have a section specifically regarding how to implement this property, so you kind of have to extrapolate. The key nugget from this is: When two objects have the same PR_MAPPING_SIGNATURE value, the client does not need to translate name to identifier and identifier to name. Can you guess where this custom store went wrong? Exactly: they were using the same PR_MAPPING_SIGNATURE across sessions, even if they changed their named property mapping!

Outlook stores the value of PR_MAPPING_SIGNATURE for your store in a property in the profile. Once that property is there, every time you open Outlook with that profile, it checks this value and compares to what it gets back from your store. If the values match, then Outlook assumes that the named property mapping it got from the prior session is still valid to use, and skips the GetIDsFromNames call. If the values don't match (or if the property isn't there in the profile) then Outlook discards it's old property mapping data and does a GetIDsFromNames call.

So, if your store provider supports PR_MAPPING_SIGNATURE, you need to make sure that you change its value when you change your named property mappings to ensure that everything works properly.