Unable to run prepareAD command

Topology
========
Exchange 2007 SP1 on Windows 2003 SP2

Error
=====
When we run prepareAD command
setup /prepareAD /organizationname:CSXDEV

Configuring Microsoft Exchange Server

Organization Preparation ......................... FAILED

Active Directory operation failed on test.xyz.com. This error is not retriable. Additional information: The object cannot be added because the parent is not on the list of possible superiors.

Active directory response: 00002099: NameErr: DSID-03050EB2, problem 2005 (NAMING_VIOLATION), data 0, best match of: 'CN=Address Lists Container,CN=CSX,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=xyz,DC=com'

Resolution
==========
Renamed the Exchange setup log to ExchanegSetuplogsOld

Checked the properties of the "Address -book-Container" through ADSIEdit under Schema partition and found that "Posssuperiors" attribute was .


Add "msExchConfigurationContainer" in "Posssuperiors" .

Installation of E2K7 SP1 RU8 failing Error 1603

Topology
========
Exchange 2007 SP1 RU 8

Error
====
Exchange 2007 SP1 RU8 installation is failing with Error 1603
Update Rollup 8 for Exchange Server 2007 Service Pack 1 (KB968012) 8.1.375.2' could not be installed. Error code 1603. Additional information is available in the log file x:\xx.log.

Resolution
==========
Changed to ExecutionPolicy setting to RemoteSigned by running following cmdlet.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned.

All scripts that are locally created will run. Scripts that are downloaded from remote locations, such as the Internet, that cannot be trusted, will not run. This is the default script execution mode.


Script Security : http://technet.microsoft.com/en-us/library/bb125017.aspx

Setup on Exchange Server 2007 CCR cluster fails.

Topology
=========
Exchange 2007 Active/Passive CCR Cluster
EVS Name : TestEVS
Node Names : Test1, Test2

Error
=====
1. Error from setup log:

[x/x/xxxx x:xx:xx AM] [1] 0. ErrorRecord: Cluster Common Failure Exception :
Failed to bring cluster resource Network Name (TEST1) in cluster group TEST1
online. Cluster Common Failure Exception : The group or resource is not in the
correct state to perform the requested operation. (Exception from HRESULT:
0x8007139F)

2. Error from system log:

Event ID : 1119
Raw Event ID : 1119
Record Nr. : 8063
Category : Network Name Resource
Source : ClusSvc
Type : Warning
Generated : x/x/xxxx x:xx:xx PM
Written : x/x/xxxx x:xx:xx PM
Machine : TEST1
Message : The registration of DNS name nambx06.corp.adobe.com for resource
'Network Name (TEST1)' over
adapter 'Public' failed for the following reason:DNS bad key.

Event ID : 1196
Raw Event ID : 1196
Record Nr. : 8064
Category : Network Name Resource
Source : ClusSvc
Type : Error
Generated : x/x/xxxx x:xx:xx PM
Written : x/x/xxxx x:xx:xx PM
Machine : TEST1
Message : The required registration of the DNS name(s) associated with Cluster
resource
'Network Name (TEST1)' failed for the following reason:
DNS bad key.

Resolution
==========

1) Dynamic updates were disabled on DNS and had created DNS records
manually for CMS.
2) Open Cluster Administrator, right click and click properties on Network Name
resource under Exchange group.
3) Click on Parameters tab and uncheck “DNS Registration Must Succeed”.
4) Retry setup again.

CCR Cluster: Unable to mount databases

Topology
=========
Exchange 2007 Active/Passive CCR Cluster
EVS Name : TestEVS
Node Names : Test1, Test2

Unable to mounte databases when Test1 was active node.
For some reason it failover and could not mount the stores and resources for the Storage Group
failed to come online. He had shut down the Test1 node.
All Resources were online on Test1 node except second Storage Group and Third Storage Group.

Event ID
=========
Event Type: Error
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 496
Date: x/x/xxxx
Time: xx:xx:xx AM
User: N/A
Computer: Test1
Description:
eseutil (3456) Database E:\Program Files\Microsoft\Exchange Server\Mailbox\Second
Storage Group\Test1 Mailbox.edb requires logfile F:\Program
Files\Microsoft\Exchange Server\Mailbox\Second Storage Group\e01000xxxxx.log
created at xx/xx/xxxx xx:xx:xx in order to recover successfully. Recovery found
the logfile created at xx/xx/xxxx xx:xx:xx .

Resolution
=============
Both(A/P) copies of Databases were in Dirty shutdown.
Required Logs were present in the respective location.
we have 2 options
To use Restore-StorageGroupCopy command "Restore-StorageGroupCopy "CMS Name\SG name"
To run a soft recover on the passive copy or on the node where the log file was created.
As we had failed in running the command Restore-StorageGroupCopy on the passive node
Ran a soft recovery on the passive node.
Soft recovery was successfull. Databases came in clean shutdown state
Failed over the resources from active to passive, all the resources came online successfully.

Rooms missing from "All Rooms" address list after Move Mailbox

ISSUE:
======
Exchange 2007\Rooms missing from "All Rooms" address list after Move Mailbox


CAUSE:
======
-In the RTM build of E2k7 there is a known issue that can occur after mailboxes
designated as "Room Mailboxes" are moved between mailbox stores.
-The attribute that identifies the mailbox as a "Room Mailboxes" is changed to the
attribute that represents a "User Mailbox"
-The value for the msExchRecipientDisplayType attribute for an account with a "Room
Mailbox" should be 7
-If this issue occurs after a move mailbox the value for the
msExchRecipientDisplayType attribute is changed to 1073741824 (this is the value
that represents a "User Mailbox".


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

WORKAROUND:
============
-You can verify this issue by using ADSIEdit.msc to view the
msExchRecipientDisplayType attribute for an account with a "Room Mailbox"
-The value should be integer value 7. If you have this issue the value will be
1073741824
-You can correct this issue by using ADSIEdit to change the value for
msExchRecipientDisplayType to 7.
-You can also modify this value in bulk by using ADMODIFY.NET, or using a script.
-After modifying the attribute you may want to speed up the process of making the
rooms visible in the All Rooms Address List by right clicking on it in EMC and
selecting apply. After this, forcing AD Replication may help as well.
-This issue is resolved in SP1 for Exchange 2007.

Unable to add replica of legacy Exchange public folders to Exchange 2007 public folder store

Error :
==========
"There are no Public folder stores which do not have a replica of this folder"

If we try to run the following Management shell command

Get-PublicFolder -Identity \NON_IPM_SUBTREE -Recurse | Format-List Name

We received following error

"There are multiple MAPI public tree found"

ENVIRONMENT:
=============

2 Exchange Servers
Exchange 2000 server
Exchange 2007 (CAS,HUB,MBX)


RESOLUTION:
============

We noticed that they have Two MAPI public folder tree available in the Org
One for E2K Admin Group and One for E2K7 Admin group
Checked the msExchPFTreeType of the Hierarchy Tree and both set to the value 1
We set the Exchange 2007 MAPI tree we set the value of msExchPFTreeType to Not set.
That made the public folder tree ad NON MAPI tree
Then deleted the public folder from Exchange 2007, then we created new public
folder (Public folder database was with empty data)
We made sure that it is associated with the correct Tree
After that the Exchange 2007 public folder showed in the add replica list, Then we
added the replicas successfully

You can use NexTags.exe to capture requests and responses between the device, Exchange ActiveSync and Exchange.

To use NexTags:

1. Run Nextags.exe on the server that is running Exchange ActiveSync. This is usually your Front End server if you have one. If you don’t have a Front End server run the utility on your mailbox server.

2. Click on the Options tab and check “Trace output to file”, and in the "File Name" box, specify a filename. The default is c:\massync.log

3. Set "Trim Percentage" to 30%.

4. Set "Limit file size to" to 10MB.

5. To capture logs for all users use * in the "User Names" field. To
Capture the log for individual users, type the user aliases separated by a
semicolon (;).

6. Make sure that the “Do Not buffer” check box is unchecked.

7. Click "Tags", and then click on “Errors”, “Warnings”, or “User” depending on the error you are trying to troubleshoot. You can also click on “Check all”. This logs everything and could impact performance.

8. Click "Enable Tracing".

9. Click "OK".


After you complete this configuration, the Exchange server records all the logging information to the file that you specified on the "Options" tab. This log can be useful to troubleshoot synchronization failures.

When you have finished troubleshooting the issue, make sure you turn off tracing by clicking on “Disable Tracing” and clicking OK .

Enabling SSL password changes for the Web client:Prerequisites

To prepare for an SSL installation, the following resources are necessary:

• Windows 2000 Active Directory Domain
• Windows 2000 Server running IIS 5.0
Step 1 – Installing the Certification Authority

The first step to installing SSL is to install and configure the Certification Authority (CA), the service which issues and maintains the server certificates. In this lab, the CA will be installed on the Windows 2000 Domain Controller. To install the CA, follow the steps below:

1. Open ‘My Computer’ > ‘Control Panel’ > ‘Add/Remove Programs’
2. Choose ‘Add/Remove Windows Components’
3. Place a check in the box next to ‘Certificate Authority’ and click ‘Yes’ when the warning appears.
4. Click ‘Next’.
5. When prompted for the CA type, choose ‘Stand-alone root CA’

Note: this will differ in actual environments depending on planning and any existing CAs.

6. Complete the ‘CA Identifying Information’ dialog with information specific to your environment and click ‘Next’. Example information, that can be used for testing is below:

7. Verify the ‘Data Storage Location’ is suitable for your server and click ‘Next’.
8. Click ‘Ok’ when warned that IIS services will be stopped and click ‘Finish’ when setup has completed copying files.

Step 2 – Generating a certificate request
The next step is to request a certificate for the web server. This is done from the server that will have MMIS v1.5 installed on it. To request a certificate, follow the steps below:

1. Click on ‘Start’, ‘Programs’, ‘Administrative Tools’ and open the ‘Internet Services Manager’ MMC snap-in.
2. Expand the server name, right-click on ‘Default Web Site’, and choose ‘Properties’.
3. Select the ‘Directory Security’ tab and click ‘Server Certificate’.
4. Click ‘Next’ to begin the wizard and choose ‘Create a new certificate’ and click ‘Next’.
5. Choose ‘Prepare the request now, but send it later’ and click ‘Next’.
6. Click ‘Next’ to accept the default values on the ‘Name and Security Settings’ dialog.
7. On the ‘Organization Information’ dialog, enter a name and organizational unit for your certificate and click ‘Next’.
8. Enter the FQDN of your server on the next dialog (for example, mmis.domain.com) and click ‘Next’.
9. Enter the country, state/province and city/locality that your server is located in and click ‘Next’ (for state/province, standards suggest you do not abbreviate but rather spell out the name, such as Washington, as opposed to WA).
10. Specify where you would like the request saved, and click ‘Next’, then ‘Next’ again and ‘Finish’ completing the request generation.

Step 3 – Submitting the certificate request

The next step is to submit the certificate request to the CA that was created in Step 1. This is also done from the server that will have MMIS v1.5 installed on it. To submit the request, follow the steps below:

1. Start Internet Explorer and enter the following URL (replace ‘CAserver’ with the name of the server the Certification Authority was installed on), http://CAserver/certsrv.
2. Choose ‘Request a certificate’ and click ‘Next’.
3. Select ‘Advanced request’ and click ‘Next’.
4. Choose the second option, ‘Submit a certificate request using a base64 encoded PKCS #10 file or a renewal request using a base64 encoded PKCS #7 file.’ and click ‘Next’.
5. Open the file that was saved in #10 in the previous step using Notepad (by default, this file is C:\certreq.txt). It will appear similar to below:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIICnjCCAkgCAQAwgY0xIzAhBgNVBAMTGm1vYmlsZS1tbWlzLm1vYmlsZWNvcnAu
Y29tMRcwFQYDVQQLEw5XaXJlbGVzcyBHcm91cDETMBEGA1UEChMKTW9iaWxlY29y
cDESMBAGA1UEBxMJQ234ahcmxvdHRlMRcwFQYDVQQIEw5Ob3J0aCBDYXJvbGluYTEL
MAkGA1UEBhMCVVMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAz+nnFAupbS2PIkcE
zu+nl1kAwxtz60eF/I+HZO/Mo6ztWrhBu4iQVmYLQYh9uE3PHGRIB+YwGII38jKp
IgmniwIDAQsfdsUzAaBgorBgEEAYI3DQIDMQwWCjUuMC4yMTk1LjIwNQYKKwYB
BAGCNwIBDjEnMCUwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMB
MIH9BgorsdfeEEAYI3DQICMYHuMIHrAgEBHloATQBpAGMAcgBvAHMAbwBmAHQAIABS
AFMAQQAgAFMAQwBoAGEAbgBuAGUAbAAgAEMAcgB5AHAAdABvAGcAcgBhAHAAaABp
AGMAIABQAHIAbwB2AGkAZABlAHIDgYkAjuYPzZPpbLgCWYnXoNeX2gS6nuI4osrW
HlQQKcS67VJclhELlnT3hBb9Blr7I0BsJ/lguZvZFTZnC1bMeNULRg17bhExTg+n
UovzPcJhMvG7G3DR17PrJ7V+egHAsQV4dQC2hOGGhOnv88JhP9Pwpso3t2tqJROa
5ZNRRSJSkw8AAAAAAAAAADANBgkqhkiG9w0BAQUFAANBAFD/X5SZwqMG8hbPGYNS
LVZvbmL8H1hbiRqYkeoYPghq2XfQre/ifA+zaMAl1rdQMVMGl9CrW/a5e02gRaUb
nko=
-----END NEW CERTIFICATE REQUEST-----

6. Select the text after the first line through to the end of the request (do not include the beginning and ending comments, then paste that text into the field labeled ‘Base64 encoded Certificate Request’ and click ‘Next’.

The request has now been submitted and is awaiting approval from the Certificate Authority. This is covered in the next section.

Step 4 – Issue the requested certificate

The next step is to issue the requested certificate. This is done on the machine that is running the Certification Authority. To issue the certificate, follow the steps below:

1. Click on ‘Start’, ‘Programs’, ‘Administrative Tools’ and open the ‘Certification Authority’ MMC snap-in.
2. Expand the name of the CA in the left window pane and select the ‘Pending Requests’ folder. The pending certificate request will appear in the right pane.
3. Right-click on the pending request, select ‘All Tasks’ followed by ‘Issue’ to issue the certificate.

The certificate has now been issued and it must be installed on the web server.

Step 5 – Installing the certificate

Now the certificate will be installed on the server that will run MMIS v1.5. To do so, from the member server running IIS 5.0, follow the steps below:

1. Start Internet Explorer and enter the following URL (replace ‘CAserver’ with the name of the server the Certification Authority was installed on), http://CAserver/certsrv.
2. Click ‘Check on a pending certificate’ and click ‘Next’.
3. Select the certificate request that was made in Step 3, and click ‘Next’.
4. Click ‘Download CA certificate’ and when prompted, save the certificate locally on the server, then close Internet Explorer.
5. Click on ‘Start’, ‘Programs’, ‘Administrative Tools’ and open the ‘Internet Services Manager’ MMC snap-in.
6. Expand the server name, right-click on ‘Default Web Site’, and choose ‘Properties’.
7. Select the ‘Directory Security’ tab and click ‘Server Certificate’ and click ‘Next’ to begin the wizard.
8. Choose ‘Process the pending request and install the certificate’ and click ‘Next’.
9. Browse to the location of the saved certificate, select it and click ‘Open’ followed by ‘Next’.
10. The certificate information will appear, click ‘Next’ to install the certificate and ‘Finish’ to complete the wizard.

That completes the certificate installation. To test, navigate to https://localhost and verify that SSL is working correctly.

Note: You may be prompted with a warning that the certificate name does not match the server name. This appears because of the way the server name was entered on the certificate request. If you entered an FQDN, the warning will not appear if you enter the URL as an FQDN as is the case when a NetBIOS name is specified in the certificate request.

Enabling SSL password changes for the Web client:

1. In ISM for each front-end server, create IISADMPWD virtual directory and map it to
drive:/WINNT/System32/inetsrv/iisadmpwd

2. Ensure that IISADMPWD directory has Anonymous Access (other auth types may be selected, but Anonymous must be one of them).

3. Ensure the Metabase setting PasswordChangeFlags is set to 0. *If you change the 1 to 0, then you can only use https://; otherwise either method will work...

cd c:\inetpub\adminscripts
adsutil set w3svc/passwordchangeflags 1

0 - requires password change by SSL
1 - allows password change by non-secure ports
2 - disables password changes
3 - undocumented but disabled
4 - disables advance notification of expiration

Troubleshooting Trusts

Trust between a Windows NT domain and an Active Directory domain cannot be established or it does not work as expected - http://support.microsoft.com/default.aspx?scid=kb;en-us;889030

A very complete guide to troubleshooting almost every kind of Trust issue. Don't let the title fool you, this is very applicable to external (legacy NTLM) trusts between forests as well in 2000 and 2003.

How to configure a firewall for domains and trusts - http://support.microsoft.com/default.aspx?scid=kb;en-us;179442

A very common support case here; because trusts are not always well-understood, this article gives a matrix-based listing of all port requirements for trusts.

How to establish trusts with a Windows NT-based domain in Windows 2000 - http://support.microsoft.com/default.aspx?scid=kb;en-us;308195

A brief guide to the actual step-by-step process of creating and verifying trusts between domains.

Troubleshooting trusts - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/ad02d816-aac3-4f13-b771-39ebe7e3a5ee.mspx

A guide to the most common trust-related issues and how to quickly fix them. This is great to have in your backpocket, as it's a difficult guide to find.

Domain and Forest Trusts Technical Reference - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/b6284369-73ea-4d68-a3a5-975a0fe6782d.mspx

Finally, an architectural guide to how trusts work, with explanatory diagrams. Understanding how the entire trust system operates is often very important to resolving issues with it.

Troubleshooting DNS in regards to AD

Troubleshooting DNS in regards to AD



While not directly related to your case, I wanted to provide some good information on general DNS troubleshooting, especially in regards to Active Directory. These systematic steps can save time (and a possible new case) when trying to isolate what DNS issue is affecting Active Directory. Statistically speaking, roughly 75% of our cases here in DS support have a root cause in DNS issues, so understanding all the pitfalls can be very useful.

Troubleshooting Active Directory—Related DNS Problems - http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/opsguide/part1/adogd10.mspx

This article covers understanding the symptoms of DNS issues in Active Directory and how to track down their root causes step-by-step. It explains the DNS SRV record requirements, includes useful tools with syntax, and goes into likely event log messages that will point you in the right direction for repairing DNS.

Troubleshooting Domain Name System Problems - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/bca4b6fe-d6a6-45cc-a433-86948b178f2f.mspx

A more general guide to troubleshooting DNS issues, but still very applicable to AD. Sometimes the simplest answers are the best ones, naturally.

DNS Server becomes an island when a domain controller points to itself for the _msdcs.ForestDnsName domain - http://support.microsoft.com/default.aspx?scid=kb;en-us;275278

A very common issue explained; how DNS islanding occurs and how to prevent it from crippling domain controllers.

DNSLint utility - http://support.microsoft.com/default.aspx?scid=kb;en-us;321045

The simplest method of using DNSLINT is to verify DNS records for domain controllers. To do this, run:

DNSLINT /AD IP of dc you want to check /S IP of DNS server authoritative for MSDCS subzone

This will run and generate an HTML-based report of records on this DNS server for AD, confirming that CNAME records match up with A records. The easiest way to interpret the results is to scroll to the very bottom of the page and look at the summary report - any warnings or errors will be noted. All issues in the body of the report are color-coded for easy viewing as well. It also has the /QL functionality in order to check SRV records and the like.

The tool also has some useful extra features, like /C (used to test ports on email servers), /T (used to create TXT output instead of HTM), and /NO_OPEN which prevents the HTM file from being loaded. Using these commands together means that you can very simple script a batch file which can be used to easily spot check the overall health of your DNS in regards to AD - very useful.

Some good further info on the tool:

How To Use DNSLint to Troubleshoot Active Directory Replication Issues - http://support.microsoft.com/default.aspx?scid=kb;en-us;321046
Finally, a brief explanation of using DNSLint to determine why replication is failing between multiple DC's.
AD Replication Troubleshooting



While not precisely related to your case, I wanted to provide some further information on general troubleshooting of AD Replication issues in domains and forests. The steps and tools below can be used to detect and repair the most common replication issues, and may save you a support call someday. I hope you find these useful!
Troubleshooting Active Directory Replication Problems - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/4f504103-1a16-41e1-853a-c68b77bf3f7e.mspx

A good general guide to deciding how to approach replication failures and break the problem down into its component pieces. It also covers the REPADMIN tool which will be instrumental in seeing error codes that drive how the troubleshooting is done.

Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/43e6f617-fb49-4bb4-8561-53310219f997.mspx

The most common cause of replication failure is DNS lookup issues (where we are unable to resolve CNAME records to servers in order to complete the replication ring). This guides an admin through systematically tracking down replication issues caused by DNS, and what sorts of errors mean specific conditions. In Windows Server 2003 SP1 this has been mitigated to some extent, and this is covered in detail in the above article.

Fixing Replication Connectivity Problems (Event ID 1925) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/7fcaa311-bc19-479d-9a4e-179704dfe08f.mspx

A step-by-step guide to determining replication issues caused by network problems (not related to DNS). This covers simple initial tests like PING and PING -L then moves on to more advanced steps like network tracing.

Fixing Replication Topology Problems (Event ID 1311) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/062e8eaa-27e0-4c5e-bc2b-2913ecce24b8.mspx

This article covers replication issues caused by issues in the overall site topology, where there is insufficient physical connectivity to complete the replication ring. This means that replication would work fine if the DC's sites and connections were configured more optimally, and there are no other underlying connectivity issues with DNS or the network itself.

How the Active Directory Replication Model Works - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/1465d773-b763-45ec-b971-c23cdc27400e.mspx

Finally, I wanted to provide more detailed information on how replication actually works. With an understanding of the system and how it operates, it becomes much easier to see where issues are and how to approach troubleshooting them. This guide goes into great detail on USN's, consistency, change notification, scheduling, linked values, and all the other pieces that make up this complex system.

AD Replication Troubleshooting

AD Replication Troubleshooting



While not precisely related to your case, I wanted to provide some further information on general troubleshooting of AD Replication issues in domains and forests. The steps and tools below can be used to detect and repair the most common replication issues, and may save you a support call someday. I hope you find these useful!
Troubleshooting Active Directory Replication Problems - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/4f504103-1a16-41e1-853a-c68b77bf3f7e.mspx

A good general guide to deciding how to approach replication failures and break the problem down into its component pieces. It also covers the REPADMIN tool which will be instrumental in seeing error codes that drive how the troubleshooting is done.

Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/43e6f617-fb49-4bb4-8561-53310219f997.mspx

The most common cause of replication failure is DNS lookup issues (where we are unable to resolve CNAME records to servers in order to complete the replication ring). This guides an admin through systematically tracking down replication issues caused by DNS, and what sorts of errors mean specific conditions. In Windows Server 2003 SP1 this has been mitigated to some extent, and this is covered in detail in the above article.

Fixing Replication Connectivity Problems (Event ID 1925) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/7fcaa311-bc19-479d-9a4e-179704dfe08f.mspx

A step-by-step guide to determining replication issues caused by network problems (not related to DNS). This covers simple initial tests like PING and PING -L then moves on to more advanced steps like network tracing.

Fixing Replication Topology Problems (Event ID 1311) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/062e8eaa-27e0-4c5e-bc2b-2913ecce24b8.mspx

This article covers replication issues caused by issues in the overall site topology, where there is insufficient physical connectivity to complete the replication ring. This means that replication would work fine if the DC's sites and connections were configured more optimally, and there are no other underlying connectivity issues with DNS or the network itself.

How the Active Directory Replication Model Works - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/1465d773-b763-45ec-b971-c23cdc27400e.mspx

Finally, I wanted to provide more detailed information on how replication actually works. With an understanding of the system and how it operates, it becomes much easier to see where issues are and how to approach troubleshooting them. This guide goes into great detail on USN's, consistency, change notification, scheduling, linked values, and all the other pieces that make up this complex system.

AdminSDHolder

Description and Update of the Active Directory AdminSDHolder Object - http://support.microsoft.com/default.aspx?scid=kb;en-us;232199

AdminSDHolder is specifically designed to protect members of built-in administrative groups. These accounts are deemed security-sensitive, and so the AdminSDHolder runs once per hour to make sure the ACLs for those accounts are set to system defaults. This can cause problems because of the method that the AdminSDHolder uses to determine which accounts are protected – it works on the basis of group memberships, including nested groups.

As an example, if you have a group called CorpHelpDesk, and CorpHelpDesk is a member of CorpAccountOps, which is in turn a member of the Account Operators built in group, then AdminSDHolder will apply changes to all the members of CorpHelpDesk based on the nested group membership.

Delegated permissions are not available and inheritance is automatically disabled - http://support.microsoft.com/default.aspx?scid=kb;en-us;817433

How to workaround issues with AdminSDHolder, as well as hotfixes for 2000 and 2003 to resolve permission delegation issues.

AdminSDHolder Object Affects Delegation of Control for Past Administrator Accounts - http://support.microsoft.com/default.aspx?scid=kb;en-us;306398

How to work around an issue within Windows 2000 where removal of a user from a protected group does not reset the 'allow inheritable permissions' attribute from the object, leading to help desk users not being able to manage those accounts.

Best Practices for Delegating Active Directory Administration - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/activedirectory/actdid3.mspx

An excellent article on Delegation and how to best leverage the technology for common administrative tasks. The article goes into how the technology actually works, recommendations on using it effectively, and common pitfalls that can be avoided.

How Security Principals Work - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/6375943b-1089-4ec5-9b2d-823b884ec1ec.mspx

Finally, an architectural guide to Security Principals in Windows 2000/2003. Covers the well-known SID's, the purpose of the individual built-in accounts, group types, the built-in groups, and much more.

Configuring and Troubleshooting Firewalls with DS

Configuring and Troubleshooting Firewalls with DS



Based on our previous discussions, I wanted to provide you with good information on configuring and troubleshooting firewalls to work with Active Directory. Understanding and using this documentation will likely save you from issues down the road, as Firewalls require considerable tuning to work with AD and are a frequent call generator here due to configuration issues. I hope you find this useful!

How to configure a firewall for domains and trusts - http://support.microsoft.com/default.aspx?scid=kb;en-us;179442

A brief matrix of the standard port requirements for NT, 2000, and 2003 directory services. Some of these ports can be modified further with the articles below, specifically to control RPC traffic.
Active Directory Replication over Firewalls - http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/confeat/adrepfir.mspx

An extensive guide to configuration of a firewall for AD replication. Includes examples and step by step sections, as well as background information on the process. This also includes details on using IPSEC to ensure that the communication is more secure.

How to configure RPC dynamic port allocation to work with firewalls - http://support.microsoft.com/default.aspx?scid=kb;en-us;154596

Information on the registry values that can modified to allow more controlled use of RPC through a firewall. the article also gives some recommendations on the minimum number of ports to keep open to prevent possible RPC endpoint exhaustion.

How to configure RPC to use certain ports and how to help secure those ports by using IPsec - http://support.microsoft.com/default.aspx?scid=kb;en-us;908472

A more advanced version of the 154596 article, which includes more information on using IPSEC along with the RPCcfg tool. Again, it is important to use caution when restricting RPC on domain controllers, as they use far more connections than an average machine and can be crippled by overzealous firewall administration.

You experience a long delay when you log on to a domain through a NAT server - http://support.microsoft.com/default.aspx?scid=kb;en-us;843427

A short and sweet article which explains why you cannot use NAT between DC's, or clients and DC's, without crippling Kerberos. One of the core elements of Kerberos is that it (by default) packages the originating computer IP addresses in its packets, and NAT will lead to the KDC believing there is a packet spoofing attack going on.

Some firewalls may reject network traffic that originates from Windows Server 2003 Service Pack 1-based computers - http://support.microsoft.com/default.aspx?scid=kb;en-us;899148
Finally, an article on changes to RPC in Windows Server 2003 SP1 and the impact it can have if your firewall software is out of date, along with workarounds that can be put in place in the meantime.

FSMO Roles and GC Explanation

What are Operations Masters? - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/6a773f69-e153-4460-9a9b-014e98110bab.mspx

Because AD operates in a Multi-Master environment, FSMO roles are used for specific components and functions that must be centralized and managed. They also (like in the case of the PDC Emulator) often have functions designed for legacy compatibility with older operating systems like NT and Win9X. This article gives a good overview of these pieces, what their dependencies are, and what they mean to you as an admin.

How Operations Masters Work - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/795229a5-8a74-4edb-a2f4-d5794d31c2a7.mspx

A complete breakdown (per role) of how each of the 5 roles (RID, PDCE, Domain Naming, Schema, and Infrastructure) operate in practical terms, and how they should be managed.

What Is the Global Catalog? - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/24311c41-d2a1-4e72-a54f-150483fa885a.mspx

An excellent explanation of GC's and what they do in a domain environment. Many systems (like Exchange) rely on this special virtual partition, and certain functional modes (starting with 2000 Native Domain) raise the need for this as well.

How the Global Catalog Works - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/440e44ab-ea05-4bd8-a68c-12cf8fb1af50.mspx

A lengthy treastise on the 'under the covers' workings of GC's, what the default settings are, how it's populated and updated, and other elements important to troubleshooting issues.

Global Catalog Tools and Settings - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/0d34c3b9-499b-41d3-a55f-527ce61e7858.mspx

Finally, the tools that can be used to monitor and manipulate GC's (DSSITE, LDP, ADSIEDIT, and REPADMIN), plus the various registry values important to the GC system, especially for Universal Group caching in 2003.

Finding Public Folders

Just as you must configure virtual directories for mailboxes, you must also configure virtual directories for each of the public folder trees that are to be accessible over HTTP through the front-end server.
When you install Exchange, a virtual directory called "public" is created under the default Exchange HTTP virtual server to allow access to the default (MAPI-accessible) public folder tree. When you create other public folder trees (for example, to host applications), you must also create virtual directories in Exchange System Manager to expose these trees over HTTP. Identical virtual directories must exist on each front-end server and on all back-end servers that host the public folder tree.
A request made to a URL in a public folder tree is handled differently when accessing the default (or MAPI-accessible) public folder tree than when accessing general-purpose public folders (also known as application Top-Level Hierarchies [TLH], or non-MAPI TLHs).
In both cases the goal for accessing public folders is twofold:
• For availability If data exists in an Exchange 2000 Server or Exchange Server 2003 public folder somewhere in the Exchange organization and is accessible over HTTP, it is available to the user.
• For consistency As long as the server is available and the user is authenticated, the same public folder server services every request from that user. For authenticated users, ensuring that they go to the same public folder server means that they see the same data every time that they access the public folder trees through the front-end server (including status of read and unread messages, which is stored on individual servers and is not replicated between public folder servers). The fact that users always reach the same back-end server is also important for server-based applications that maintain session state, such as some built with Active Server Pages (ASP).
Public Folder Referrals
In Exchange, you can configure public folder replication on a per-folder basis. The actual public folder tree hierarchy is available on all Exchange public folder servers in the organization, but the contents of each folder may not be. This information is not stored in Active Directory but is maintained as a property on each folder in the public folder store. Therefore, special handling is required when the back-end server selected by the front-end server does not contain the contents of the folder requested by the client.
The following figure illustrates how public folder referrals travel through a front-end server.

1. An HTTP client authenticates against the front-end server and requests /public/PublicFolder2.
2. The front-end server authenticates the user against Active Directory and requests the location of the user's default public folder store.
3. Active Directory indicates to the front-end server that the user's default public folder store is on Server1.
4. The front-end server sends the client request to Server1.
5. Server1 tells the front-end server that it does not have the contents of /public/PublicFolder2, but Server2 and Server3 do.
6. The front-end server performs a hashing algorithm against the list of servers with the content (in this case, Server2 and Server3). The results of the hash in this case turn out to be Server2, so the front-end server forwards the request to Server2.
Note:
A hashing algorithm applies a given number (in this case, the user's security token) and uses it to generate a position in a list so that the distribution of all possible inputs is even over the list.
7. Server2 returns the contents of /public/PublicFolder2 to the front-end server, which then sends the contents to the HTTP client.

Enabling the "Change Password" Feature

If you are using Outlook Web Access, you can enable the Change Password feature in IIS to:
• Alert users when their passwords expire.
• Enable users to use the Options button in Outlook Web Access to change their passwords.
Keep in mind that if you want to use the Change Password feature, you must also use SSL between clients and the front-end server to secure the password during transmission. Additionally, you must create a virtual directory named IISAdmPwd on the front-end server and back-end servers to handle the Change Password requests.
Note:
The only time you must require SSL on a back-end server is when you want users to be able to connect to the back-end server directly. Remember, however, that front-end servers cannot use SSL when connecting to back-end servers. Therefore, if you require SSL on the back-end server, ensure that you do not require SSL on the following directories so that front-end servers can still connect to them: Exchange, Public, ExchWeb, Exadmin, and any mailbox or public folder virtual roots.
For more information about how to configure the Change Password feature, see Microsoft Knowledge Base article 327134, "XCCC: HOW TO: Use the Change Password Feature in Outlook Web Access."
For more information about how to configure SSL, see Helping to Secure Communication: Client to Front-End Server.

Logging on to Outlook Web Access

Users can log on to Outlook Web Access using either implicit logon or explicit logon.
Implicit Logon
If the front-end server is configured to authenticate users, users can access their mailboxes by omitting the username from the request, and pointing their browser to their mailbox virtual directory. The usual URL is https:///exchange/. After authenticating the user, the authentication information is used to look up the mailbox associated with the user in Active Directory and the back-end server on which the mailbox is located. The URL is updated with the user name and sent to the correct back-end server. This is known as implicit logon. Implicit logon is useful only for logging on to Outlook Web Access; specialized HTTP clients generally do not use implicit logon.
Exchange 2000 Server SP3 and Exchange Server 2003
Implicit logon makes use of the SMTP domain specified on the HTTP virtual directory to identify the user. Therefore, users connecting to that virtual server must have an e-mail address in their list of SMTP proxy addresses on their object in Active Directory with the same domain.
Exchange Server 2003 SP1
Implicit logon no longer relies exclusively on the SMTP domain specified. All the user information can be gleaned from their logon. Users can use any mailbox Exchange virtual directory to access their e-mail messages.
Explicit Logon
There are a few URLs that users can use to connect to Outlook Web Access. The usual URL is https:///exchange//.Accessing Outlook Web Access using this URL is referred to as explicit logon.
Explicit logon must be used when the front-end server is not configured to authenticate users (for more information about authentication, see Authentication Mechanisms for HTTP) or when a user is attempting to access a mailbox that is not their own but to which they have access, for example, in the case of delegate users.
Exchange 2000 Server SP3 and Exchange Server 2003
When the front-end server receives an explicit logon request from a client, the user name is extracted from the URL and combined with the SMTP domain name associated with the virtual directory or virtual server to construct a fully qualified SMTP address. The front-end server looks up this address in Active Directory and determines which back-end server has the mailbox associated with the address. The front-end server then forwards the request to that back-end server, which processes the request and returns it back through the front-end server to the client.
Exchange Server 2003 SP1
The user can choose to override the SMTP domain configured on the mailbox virtual directory, by specifying the SMTP address in the URL itself. For example; https:///exchange/username@domain.com. If no SMTP domain is specified, the SMTP domain from the virtual directory will be used.
You can prevent specific users from accessing Outlook Web Access by disallowing the HTTP protocol for those users. To change a user's protocol settings, in Active Directory Users and Computers, use the Exchange Advanced tab in a user's properties.
Simplifying the Outlook Web Access URL
Users commonly request that a simpler URL be made available for accessing their mailbox. For detailed instructions on simplifying the Outlook Web Access URL, see How to Simplify the Outlook Web Access URL

Finding User Mailboxes

To provide access to mailbox folders through HTTP, you must have a virtual directory on both the Exchange front-end and back-end servers that points to the mailboxes.
Note:
User mailboxes cannot be stored on the front-end server.
When you install Exchange, a virtual directory named "Exchange" is created in the default virtual server. This directory points to the default SMTP domain for the Exchange organization. When you configure additional virtual directories on the front-end server through Exchange System Manager, you can select the SMTP domain name. In Exchange 2000 Server SP3 and Exchange Server 2003, users connecting to that virtual server must have an e-mail address in their list of SMTP proxy addresses on their object in Active Directory with the same domain. In Exchange Server 2003 SP1, users can override the SMTP domain by specifying the SMTP address in the URL (for explicit logon), or just use an implicit logon. For more information see "Logging on to Outlook Web Access" later in this topic.
In the dialog box where the SMTP domain is selected, the list of domains is a list of all domains for which there are recipient policies. Therefore, you might see duplicates in the list; it is not important which one you select.
When the front-end server detects a request to a location in the mailbox store (based on the setting of the virtual server or directory), it contacts an Active Directory global catalog server in the domain using Lightweight Directory Access Protocol (LDAP) and determines which back-end server contains the user's mailbox.

Supporting HTTP Access

Whether generated by a browser or a specialized client, HTTP requests from the client computer are sent to the front-end server. The front-end server uses Active Directory to determine which back-end server to proxy the request to.
After determining the appropriate back-end server, the front-end server forwards the request to the back-end server. Apart from specific header information that indicates the request was passed through a front-end server, the request is almost the same as the original request sent from the client. In particular, the HTTP host header, which matches the name of the front-end server to which the request was sent (meaning the hostname or fully qualified domain name that the user entered in the browser), remains unchanged. The front-end server contacts the back-end server using the hostname of the back-end server (for example, backend1), but in the HTTP headers of the request, the front-end server sends the host header used by the client, for example, www.adatum.com. The host header setting ensures that the appropriate back-end Exchange virtual server handles the request. For more information about configuring virtual servers on a back-end server, see Configuring a Back-End Server.
For HTTP requests, the front-end server always contacts the back-end server over TCP port 80 (the default HTTP port), regardless of whether the client contacted the front-end server through port 80 or 443 (the SSL port). This means that:
• HTTP virtual servers on the Exchange front-end server can listen only on port 80 (HTTP) or 443 (HTTPS).
Note:
No other ports other than port 80 and port 443 can be used for HTTP virtual servers on the Exchange front-end servers.
• SSL encryption is never used between the front-end and back-end servers, although the client should use it to communicate with the front-end server.
• HTTP virtual servers that differentiate themselves from other servers only by port number are not supported in a front-end and back-end topology. For example, if a back-end server has an HTTP virtual server listening on port 8080, a client can access that back-end server only if the client is pointed directly to the back-end server (for example, http://backend1:8080/data). A client connecting to the front-end server cannot access this data.
The back-end server processes the HTTP request from the front-end normally, and the response is sent unchanged through the front-end server back to the client. This whole process is not visible to the client, which just interacts with the front-end server. The client is unaware of how the request was handled internally.

Running SMTP for POP and IMAP Clients

POP and IMAP protocols are used only for receiving mail; you must configure SMTP on the front-end server so that POP and IMAP clients can submit mail. You do not have to run SMTP on the Exchange front-end server. Instead, you can use another server as a dedicated SMTP gateway.
Important:
To run SMTP on the front-end server and enable it to accept inbound mail (mail for your domains), you must mount a mailbox store on the front-end server. This mailbox store must not contain any mailboxes. You must mount a mailbox store on the front-end server because any non-delivery reports (NDRs) must be routed through the mailbox store for formatting.
To configure SMTP so that POP and IMAP clients can submit mail to external domains, you must allow relaying.
By default, Exchange allows relaying only from authenticated clients. It is recommended that you keep this default. Clients such as Microsoft Outlook Express 6.0 and Microsoft® Office Outlook® 2003, and previous versions of Outlook Express and Outlook support SMTP authentication in addition to Transport Layer Security (TLS) encryption.
You should not allow relaying in either of the following ways:
• You should not allow anonymous relaying to all IP addresses; if your front-end server is connected to the Internet, doing this allows anyone on the Internet to use your server to send mail.
• You should not allow relaying from specific client IP addresses. Even if you are familiar with the subnet from which clients send mail, the Internet environment makes it difficult to determine such a specific set of IP addresses.
Note:
If you want the front-end server to act as the bridgehead server between your company and the Internet, it is recommended that the server on the Internet that accepts mail for your domains has the ability to scan incoming messages for viruses.
Note:
For more information, see the Exchange technical guide, Exchange Server 2003 Transport and Routing Guide.

IMAP Access to Public Folders

When a non referral-enabled IMAP client connects to a back-end server, it can access only public folders that have a replica on the user's home server. To access public folders that have replicas on other servers, an IMAP client must be referral-enabled. A referral-enabled client issues special commands to an IMAP server to create a list of the public folders available to the client. When the client computer requests a public folder that does not have a local replica, the server responds to the client request with a referral URL that contains the name of the server that has the public folder. The referral-enabled IMAP client computer then creates a new connection to that server to retrieve the appropriate information.
In a front-end and back-end topology, however, the front-end server acts as a referral-enabled client, so IMAP clients connecting to the front-end server do not need to support referrals; the front-end server handles referrals for them. It transparently maps non referral-enabled client requests to their referral counterparts, making the entire list of public folders available to a non referral-enabled client. When the front-end server receives a referral response from the back-end server, it does not pass this response back to the client. Instead it follows the referral for the client and makes a connection to the appropriate back-end server that has the data. The back-end server then responds with the requested item, which the front-end server relays back to the client.

Authentication for POP and IMAP Clients

POP and IMAP e-mail clients send user and password information in clear text. If the front-end server is accessible from the Internet, you should configure SSL so that user authentication information and data is not passed over the Internet in clear text.

Supporting POP and IMAP Clients

When you use a front-end server, the names of the servers that host the mailboxes are hidden from the users. Client computers connect to one host name shared by the front-end servers. As a result, moving users between servers is transparent to the users and requires no reconfiguration of client computers.
To log on, a POP or IMAP client sends the front-end server a logon request that contains the name of the mailbox to be accessed. The front-end server authenticates the user and uses Active Directory to determine which back-end server contains the user's mailbox. The front-end server then proxies the logon request to the appropriate back-end server. The back-end server then sends the results of the logon operation back to the front-end server, which returns the results of the operation back to the client. Subsequent POP or IMAP commands are similarly handled.
Note:
SMTP must be available to allow POP and IMAP clients to submit e-mail. You can install SMTP on the front-end server or set up a separate SMTP server. E-mail submission through SMTP on the front-end server works the same as it does on any other server running Exchange. For more information about how to configure SMTP on a front-end server, see Configuring Exchange Front-End Servers.

System Attendant on Front-End Servers

By default, Exchange System Attendant no longer requires RPCs when it runs on a front-end server. The components of System Attendant that use RPCs are no longer loaded on front-end servers; therefore, these components are disabled when you designate a server as a front-end server. The following list briefly describes these components:
• DSProxy
The DSProxy service refers MAPI clients (such as Microsoft® Office Outlook® 2002) to global catalog servers for global address list lookups. DSProxy also allows MAPI clients with older versions of Outlook to access Active Directory. DSProxy no longer runs on front-end servers; therefore, the front-end server can no longer determine which back-end server contains a MAPI client's mailbox. As a result, you cannot point a MAPI client to the front-end server to determine the user's back-end server and then route the request to the appropriate server.
Note:
To enable DSProxy on the front-end server for routing MAPI client requests, install Exchange 2000 Server Service Pack 3 (SP3) and create the registry key described in Microsoft Knowledge Base article 319175, "XADM: You Cannot Perform a Check Names Query Against a Front-End Exchange Computer." Note that to receive these referrals, the client must have RPC access to the front-end server. Additionally, the front-end server must have RPC access to domain controllers.
• Recipient Update Service
The Recipient Update Service updates recipients in the directory to match address lists or recipient proxy policies. The Recipient Update Service no longer runs on front-end servers, so be sure that none of your front-end servers are designated to run the Recipient Update Service. To do this, in Exchange System Manager, under Recipients, check the properties of each Recipient Update Service and ensure that no front-end servers are named in the Exchange server field.
• Offline Address Book Generation (OABGen)
OABGen creates the offline address book. Without the OABGen service, front-end servers no longer generate offline address books.
• Group Polling
System Attendant uses group polling to ensure that the local computer remains a member of the Domain Exchange Servers group. System Attendant polls the Domain Exchange Servers group and adds the local computer back to the group if it is no longer a member. Front-end servers no longer perform this function.
• Mailbox Management
The Mailbox Management service starts and stops the mailbox cleanup process according to the settings defined in Recipient Policies. Mailbox Management no longer runs on front-end servers.
• Free/Busy (madfb.dll)
The free/busy service manages user schedules. This service no longer runs on front-end servers.

Dependency on DSAccess

DSAccess is a shared Exchange Server component that accesses and stores directory information in a cache. DSAccess dynamically detects the directory servers that other Exchange components should contact, based on criteria such as Active Directory site configuration and Active Directory server availability. Exchange front-end servers use DSAccess to determine which server contains a particular user's mailbox, the Simple Mail Transfer Protocol (SMTP) addresses that exist for a user object, the servers that contain public folder stores, and so on.
DSAccess uses Lightweight Directory Access Protocol (LDAP) for most operations. However, DSAccess still uses RPCs to call the NetLogon service for each domain controller and global catalog server that it discovers.
If you put a front-end server in a perimeter network where you want to restrict RPC traffic between the perimeter network and the corporate network to specific services only, the NetLogon RPC from DSAccess to domain controller and global catalog servers may fail. If this occurs, DSAccess determines that RPC connectivity is just blocked, and that the servers are still available. However, DSAccess continues to send the NetLogon RPC, which may affect performance.
To stop DSAccess from doing the NetLogon RPC check, you can create a registry key. For more information about optimizing DSAccess in a perimeter network, see Configuring DSAccess for Perimeter Networks.

Remote Procedure Calls in a Perimeter Network

If you decide to situate your Exchange front-end servers in a perimeter network, be aware that remote procedure calls (RPCs) are used to access Active Directory.
Note:
It is recommended that you use an advanced firewall server (such as ISA Server) instead of the front-end server in the perimeter network. For more information, see Advanced Firewall in a Perimeter Network.
Remote Procedure Calls are used by Internet Information Services (IIS) to authenticate clients on the front-end server.

Integration with Internet Information Services

Exchange stores configuration information in Active Directory® directory service, whereas Internet Information Services (IIS) stores configuration information in the metabase. The metabase is a local configuration database shared by the protocols that IIS supports. The Exchange System Attendant service regularly replicates relevant configuration changes made in Active Directory through Exchange System Manager to the metabase. You can tell when the configuration replication has occurred by looking for entries in Event Viewer from the metabase update service (MSExchangeMU). To view MSExchangeMU events, in the server's properties, on the Diagnostics Logging tab, set the MSExchangeMU logging level to Minimum or greater.

Front-End and Back-End Topology Advantages

How a Front-End and Back-End Topology Works
Although the general functionality of the front-end server is to proxy requests to the correct back-end servers on behalf of the client computers, the exact functionality of the front-end server depends on the protocol and the action being performed.
This section discusses the Windows® and Microsoft Exchange Server components that are essential to understanding how front-end and back-end topology works. Make sure that you understand how these components function in a front-end and back-end topology and assess whether the modifications will affect your organization.
This section also explains how front-end and back-end servers support the various client protocols.

Front-End and Back-End Topology Advantages

The front-end and back-end server topology should be used for multiple-server organizations that provide e-mail access to their employees over the Internet. Additionally, organizations that use Microsoft® Office Outlook® Web Access, POP, IMAP, and RPC over HTTP on their internal network can also benefit from a front-end and back-end server topology.
Single namespace
The primary advantage of the front-end and back-end server architecture is the ability to expose a single, consistent namespace. You can define a single namespace for users to access their mailboxes (for example, https://mail for Outlook Web Access). Without a front-end server, each user must know the name of the server that stores their mailbox. This complicates administration and compromises flexibility, because every time your organization grows or changes and you move some or all mailboxes to another server, you must inform the users.
With a single namespace, users can use the same URL or POP and IMAP client configuration, even if you add or remove servers or move mailboxes from server to server. Additionally, creating a single namespace ensures that HTTPS, POP, or IMAP access remains scalable as your organization grows. Finally, a single namespace reduces the number of server certificates required for SSL encryption because clients are using SSL to the same servers and using the same namespace.
Offloads SSL Encryption and Decryption
Clients such as Microsoft Office Outlook® 2003 or Outlook Web Access that access your Exchange servers from the Internet should use Secure Sockets Layer (SSL) to connect to their Exchange servers to protect the traffic from interception. However, processing SSL traffic can be a significant overhead for a server. The front-end and back-end architecture allows the front-end to handle the SSL encryption, freeing up the processor on the back-end Exchange servers to allow for increased overall e-mail performance. Additional improvements can be made using SSL accelerators or offloading SSL encryption to advanced firewalls (such as ISA 2000 with Service Pack 1 and Feature Pack 1).
Security
You can position the front-end server as the single point of access on or behind an Internet firewall that is configured to allow only traffic to the front-end from the Internet. Because the front-end server has no user information stored on it, it provides an additional layer of security for the organization. In addition, the front-end servers authenticate requests before proxying them, protecting the back-end servers from denial-of-service attacks.
Improved Public Folder Access and Features
A front-end Exchange server increases the robustness of accessing public folders, as it knows the state of back-end servers and can use multiple referrals to access public folder data. This includes system data such as calendar free/busy information. In addition, in Exchange Server 2003, a front-end Exchange server enables your users using Outlook Web Access to reply or forward to posts in public folders. Without a front-end server, public folder posts can be only read.
Increased IMAP Access to Public Folders
The IMAP protocol specification allows a server to refer a client to another server. Exchange supports this referral functionality in cases where a public folder store on a particular server does not contain the content requested and the client needs to be referred to another server. However, this requires a client that supports IMAP referrals, and most clients do not support referrals. (The University of Washington Pine client and toolkit is one example of a client that supports referrals.)
When a non referral-enabled IMAP client connects through a front-end server, the client can access the entire public folder hierarchy, as the front-end server itself will automatically handle any referrals. This makes the referral transparent to the client. For more information about non referral-enabled IMAP clients, see Request for Comments (RFC) 2221 and RFC 2193.
Multiple Protocols Supported
The front-end and back-end architecture supports RPC over HTTP, HTTP, POP, and IMAP. You can also install SMTP on the front-end server, although there are essentially no differences between SMTP on a front-end or back-end server.
Note:
The MAPI remote procedure call (RPC) protocol (that is used by Outlook on non- RPC over HTTP mode) is not proxied by the front-end server. Outlook has built-in support for handling situations where mailboxes are moved from one server to another or where content is not available on a server.

New Exchange Server 2003 Features for the Front-End and Back-End Architecture

Exchange Server 2003 builds on the front-end and back-end server architecture and adds new features and capabilities such as RPC over HTTP communication that enables users with Outlook 2003 clients to access their Exchange information from the Internet. Additionally, the standard version of Exchange Server 2003 enables you to configure a server as a front-end server.
Kerberos Authentication
New for Exchange Server 2003 is the ability for the Exchange front-end server to use Kerberos authentication for HTTP sessions between the front-end and its respective back-end servers. While the authentication is now using Kerberos, the session is still being sent using clear text. Therefore, if the network is public or the data is sensitive, it is recommended that you use Internet Protocol security (IPSec) to secure all communication between the Exchange front-end and back-end servers.
RPC over HTTP
With Exchange Server 2003 you can now use the Windows RPC over HTTP feature to enable users who are running Outlook 2003 to be able to access their corporate information from the Internet. Information about how to plan, deploy, and manage this new feature for Exchange is in Exchange Server 2003 RPC over HTTP Deployment Scenarios.
Exchange Server 2003 Editions
Exchange Server 2003 is available in two editions, Exchange Server 2003 Standard Edition and Exchange Server 2003 Enterprise Edition. You can configure either for use as a front-end server in a front-end and back-end server architecture.
Note:
Exchange 2000 Server can be used only as a back-end server in a front-end and back-end configuration. However, Exchange 2000 Enterprise Server can be used as a front-end server or a back-end server in a front-end and back-end configuration. For more information about the differences between Exchange 2000 Server and Exchange 2000 Enterprise Server, see Microsoft Knowledge Base article 296614, "Differences between Exchange 2000 Standard and Enterprise versions."
Forms-Based Authentication
Exchange Server 2003 includes a new authentication feature for your Outlook Web Access clients. For information about how to enable this feature, see Authentication Mechanisms for HTTP.
Outlook Web Access Version Support
To provide the new Exchange Server 2003 version of Outlook Web Access for users, Exchange Server 2003 must be installed on both the front-end server and the back-end server to which your users connect. When users connect to an Exchange 2003 front-end and back-end server, they are able to take advantage of the following features:
• Forms-based authentication
• Replying to and forwarding posts in a public folder through Outlook Web Access
• Integrated authentication between the front-end and back-end servers
Different combinations of Exchange Server 2003, Exchange 2000 Server, and Microsoft Exchange Server 5.5 determine the version of Outlook Web Access that your users can use. The following table lists the version of Outlook Web Access that users have access to, based on the versions of Exchange that are installed on the front-end and back-end servers.
Outlook Web Access versions available to users
Front-end server Back-end server Outlook Web Access version
Exchange 5.5 Exchange 5.5 Exchange 5.5
Exchange 5.5 Exchange 2000 Exchange 5.5
Exchange 5.5 Exchange 2003 Not supported
Exchange 2000 Exchange 5.5 Not supported
Exchange 2000 Exchange 2000 Exchange 2000
Exchange 2000 Exchange 2003 Not supported
Exchange 2003 Exchange 5.5 Not supported
Exchange 2003 Exchange 2000 Exchange 2000
Exchange 2003 Exchange 2003 Exchange 2003

The Exchange Server 2003 version and the Exchange 2000 Server version of Outlook Web Access are substantially different from the Exchange Server 5.5 version of Outlook Web Access. The Exchange Server 5.5 version of Outlook Web Access uses Active Server Pages (ASP) to communicate with an Exchange computer that uses Collaboration Data Objects (CDO) 1.2 and MAPI. The number of clients that can access the mailbox store at the same time is limited by the MAPI-based connection to the Exchange computer.
The Exchange Server 2003 version and the Exchange 2000 Server version of Outlook Web Access do not use MAPI to access the mailbox store, and they do not use ASP pages for client connections. Clients continue to connect to the Web Access Component through Hypertext Transfer Protocol (HTTP). However, the Internet Information Services (IIS) server that hosts the Outlook Web Access component uses the Microsoft Exchange Store service to provide access to the user's messaging functions. IIS receives Outlook Web Access client requests as a proxy for message traffic between a Web client and an Exchange 2003 server or an Exchange 2000 server. If the server contains the Exchange 2003 database, Outlook Web Access uses a high-speed channel to access the mailbox store. If the server is a front-end server, Outlook Web Access sends the request to a back-end server using HTTP.

All Recipient Update Service tasks

The Recipient Update Service is a sub process that runs under the System Attendant process. It carries several task of updating information on all the domains of a forest. This is a list of all tasks that the Recipient Update Service does, and it is divided into 4 categories.
Recipient Policy:
• Set the proxyAddresses for users based on Recipient Policies. It won’t set if the proxyAddresses were manually added
• Set other mail attributes, like targetAddress, textEncodedORAddress and mail.

Address List:
• Set the showInAddressBook attribute based on the Address Lists present. This attribute will define which objects appear on which Address List. It also need to “Resolve Names” on Outlook or other MAPI Client.

System Policy:
• Sets the homeMDB, homeMTA and/or msExchHomeServerName if at least one is present. It will not change any attribute if is already there.
• Sets the msExchMailboxGuid if not present.
• Sets the legacyExchangeDN if not present.
• Sets the displayName if not present.
• For Groups that have the hideDLMembership attribute equal to TRUE, it will added some Non-Canonical ACEs into the ACL of that group, to prevent people from seeing the membership of that group.

Miscellaneous:
• Sets the ACL on the “cn=Exchange,cn=System,dc=MyDomain” container to reflect administrative privileges given by the Exchange Delegation Wizard.
• Populate the members of the “All Exchange Servers” groups on each domain of the forest.

8. Additional reading

286356 XADM: Recipient Update Service Does Not Stamp Proxy Addresses
328738 XADM: How the Recipient Update Service Applies Recipient Policies

7. Were changes needed?

At the end of the evaluation process, if no changes are needed you'll see an 8160:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8160
Description:
No change required for CN=e2kuser7,CN=Users,DC=bilong,DC=test. DC=bilong,DC=test

In some cases you'll see the 8160 even when it seems clear that changes should have been made. For instance, you may be looking at a recipient with no proxy addresses at all. You see 8130 events indicating that recipient policies match the user, yet the evaluation process logs this event indicating no changes are needed. This behavior is typical of a situation where a proxy generator has failed to load. See KB:286356 for more details on this problem.

If changes were made, you should see 3 events:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8039
Description:
Completed the transaction...
dn:
changetype: Modify
showInAddressBook:add:CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=Microsoft,CN=Mic...
: CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Cont...
mail:TestUser1@Site1.Microsoft.com
textEncodedORAddress:c=US;a= ;p=Microsoft;o=Site1;s=User1;g=Test;
proxyAddresses:X400:c=US;a= ;p=Microsoft;o=Site1;s=User1;g=Test;
: SMTP:TestUser1@Site1.Microsoft.com
: MS:MICROSOFT/SITE1/TESTUSER1
: CCMAIL:User1, Test at Site1
: smtp:TestUser1@secondary.com
msExchPoliciesIncluded:add:{14FE313C-34F5-41DC-8361-D58A46A5260A},{3B6813EC-CE89-42BA-9442-D87D4AA30DBC}
: {14FE313C-34F5-41DC-8361-D58A46A5260A},{26491CFC-9E50-4857-861B-0CB8DF22B5D7}
msExchUserAccountControl:0
msExchALObjectVersion:49
objectGUID:EDC7EA535F006845892C30A34F038549
-
DC=bilong,DC=test

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8035
Description:
Successfully modified entry 'CN=TestUser1,CN=Users,DC=bilong,DC=test' on directory bilongexch1.bilong.test. DC=bilong,DC=test

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8167
Description:
Modified the object: 'CN=TestUser1,CN=Users,DC=bilong,DC=test'. DC=bilong,DC=test

Finally, at the end of the evaluation of this recipient, you'll get two more events:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8133
Description:
Calculations complete on 'CN=TestUser1,CN=Users,DC=bilong,DC=test'. DC=bilong,DC=test

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8162
Description:
Thread #12b8: waiting for next Address List transaction. DC=bilong,DC=test

6. Proxy generation

On Exchange 2003, with proxy generation logging (Diagnostics Logging > MSExchangeSA > Proxy Generation) turned up you will see an event 3006:

Event Type: Information
Event Source: MSExchangeSA
Event Category: Proxy Generation
Event ID: 3006
Description:
Policy provider instance processing recipient.
Recipient DN: CN=e2kuser7,CN=Users,DC=bilong,DC=test
Current recipient proxies:
X500:/O=Microsoft/OU=Site1/cn=Recipients/cn=e2kuser7
smtp:e2kuser7@secondary.com
CCMAIL:e2kuser7 at Site1
MS:MICROSOFT/SITE1/E2KUSER7
SMTP:e2kuser7@Site1.Microsoft.com
X400:c=US;a= ;p=Microsoft;o=Site1;s=e2kuser7;
Applicable policies:
CN=Default Policy,CN=Recipient Policies,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=bilong,DC=test
CN=Site1,CN=Recipient Policies,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=bilong,DC=test
Chosen policy: CN=Site1,CN=Recipient Policies,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=bilong,DC=test
Proxies of chosen policy:
smtp:@secondary.com
X400:c=US;a= ;p=Microsoft;o=Site1;
SMTP:@Site1.Microsoft.com
MS:MICROSOFT/SITE1
CCMAIL: at Site1
Proxies in change list:
Proxies to generate:
Conflicts during generation:
Proxies generated:
Proxies written to recipient:

This event will give you more insight as to the decisions made in the proxy generation step, as well as a nice summary of the applicable policies. This can save you the work of reading through the 8130 events.

5. Which policies match the user?

If you got this far, then you know that the RUS queried for the changes, and the query returned the expected result. The next question is what happened when the RUS processed that user.

When the RUS picks up one of the objects queued for processing, you'll see this event:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8163
Description:
Thread #12b8: received next Address List Transaction. DC=bilong,DC=test

After that the RUS begins evaluating the object against each address list and policy. Each evaluation generates an event 8129:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8129
Description:
Evaluating directory object 'CN=e2kuser7,CN=Users,DC=bilong,DC=test' against address list 'CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=bilong,DC=test' rule '(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))'. DC=bilong,DC=test

If the address list or policy matches the object, you'll also get an 8130:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8130
Description:
'CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=bilong,DC=test' added to 'CN=e2kuser7,CN=Users,DC=bilong,DC=test'. DC=bilong,DC=test

By reading the 8129 and 8130 events, you can determine which policies and address lists the RUS determined match the user. Note that just because you see an 8130 for more than one recipient policy does not mean that multiple policies will be applied to the user. Out of all the matching policies, the policy with the highest priority is the only one that will affect this recipient. Address lists, on the other hand, are cumulative. All matching address lists will be added to the recipient.

In some cases, the RUS will have to query the DC to see if a policy applies. In that case you may see a series of events like this:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8129
Description:
Evaluating directory object 'CN=e2kuser7,CN=Users,DC=bilong,DC=test' against address list 'CN=NewPolicy,CN=Recipient Policies,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=bilong,DC=test' rule '(&(extensionAttribute1=mySpecialValue))'. DC=bilong,DC=test

Event Type: Information
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8011
Description:
Searching directory bilongexch1.bilong.test at base '' using filter '(&(extensionAttribute1=mySpecialValue))' and requesting attributes ObjectClass; ReplPropertyMetaData. DC=bilong,DC=test

Event Type: Information
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8012
Description:
Search of directory bilongexch1.bilong.test at base '' returned 0 objects. DC=bilong,DC=test

In order to determine if this policy matched the user, the RUS issued a search against the DC using the objectGUID of the user as the base of the search and the filter from the policy as the filter. In this case the search returned 0 results, which tells the RUS that the policy does not match this user.

So by reading the 8130 events, you can note all 8130 events that correspond to recipient policies. Then, out of each recipient policy shown in an 8130, you can identify the one among them that has a higher priority than all the others. That is the policy which the RUS should generate addresses for, assuming it's appropriate for the RUS to generate addresses for the given recipient. For more information on how the RUS decides to generate addresses, see KB:328738.

4. Did the query return results?

If you found an 8011 that shows a search for a range of USNs including your test user, the next question is did the search return any results. Just after the 8011 you should find an 8012:

Event Type: Information
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8012
Description:
Search of directory bilongexch1.bilong.test at base 'DC=bilong,DC=test' returned 16 objects.

If you do not find an 8012 event corresponding to the 8011, then Exchange did not see a response to that search. Typically this would indicate a network problem and cause the RUS to hang at that point. After that you usually do not see any more 8011 queries against the root of the domain, because the RUS continues to wait for a response to this search. If you are seeing this behavior repeatedly, it's best to get a Netmon trace capturing the behavior so the network problem can be identified.

If the search returned 0 objects, then the Exchange server computer account did not have permissions to see that user object. These permissions come from the Exchange Enterprise Servers group, which is granted permissions at the root of the domain when setup /domainprep is run. If these permissions are changed, or if inheritance on a subcontainer is removed, this can prevent Exchange from seeing the user. Also, the Exchange Enterprise Servers group for that domain should contain the Exchange Domain Servers groups for all the other domains, and one of the Exchange Domain Servers groups should contain the Exchange server responsible for this RUS. If this chain of membership has been broken, that can also keep the Exchange server from seeing the user.

If the search returns more than 20 objects, you will see more than one 8012 event. The RUS uses a page size of 20 for this search, so the results are returned in batches of 20. Expect to see an 8012 for every 20 objects returned.

If the search did return some objects, the events following the 8012 should list the objects that are being queued for processing:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8175
Description:
Processing change to 'CN=e2kuser7,CN=Users,DC=bilong,DC=test'.

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8134
Description:
Queuing request to process 'CN=e2kuser7,CN=Users,DC=bilong,DC=test'.

By examining the 8175 and 8134 events following the 8012, you can determine if the user you're interested in was returned in the search. If the user in question was not returned, this would indicate a permissions problem as noted above. When the RUS is done queuing changes to process, you'll see:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8169
Description:
Retrieved all directory changes under: 'DC=bilong,DC=test'.

3. How to determine if a Rebuild was run

One way to check for a Rebuild is to use the repadmin tool from the Windows 2000 Support Tools. Use ADSI Edit or LDP to get the distinguishedName of the RUS you are troubleshooting. Then, from a command line, run:

repadmin /showmeta "" >rusmeta.txt

The resulting text file will contain a list of properties on the RUS object. Find the line corresponding to the msExchDoFullReplication property:

298589 Default-First-Site-Name\BILONGEXCH1 298589 2004-06-29 17:10:59 2 msExchDoFullReplication

When an admin chooses Rebuild, msExchDoFullReplication is set to TRUE, and the RUS later sets it to FALSE after the Rebuild kicks off. By looking at the timestamp shown in the repadmin output, you can see when this attribute was last changed, and thus when a Rebuild was last run.

Another way to check for a Rebuild is to turn down the diagnostics logging on everything but Address List Synchronization, and leave Address List Synchronization at Medium. Then, watch the application log for the following events. When a Rebuild is initiated, event ID 8329 is logged:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8329
Description:
The Recipient Update Service is starting a rebuild of DC=bilong,DC=test

Then, about every 10% of the way through the entire range of USNs, the RUS will report the progress of the Rebuild in event ID 8332:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8332
Description:
The Recipient Update Service has started to export a block of entries from DC=bilong,DC=test, beginning at USN 1. It will finish processing the directory when it reaches USN 298599

When the Rebuild completes, the RUS will log an 8330:

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8330
Description:
The Recipient Update Service has completed the rebuild of DC=bilong,DC=test

Note that running a Rebuild usually is not useful for troubleshooting. The only difference between a Rebuild and an Update Now is that Rebuild causes the RUS to start over from a USN of 1. Update Now starts from the highest USN last recorded by the RUS, which is stored in the msExchServer1HighestUSN property on the RUS object in the Active Directory. So if the RUS is not working as expected against new or modified objects (the objects that would be touched by an Update Now), running a Rebuild will not help. Because of the time it can take for a Rebuild to complete in a large environment, carefully consider how much time it will take to resume normal RUS operation before you choose to do a Rebuild. Once a Rebuild has started, you must wait for the RUS to catch up before you can do any useful troubleshooting against new and modified objects. For more information on how the RUS queries for changes, see KB:328738.

2. Is the RUS querying for changes?

First you should determine if the RUS is even looking for recipients to process. Based on the schedule, or when Update Now is chosen, the RUS will query the domain for any new or modified objects. The first step in troubleshooting a RUS that's not stamping is to verify that it's checking for changes at all.

In ADSI Edit or LDP, connect to the DC that the RUS points to, and find your test user. Look at the USNChanged attribute and make a note of the value.

Next, open up the application event log on the Exchange server responsible for the RUS. Go to View->Find. For Event ID put 8011. For Description put "Base 'DC" (without the enclosing quotes). This will take you to the most recent search for changes against the domain naming context:

Event Type: Information
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8011
Description:
Searching directory bilongexch1.bilong.test at base 'DC=bilong,DC=test' using filter '(&(USNChanged>=273870)(uSNChanged<=298312)((objectclass=*)))' and requesting attributes distinguishedName; objectGUID; LegacyExchangeDN; msExchADCGlobalNames; ObjectSID; ObjectClass; objectCategory; displayName; msExchHideFromAddressLists; hideDLMembership; ntsecuritydescriptor; showInAdvancedViewOnly; msExchALObjectVersion; showInAddressBook; msExchPolicyEnabled; givenName; sn; cn; mailNickname; targetAddress; initials; proxyAddresses; mail; textEncodedORAddress; msExchHomeServerName; msExchExpansionServerName; msExchCustomProxyAddresses; msExchPoliciesIncluded; msExchPoliciesExcluded; replPropertyMetaData; replicatedObjectVersion; ReplicationSignature; WhenChanged; WhenCreated; USNchanged; USNcreated; ObjectVersion; isDeleted; homeMDB; homeMTA; msExchMailboxGuid; msExchMailboxSecurityDescriptor; msExchResourceGUID; UserAccountControl; msExchUserAccountControl.

Here you can see the RUS is searching for any objects with a USNChanged value between 273870 and 298312. You may notice that there are many other events 8011 in the application log that contain different searches. These are generated by many different operations. For the purpose of troubleshooting the stamping of users, though, the only 8011 events we are interested in are the ones where the base of the search is the domain in question. This is why it is useful to use Find to skip directly to an 8011 event that contains the text "Base 'DC" - this will take you directly to a search against a domain and skip over the rest of the 8011 events. If you have RUS's for different domains running on the same Exchange server, you may want to include the entire name of the domain in the Description portion of the Find window, so you can skip over any 8011 events for other domain RUS's.

If the user you've identified has a USNChanged value higher than the range of USNs in this event, then the RUS has not yet queried for that user. If the USNChanged on your user is much greater than the USNs currently being processed by the RUS, that's an indication that the RUS has fallen behind and is still catching up to the latest changes. One common reason for this is that a Rebuild was run. When you choose Rebuild, the RUS starts over from a USNChanged of 1 and queries for all objects in the domain. In a large domain, it can take hours or in some cases days for the RUS to process all the objects and catch up after running a Rebuild.

If the user you've identified has a USNChanged value lower than the range of USNs in this event, then this RUS has already passed that user. In that case, continue to search back through the application log until you find the 8011 that contains the range of USNs that includes the user in question. If you can not find it, another option is to make another change to the user. Any change to the object, even just changing the description, will cause the USNChanged to be bumped up to the latest value on the DC. So if the RUS has already gone past the user in question and you can not find the associated 8011, just make a change to the user and note the new USNChanged. Then watch the app log for the next 8011, which should include the USN of the user you just updated.

If there is no 8011 with "Base 'DC" in the description, then the domain RUS has not kicked off since logging was turned up, or if it has then the event wrapped out of the log. If a Rebuild is running it may be difficult to catch the 8011 against the domain root, since the application log will be filling up in a very short time during a Rebuild. See the next section for instructions on how to determine if a Rebuild is running.

If there is no 8011 and it does not appear that a Rebuild is running, check the schedule on the RUS. You can try choosing Update Now to get the RUS to kick off immediately, but do not start a Rebuild or Apply a policy. If you still see no 8011 querying the root of the domain within the next few minutes, it is likely that the RUS is hanging waiting for a response to a search against the DC.

When the RUS is hanging in an LDAP query, you can restart the System Attendant service to get it going again. However, the RUS may hang again unless the cause of the LDAP query hang is identified and corrected. This is usually caused by a network problem, and a Network Monitor capture of the query hanging will be needed to identify the cause.

If the 8011 does contain a range of USNChanged values that includes the USNChanged on the user, then you have answered the first question.

TROUBLESHOOTING THE RUS USING THE EVENT LOG

1. About troubleshooting with logging

Many RUS problems can be identified through careful examination of the application event log. It is useful to use event logging to troubleshoot the RUS for many different behaviors, such as when the RUS is not stamping objects at all, appears to be taking a long time, or is stamping them with the wrong proxy addresses. This article describes how to use the event log to identify these issues.

It is up to the domain RUS's for a given domain to stamp the mail-enabled objects in that domain naming context. Exchange allows you to create up to one domain RUS for every DC in the domain. If a domain has more than one domain RUS, the first step in the troubleshooting process is to choose one particular RUS to troubleshoot

To begin logging the events of interest to the application log, increase logging on the following objects to Maximum on the Exchange server responsible for the domain RUS you've chosen:

MSExchangeAL\LDAP Operations
MSExchangeAL\Address List Synchronization
MSExchangeSA\Proxy Generation (Exchange 2003 only)

Once you've chosen a domain RUS to look at and turned up logging on that Exchange server, the next step is to choose an object to test with, such as a user that has not been stamped yet in that domain. Once you know which RUS you're looking at, and which user you're expecting it to stamp, you can begin taking a closer look at what the RUS is doing.

Repeatedly choosing Rebuild on the RUS or Apply This Policy Now on a policy can complicate the troubleshooting process by causing the RUS to process large numbers of objects. This results in the application log quickly overwriting itself and makes it difficult to follow the sequence of events described above. When troubleshooting the RUS, it is best to avoid Rebuilding or Applying and instead focus on a single test user and use only Update Now to check for new and modified objects. After an Update Now, you can walk through the events described above to understand what the RUS is doing to a particular recipient.

Public Folder Replication

(Reference Internal KB Article – 842273)

Information to be retrieved from the customer:

· Get the Domain topology (No of DC/GC in the site)

· Get the Exchange Server topology (Between what Exchange Servers is the PF Replication not working)

· Check for third party software, Anti-virus in use (If yes, is it Exchange aware)

Preliminary Questions to be asked:

· The number of exchange servers to which the replication is not taking place.

· The versions of the source and target servers’ along with their service packs.

· Recent changes made on the above servers.

· Is the Hierarchy / Content being replicated or not replicating at all?

· Public folder replication would not take place if mail-flow is not working. So, this should be checked at the beginning.

Troubleshooting Steps to be performed

1. Determine whether the public folder store has an e-mail address

2. Check to make sure we have the Replica on the Public folder. (ESM – AG – First AG – Folders – Public Folders --- properties --- Replication)

3. To check the Default SMTP Virtual Server for (Smart Host) if any.

(The email has been sent to team members for Checking Default SMTP Virtual Server Settings by Arun Mysore to set the default settings on Default SMTP Virtual Server)

4. To check the Message tracking and then with diagnostics logging.

KB 246856 / KB 262162

Eg: Incase if the message is getting stuck in Pending Submission, then it is always the third party software which will be causing the problem. Also for other queues please refer related kb articles in VKB.

5. Increase diagnostics logging on public folder replication messages

• Replication AD Updates

• Replication Incoming Messages

• Replication Outgoing Messages

• Non-Delivery Reports

• Replication Backfill

• Replication General

6. Determine whether the replication messages that are sent from one computer are received by another computer

7. Determine whether only new or modified public folder information is replicated successfully

Event ID: 3018: This event is logged on the computer where the hierarchy change was made

3028: This event is logged on the computer that receives the outbound replication message

How to send replication status request messages in Exchange 2000 Server KB 321082

3020: This event is logged on the computer that sends the public folder content to another computer

3030: This event is logged on the computer that receives the outbound replication message

Update to send status request messages in Exchange 2000 Server KB 813629

3014: This event is logged on the computer that sends the backfill request message.

3024: This event is logged on the computer that receives the backfill request message

3017: This event is logged on the computer that sends the status replication message

3027: This event is logged on the computer that receives the status replication message

Try dismounting and re-mouting the public folder store to check if the event ids are being generated.