June 16, 2014 - Nick
Outlook 2010 NK2 / Autocomplete cache troubleshooting
Another interesting day here at the office. We encountered an issue where a user’s autocomplete cache, also known as the nickname cache, was completely wiped without any known reason. Apparently there isn’t too much documentation out there on the subject (maybe my googlefu isn’t working well today), most of it refers to older versions of Outlook and Exchange prior to 2010 and dealing with NK2 files which is no longer the case. Outlook 2010 changes the location of the autocomplete cache; the NK2 file we’ve previously known but it’s now a file stored both on the Exchange mailbox (or .pst file) and on the local machine in the %USERPROFILE%\AppData\Local\Microsoft\Outlook\RoamCache
- Filename change: In the previous versions of Outlook, the AutoComplete filename was created with .nk2 extension. On Outlook 2010, the filename is created with .dat extension and in the following format: Stream_Autocomplete_0_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.dat The xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx section is a random 16-bytes hash.
- On a new Outlook installation or new Outlook profile, the Stream_Autocomplete file is created only after the user sends the first email message. Be aware that NK2Edit cannot edit the Autocomplete data until the Stream_Autocomplete file is created in the first time.
- In addition to the AutoComplete file stored in the local hard drive, another copy of the AutoComplete data is stored inside the message store of Outlook. For MS-Exchange profile, this copy of the AutoComplete data is stored on the Exchange server. For profile based on .pst file, this copy of the AutoComplete data is stored inside the .pst file.
- If you delete the local AutoComplete file (with .dat extension) or if the user connects the Exchange server from another computer, the AutoComplete data stored in the Exchange server is automatically copied to the local computer.
- The steam_autocomplete .dat file is only a cache and is not used to write back to the delivery store when the user exits Outlook 2010 or Outlook 2013.
An approach that I’ve had success in re-populating the nickname cache for a user with in the past is with the following steps. One preface to this method is that we use something called AppSense environment which keeps a history of the user’s personalizations – so we usually will have a a couple revisions of the stream_autocomplete file. Also – one other point to note is that when a user’s autocomplete is overwritten (even if we don’t have AppSense in the picture) a version of the file usually exists in the ‘RoamCache’ file that you can use for the re-import.
- Close down all the user’s instances of Outlook, everywhere. Also, make sure if you have Citrix or Outlook as a published application, the user is logged off the session.
- From a workstation logged in as the user experiencing the issue, locate and backup a copy of the user’s stream_autocomplete_o_xx.dat file. If the file has an viable content, it will probably a decent amount of data in it. This file will be what we use for the import again:
- Again from the same workstation logged in as the affected user, run the following command: Outlook.Exe /cleanautocompletecache – This command will delete the AutoComplete cache completely from both local and message stores hopefully removing/decreasing the potential for this issue to re-occur.
- Download an application called NK2Edit and launch on the user’s workstation. If you launch in the context of the user you’re logged in as, it will automatically open the users existing autocomplete file. It will be probably be empty in our scenario because of running the switch /cleanautocompletecache. In our case, we’ll use our backed up version of the .dat file by going to File -> Open .NK2 file and browsing to the location. Be sure to choose ‘Outlook 2010 AutoComplete .dat file’ as highlighted below:
- Once we have this loaded and the entries look good, we can now goto File -> Export to Message Store (Outlook 2010) and import the new file back into the user’s mail profile:
Granted there are no extraordinary issues, this should solve our problem. I haven’t see the issue reoccur again on a user that I’ve performed these steps on.
If anyone has anything to add – please do so in the comments below! Thanks for reading and hope this helps anyone out there!