You are currently offline, waiting for your internet to reconnect

Analyzing Exchange RPC traffic over TCP/IP

This article was previously published under Q159298
Retired KB Content Disclaimer
This article was written about products for which Microsoft no longer offers support. Therefore, this article is offered "as is" and will no longer be updated.
SUMMARY
With Exchange Server, you sometimes need to read and analyze sniffer traceswhen troubleshooting server-to-server communication along with client-to-server communication. This article addresses RPC sniffs between variousExchange Server services.
MORE INFORMATION

End Point Mapper

To understand the various stages an RPC Client goes through in order toconnect to a certain service, we must first understand how the RemoteProcedure Call (RPC) Service', otherwise known as the End Point Mapper,aids Exchange in its quest for service UUID numbers. The End Point Mapperperforms a variety of tasks but the one we are interested in is its abilityto tell us the port number a service we are looking for is listening on.UUID's can be generally categorized by their first 2 characters,for Microsoft Exchange v4.0 and v5.0:
A4 - STORE
F5 - DIRECTORY
E1 - ENDPOINT MAPPER
Let us take the following example where ExchangeA Server wants to send amessage to ExchangeB Server (ExchangeA and ExchangeB are in the same sitetherefore the communication mechanism is RPC and in this case it is overTCP/IP).

The first thing that ExchangeA must do is query ExchangeB's End PointMapper to find where its MTA is listening. The reason for this is the portnumber that each Exchange service listens on can change on subsequentstartups. The End Point Mapper is responsible for tracking which serviceis listening on which point. When an Exchange service starts, it registersitself with the End Point Mapper and asks the End Point Mapper to assign ita port number. The End Point Mapper is always listening on port 135 forTCP/IP and the End Point Mapper's UUID is (E1AF8308-5D1F-11C9-91A4-08002B14A0FA).

The following 11 frames show the complete conversation between ExchangeA(on port 3464) and ExchangeB's End Point Mapper (on port 135):
1. TCP: ....S., len:    4, seq: 562005063-562005066, ack:         0, win:   8192, src: 3464  dst:  1352. TCP: .A..S., len:    4, seq: 875064831-875064834, ack: 562005064, win:   8760, src:  135  dst: 34643. TCP: .A...., len:    0, seq: 562005064-562005064, ack: 875064832, win:   8760, src: 3464  dst:  1354. MSRPC: c/o RPC Bind:         UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA   call 0x54004E  assoc grp 0x0  xmit 0x16D0  recv 0x16D05. MSRPC: c/o RPC Bind Ack:     call 0x54004E  assoc grp 0x33CFA  xmit   0x16D0  recv 0x16D06. MSRPC: c/o RPC Request:      call 0x1  opnum 0x3  context 0x0  hint   0x847. MSRPC: c/o RPC Response:     call 0x1  context 0x0  hint 0x80  cancels   0x08. TCP: .A...F, len:    0, seq: 562005292-562005292, ack: 875065044, win:   8548, src: 3464  dst:  1359. TCP: .A...., len:    0, seq: 875065044-875065044, ack: 562005293, win:   8532, src:  135  dst: 346410. TCP: .A...F, len:    0, seq: 875065044-875065044, ack: 562005293, win:   8532, src:  135  dst: 346411. TCP: .A...., len:    0, seq: 562005293-562005293, ack: 875065045, win:   8548, src: 3464  dst:  135				

Frame 1 - ExchangeA sends a Syn packet to ExchangeB.

Frame 2 - ExchangeB acknowledges the packet with a SynAck packet.

Frame 3 - ExchangeA sends an acknowledge of the SynAck.We now have a TCP connection between ExchangeA and ExchangeB.

Frame 4 - ExchangeA is Binding to ExchangeB's End Point Mapper. We knowthis by the UUID number (E1AF8308-5D1F-11C9-91A4-08002B14A0FA) it issending the Bind to and also by the dst: port number.

Frame 5 - ExchangeB acknowledges the Bind with a BindAck.We now have an RPC connection between ExchangeA and ExchangeB's End PointMapper.

Frame 6 - ExchangeA sends an RPC Request of opnum 0x3 to ExchangeB alongwith the UUID of the service it is looking for (in this case it isExchangeB's MTA). This is to request the port number of the service withthe corresponding UUID.

Frame 7 - ExchangeB returns the port number that the service that matchesthis UUID is listening on. ExchangeA now has all the information it needsto find the MTA on ExchangeB.

Frames 8 through 11 - Closing down the TCP connection between ExchangeA andExchangeB.

Now that ExchangeA knows the port number it needs to connect to ExchangeB'sMTA. An important note here is the Exchange MTA does an RPC bind slightlydifferent than most RPC binds. It performs a two-way handshake, meaning,not only does ExchangeA have to bind to ExchangeB but ExchangeB must bindto ExchangeA before any messages can be sent. Therefore, you should see aBind followed by a BindAck then another Bind from the other server followedby another BindAck as illustrated below.
1. TCP: ....S., len:    4, seq: 562005113-562005116, ack:         0, win:   8192, src: 3470  dst: 47642. TCP: .A..S., len:    4, seq: 875064881-875064884, ack: 562005114, win:   8760, src: 4764  dst: 34703. TCP: .A...., len:    0, seq: 562005114-562005114, ack: 875064882, win:   8760, src: 3470  dst: 47644. MSRPC: c/o RPC Bind:         UUID 9E8EE830-4459-11CE-979B-00AA005FFEBE   call 0x1EBE80  assoc grp 0x0  xmit 0x16D0  recv 0x16D05. MSRPC: c/o RPC Bind Ack:     call 0x1EBE80  assoc grp 0x3150EAC1  xmit   0x16D0  recv 0x16D06. TCP: .AP..., len:  206, seq: 562005250-562005455, ack: 875064990, win:   8652, src: 3470  dst: 47647. MSRPC: c/o RPC Request:      call 0x1  opnum 0x0  context 0x0  hint   0x11E8. TCP: .A...., len:    0, seq: 875064990-875064990, ack: 562005792, win:    8082, src: 4764  dst: 34709. TCP: ....S., len:    4, seq: 875064951-875064954, ack:         0, win:    8192, src: 1969  dst: 173310. TCP: .A..S., len:    4, seq: 562005173-562005176, ack: 875064952, win:   8760, src: 1733  dst: 196911. TCP: .A...., len:    0, seq: 875064952-875064952, ack: 562005174, win:   8760, src: 1969  dst: 173312. MSRPC: c/o RPC Bind:         UUID 9E8EE830-4459-11CE-979B-00AA005FFEBE   call 0x6C645F65  assoc grp 0x0  xmit 0x16D0  recv 0x16D013. MSRPC: c/o RPC Bind Ack:     call 0x6C645F65  assoc grp 0x215D6F47   xmit 0x16D0  recv 0x16D014. TCP: .AP..., len:  192, seq: 875065087-875065278, ack: 562005282, win:   8652, src: 1969  dst: 173315. MSRPC: c/o RPC Request:      call 0x7DFE09C  opnum 0x1  context 0x0   hint 0x216. TCP: .A...., len:    0, seq: 562005282-562005282, ack: 875065335, win:   8377, src: 1733  dst: 196917. MSRPC: c/o RPC Response:     call 0x7DFE09C  context 0x0  hint 0x1C   cancels 0x018. MSRPC: c/o RPC Response:     call 0x1  context 0x0  hint 0x20  cancels   0x0				

Frames 1 through 3 - Once again our TCP three way handshake.

Frame 4 - ExchangeA MTA is binding to ExchangeB MTA.

Frame 5 - ExchangeB acknowledges the Bind with a BindAck.

Frame 6 -

Frame 7 - ExchangeA sends an RPC Request with opnum 0x0. An opnum 0x0 is anMtaBind call. This will trigger ExchangeB's MTA to issue a Bind toExchangeA as the MTA's need a two way connection.

Frame 8 - ExchangeB acknowledges it received Frame 7.

Framess 9 through 11 - Our TCP three way handshake initiated by ExchangeBthis time.

Frame 12 - ExchangeB MTA is binding to ExchangeA's MTA.

Frame 13 - ExchangeA acknowledges the Bind with a BindAck.

Frame 14 -

Frame 15 - ExchangeB sends an RPC Request with opnum 0x1. An opnum 0x1 is anMtaBindBack call. This is setting up the two way conversation the MTA's need.

Frame 16 - ExchangeA acknowledges it received Frame 15.

Frame 17 - ExchangeB's response to Frame 7.

Frame 18 - ExchangeA's response to Frame 15.

This illustrates the flow of an RPC connection. The example aboveillustrates specifically a typical connection between two MTA's. This samekind of conversation will happen between the other various ExchangeServices as well although the MTA is the only one that needs a two wayconversation to exchange information.

The information contained in this article uses the MTA for its examples. Animportant note is this same type of conversation will happen with any andall Exchange RPC communication over TCP/IP.
  1. The TCP three-way handshake will be established.

    The End Point Mapper is consulted in order to determine on which port the service wanted is listening.

    A Bind and BindAck between the two services will happen to establish RPC communication.

    Optional - A series of Requests and Responses with opnums will be issued.

    Optional - The RPC communication is ended.

    The TCP connection is broken with Fin packets.
  2. The End Point Mapper is consulted in order to determine on which port the service wanted is listening.

    A Bind and BindAck between the two services will happen to establish RPC communication.

    Optional - A series of Requests and Responses with opnums will be issued.

    Optional - The RPC communication is ended.

    The TCP connection is broken with Fin packets.
  3. A Bind and BindAck between the two services will happen to establish RPC communication.

    Optional - A series of Requests and Responses with opnums will be issued.

    Optional - The RPC communication is ended.

    The TCP connection is broken with Fin packets.
  4. Optional - A series of Requests and Responses with opnums will be issued.

    Optional - The RPC communication is ended.

    The TCP connection is broken with Fin packets.
  5. Optional - The RPC communication is ended.

    The TCP connection is broken with Fin packets.
  6. The TCP connection is broken with Fin packets.
When looking through sniffer traces of RPC communications, or any TCPcommunication, it is important that you are aware that multipleconversations can be occurring simultaneously. Do not assume that simplybecause a Request packet follows a BindAck packet that this Request camefrom the particular conversation you are interested in. A quick check ofthe destination and source ports with TCP will tell you if the packet youare looking at is part of the conversation you are interested or not. Ifthe destination and/or source port number is no the same as the portnumbers used in the TCP three way handshake, the packet you are looking atis part of a separate conversation.

A good display filter within Network Monitor, filtering on the destinationand source port numbers will serve as a great aide in ensuring the packetsyou are looking at do indeed belong to the conversation in question.

One other important note is this article addresses RPC over TCP only. Nomatter what the underlying protocol is, the RPC piece of this articleremains the same. For example RPC over IPX would work quite similarlyexcept the IPX communication would have to be established prior to RPC muchin the same way TCP must be established before RPC.
Netmon Network Monitor
Properties

Article ID: 159298 - Last Review: 10/28/2006 18:30:43 - Revision: 3.4

  • Microsoft Exchange Server 5.5 Standard Edition
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • kbnetwork kbusage KB159298
Feedback