When you add an SMTP Address to an existing user account, Exchange (and we are talking Exchange 2003 here) is responsible for determining if the address is unique within the organization. Specifically, this validation is handled by the Exchange System Attendant. Once you install the Exchange Management Tools on a computer, the Active Directory Users and Computers snap-in is extended to provide Exchange functions. Without the Exchange Management Tools, you cannot use Active Directory Users and Computers to add an SMTP Address, as the E-mail Addresses tab is not present. This same extension is responsible for initiating the validation process. Following is a breakdown of the process that occurs and the logic that is used to select an Exchange server.

1. The LDAP query that is used is a basic query that asks for a list of all Exchange servers as seen below.

Client to DC LDAP LDAP: Search Request, MessageID:346, BaseObject: cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=domain,dc=com, SearchScope: WholeSubtree, SearchAlias: neverDerefAliases Filter: (objectCategory=msExchExchangeServer)

2. The list of Exchange servers is then ordered based on the WhenCreated attribute on the Exchange Server object in the Configuration Container, with the oldest server being first in the list, and the newest server being last on the list.

3. If the Exchange Server responds to the ping, the client proceeds to the next step. If it does not respond to the ping, the next Exchange server will be selected and the ICMP test retried. If no servers respond to the ping, the operation will fail and an error such as the following will be received

An Exchange Server could not be found in the domain
Check if the Microsoft System Attendant service is running on the Exchange Server.
ID no: x10308a2
Microsoft Active Directory – Exchange Extension

4. This allows the client to enumerate the list of services and check if a particular service is running. In this case, we want to find out if the System Attendant service is running. You can see this happening by using Network Monitor (NetMon), or your favorite network sniffer. Here is what it looks like.

Client to Server SVCCTLSVCCTL: ROpenSCManagerW Request, Machine=\\EXCHANGE_SERVER Database=NULL Access=0x00000004
Server to Client SVCCTL SVCCTL: ROpenSCManagerW Response, Status = ERROR_SUCCESS
Client to Server SVCCTL SVCCTL: ROpenServiceW Request, ServiceName=MSExchangeSA DesiredAccess=0x00000004
Server to Client SVCCTL SVCCTL: ROpenServiceW Response, Status = ERROR_SUCCESS
Client to Server SVCCTL SVCCTL: RQueryServiceStatus Request
Server to Client SVCCTL SVCCTL: RQueryServiceStatus Response, State=0x00000004: SERVICE_RUNNING, Status = ERROR_SUCCESS
Client to Server SVCCTL SVCCTL: RCloseServiceHandle Request
Server to Client SVCCTL SVCCTL: RCloseServiceHandle Response, Status = ERROR_SUCCESS
Client to Server SVCCTL SVCCTL: RCloseServiceHandle Request
Server to Client SVCCTL SVCCTL: RCloseServiceHandle Response, Status = ERROR_SUCCESS

From the details of this NetMon trace, you can see that the client first requests access to the Service Control Manager, then queries for the service MSExchangeSA (bolded above), which is the Exchange System Attendant service. Finally, the client requests the status of the service to make sure that it is running (response bolded).

At this point, if the client receives a result of SERVICE_RUNNNG, it will proceed to the next step. If the service is not running, the client will go on to the next Exchange server in the list and start this process over again until it finds an Exchange server where the System Attendant service is running.

Note that if you have Windows 2003 SP1 installed, you must be logged on with an account that is a member of the Local Administrators group on the Exchange server, otherwise the query to the Service Control Manager will fail. Windows 2003 SP1 limits the ability of non-admins to access the Service Control Manager, and will prevent the discovery of running services.

If you are running into this issue, and you cannot log on as an administrator account, you can follow the instructions in this KB article to revert the permissions on the Service Control Manager back to how they were in RTM.

907460 Non-administrators cannot remotely access the Service Control Manager after you install Windows Server 2003 Service Pack 1
http://support.microsoft.com/default.aspx?scid=kb;EN-US;907460

5. Viewing the NetMon trace shows the following

Client to Server MSRPC MSRPC: c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Endpoint Mapper Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
Server to Client MSRPC MSRPC: c/o Bind Ack: Call=0x1 Assoc Grp=0x4DE1 Xmit=0x16D0 Recv=0x16D0
Client to Server EPM: Request: ept_map: NDR, unknown v16.1, RPC v5, 0.0.0.0:135 (0x87) [DCE endpoint resolution(135)]
Server to Client EPM EPM: Response: ept_map: NDR, unknown v16.1, RPC v5, 172.29.13.38:4560 (0x11D0) [4560]

Notice here the last response from the server (response in bold). The end of the string shows the port that the System Attendant is listening on, 0x11D0 in this example, which is port 4560 when converted from Hex to Decimal. The Endpoint Mapper dynamically assigns a random high port (1024-65535) to the service requested, and then tells the requesting client which port that is.

You can also statically map the port that the System Attendant is listening on by following this KB article.

270836 Exchange Server static port mappings
http://support.microsoft.com/default.aspx?scid=kb;EN-US;270836

6. Of note is that once you get to this point in the process, the client must be able to talk to the port that is specified. If the client attempts to contact the System Attendant using the specified port, and it does not receive a response, it will not query another Exchange server. Instead, you will see an RPC error message popup on the client computer, and adding the SMTP address will fail. This may occur if the Exchange server that the client computer queries is in a remote location, or if it is in a DMZ/segmented network with limited access. A common error message would be as shown below.

There are no more endpoints available from the endpoint mapper.
Facility: Win32
ID no: c00706d9
Microsoft Active Directory - Exchange Extension

To counteract problems such as this, KB article 895668 allows you to set a “preferred” Exchange server for Active Directory Users and Computers to use. Once the registry key has been set, the client computer will attempt to contact the System Attendant on that preferred Exchange server before using another server from the list.

895668 Active Directory Users and Computers may stop responding when you use Active Directory Users and Computers on a server that is not running Exchange Server 2003 to change a user's proxy address
http://support.microsoft.com/default.aspx?scid=kb;EN-US;895668

If you decide to implement this registry key, and you are not running Exchange 2003 SP2, then you will also need to implement a hotfix, which is mentioned in the article.

7. The client computer then initiates a TCP connection to a Global Catalog Server and issues an LDAP request for the specific smtp address you are trying to add.

Client to Server TCP TCP: Flags=.S......, SrcPort=3074, DstPort=Microsoft Global Catalog (LDAP)(3268), Len=0, Seq=846105024, Ack=0, Win=65535 (scale factor 0) = 65535
Server to Client TCP TCP: Flags=.S..A..., SrcPort=Microsoft Global Catalog (LDAP)(3268), DstPort=3074, Len=0, Seq=3019837164, Ack=846105025, Win=16384 (scale factor 0) = 16384
Client to Server TCP TCP: Flags=....A..., SrcPort=3074, DstPort=Microsoft Global Catalog (LDAP)(3268), Len=0, Seq=846105025, Ack=3019837165, Win=65535 (scale factor 0) = 65535
Client to Server LDAP LDAP: Bind Request, MessageID:2525, Version: 3
Server to Client LDAP LDAP: Bind Response, MessageID:2525, Status: Success
Client to Server LDAP LDAP: Search Request, MessageID:2527, BaseObject: NULL, SearchScope: WholeSubtree, SearchAlias: neverDerefAliases
Server to Client LDAP LDAP: search Result Done, MessageID:2527, Status: Success

Frame Details (some details omitted):

MSFTGC: Search Request, MessageID:442, BaseObject: NULL, SearchScope: WholeSubtree, SearchAlias: neverDerefAliases
SearchRequest: BaseDN: NULL, SearchScope: WholeSubtree, SearchAlias: neverDerefAliases
BaseObject: NULL
Scope: WholeSubtree
Filter: (proxyAddresses=SMTP:newaddress@domain.com)
Operator: Equality Match, 3(0x03)
Length: 42
MatchFilter: proxyAddresses=SMTP:newaddress@domain.com
Attributes: ( distinguishedName )
Control:

If you further look at the Frame details, you will see that an LDAP filter is also being used, which is proxyAddresses=SMTP:email@domain.com, and the request is searching for any matches to this filter (information bolded above). If the search result returned by the Global Catalog server indicates that there are no matches, we move to the next step, which is to make the actual modification. This is seen via an LDAP Modify request, as seen below.

Client to Server LDAP LDAP: Modify Request, MessageID:467
Server to Client LDAP LDAP: Modify Response, MessageID:467, Status: Success

Frame Details (some details omitted):

Ldap: Modify Request, MessageID:467
OperationHeader: Modify Request, 6(0x6)
ModifyRequest: Object: CN=UserName,CN=Users,DC=domain,DC=com
Object: CN=UserName,CN=Users,DC=domain,DC=com
Modification: <Replace> proxyAddresses =
Type: proxyAddresses
Attribute: SMTP:Primay@domain.com
Attribute: smtp:Secondary@domain.com
Attribute: smtp:newaddress@domain.com

The details of the frame indicate that the modification request is to replace the attribute ProxyAddresses, with the replacement value showing the new SMTP address you just added via Active Directory Users and Computers. Observing the Success response from the server indicates that the attribute was successfully modified to include the new smtp address.

Additional reading:

About 2 years ago, Fabio Pintos wrote a great blog post that also deals with smtp addresses. That post can be found in the archives here:
http://msexchangeteam.com/archive/2005/01/10/350132.aspx

- Ben Winzenz