To resolve this problem, apply the hotfix that is available
through this article or the latest service pack and then clean up any accounts
that are already affected.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
301378�
How to obtain the latest
Exchange 2000 Server service pack
To resolve this problem, you have to apply the
hotfix listed in this article and clean up any accounts that are already
affected. Just applying the hotfix listed in this article does not correct the
issue for users who have already replicated to the Active Directory over the
one-way Connection Agreement. The fix prevents new users from being stamped
incorrectly when replicating to the Active Directory over a one-way Connection
Agreement.
If you have already changed the one-way Connection
Agreement to a two-way Connection Agreement and permissions have already been
removed from the Exchange 5.5 mailboxes, follow the steps in the "Scenario 1"
section to resolve this problem. If you have not yet changed the one-way
Connection Agreement to two-way, follow the steps in the "Scenario 2" section
to clean up the accounts that have replicated through the one-way Connection
Agreement to prevent the 5.5 mailbox permissions from being removed when you
flip the Connection Agreement to two-way.
Scenario 1
Important Follow these steps in the order that they are listed to make sure
that the permissions are not removed again.
- Stop the ADC service, and then disable it.
- Apply the ADC fix listed at the bottom of the "Resolution"
section.
- Remove the msExchMailboxSecurityDescriptor attribute from all the users in Active Directory that the one-way
Connection Agreement replicated from Exchange Server 5.5 to Active Directory.
Make sure you do not remove this attribute from any Exchange 2000 mailboxes. To
identify these users and remove the msExchMailboxSecurityDescriptor attribute from many users, use the Ldifde.exe utility to query,
and then to modify the user accounts:
- Run the following Ldifde.exe command to generate an
LDIF export file:
ldifde -f file_name -d "dc=domain,dc=com" -r "(&(objectCategory=person)(objectClass=user)(msExchMailboxSecurityDescriptor=*))" -l nothing
The following text is an example of the output file that the
command creates:
dn: CN=UserA,CN=Users,DC=domain,DC=com
changetype: add
dn: CN=UserB,CN=Users,DC=domain,DC=com
changetype: add
- Change the export file to look similar to:
dn: CN=UserA,CN=Users,DC=domain,DC=com
changetype: modify
delete: msExchMailboxSecurityDescriptor
-
dn: CN=UserB,CN=Users,DC=domain,DC=com
changetype: modify
delete: msExchMailboxSecurityDescriptor
-
Each record must be followed by a hyphen and a blank
line, including the last record in the file.
Note You can use the find and replace feature in Microsoft Word to
convert the export file to the import file. Make sure that you save the file in
plain text format when you finish.
To use Word to create the import
file:
- On the Edit menu, click Replace to open the Find and Replace dialog
box.
- In the Find what box, type:
^p^p
Note Type the caret character (^) followed by a lowercase p, not
CTRL+P.
You can also copy these search strings, and then paste them
in the Word Find and Replace dialog box. - In the Replace with box, type:
^p-^p^p
Click Replace All. A hyphen and a blank line are inserted following each record in
the file. - In the Find what box, type:
changetype: add^p
- In the Replace with box, type:
changetype: modify^pdelete: msExchMailboxSecurityDescriptor^p
Click Replace All. - Either save the file that is generated as plain
text, or paste the contents of the file in Microsoft Notepad to visually verify
that the formatting matches the previous example.
- To import the file, run the following Ldifde
command:
ldifde -i -f file.txt -s domaincontroller
- Fix the Exchange Server 5.5 permissions on any affected
mailbox by granting the account the mailbox owner right. To do so:
- Grant the mailbox account the mailbox owner right
manually.
- Restore a copy of the directory that was made before
the permissions change.
- If an export of permissions was done before the
permissions change, do a directory import of permissions.
If an
export of permissions before the change is not available, you can do a
directory export of all the affected mailboxes and then edit the .csv file by
changing the Primary Windows NT Account column header to Obj-Users and import
this file back in. This will correct the permissions for the user who is the
primary account listed on the mailbox. You must manually fix any other accounts
that were added with the User right.
For more information about how to export or import mailbox
permissions, click the following article number to view the article in the Microsoft Knowledge Base:
188628�
Exporting and importing
permissions on objects
Note You can run a default export of the Exchange 5.5 directory to get
all the required header fields. If you do not, for the subsequent import to
work, you must export at least the following four header fields, and increment
the Object Version value.
- Obj-Class
- Directory Name
- E-mail addresses
- Primary Windows NT Account
- "Touch" all the Exchange Server 5.5 mailboxes where you
removed the msExchMailboxSecurityDescriptor attribute from the corresponding user account in Active Directory
in step 3. To do so quickly, do a directory export of all the mailboxes in the
Exchange Server Administrator program, and then immediately import the export
(you do not have to change anything in the export). This export and import
increments the Object-Version attribute on all the mailboxes in Exchange Server 5.5.
The Object-Version attribute must be incremented so that Exchange Server has the
newest object change. Because Exchange Server has the newest object change,
replication occurs from the Exchange Server side first. This stamps the msExchMailboxSecurityDescriptor attribute correctly. If the Exchange Server side does not have
the newest change, replication occurs from Active Directory first (because
removing the msExchMailboxSecurityDescriptor attribute in step 3 is considered an object change), and this
removes the mailbox owner right again. - Set the ADC service to automatic, and then start the ADC
service.
- Force a full replication of the recipient Connection
Agreement.
Scenario 2
- Stop the ADC service, and then disable it.
- Apply the ADC fix.
- Remove the msExchMailboxSecurityDescriptor attribute from all the users (same as step 3 in the earlier
"Scenario 1" section).
- Run another ldifde export with the same syntax that you
used in the first export and verify that no users show up in this export file.
(The export pulls all mailboxes with the msExchMailboxSecurityDescriptor attribute stamped on them so if it was stripped off all the
mailboxes correctly in step 3, no mailboxes should show up in the second
export.)
- Force a full replication of the 1-way Connection Agreement
so that the msExchMailboxSecurityDescriptor attribute is restamped on all the Exchange 5.5 mailboxes
correctly.
- When you are sure that the msExchMailboxSecurityDescriptor attribute has been stamped correctly on all the users, you can
flip the 1-way Connection Agreement to a 2-way Connection Agreement. You can
verify that all the mailboxes have been restamped correctly by running the same
ldifde export that you performed in step 3 and verify that you have the same
number of entries that you had in the very first export.
ADC Fix
The English version of this fix has the following file attributes
or later:
Component: ADC
Collapse this tableExpand this table
File name | Version |
---|
Adc.exe | 6.0.5770.45 |
Note Because of file dependencies, this update requires Microsoft
Exchange 2000 Server Service Pack 2.