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?
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:
To examine MAPI properties, we used MFCMAPI tool.
Our testing environment was as follows:
Outlook / MAPI profiles are configured using the Mail applet in system control panel, which gets installed with Outlook.
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.
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.
PR_ROAMING_BINARYASTREAM property of type PT_BINARY in the message appears to hold AutoComplete raw data.
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.
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.
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.
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.
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.