Our current environment includes two sister companies with a cross-forest trust.
- Servers are 2003 Citrix servers, fully patched.
- Office is 2010 Office x86 also fully patched
We are migrating users from one Exchange org to another. No problems with the migrations. No problems getting to email.
The problems come in with the outlook clients updating themselves. They will prompt the user to restart outlook. When it comes back up, one of two scenarios happen:
- If Cached mode is disabled the client sits with the "Send/receive" bar increasing slowly and indefinitely. Mail flow works, but during this time outlook is creating a copy of every single item in the mailbox, and deleting the copies. So their inbox looks like it's "jumping" up and down one email at a time. This also causes their RestoreDeletedItems folder to grow very large very fast.
- If Cached mode is disabled, they get a direct error of "Outlook data file cannot be accessed (error 8004010F)" as soon as they hit send/receive.
Now, the "fix" is to delete the profile and recreate it. However, this is not an option for 1,000 users in mixed environments (Citrix, remote, local, etc.)
We have determined the fault to be directly tied to a single Registry Key that is not getting updated accordingly. The Registry Key is: HKEY_Current_User\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\MS Exchange Settings\9375CFF0413111d3B88A00104B2A6676\00000001\Deliver Store EntryID
- "MS Exchange Settings" in that list is the default profile name being used
- "9375CFF0413111d3B88A00104B2A6676" is the same key for every user
- "00000001" could also be "00000002," or "00000003", etc......
Delivery Store EntryID is not updating after migration. It shows the new mail server address, but the old ExchangeDN
- We've discovered that if we replace the binary data in that key with binary data that reflects the new ExchangeDN for the user, the problem is solved.
- We can also "fix" the problem by deleting the Binary key "Delivery Store EntryID" itself. Restarting outlook recreates this key correctly.
- We can also "fix" the problem by deleting the parent (09375cff.......) key. Restarting outlook recreates this key correctly.
- We can also "fix" the problem by recreating the profile entirely.
But instead of scripting deletions of the registry, we really need to find the root cause.
I don't think it's a server config as all newly created profiles auto-populate correctly.
