Forum Discussion

juan_47813's avatar
juan_47813
Icon for Nimbostratus rankNimbostratus
May 10, 2012

Problem Outlook Exchange 2010

Hello.

 

First of all, sorry for my English.

 

We've a customer who has a Exchange 2010 service for his users: OWA, RPC, etc.

 

He has two CAS servers, using Windows NLB technology.

 

The idea is to migrate to a F5 load balanced service.

 

I've created all of services following the deployment guide (LTM v11).

 

All seemed to work fine, but in the end a few Outlook clients didn't work properly: the following message appears -> "Outlook is unable to connect to Exchange server" (something like that).

 

It's curious because it only fails from some determined PC's; some PC's in the same VLAN work fine. All outlook profiles you create in "the bad PC's" don't work. We changed the IP address and we obtained the same result.

 

Is it necessary to carry out additional changes of configuration on the CAS servers?

 

Anyone can help us, please?

 

Thank you all.

 

  • Hi Juan,

     

    Which particular service of Exchange is not working fine with these users???? is it that they open their outlook client and it dosent connect??? or is it outlook any where or else kindly mention. A quick test you may have to check out the certificates and let me know if u r using a chain certificate or single certificate???

     

     

    Regards,
  • juan's avatar
    juan
    Icon for Nimbostratus rankNimbostratus
    Hi Faisal.

     

    Thanks for your reply.

     

    "is it that they open their outlook client and it dosent connect???" Exactly, that's the problem.

     

    I'll describe better the situation:

     

    - We have two CAS servers, load balanced as Windows NLB

     

    - The idea is to use F5 LTM as load balancing technology.

     

    - I've set all Exchange services: OWA, Autodiscover, RPC, etc.. following the deployment guide: http://www.f5.com/pdf/deployment-guides/microsoft-exchange2010-ia

     

    pp-dg.pdf.

     

    - Everything seems to work fine, except that some clients using Outlook 2010 can not connect to exchange server.

     

    - The strange thing is that it always fails from the same computerd. From computers on the same VLAN, some fail and others do not.

     

    - We have logged the connections. When using the Outlook 2010 client, always begins with an RPC connection to port 135.

     

    - In the good and correct situation, there are connections to RPC ports 7575 and everything works fine.

     

    - In the bad situation, there are only attempts of RPC connections to port 135 and a message appears on the client, something like "Outlook can not connect to the Exchange server."

     

    We have seen the following message captured with Network Monitor "DCERPC174Bind_ack: call_id: 2 Fragment: Single Unknown result (3), reason: Local limit exceeded"

     

    Can you help us? Have you had any similar cases?

     

    Our suspicion is that the problem may be related to any further modification to be carried out in the CAS server configuration, something related to authentication and FQDN.

     

     

    When you ask me about certificate, do you mean certifacates installed in F5 or in CAS servers?

     

    Thank you

     

  • Hi Juan,

     

    First of all I believe you must have configured the RPC service to use any port not any particular port check this out. If it is already set to any port good if not then make it use any port. Secondly if this doesn't work create the RPC pool separately that is remove it from the iApp and create a VS seperately for RPC and even in that keep the port to any check this out and update.

     

     

    Regards,

     

     

  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    Juan

     

     

    I take it there's no obvious difference between the clients and they're all using the same version of Outlook? Also, on the bad PCs can you telnet to port 135 and 7575 to ensure this works?

     

     

    I take it if you go direct and bypass the f5 it works?

     

     

    I'm wondeing if it's a TCP issue and possibly keep-alives? Can you double check what your TCP profile is set up for it's Keep Alive settings, compared to the deployment guide?

     

     

    This askf5 article may help: http://support.f5.com/kb/en-us/solutions/public/8000/000/sol8049.html and this MS article: http://support.microsoft.com/kb/2535656

     

     

    Rgds

     

    N

     

     

  • juan's avatar
    juan
    Icon for Nimbostratus rankNimbostratus
    Hi Faisal.

     

    I don't understand why RPC service must use any port. We have configured three RPC ports: 135, 7575 and 7576. For most of the users, it works fine.

     

    But, as you say, one of our test has been create a separate Virtual Server, without specifying a port (any), and with members with any as port too, and with Port Translation as enabled and as disabled, without luck.

     

    We can't see any connections to that virtual server.

     

    Thank you very much.

     

     

  • Hi Juan,

     

    I think at this time its better to see your configuration rather then giving you any further options to check I believe if you create a VS with any port for RPC you must be able to see the connections. I wish to see your configuration if that is possible .

     

     

    Regards,
  • juan's avatar
    juan
    Icon for Nimbostratus rankNimbostratus
    Hi.

     

    Nathan: Yes, telnet to ports 135 and 7575 works fine.

     

    We've figured out the following thing: Between the clients and the F5 there is a cluster of Stonegate Firewalls. There is a rule that allow port 135 between the subnet of the clients and the F5 services subnet. If we change that rule to allow any port, it works!!. It's clear that it has to do with the MSRPC protocol, and specifically with the negotiation of the Transfer Syntax.

     

    Content of a "successful" packet:

     

    Frame: Number = 115, Captured Frame Length = 170, MediaType = ETHERNET

     

    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-E8-4C-84-41],SourceAddress:[00-50-56-B1-00-12]

     

    + Ipv4: Src = 10.33.4.216, Dest = 10.34.253.76, Next Protocol = TCP, Packet ID = 20945, Total IP Length = 156

     

    + Tcp: Flags=...AP..., SrcPort=2542, DstPort=DCE endpoint resolution(135), PayloadLen=116, Seq=1879818234 - 1879818350, Ack=3166776705, Win=64240 (scale factor 0x0) = 64240

     

    - Msrpc: c/o Bind: EPT(EPMP) UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0

     

    - Bind: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)

     

    RpcVers: 5 (0x5)

     

    RpcVersMinor: 0 (0x0)

     

    PType: 0x0B - Bind

     

    + PfcFlags: 3 (0x3)

     

    + PackedDrep: 0x10

     

    FragLength: 116 (0x74)

     

    AuthLength: 0 (0x0)

     

    CallId: 1 (0x1)

     

    MaxXmitFrag: 5840 (0x16D0)

     

    MaxRecvFrag: 5840 (0x16D0)

     

    AssocGroupId: 0 (0x0)

     

    - PContextElem:

     

    NContextElem: 2 (0x2)

     

    Reserved: 0 (0x0)

     

    Reserved2: 0 (0x0)

     

    - PContElem: 0x1

     

    PContId: 0 (0x0)

     

    NTransferSyn: 1 (0x1)

     

    Reserved: 0 (0x0)

     

    + AbstractSyntax: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)

     

    + TransferSyntaxes: {8A885D04-1CEB-11C9-9FE8-08002B104860} NDR

     

    - PContElem: 0x1

     

    PContId: 1 (0x1)

     

    NTransferSyn: 1 (0x1)

     

    Reserved: 0 (0x0)

     

    + AbstractSyntax: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)

     

    + TransferSyntaxes: {6CB71C2C-9812-4540-0100000000000000} BTFN - Security Context Multiplexing Supported

     

    AuthVerifier: 0x1

     

     

    Content of a "failed" packet:

     

    Frame: Number = 109, Captured Frame Length = 214, MediaType = ETHERNET

     

    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-E8-4C-84-41],SourceAddress:[00-50-56-B1-00-07]

     

    + Ipv4: Src = 10.33.4.99, Dest = 10.34.253.76, Next Protocol = TCP, Packet ID = 25893, Total IP Length = 200

     

    + Tcp: Flags=...AP..., SrcPort=49426, DstPort=DCE endpoint resolution(135), PayloadLen=160, Seq=884801470 - 884801630, Ack=1053259839, Win=256 (scale factor 0x8) = 65536

     

    - Msrpc: c/o Bind: EPT(EPMP) UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Call=0x2 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0

     

    - Bind: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)

     

    RpcVers: 5 (0x5)

     

    RpcVersMinor: 0 (0x0)

     

    PType: 0x0B - Bind

     

    + PfcFlags: 3 (0x3)

     

    + PackedDrep: 0x10

     

    FragLength: 160 (0xA0)

     

    AuthLength: 0 (0x0)

     

    CallId: 2 (0x2)

     

    MaxXmitFrag: 5840 (0x16D0)

     

    MaxRecvFrag: 5840 (0x16D0)

     

    AssocGroupId: 0 (0x0)

     

    - PContextElem:

     

    NContextElem: 3 (0x3)

     

    Reserved: 0 (0x0)

     

    Reserved2: 0 (0x0)

     

    - PContElem: 0x1

     

    PContId: 0 (0x0)

     

    NTransferSyn: 1 (0x1)

     

    Reserved: 0 (0x0)

     

    + AbstractSyntax: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)

     

    + TransferSyntaxes: {8A885D04-1CEB-11C9-9FE8-08002B104860} NDR

     

    - PContElem: 0x1

     

    PContId: 1 (0x1)

     

    NTransferSyn: 1 (0x1)

     

    Reserved: 0 (0x0)

     

    + AbstractSyntax: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)

     

    + TransferSyntaxes: {71710533-BEBA-4937-8319-B5DBEF9CCC36} NDR64

     

    - PContElem: 0x1

     

    PContId: 2 (0x2)

     

    NTransferSyn: 1 (0x1)

     

    Reserved: 0 (0x0)

     

    + AbstractSyntax: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)

     

    + TransferSyntaxes: {6CB71C2C-9812-4540-0300000000000000} BTFN - Security Context Multiplexing Supported

     

    AuthVerifier: 0x1

     

     

     

    It seems that when the client negotiates more types of transfer syntax, it fails. Is the F5 device modifying the packet? Any idea?

     

     

    Thank you very much.

     

     

    P.D.: When doing the test directly to the CAS server, it works, following the same way through the same firewall. F5 device is in a "one-arm" configuration, same internal and external VLAN.
  • Hi Juan,

     

    With your above reply it's gud to know that it finally worked for you but I got a lil bit confused with your reply. When you change the rule on the firewall to any any the clients who were facing problem before starts working???is it??? or they are again facing some problem as per the few lines mentioned towards the end of your description. Did u manage to find out which other ports are being used for communication.

     

     

    Regards,
  • juan's avatar
    juan
    Icon for Nimbostratus rankNimbostratus
    Hi everybody.

     

    In the end, it was due to a bug in the stonegate firewalls cluster, related to RPC protocol.

     

    Thank you very much.