Microsoft Outlook AutoComplete Research

Project Description

The task was to investigate the behaviour of AutoComplete function in Microsoft Outlook software, specifically what happens during creation of a new profile, or copying an existing Outlook profile.

AutoComplete (or Auto-Complete) is a feature that suggests emails and names when you type them in To, Cc, and Bcc fields when composing a new message in Outlook.

We needed to know the location of auto-complete files and properties related to this feature, and investigate options of making a new Outlook profile to use auto-complete settings from an already existing profile.

We needed to know the location of auto-complete files and properties related to this feature, and investigate options of making a new Outlook profile to use auto-complete settings from an already existing profile. For example, when a new MAPI / Outlook profile is created, how exactly do we make it reuse auto-complete from the existing profile, so that the behaviour of the feature is exactly the same?

Completion Notes

A very useful reference regarding AutoComplete in Microsoft Outlook is this Slipstick article. It looks like AutoComplete-related things are very much Outlook version-specific. The article mentions:

MAPI Tools

To examine MAPI properties, we used MFCMAPI tool.

Outlook Testing Environment

Our testing environment was as follows:

IMAP and SMTP mail server ports in Outlook profile
IMAP and SMTP mail server ports

Configuring Outlook Profiles

Outlook / MAPI profiles are configured using the Mail applet in system control panel, which gets installed with Outlook.

Windows Control Panel with Mail applet
Windows Control Panel with Mail applet

Location of AutoComplete Data

Experiments showed that the AutoComplete data is stored not in one location, but at least in two:

Both sets of data do not exist initially. They appear at different time points.

Let's examine the process in more detail.

New Outlook Profile

Let's create a new profile with the Mail applet without starting Outlook and see the MAPI properties of the associated store. Specifically, we are trying to determine whether IPM.Configuration.Autocomplete hidden message exists. No, not at this time. MFCMAPI tool shows us that the Associated Contents Table for the Inbox folder is empty.

Starting and closing Outlook will create a few hidden messages in there, but not IPM.Configuration.Autocomplete.

Now let's send our first message without closing Outlook. After we send the message, the AutoComplete feature starts working, meaning that it suggests this one email when we try to send another message. But there is still no IPM.Configuration.Autocomplete message. Closing Outlook does create it, and we can examine its properties.

Microsoft Outlook IPM.Configuration.Autocomplete hidden message properties
IPM.Configuration.Autocomplete hidden message properties

PR_ROAMING_BINARYASTREAM property of type PT_BINARY in the message appears to hold AutoComplete raw data.

PR_ROAMING_BINARYASTREAM property in IPM.Configuration.Autocomplete hidden message in Outlook
PR_ROAMING_BINARYASTREAM property in IPM.Configuration.Autocomplete hidden message

Note that at this time (Outlook application closed), the data exists in .ost but there is no cache file.

Opening Outlook again and doing nothing now does create a new file Stream_Autocomplete_0_[GUID].dat with data for our sender.

The file name contains a GUID, where does it come from? If we look at the system registry under HKCU\Software\Microsoft\Office\15.0\Outlook\Perf\RoamingStreamsCache - we will find the GUIDs as sub-keys there.

Microsoft Outlook roaming streams cache registry keys
Outlook roaming streams cache registry keys

The key with our GUID contains MsgEID value of REG_BINARY type, which matches PR_ENTRYID MAPI property of the IPM.Configuration.Autocomplete hidden message.

Location of AutoComplete Cache Files

Outlook 2013 stores reaming streams cache files in %localappdata%\Microsoft\Outlook\RoamCache

We can type it into Windows Explorer either as is, or a fully resolved path, which apparently depends on drive and user name.

Notice that deleting the IPM.Configuration.Autocomplete hidden message with MFCMAPI tool (when it works and does not crash when doing so) and redoing things with Outlook gets as a filename with a different GUID. A screenshot below shows 3 files with a different GUID, all used with 1 Outlook profile, after manual delete of the hidden message, restarting Outlook, resending a test message, and restarting Outlook again.

Microsoft Outlook AutoComplete cache files
Outlook AutoComplete cache files

Retaining Outlook AutoComplete Data

What are our options if we wanted to retain existing user AutoComplete data in another new profile?

Upon creating a new profile, AutoComplete feature has nothing to suggest, and there is no cache file.

After a user sends their first message and restarts Outlooks, then the IPM.Configuration.Autocomplete message appears in the associated contents table for Inbox in the message store. Restarting Oulook again generates a new corresponding cache file.

At this point we can:

What if we wanted to do everything programmatically without restarting Outlook 2 times? In theory, we can try to copy the hidden message from the old profile to new. This has not been tested, though, but seems like a good approach. If copying cannot work, we may also try creating a new hidden message there (with Outlook closed), and then setting its PR_ROAMING_BINARYASTREAM property to match the old profile.

Copied Outlook Profile

This appears to work a bit better, but has an unexpected side effect, which manifests itself like so:

It happens because a profile copy reuses the same .ost file, therefore, the entry id for the hidden message is the same, and many things are, therefore, shared.

Summary