Forum Discussion

yb_100067's avatar
Icon for Nimbostratus rankNimbostratus
Feb 06, 2012

Exchange 2010 on LTM v11

Hi All,



I am deploying load balancing for Exchange 2010, using LTM v11 and I am having issues with the RPC service. In a nutshell, when I start the Outlook client and try to configure a profile, I get the following error:



" The action could not be completed. The connection to the Microsoft Exchange Server is not available. Outlook must be online to complete this action"



A tcpdump shows this error returning from the server:



"DCERP Bind_ack: call_id:1, NTLMSSP_CHALLENGE Provide rejection, reason: Abstract syntax not supported"



However, a direct connection to the pool member works fine.



I am using the default iApp to deploy OWA, ActiveSync, Autodiscover, RPC, POP and SMTP. I have a combined VIP for the main services and separate VIPs for RPC, POP and SMTP. I have 3 VIPs for RPC - basic port 135 and two static ports for mapi and address book virtual.



Following the implementation guidelines, I created new LAN/WAN profiles changing the timeout to 7200 and configure the option match across services for the RPC VS.



Through torubleshooting, I also noticed on the tcpdumps the server is passing the pool member's IP address and FQDN back to the client. I am taking this could rather be an issue on the Exchange configuration.



Has anyone seen this issue before?



Thank you,





3 Replies

  • Dayne_Miller_19's avatar
    Historic F5 Account
    Hi YB-

    Did you remember to create a Client Access Array on your Exchange servers? If you have more than one Client Access server *or* the published FQDN is different than the hostname of your single server, this is required. (Microsoft recommends you create a Client Access Array all the time.)

    We cover this briefly on page 20 of the v11 deployment guide and page 16 of the v10 guide.

    From the Exchange Management Shell, run this command to see what you've configured:


    In one of my test environments, for instance, I get these results:

    Name                Site                 Fqdn                           Members
    ----                ----                 ----                           -------
    Array1              Seattle             {SEACA00, SEACA01}

    This shows I have an array named 'Array1' that contains the servers SEACA00 and SEACA01. Importantly, it also shows the FQDN I've assigned; that's the FQDN that will get returned to the clients (rather than the hostname of either of the individual servers).

    If you haven't created a Client Access Array, do this:

    New-ClientAccessArray -Name "arrayname" -FQDN -Site "sitename"

    "arrayname" is any identifiable name you want to give the array; sitename is your AD site (you can only have one Client Access Array per AD site). Make sure to put your own FQDN in place of

    Then, since you have previously initialized your mailbox databases, you'll need to associate them with the array (any databases you add after creating the array will become part of it automatically). To associate the existing databases with the array, do this:

    Get-MailboxDatabase | Set-MailboxDatabase -RPCClientAccessServer

    Make sure you specify the same FQDN that you used when establishing the array.

    (I'm not sure if you need to restart any services at this point, but I don't believe you do.)

    And that should be it! Give it a try and let us know how it works for you.
  • Thanks for you reply Dayne. We did configure the CAS array, pointing it to the FQDN of the LTM's RPC VS. We also mapped the Mailbox DB to use the LTM's RPC VS via the FQDN. It does seem to pick that up as when I try to configure a new Outlook profile, if I type the real server name (one of the pool members FQDN) and a user account, it finds the user and changes the server name to be the FQDN of the VS. However, it will not connect using the FQDN that points to the RPC VS.



    What puzzles me is the fact that on the tcpdump DCERPC reject packet, the server replies to the client with its own FQDN and IP address. I am not too sure if this is the normal Exchange behaviour after having created the CAS array and CAS FQDN.
  • Hi Dayne & All,



    I have just found the source of the issue. Because we are using static ports on Exchange for RPC, MAPI and Address Book, the LTM iApp creates specific Virtuals for each service but maps all of them to the same pool, listening on port 135. Based on this post





    I found the solution and created specific pools and pool members for each of the services. RPC is now working fine.