However, not all migrations or M&A scenarios allow for this information to retained, it might get overlooked, or perhaps organizations wish to start with a clean slate. For example, in Exchange hybrid deployments, Active Directory Connect (DirSync) will take care of properly propagating this attribute, stamping it as x500 address on the proxyAddresses attribute. That is, unless it has been applied to the migrated mailbox and thus can be resolved in the new environment. Now, because AutoComplete and other recipient caches are static, this x500 address may become invalid at some point. When picking an address from the list, you are effectively picking the associated x500 address. When using an Exchange-related recipient, Outlook will store the underlying address that is used by Exchange – the infamous X500 legacyExchangeDN, which looks like /o=Organisation/ou=Administrative Group/cn=Recipients/cn=Username – together with the recipient. The issue arises when mailboxes are moved to other organizations such as during a merger or acquisition, or other form of cross-Exchange organization or tenant mailbox move. In addition, other recipient information not directly stemming from addressing is stored as well, such as the Suggested Contacts folder. Outlook on the web (OWA) on the other hand, utilizes its own caching mechanism, storing this recipient information in a different part of your mailbox. This item, the AutoComplete Stream, will be cached locally by Outlook for performance reasons. ![]() For Outlook 2010 and up, this information is stored in a hidden item in your mailbox. Before Outlook 2010, this information was stored in local NK2 files. This information can be stored in multiple locations, depending on the client used.
0 Comments
Leave a Reply. |