Resolution in article 317721 fails to fix mailbox owner rights removal issue (329169)

MORE INFORMATION

The following questions and answers provide additional information:

Q1: Does this problem occur with all versions before the ADC hotfix?

A1: No. The release-to-manufacturing (RTM) and Service Pack (SP) 1 versions of the ADC will not cause this problem. Customers who used the SP2 version of the ADC to run a one-way connection agreement will experience the problem.

Q2: I installed the Microsoft Exchange Server 2003 ADC, the SP3 ADC, or the post-SP2 ADC hotfix (5770.45/q317861engi.exe) before I switched to two-way CA, but the mailbox permissions were still removed after I switched to a two-way. Why?

A2: Because you used an SP2 ADC to execute a one-way CA sometime in the past. After a one-way CA is executed, the stamped accounts are placed in a "pre-removal" state. When they are in this state, installing the later ADC version cannot prevent 5.5 mailbox permission removal after you switch to two-way CA. One-way SP2 CAs damage the Active Directory accounts, but users do not notice the affects. When a two-way CA exists (or a one-way CA in the opposite direction), you notice the full effects of the damaged Active Directory security descriptors.

Q3: How can I tell if mailboxes are in the "pre-removal" state, as mentioned previously?

A3: It is not the Exchange 5.5 objects that are in this state. Their associated Active Directory accounts are placed in a "pre-removal" or damaged state. You can identify candidates for mailbox permission removal if there are mailbox rights with at least two access control entries (ACEs), a domain\username entry, and a SELF entry on the associated Active Directory account's properties. If you view the SELF entry, it lacks the Full mailbox access check box. The domain\username entry is the true mailbox owner, and it does have the Full mailbox access check box selected.

Q4: How can I prevent SELF's missing "Full Mailbox Access" from replicating to Exchange 5.5?

A4:When you reset msexchmailboxsecuritydescriptor on the Active Directory accounts, SELF's ACE is stored in msexchmailboxsecuritydescriptor, so the attribute is directly linked to mailbox rights. Similarly, the Active Directory's Full mailbox access check box is linked directly to Exchange 5.5's Mailbox owner check box.

Q5: I am using ADSIEdit to view the msexchmailboxsecuritydescriptor of a problem account, and it is blank. But Active Directory Users and Computers (ADUC) shows that there are mailbox rights. Why?

A5: There is still a value present, but ADSIEdit cannot display the contents of that field. Remember that the field is not empty unless the value is <not set>. If you clear this attribute so that it says <not set>, and then you return to mailbox rights in ADUC , you will receive a c1033028 error message.

Q6: It seems easier to create a script to remove msexchmailboxsecuritydescriptor from all Active Directory accounts. Does this pose a threat?

A6: Yes. Do not remove this value from Active Directory accounts that have Exchange 2000 mailboxes. Knowledge Base article 317721 states that you must remove the value only from those Active Directory accounts with Exchange 5.5 mailboxes that were affected. This means that you must identify the accounts that have the problem.

Q7: I am reimporting my .csv file as described in Knowledge Base article 317721, but I noticed that the object-version does not increment for some of the Exchange 5.5 mailboxes. As a result, those 5.5 mailbox owner permissions are deleted when the ADC service is turned on again. What did I do wrong?

A7: You probably created their own custom .csv file and exported to it. Check to see if the .csv file does not have the E-mail Addresses column. If it is missing, this explains why object-version will not be incremented. Because object-version is not incremented, the removed msexchmailboxsecuritydescriptor on the Active Directory account overrides Exchange 5.5 settings. The default .csv export includes the E-mail addresses column.

Q8: Knowledge Base article 317721 says "If an export of permissions was done before the permissions change, do a directory import of permissions." What header field to I use to export these permissions?

A8:Obj-User is the header field that you can export to. The resulting .csv file will show those accounts with the "User" role on a mailbox. By default, the primary Microsoft Windows NT account is given the "User" role. This role includes the mailbox owner right. (Note The plural version, obj-users, has the same affect. These header fields may not be listed in the header.exe utility.)

Q9: All Exchange 5.5 mailboxes are set to the "Custom" role, and the mailbox owner check box is removed. What is the quickest way to change this back?

A9: The quickest method of programmatically resetting all Exchange 5.5 mailbox permissions to their primary Windows NT account is: Export all Exchange 5.5 mailboxes to .csv files. Open the .csv file in Notepad, and change the first line's Primary Windows NT account text to Obj-User. Import the modified .csv file.

Q10: Will moving all the mailboxes to Exchange 2000 allow the users to access their mailboxes again?

A10: Yes. A possible alternative to rolling-back your Exchange 5.5 directory and identifying and cleaning-up accounts is to move the mailboxes to Exchange 2000. Because the Exchange 5.5 directory stored the final bit that prevented the user from accessing the mailbox, moving the user to Exchange 2000 will force the logging-on user to use the permissions stored in Active Directory, not in Exchange 5.5. Although the corrupted SELF ACE still exists in the Active Directory, Active Directory also contains the domain\username ACE that permits the user to log on.