次の方法で共有

Having problems downloading the OAB after you have migrated?

  • [アーティクル]

When an Outlook client attempts to downloads the OAB (Offline Address Book) it will attempt to download the OAB that is associated with that user’s mailbox store. Each mailbox store has an attribute stamped on it called 'msExchUseOAB', and this attribute contains the DN (Distinguished Name) of the Offline Address Book that all users on that mailbox store will download. The information store (store.exe) will attempt to confirm this information by back referencing which mailbox store to check based on the security descriptor passed to it.

In order for this setup to work you have to grant access to accounts that are not part of the Exchange Server 2003 organization's Active Directory forest. If you use a mailbox's Mailbox Rights dialog box (in Active Directory Users and Computers) to grant permissions such as Full Mailbox Access to delegate users, you might have noticed a permission named Associated External Account.

NOTE: This can cause some confusion is organizations have specific OAB's and John's default OAB might be different than the "Accounts Payable" OAB. This is organizational consideration, not a technical issue. John will still have Full Mailbox Access (FMA) and Send As right for the "Accounts Payable" mailbox and still operate as that entity.

Some additional information can be found here: Understanding Exchange Server 2003 Mailbox Access Delegation - https://technet.microsoft.com/en-us/library/aa998694.aspx

Although ms-Associated-External-Account is displayed in the list of permissions, the Associated External Account attribute is not a true permission. It is meant to be used only when the mailbox itself is associated with a disabled account, and the disabled account is associated with another user account (typically a Windows NT Server 4.0 account that has not yet been migrated to Active Directory).

If the users to whom you want to grant delegate access reside in a domain outside the Active Directory forest (such as in a Windows NT Server 4.0 domain or in a separate Active Directory forest), you can add those users to the list in the permissions dialog box in the way you would any other users. Do not try to set the Associated External Account attribute for any delegate user. Associated External Account can only be used one time per mailbox, and only under the condition outlined previously. It does not affect delegates in any way.

If the mailbox has a typical, enabled Active Directory account, setting the Associated External Account attribute can cause odd behavior such as lost permission settings, downloading the incorrect OAB or Outlook sync failures.

Problem

On a standard mailbox enabled user account an attribute called "msExchMailboxSecurityDescriptor" is used. The msExchMailboxSecurityDescriptor maps back to the user accounts, and Exchange can look up that user to check the "homeMDB" attribute. On a mailbox enabled, but disabled user, "msExchMailboxSecurityDescriptor" is not used because the account is disabled. In these cases "msExchMasterAccountSid" is used.

The problem can arise where one account, John Doe, is an Active Directory user but does not have his own mailbox. John Doe created a profile to access and use a generic resource mailbox the have been granted access to for a specific job role, say, Accounts Payable.

John logs into his Windows workstation as "John Doe" and thus has the security context. He then uses Outlook to log into the "Accounts Payable" mailbox. When he attempts to download the OAB it will fail. Exchange attempts to back reference which Store to check for OAB information. Because "Accounts Payable" is disabled, we do not use "msExchMailboxSecurityDescriptor" and attempt to use "msExchMasterAccountSid". In this case "msExchMasterAccountSid" has been granted to SELF per normal practices. SELF is a well know built in SID that does not map back to a specific user. Therefore the back reference fails and we don't know which OAB to attempt to download. Being that John's account is mailbox enabled there are not attribute to check off his security context.

Normal best practice would be for John to have his own "John Doe" Active Directory account mailbox enabled. Then he would access the "Accounts Payable" mailbox as a resource mailbox instead of his primary mailbox. This will allow Exchange to use the "msExchMailboxSecurityDescriptor" from John's mailbox to download the OAB. When an Outlook client logs on to their mailbox store the store.exe process will evaluate the security rights like “msExchMailboxSecurityDescriptor” and “msExchMasterAccountSid” amongst other tasks and will also try to find the default OAB.

In this case, the “msExchMasterAccountSid” is not set to an external account, it is set to “SELF”, which is a well know built in SID. When we pass that information to Store, “SELF” is not a real SID, and therefore the store.exe process cannot resolve in the Active Directory what the true default OAB should be. Now when John Doe downloads the OAB he will run in to one of the following situations:

This is what the error looks like from the sync log from within Outlook:

12:45:53 Synchronizing Mailbox <John Doe>
12:45:53 Done
12:45:54 Microsoft Exchange offline address book
12:45:54 0x8004010f

For more information please see this article: Detecting and Correcting msExchMasterAccountSid Issues - https://technet.microsoft.com/en-us/library/bb124164.aspx

Here is a Workaround

We have introduced a new registry key in Exchange 2003 SP2 that will allow us to set a default OAB DN path: KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ServerName\Public-<GUID>

When an Outlook client logs in we will evaluate this registry key and see that we have a hard coded OAB, and any Outlook client that doesn’t resolve correctly will be forced to download this default OAB. This can become complicated in some environment where customers have multiple OAB's. With any customer that has just one OAB (Example: The Default Offline Address List) this is easy.

We can set this via the registry on a per Store basis. It will be set on the Public Folder Stores in question.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<server>\Public-<GUID>

Create a new String value: “Default OAB DN”

WARNING: Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate the following registry subkey:
3.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ServerName\Public-<GUID>
4. On the Edit menu, click New, click String Value, and then type Default OAB DN for the name.
5. Right-click Default OAB DN, and then click Modify.
6. In the Edit String dialog box, you must type the LDAP Distinguished Name (DN) attribute of the Offline Address Book. For example, the default Offline Address Book DN attribute may appear similar to the following: CN=Default Offline Address List,CN=Offline Address Lists,CN=Address Lists Container,CN=ORGANIZATION,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DOMAIN,DC=COM
7. Click OK.
8. Quit Registry Editor

Dave

Comments

  • Anonymous
    August 24, 2007
    Scalix: A Microsoft ‘Exchange killer’ no more? How to View Email Headers Companies Clamping Down on Messaging