Exchange Admin Q and A: Often Misunderstood Subjects Part 2
Topic Last Modified: 2006-01-12
By Nino Bilic
This article explains some of the misunderstood subjects related to Microsoft® Exchange Server.
It is a misconception that running Exchange 2000 Server /domainprep resets permissions on the Exchange organization. To do that, you need to run the full Exchange 2000 Server Setup, as opposed to Exchange /domainprep. You can accomplish the same result by running the service pack setup in Exchange 2000 Server. For instructions, see Microsoft Knowledge Base article 320007, "XADM: Permissions That Are Modified Manually Are Reset to the Default Values."
On Exchange Server 2003, Setup stamps permissions on the Exchange organization only once, on initial setup only. Further setups will not reset manually changed permissions as Exchange 2000 Server Setup did. Running Setup again in Exchange Server 2003 will not help you resolve permissions problems.
Opening Exchange administrator and connecting to Site Replication Service (SRS), and then looking at recipients as a test if replication was successful from a server running Exchange Server version 5.5 is not a good enough test. It does not show you the true content of recipients in SRS.
In Exchange Server 5.5, the content of the right pane when viewing the recipients is populated by the use of MAPI call. SRS does not have that MAPI functionality anymore. Therefore, when viewing recipients from SRS using Exchange administrator, what you are seeing is recipients as they are in Active Directory, rather than what is in SRS in the Exchange Server 5.5 directory.
To get a true picture of what has replicated to SRS from Exchange Server 5.5 through directory replication, you must perform a directory export from SRS to a .csv file. Alternatively, you can run Ldp.exe to look at the SRS database and see the recipients. This method will show the true list of recipients in the SRS.
When you dump the database header, one of the fields that you are looking at is Repair Count. It is a misconception that Repair Count shows how many times the database was repaired. In reality, the Repair Count shows how many repairs were done on the database during the last repair only. The following code sample shows the area of the database that this refers to. Specially note the line:
Repair Count: 0
C:\Program Files\Exchsrvr\MDBDATA>eseutil /mh priv1.edb Microsoft(R) Exchange Server Database Utilities Version 6.5 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating FILE DUMP mode... Database: priv1.edb File Type: Database Format ulMagic: 0x89abcdef Engine ulMagic: 0x89abcdef Format ulVersion: 0x620,9 Engine ulVersion: 0x620,9 Created ulVersion: 0x620,9 DB Signature: Create time:06/12/2003 20:47:14 Rand:10137710 Computer: cbDbPage: 4096 dbtime: 356535 (0-356535) State: Clean Shutdown Log Required: 0-0 Streaming File: Yes Shadowed: Yes Last Objid: 451 Scrub Dbtime: 0 (0-0) Scrub Date: 00/00/1900 00:00:00 Repair Count: 0 Repair Date: 00/00/1900 00:00:00 Last Consistent: (0x68,12E6,DD) 10/29/2003 15:56:20 Last Attach: (0x63,15FD,1E6) 10/24/2003 11:11:10 Last Detach: (0x68,12E6,DD) 10/29/2003 15:56:20 Dbid: 1 Log Signature: Create time:06/12/2003 20:47:01 Rand:10176758 Computer: OS Version: (5.2.3790 SP 0)
It is little known that when Exchange administrator enables circular logging on Exchange Server 2003 or Exchange 2000 Server, all of transactions for the .stm file are not being logged in transaction logs. Therefore, with circular logging on, Exchange Server 2003 and Exchange 2000 Server are more vulnerable in a server failure, if there are mailboxes involved. Some information that should have been committed to the .stm file could be permanently lost in the case of power failure.
The following sections explain when the Recipient Update Service is supposed to remove the addresses from users.
Prior to Exchange 2000 Server Service Pack 1 (SP1), there was a bug in Exchange System Manager that would cause the Recipient Update Service to remove all addresses of a particular type if one of the addresses of that type was not selected in recipient policy. This bug was fixed in Exchange 2000 Server SP1. Now Recipient Update Service does not remove all addresses of a particular type if one of the addresses of that type was not selected in recipient policy. For example, before Exchange 2000 Server SP1:
Recipient policy: X SMTP: @domain1.com X SMTP: @domain2.com
@domain2.com is not selected and recipient policy is applied, the Recipient Update Service would remove all of the Simple Mail Transfer Protocol (SMTP) addresses from the user, in this case
@domain2.com. Note that this also occurs when the address that is not selected is not the primary address. For more information, see Microsoft Knowledge Base article 291842, "XIMS: SMTP Proxy Addresses Are Deleted for All Users."
This problem can occur if you install Exchange System Manager on your client computers to administer your servers, and you do not apply the service packs to those Exchange System Manager-only computers. In this case, using Exchange System Manager from a client computer against a server running Exchange 2000 Server Service Pack 3 (SP3) would cause this problem to occur.
Assume that there is a policy that has two SMTP addresses:
The @domain1.com is a primary address for the given address type.
If you clear the check box for a primary address on a policy and you apply the policy, all addresses of that type are removed. When you clear the check box for an address on a policy, the Recipient Update Service does not prompt you to apply the policy. If you do not apply the policy, all addresses of that type are not removed. However, if you apply the policy later, the addresses are removed at that later time.
Assume that there is a policy that has two address types:
Note that there is only one address of the type SMTP. If you now remove the address type of SMTP from the policy, and then apply the change, the addresses of the type SMTP will be removed from users that this policy applies to based on the filter. If you do not apply the change, later manual application of policy will not remove the address type. If you want to remove the address type later, you will have to create the same address type in the policy, select it, remove it, and then apply the change.
For more information, see the following Exchange Server resource and Microsoft Knowledge Base articles: