For lack of a better word

Outlook sends 3DES when I've chosen AES 256

Dave V - MSFT — Mon, 29 Oct 2018 09:18:24 GMT

We see this as common question in Microsoft Support so I wanted to lay out the approach Outlook for Windows takes to determine what encryption algorithm is chosen when sending encrypted email to a recipient. First, know that when choosing algorithms Outlook determines what both the sender and recipient supports. Although it will refer to the sender preference, it will not always send using that preference. It does this to ensure that the recipient can actually read the encrypted message. Here is the process Outlook takes to choose an algorithm:

It looks at the recipient's certificate and checks to see if it comes from a particular provider. If it knows which provider generated the certificate, or can query the provider itself, then it can determine what algorithms the provider supports.
It looks at the recipient's certificate and checks for the presence of the SMIME Capabilities attribute. If present, it will examine this attribute and look at the algorithms that the certificate supports.
If neither of these options are viable, it will default to a base default algorithm. This will be 3DES if you're using Outlook 2007, 2010, 2013, 2016 MSI or a version of Office 2016 (C2R) less than 16.8518.1000. It'll be AES 256 if you're using a version greater than 16.8518.1000 (C2R).

Once it determines what algorithms the recipient can support, it finds the intersection of the recipient and the sender and chooses the best algorithm from there. This is where the sender's preference may be overridden. Therefore, if you're seeing a chosen algorithm different than what you expect, you can use the steps above to determine how the algorithm was chosen. The recommended approach for fixing this is for the recipient to change the certificate to include the SMIME Capabilities attribute. This way the recipient can advertise to Outlook what algorithms the sender should use to send encrypted message to the recipient. Note: Group Policy can also impact this decision, but that's not discussed in this article.

Time Travel Debugging now in preview

Dave V - MSFT — Tue, 24 Oct 2017 08:28:33 GMT

I know I'm a little late to the party, but I just came across this and I'm very excited about its release. I've been using TTD for over 10 years internally and it is an awesome tool to capture issues that just won't reproduce themselves easily. From a support perspective it's been amazing. https://blogs.msdn.microsoft.com/windbg/2017/09/25/time-travel-debugging-in-windbg-preview/

How to create an profile that uses MAPI/HTTP in Outlook 2013

Dave V - MSFT — Mon, 19 Jun 2017 15:36:32 GMT

I had a case recently where the customer wanted to know how to programmatically create a MAPI over HTTP profile using Outlook 2013. A few years ago I had developed a little sample to do just that, but I never posted it. Therefore, today I'm fixing my omission. You can view the sample code here.

Access to the Recovery Database in Exchange Server 2016 from an application

Dave V - MSFT — Mon, 20 Mar 2017 09:22:44 GMT

I have had several customers interested in how to access the Recovery Database (RDB) programmatically in Exchange 2016. Extended MAPI is the only way to access the Recovery Database programatically. The Exchange MAPI subsystem (aka MAPI\CDO) is the only subsystem capable of accessing the Recovery Database. This is because access to the Recovery database requires the use of the flag OPENSTORE_RECOVERY_DATABASE (0x100000). This flag is not available in the Outlook MAPI subsystem. If you try to use it from Outlook's MAPI, the call to IMAPISession::OpenMsgStore() will fail with MAPI_E_UNKNOWN_FLAGS (0x80040106). Therefore, you are forced to use the Exchange MAPI subsystem. As you know, Exchange Server 2016 has an explicit block in place that prevents from clients using the Exchange MAPI subsystem. A programmatic alternative to MAPI to access the RDB is through the use of Exchange Powershell's New-MailboxRestoreRequest cmdlet. You could then restore the data to a temporary mailbox in a normal mailbox database. Once there, you could use Exchange Web Services or the Outlook Mail REST APIs to access that data. The user of your application never has to know about this temporary mailbox. It could only be accessible by your application. Your application could then find whatever it is that it's looking for and then only restore that particular data to the end user's mailbox. Previous versions of Exchange Server support both EWS and this cmdlet so this architecture could work going back to Exchange 2010. That's probably the furthest you'll want to go back anyhow.

How to indicate that a profile targets a consumer account

Dave V - MSFT — Thu, 16 Mar 2017 08:47:42 GMT

I had a case recently where the customer was using my post for creating a Outlook 2016 profile programmatically and found that the program would hang when performing certain MAPI operations. This only happened when the profile was created programmatically (i.e. not through the Outlook UI or the Mail applet) and the target account was an Outlook.com account. As you may be aware, Outlook.com addresses are being migrated to Exchange as the backend and Extended MAPI can be used to consume them. The root cause of the issue was that Outlook uses the PR_PROFILE_EXCHANGE_CONSUMER_ACCOUNT property to determine if the target account is a "consumer account". If so, certain MAPI operations are avoided. For example, creation of a Global Address Book (GAL). Thus, if you are programmatically creating a MAPI profile that targets an Outlook.com address you need to pre-populate this property yourself. This begs the question, "How do you know if the account is a consumer account?" There are several ways that you can tell: First, you could look at the domain, if it's Outlook.com or Hotmail.com, then chances are high that it's a consumer account. If you want to be 100% sure, you could perform an Autodiscover on the target address and let Exchange tell you. In the Autodiscover response you'll consult the element 'ConsumerMailbox' in the Accounts section of the response. True means that it is, otherwise False. Once you have that data, you'll need to set the PR_PROFILE_EXCHANGE_CONSUMER_ACCOUNT property to what the Autodiscover response was. If the target account is not a consumer account you can omit it completely. You'll need to set this property on the profile section identified as the "EMSMDB Section". You can query for the property PR_PROFILE_EMSMDB_SECTIONID and that'll give you the MAPIUID of this profile section. You must do this before you follow the instructions in my post. Lastly, the profile must be a cached mode profile. This property goes hand in hand with cached mode profiles. Setting this property without indicating that the profile is a cached mode profile will result in undefined behavior. Additional Information You'll need to define the property in your application to use it. This property is not included in any of the MAPI headers. I've included that below: #define PR_PROFILE_EXCHANGE_CONSUMER_ACCOUNT PROP_TAG(0x00B, 0x665e) At the time of this writing, in order to get the property from Autodiscover, the Exchange Server must think that an Outlook for Windows client is asking for it. Therefore, you must set the User-Agent of the program making the HTTP request to the value that an Outlook for Windows client would use. I'll edit this post when this is addressed.

Programmatically connecting to another mailbox when MAPI / HTTP is used

Dave V - MSFT — Tue, 13 Dec 2016 10:25:18 GMT

I've been meaning to create this post for a while, but haven't got around to it. I had a case recently where a customer wanted to connect to a user's Archive mailbox for which the service application had permissions. However, the transport in use was MAPI over HTTP (MAPI/HTTP). He was getting the error MAPI_E_CALL_FAILED (0x80004005) from the call to IMAPISession::OpenMsgStore(). His code worked when the transport was RPC over HTTP (ROH). Introduction When a MAPI client application attempts to connect to multiple mailboxes using a “hub and spoke” type approach, wherein the MAPI application connects to an initial mailbox and then connects to additional mailboxes for some sort of processing, if the transport in use is MAPI/HTTP, IMAPISession::OpenMsgStore() returns MAPI_E_CALL_FAILED (0x80004005). This may be because the EntryID passed to OpenMsgStore() is not valid. The EntryID needed to connect using MAPI/HTTP is a version 3 (v3) EntryID. IExchangeManageStore::CreateStoreEntryID() can only create version 1 (v1) EntryIDs. After all, this method was created for the early versions of Exchange Server. Therefore, a new interface is needed in order to create v3 EntryIDs. Enter IExchangeManageStoreEx. This interface was previously documented in a former blog post. However, the method CreateStoreEntryID2() takes additional data. First, you will need to define the new property PR_PROFILE_USER_SMTP_ADDRESS_W in your code base.

// 0x6641001F
#define PR_PROFILE_USER_SMTP_ADDRESS_W PROP_TAG(PT_UNICODE, 0x6641)

Next, you add that to the list of properties passed to the method CreateStoreEntryID2(). This property is what is used by Outlook to perform an Autodiscover to get the mailbox settings for the target mailbox.

LPSPropValue         lpspv = nullptr;
MAPIAllocateBuffer((sizeof(SPropValue) * 4), (LPVOID*)&lpspv);
ZeroMemory(lpspv, sizeof(SPropValue) * 4);

lpspv[0].ulPropTag = PR_PROFILE_MAILBOX;
lpspv[0].Value.lpszA = TargetMailboxDN;

lpspv[1].ulPropTag = PR_PROFILE_MDB_DN;
lpspv[1].Value.lpszA = TargetStoreDN;

lpspv[2].ulPropTag = PR_FORCE_USE_ENTRYID_SERVER;
lpspv[2].Value.b = true;

lpspv[3].ulPropTag = PR_PROFILE_USER_SMTP_ADDRESS_W;
lpspv[3].Value.lpszW = L"Susan@Contoso.com";

hres = m_pMsgPrivStore->QueryInterface(IID_IExchangeManageStoreEx,
                                                                     (LPVOID*)&pManageStoreEx);
if (FAILED(hRes) || pManageStoreEx == nullptr)
{
    // Handle the error
    goto Cleanup;
}

hRes = pManageStoreEx->CreateStoreEntryID2(4, 
                        lpspv, 
                        ulCreateStoreEIDFlags, 
                        &cbEID,
                        &lpEntryId);
Cleanup:
MAPIFreeBuffer(lpsv);

From there you call IMAPISession::OpenMsgStore() as you did before passing the v3 EntryID you obtained from the call to IExchangeManageStoreEx::CreateStoreEntryID2(). More Information

This was added to Outlook 2016 in a product update.
This was added to Outlook 2013 in a product update. For Outlook 2013, you must also enable the registry value "AllowAutoDiscoverForNonOutlook" documented here.
I didn't test for Outlook 2010. I'll use this as an exercise for the reader. However, if it's not there it won't be added since Outlook 2010 is no longer in main stream support.
MFCMAPI now supports supplying a SMTP address to create a v3 EntryID. I submitted this as a PR to MFCMAPI.

MAPILogonEx() may appear to hang in Outlook 2016

Dave V - MSFT — Mon, 19 Sep 2016 19:49:13 GMT

I had a case recently where the customer was had written a service application using Extended MAPI. The customer found that in his test environment the call to MAPILogonEx() was hanging and not returning. After debugging it, we realized that the hang was caused by an unseen SSL security prompt. The target Exchange server hosting Autodiscover was using a self-signed certificate. Because the transport being used was RPC over HTTP (ROH) and the certificate was untrusted by the client, Outlook was prompting the "user" to accept the use of the certificate. Since this was a service application and there was no one to accept the prompt, MAPILogonEx() would hang. Ultimately, this is a by-design issue with ROH. ROH doesn't allow you to "trust" certain types of security prompts, although you really wouldn't want to anyhow. Since Outlook can't proceed without someone trusting the certificate, it needs to prompt. To workaround this, the developer has two options:

Use only trusted certificates for your Exchange Server. Even in the scenario of a self-signed certificate, you can manually trust the certificate or possibly create a GPO for all machines in the organization to trust it.
Use the registry value outlined in this article: Outlook 2016 displays a prompt that lets you connect to an Exchange server if a certificate issue occurs https://support.microsoft.com/en-us/kb/3114926

If you use the latter, understand that the request will fail and that should cause MAPILogonEx() to fail. However, the failure not may be immediately obvious. You may not see the result of the failure until a subsequent call to MAPI (e.g. IMAPISession::OpenMsgStore()).

MAPILogonEx causes crash if Version Info is not specified on the module

Dave V - MSFT — Mon, 25 Jul 2016 14:48:50 GMT

I wanted to create a simple Extended MAPI application that would call MAPIInitialize() followed by MAPILogonEx(). Seems simple right? I do it all the time. However, this time, for whatever reason, every time I called MAPILogonEx() my process crashed. No matter what flags I chose, or how I called either MAPIInitialize() or MAPILogonEx(), it would crash. I was perplexed. I've written ton of MAPI code and never got an error like this. After debugging it I realized that Office¹ requires that the application include file version information. If the path to the application is too long or the application doesn't have file version information, Office¹ will force a crash of the application. I believe it does this for the Help. Here are some ways you can recognize this problem. First, you'll see a stack similar to this in Visual Studio:

kb
 Index  Function
--------------------------------------------------------------------------------
 1      Mso98win32client.dll!6d08313b()
 2      [Frames below may be incorrect and/or missing, no symbols loaded for Mso98win32client.dll]
 3      Mso98win32client.dll!6d07c374()
 4      vcruntime140.dll!7400d627()
 5      vcruntime140.dll!7400e882()
 6      vcruntime140.dll!740036e8()
 7      vcruntime140.dll!74003654()
 8      vcruntime140.dll!74003215()
 9      vcruntime140.dll!74002f88()
 10     vcruntime140.dll!7400ec26()
 11     ntdll.dll!77d3b652()
 12     ntdll.dll!77d3b624()
 13     ntdll.dll!77d1420b()
 14     ntdll.dll!77d28e7f()
 15     KernelBase.dll!766802c5()
 16     KernelBase.dll!76695468()
 17     vcruntime140.dll!740049a5()
 18     Mso98win32client.dll!6d07c4fe()
 19     Mso98win32client.dll!6d02b65a()
 20     OLMAPI32.DLL!6f53a7b0()
 21     Mso20win32client.dll!6f2eee84()
 22     Mso20win32client.dll!6f2eec62()
 23     Mso20win32client.dll!6f2ece9c()
 24     Mso20win32client.dll!6f2f40f5()
 25     OLMAPI32.DLL!6f5393db()
 26     OLMAPI32.DLL!6f5393bd()
 27     OLMAPI32.DLL!6f54e8bb()
 28     OLMAPI32.DLL!6f54dd36()
 29     OLMAPI32.DLL!6f54cb9b()
 30     OLMAPI32.DLL!6f5446a5()
 31     OLMAPI32.DLL!6f543eff()
 32     MSMAPI32.DLL!51974e3d()
*33     YourAppHere.exe!MAPILogonEx(unsigned long a=0x00000000, wchar_t * b=0x00000000, wchar_t * c=0x00000000, unsigned long d=0x0000003b, IMAPISession * * e=0x0286f870)
 34     YourAppHere.exe!WorkerThread(void * state=0x008ff74c)
 35     msvcr120d.dll!5a2c3651()
 36     msvcr120d.dll!5a2c3861()
 37     kernel32.dll!772338f4()
 38     ntdll.dll!77d15de3()
 39     ntdll.dll!77d15dae()

and an error message that says Unhandled exception at 0x6D08313B (Mso98win32client.dll) in YourAppHere.exe: 0x0128300C (parameters: 0x00000001, 0x00000000). Now, fixing this is easy if you know what to do. In Visual Studio, just add the resource type "Version" and fill in the various fields for your application. Next, Clean the solution, and Rebuild. I find that if I don't Clean and Rebuild, it doesn't fix the issue. That's it. After that it should work. This was a big blocker for me, but I suppose that for people building real world applications this won't be a problem since they'll have this included in their applications anyway. Only little test applications would be affected. ¹ I use this term rather than Outlook because this isn't Outlook's doing. This is "shared Office code" that causes this, not Outlook.

IMAPISession::OpenMsgStore() returns MAPI_E_VERSION (0x80040110)

Dave V - MSFT — Mon, 14 Dec 2015 11:17:00 GMT

As documented previously, Exchange 2016 will not allow connections from Exchange's MAPI (aka MAPI \ CDO). MAPI client applications may receive the error MAPI_E_VERSION (0x80040110). If you are running On-Premises Exchange 2016 and have access to the RPC Client Access logs, you will see this error in the log around the time that the connection was attempted:

RpcDispatch: [RpcServerException] Client version 6.0.XXXX.0 is below the minimum required version 10.0.0.0. (StoreError=Version)

The recommended approach is to use Exchange Web Services or the REST APIs to access the Exchange mailbox. As a temporary workaround you could try porting the MAPI client application to Outlook's MAPI, but Outlook's MAPI can't log into Recovery Databases and have other nuances that may make this not viable.

How to configure an Outlook 2016 profile using MFCMAPI

Dave V - MSFT — Wed, 28 Oct 2015 22:00:00 GMT

The process for creating a Outlook profile in Outlook 2016 has changed. This article documents the simple steps to create one using MFCMAPI. Note: For non-developers this is not the recommended way of creating profiles in Outlook 2016. It is recommended that you use Outlook to create the profile as the logic for this is all built-in. However, you can use these steps for troubleshooting purposes.

Open up MFCMAPI, go to Profile > Show Profiles
Click Actions > Create Profile

Give the new profile a name and click OK.

Select the new profile

Type MSEMS for the service name
Uncheck the box which says "Display Service UI"

Click OK
Double-Click the newly created profile.
Single-Click the MSEMS service.
Find the Exchange Profile section. This is a little difficult in Outlook’s MAPI since in 2010 and above we no longer have the global profile section. To find the Exchange Profile Section find the property PR_EMSMDB_SECTION_UID (0x3D150102) in the properties for the service. The value will be the GUID of the profile section persisted in binary form which will be used in the subsequent steps. You will need to remember this value.
Double-Click the MSEMS service.
Find the Exchange profile section by using the UID gathered from Step 10 and single-click it to select the row.
Go to Property > Additional Properties

Click Add and add the following properties PR_PROFILE_USER_SMTP_EMAIL_ADDRESS_W (0x6641001F) and PR_DISPLAY_NAME_W.

Click OK
Configure each property using the guidance below.

Property: PR_PROFILE_USER_SMTP_EMAIL_ADDRESS_W

Value: SMTP Address of the user

Property: PR_DISPLAY_NAME_W

Value: The display name of the user

Find the property PR_STORE_PROVIDERS in the Exchange profile section. This is the EMSMDB profile section. Note the value of it.

Find the corresponding profile section whose UID matches the value of PR_STORE_PROVIDERS.
Repeat Steps 13 - 17 for that profile section too.

Select Session > Logon and display store, and select the profile if it is not already selected.
You may be prompted for credentials, but it should work successfully.

More Information The display name on the Exchange profile section is not required, but I included it here for simplicity. In Step 14, it is okay if the property name is not resolved to PR_PROFILE_USER_SMTP_EMAIL_ADDRESS_W. Sample code can be found here that shows you how to do this programmatically. If you're creating a profile for an Outlook.com or Hotmail.com address please consult this blog post as well.