We’ve done a fair few migrations now, with several colleges and units within the university deciding to retire their in-house email system and join Nexus. And as user accounts were migrated in from some of these other systems we had the occasional issue reported with Outlook’s ‘autocomplete’ function.
Outlook’s autocomplete data is stored in a ‘nickname file’ (with an NK2 file extension) but, for complicated reasons, it stores X400 addresses rather than the more obvious SMTP address. When we migrate an Oxford user their email address doesn’t change but – especially where the user has come from another implementation of Exchange – the X400 address will inevitably be different after they’ve moved.
Now for new messages this is fine – the email address still works after all – but anyone relying on Outlook to auto-populate the ‘send’ field from their nickname file will likely get non-delivery reports, all due to that pesky X400 data being used instead.
In the past the traditional fix for this has been to fix things at the user end – the fortunate ones might have used an NK2 editor to extract/edit the offending email addresses. Other users might have let Outlook (or OWA) suggest the name and then use the delete key to remove the one broken address. But in some cases users may have had their NK2 file removed entirely.
Is there a better fix?
The starting point is to get that user’s X400 data from the original system, prior to migration. It can be extracted afterwards from the NK2 file or via Powershell:
Get-Mailbox <username> | fl LegacyExchangeDN
This should show something like this:
Post migration, it’s possible to add that old X400 data back to the account’s properties by adding a custom address onto the object. Alternatively, if you’re not keen on mixing up your X400 data, you can add the old X400 address to a brand new contact object. A moment tweaking that new contact to forward email to the current user account and you’ve achieved the same objective.