Outlook 2010 Nickname Cache – An insider Story

Name cache in Outlook is a great feature, we all know. I personally find it extremely very useful since it saves a lot of time while selecting recipients. It has also helped adding few of those recipients who were likely to get missed on an email.

Outlook 2003 and 2007 both used locally stored .NK2 files to hold these name cache. These NK2 files could be found at %APPDATA%\Microsoft\Outlook. It was easy to backup these files or import them back if there were any issues observed. That was pretty simple business there. But a pain of keeping a bakup of these files was always there. In most the cases when user changed their computer these files were most likely to get skipped and they would lose their nickname cache.

When Outlook 2010 was launched it also changed the way the name cache is used by outlook. Instead of using a local NK2 file, outlook 2010 stores the name cache directly in the mail account’s delivery store (in simple words – “Mailbox”).

This post does not provide any troubleshooting information but a little more insight of this changed method of storing nick name cache directly into mailbox. Although it does not outline any troubleshooting steps, the information in this post should be helpful enough if you are troubleshooting a problem related to nickname cache.

The way nickname cache is stored in one of the portions of extremely complex structure in an exchange server 2010 mailbox is in the form of an attribute on a mailbox rule. To understand and to see the way this thing works; you require the very famous geeky tool, MFCMAPI. I must say Stephen Griffin has done an extra ordinary job by developing this utility and keeping it all the way updated over so many year. Thanks Steve 🙂

Let us take a look at how does this thing look like and how to see it.

1. Download MFCMAPI from http://mfcmapi.codeplex.com . Latest the better.

2. If you do not wish to do all configurations for running MFCMAPI without outlook, use it on a computer where outlook is installed. I would prefer outlook 2010 on the computer where I am going to use MFCMAPI.

3. Once you have the utility downloaded, open your mailbox by logging on to the profile you wish to explore.

Logon Screen

4. Select the profile that is already configured on the computer.


5. After you select the profile, you would see your mailbox, archives and public folder store in the window. In my case I do not have any PST files and PF store on my exchange server. Now, right click on your mailbox and select Open Store


6. That brings up another window, which is an invisible view of the mailbox using any known MAPI, NON-MAPI client. Expand Root – Mailbox –> IPM_SUBTREE in this newly opened window and you would see the similar folder structure that you see using outlook. If you are connected to exchange server in online mode the structure would look a very little different and IPM_SUBTREE is replaced with another folder named Top of Information Store.

A few more folders are made visible by MFCMAPI. I strongly recommend you do not play around them unless you really understand why they are there.

7. Select your Inbox folder, right click, and select Open associated contents table from the context menu.

8. Above action brings up another window of MFCMAPI, which shows hidden, visible rules in your mailbox.


You may not see the similar screen as above since I have adjusted the columns as per my convenience. Yet, the key bit here is the rule that stores your nickname cache information. By expanding columns and scrolling horizontally in the rules pane; you should be able to figure out a rule that’s message class is IPM.Configuration.Autocomplete. Yes, that is the one which manages your nickname cache.

Question is, where is the actual information? Why is it not visible in above screen shot if the message class IPM.Configuration.Autocomplete holds all my nickname cache data? Well, do  you see that red mark in the properties pane?

The nickname cache is stored in a property of the rule IPM.Configuration.Autocomplete named PR_ROAMING_BINARYSTREAM. That is correct. It is a binary stream that is stored in your mailbox as a property of the rule mentioned / highlighted above.

I think the data you are interested in is still not visible to you. This is the real trick. The property PR_ROAMING_BINARYSTREAM is the property of type PT_BINARY. Since it holds a binary stream of information it may not be displayed directly when you are on the screen shown above.

9. To see what is inside the scoop; right click on the property 0x7C09000A and select Smart View.


10. In Structure Picker window, select structure to interpret as Nickname Cache

11. A new window that will show up on your screen is the information you perhaps did not know. 🙂


Whoa! What is that information?

Looks weird first time but if you take a closer look at the information that is displayed, it looks like some structured information represented in a plain text format. This binary stream is nothing but a structure that is similar to a database consisting of rows and properties on each row which has further properties again. Lets dive a little deeper into this information

Nickname Cache
Metadata1 = cb: 4 lpb: 0DF0ADBA
Major Version = 12
Minor Version = 0
Row Count = 11

Row Count tells you about how many records are stored in your nickname cache.


Below is a dump of single record that appears in your nickname cache when you start typing a name in outlook To, CC, BCC fields (Names and Email Addresses changed by me)

  • A closer analysis of below dump would make you understand that each row is represented by an unique number starting from 0. Each name that appears after you start typing a recipient’s name is equal to a Row in the below information. If you have 100 names stored, the first row would be Row 0 and the last would be Row 99
  • Each row represents a unique record itself.
  • Each row has few more properties represented by Property[0], Property[1], and so on. These properties have their own properties again. Just like what you see in below dump.
  • Each of these properties represent a specific block of information about the cached nickname by outlook.

For Example:

Property[0] – Property Name
Property = 0x6001001F – Property Identifier
Exact Matches: PR_NICK_NAME_W – Property Name
Partial Matches: PR_NICK_NAME, PR_NICK_NAME_A, PR_DOTSTUFF_STATE – Other properties with similar structure to PR_NICK_NAME_W
PropString = Exchange.Geek@GEEKLABS.COM AltPropString = cb: 40 lpb: – Self Explanatory. This is the string value of the property [0] which is PR_NICK_NAME_W

    Row 0
    cValues = 0x00000017 = 23
    Property = 0x6001001F
    Exact Matches: PR_NICK_NAME_W
    PropString = Exchange.Geek@GEEKLABS.COM AltPropString = cb: 40 lpb: 4F004D002E004900540046004D005300400067006D007200670072006F00750070002E0069006E00
    Property = 0x39FE001F
    Exact Matches: PR_SMTP_ADDRESS_W, PidTagSmtpAddress
    Partial Matches: PR_SMTP_ADDRESS, PR_SMTP_ADDRESS_A, ptagPrimarySMTPAddress
    PropString = Exchange.Geek@GEEKLABS.COM AltPropString = cb: 40 lpb: 4F004D002E004900540046004D005300400067006D007200670072006F00750070002E0069006E00
    Property = 0x3A00000A
    Partial Matches: PR_ACCOUNT, PR_ACCOUNT_A, PR_ACCOUNT_W, PidTagAccount
    PropString = Err:0x8004010F=MAPI_E_NOT_FOUND AltPropString =
    Property = 0x0C150003
    Exact Matches: PR_RECIPIENT_TYPE, PidTagRecipientType, ptagRecipientType
    PropString = 2 AltPropString = 0x2
    Smart View: Flags: MAPI_CC
    Property = 0x3001001F
    Exact Matches: PR_DISPLAY_NAME_W, PidTagDisplayName
    Partial Matches: PR_DISPLAY_NAME, PR_DISPLAY_NAME_A, ptagDisplayName
    PropString = Exchange Geek AltPropString = cb: 54 lpb: 530075006E0069006C0020004F007000650072006100740069006F006E0020004D0061006E006100670065007200200042004C005200
    Property = 0x3002001F
    Exact Matches: PR_ADDRTYPE_W, PidTagAddressType
    Partial Matches: PR_ADDRTYPE, PR_ADDRTYPE_A, ptagAddrType
    PropString = EX AltPropString = cb: 4 lpb: 45005800
    Property = 0x0FFF0102
    Exact Matches: PR_ENTRYID, PR_MEMBER_ENTRYID, PidTagEntryId, PidTagMemberEntryId, ptagEntryId
    PropString = cb: 116 lpb: 00000000DCA740C8C042101AB4B908002B2FE18201000000000000002F6F3D474D5247726F75702F6F753D45786368616E67652041646D696E6973747261746976652047726F7570202846594449424F484632335350444C54292F636E3D526563697069656E74732F636E3D434E4C5432363300 AltPropString = ….ܧ@ÈÀB..´¹..+/á?……../o=GEEKLABS/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=ExchangeGeek.
    Smart View: Exchange Address Entry ID:
    abFlags = 0x00000000
    Provider GUID = {C840A7DC-42C0-1A10-B4B9-08002B2FE182} = muidEMSAB
    Version = 0x00000001 = EMS_VERSION
    Type = 0x00000000 = DT_MAILUSER
    X500DN = /o=GEEKLABS/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=ExchangeGeek
    Property = 0x3003001F
    Exact Matches: PR_EMAIL_ADDRESS_W, PidTagEmailAddress
    PropString = /O=GEEKLABS/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=ExchangeGeek AltPropString = cb: 174 lpb: 2F004F003D0047004D005200470052004F00550050002F004F0055003D00450058004300480041004E00470045002000410044004D0049004E004900530054005200410054004900560045002000470052004F005500500020002800460059004400490042004F0048004600320033005300500044004C00540029002F0043004E003D0052004500430049005000490045004E00540053002F0043004E003D0043004E004C005400320036003300
    Property = 0x300B0102
    Exact Matches: PR_SEARCH_KEY, PidTagSearchKey, ptagSearchKey
    PropString = cb: 91 lpb: 45583A2F4F3D474D5247524F55502F4F553D45584348414E47452041444D494E4953545241544956452047524F5550202846594449424F484632335350444C54292F434E3D524543495049454E54532F434E3D434E4C5432363300 AltPropString = EX:/O=GEEKLABS/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=ExchangeGeek.
    Property = 0x3D010102
    Exact Matches: PR_AB_PROVIDERS, PidTagAbProviders
    PropString = cb: 16 lpb: 64089B1A0053EC4995777ED6B1F7232A AltPropString = d.?..SìI?w~Ö±÷#*
    Property = 0x5FFF0003
    Exact Matches: PR_RECIPIENT_TRACKSTATUS, PidTagRecipientTrackStatus, ptagRecipientTrackStatus
    PropString = 0 AltPropString = 0x0
    Smart View: Flags: respNone
    Property = 0x5FDE0003
    Exact Matches: PR_RECIPIENT_RESOURCESTATE, PidTagRecipientResourceState
    PropString = 0 AltPropString = 0x0
    Property = 0x5FFD0003
    Exact Matches: PR_RECIPIENT_FLAGS, PidTagRecipientFlags
    PropString = 1 AltPropString = 0x1
    Smart View: Flags: RECIP_SENDABLE
    Property = 0x5FF6001F
    Exact Matches: PR_RECIPIENT_DISPLAY_NAME_W, PidTagRecipientDisplayName
    PropString = Exchange Geek AltPropString = cb: 54 lpb: 530075006E0069006C0020004F007000650072006100740069006F006E0020004D0061006E006100670065007200200042004C005200
    Property = 0x5FF70102
    Exact Matches: PR_RECIPIENT_ENTRYID, PidTagRecipientEntryId, ptagRecipientEntryId
    PropString = cb: 116 lpb: 00000000DCA740C8C042101AB4B908002B2FE18201000000000000002F4F3D474D5247524F55502F4F553D45584348414E47452041444D494E4953545241544956452047524F5550202846594449424F484632335350444C54292F434E3D524543495049454E54532F434E3D434E4C5432363300 AltPropString = ….ܧ@ÈÀB..´¹..+/á?……../O=GEEKLABS/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=ExchangeGeek.
    Smart View: Exchange Address Entry ID:
    abFlags = 0x00000000
    Provider GUID = {C840A7DC-42C0-1A10-B4B9-08002B2FE182} = muidEMSAB
    Version = 0x00000001 = EMS_VERSION
    Type = 0x00000000 = DT_MAILUSER
    Property = 0x5FF20003
    PropString = 0 AltPropString = 0x0
    Property = 0x5FEF0003
    PropString = 0 AltPropString = 0x0
    Property = 0x5FF50003
    PropString = 0 AltPropString = 0x0
    Property = 0x5FEB0003
    PropString = 0 AltPropString = 0x0
    Property = 0x5FDF0003
    Exact Matches: PR_RECIPIENT_ORDER, PidTagRecipientOrder, ptagRecipientOrder
    PropString = 8 AltPropString = 0x8
    Property = 0x6002000B
    PropString = False AltPropString =
    Property = 0x6003001F
    PropString = Exchange Geek <Exchange.Geek@GEEKLABS.COM> AltPropString = cb: 100 lpb: 530075006E0069006C0020004F007000650072006100740069006F006E0020004D0061006E006100670065007200200042004C00520020003C004F004D002E004900540046004D005300400067006D007200670072006F00750070002E0069006E003E00
    Property = 0x60040003
    Exact Matches: PR_NICK_NAME_WEIGHT
    PropString = 16384 AltPropString = 0x4000

    Again, another question would start bothering you. Do I mean that outlook queries exchange server over MAPI all the times when someone start typing a name in To, CC or BCC fields?

    Answer is No!

    Unless your outlook profile is not configured in Online mode; outlook would not really go and ask for the information to the exchange server. Instead, it maintains a local replica of the nickname cache which is stored on the client computer at location %USERPROFILE%\AppData\Local\Microsoft\Outlook\RoamCache in one or more .dat files.

    This behavior makes it faster to access the information instead of making a MAPI call to the store every time someone types a name. This locally stored information stays in read only format though. Outlook can read from these files but cannot write back into them. Even if you manage to write something back to these files the updated information would not get written back in your mailbox on the server.

    Another aspect of the way nickname cache information is displayed in Exchange 2010 Outlook Web App. Since OWA works as a persistent session to CAS server / CAS Array from the client computer this information should ideally be streamed online every time someone tries to type a name in To, CC or BCC fields. But, interestingly, the way this information is handled by OWA is little different that you can imagine. Exchange 2010 OWA (premium mode only) also caches this binary stream stored in the prop PR_ROAMING_BINARYSTREAM locally to the client computer. That is why you may still see name cache available in OWA new message window, even after losing network connection to the server.




    Well, that is all about it. I will keep few more things posted as and when get time. For now, enjoy this post and let me know if you find any documentation bugs :-). Feel free to leave your feedback in case you like / disliked this post.


    9 thoughts on “Outlook 2010 Nickname Cache – An insider Story”

    1. Fantastic. Thanks. Still need some info to get the full picture.

      If I copy a Stream_Autocomplete*.dat file from another user or another (older pc with Outlook2010) into the RoamCache folder and rename the file properly, then it actually works as autocomplete in Outlook.

      But the content will newer get into the users Exchange Mailbox – is that correct?

      And another question: Will new typed email adresses be filled in /appended to the Stream_Autocomplete file or only placed in the Exchange Mailbox nickname cache?

      1. Thanks Tommy. The post does talks about your question. Stream_Autocomplete*.dat files are read only and the data from them is not written back to mailbox. To answer your second question, they are only placed in Mailbox.

    2. Great stuff and really informative, keep up posting more articles so that I am in synch with these indepth stuff for 2010

    Comments are closed.