none
Network Load Balancer & Remote Desktop Services

    Question

  • I installed the NLB Feature on 2 Remote Desktop Host servers. They converged successfully. I can ping the name of the RDS farm, and it resolves to the shared NLB cluster IP address - though, I set that in DNS. I can still RDP to the name of the farm from inside and outside of the network. User load is properly split between servers.

    However, NLB doesn't seem to be doing what it's designed to do. If I take a server off-line - i.e. shutting it down. Logins still cannot be processed when attempting to RDP using the farm name.

    There is SPARSE documentation on RDS Network Load Balancing. The very little stuff out there refers to Terminal Services and there's still no useful information.

    RDSH 1 (w/ NLB Feature - SVR08R2)
    RDSH 2 (w/ NLB Feature - SVR08R2)
    NLB Cluster "rdscluster.ourdomainname.com" (Added to DNS - can ping, resolves, and can RDP)

    I set the shared cluster IP as the default IP for reconnections in the RDSH servers - rather than the onboard NIC.

    RD Session Broker on Remote Desktop Gateway Server (SVR08R2)
    RD Farm name "tsfarm"

    The bottom line is I want a seamless experience - even when one system is off-line. Users won't know the difference.

    Friday, January 07, 2011 7:06 PM

Answers

  • I believe I've resolved the overlying problem which fixes all the issues I was having with NLB. VMWare doesn't like NLB in Unicast mode without changing several settings in the Virtual environment. VMWare documents the needed changes but also suggests using NLB in Multicast mode.

    Here's a VMWare KB article:
    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1556

    Essentially, for Unicast mode to work, VMWare needs the NLB nodes to be on the same ESX host - which ours were not - somewhat obviously - since we would want the user load split up between hosts. VMWare wants the ESX host configured to not send RARP packets when any of its virtual machines is powered on. Configuring this would prevent teaming failover protection - which we don't want.

    I opted to go with changing to Multicast mode (rebuilding the cluster) and instantly my issues were resolved - all of them.

    Users are logged into both servers - though not in the manner I would like - evenly distributed, one server can be powered down/taken off line, and users can still RDP to the farm and hit the other server, and there are no network errors and a loss of connectivity.

    Eventually, when done testing, we will move from virtual RDSH servers to physical boxes - so this may have all been just a 'learning experience'. :)
    • Marked as answer by JEPalm Wednesday, January 12, 2011 10:30 PM
    • Unmarked as answer by JEPalm Thursday, January 13, 2011 2:31 PM
    • Marked as answer by Alan ZhuModerator Friday, January 14, 2011 1:54 AM
    Wednesday, January 12, 2011 10:30 PM

All replies

  • hi Jayun, are you using RDCB (RD Sesssion Broker) to load balance or relying on NLB?

    What's the affinity set to on the NLB and ports that NLB listens for?

    Friday, January 07, 2011 7:25 PM
  • James,

    I am using RD Session Broker to split the user load/sessions between servers. I wanted to add the NLB feature to allow for logins to still process when one server in the RD Session Broker 'farm' is not online. From what I've read, I need NLB for that.

    On each host Affinity is set to 'Single' Ports are 0 to 65535 - though, I guess I really only need 3389 (?and 443 since some part of the RDP traffic is encrypted - maybe just to the Remote Gateway Server?) The ability to change these options is grayed out.

    On the cluster Affinity and Ports are set the same - but I can edit them.

    The 'Dedicated IP Address' in the NLB Manager properties is set to the local server IP - is that how it should be?

    Also:
    open NLB Manager, I get the message "Running NLB Manager on a system with all networks bound to NLB might not work as expected. If all interfaces are set to run NLB in "unicast" mode, NLB Manager will fail to connect to hosts."
    All my networks are bound to NLB and NLB is in "unicast" mode per the instructions from Microsoft to configure NLB.

    Friday, January 07, 2011 8:12 PM
  • Hi Jayun,

    From what I understand you use NLB as the initial loadbalancer and also use the RD Connection Broker for Broker and loadbalancing? If so, that could be cause of what you experience.

    When a user connections through the initial loadbalancing mechanism (NLB) it will be redirected to the RDSH server with the least load based on your NLB settings.

    The RDSH server then contacts the RD Connection Broker to find out whether this user has a existing (disconnected, idle or active session), if so, the session will be redirected to the RDSH server that holds that session.

    So far so good.

    But, if the RD Connection Broker has no record of a existing session it goes and finds the RDSH server that has the least amount of sessions itself. And this could lead to a scenario where the users ends up being redirected to a offline RDSG server. And thus the user is unable to connect.

    I would suggest using NLB as your loadbalancer and use RD Connection Broker only for the Broker functionality (not loadbalancing).

    You can accomplish this by disabling the following setting:

    Use RD Connection Broker load balancing
    Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\RD Connection Broker\

    Explanation:
    If you enable this policy setting, RD Connection Broker redirects users who do not have an existing session to the RD Session Host server in the farm with the fewest sessions. Redirection behavior for users with existing sessions is not affected. If the server is configured to use RD Connection Broker, users who have an existing session are redirected to the RD Session Host server where their session exists.

    If you disable this policy setting, users who do not have an existing session log on to the first RD Session Host server to which they connect.

    Kind regards,
    Freek Berson
    http://microsoftplatform.blogspot.com/

    Friday, January 07, 2011 11:11 PM
    Moderator
  • Freek,

    Thank you for your suggestion. I made the change in the local GPOs. However, I'm having some connectivity issues - perhaps seperate from that setting.

    Upon reboot after modifying those GPO's, I logged in several test users - all of which went to the same server - though, at the time (and again now, after another reboot), one server had the yellow triangle and exclamation on the network connection. Perhaps this shows that NLB is working, in a way, in that one server is offline/has connectivity issues, but users can still access the online server - this is something that never worked without NLB.

    It appears that both systems seem to alternate when they have network connectivity - some times both can browse the local network (file shares) - sometimes only one can. One server can never access local intranet websites (SharePoint, CRM, etc.) but the other server can. It appears that the most recent server to power on will get the working network connection and the other server already powered on gets cut off. This is constant.

    • Edited by JEPalm Monday, January 10, 2011 4:09 PM
    Monday, January 10, 2011 3:07 PM
  • Jayun,

    "...one server had the yellow triangle and exclamation on the network connection. Perhaps this shows that NLB is working, in a way, in that one server is offline/has connectivity issues, but users can still access the online server.."

    Correct, it's correct behavior that NLB sends users to the server that is online and has no networkissues.

    "...It appears that both systems seem to alternate when they have network connectivity - some times both can browse the local network (file shares) - sometimes only one can. One server can never access local intranet websites (SharePoint, CRM, etc.) but the other server can. This is constant..."

    That sounds like a network issue not related to NLB or Connection Broker. I would advise to check network settings perform tracerts and check eventlogs on that.

    • Marked as answer by Alan ZhuModerator Wednesday, January 12, 2011 2:56 AM
    • Unmarked as answer by JEPalm Wednesday, January 12, 2011 10:21 PM
    Monday, January 10, 2011 3:37 PM
    Moderator
  • I believe I've resolved the overlying problem which fixes all the issues I was having with NLB. VMWare doesn't like NLB in Unicast mode without changing several settings in the Virtual environment. VMWare documents the needed changes but also suggests using NLB in Multicast mode.

    Here's a VMWare KB article:
    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1556

    Essentially, for Unicast mode to work, VMWare needs the NLB nodes to be on the same ESX host - which ours were not - somewhat obviously - since we would want the user load split up between hosts. VMWare wants the ESX host configured to not send RARP packets when any of its virtual machines is powered on. Configuring this would prevent teaming failover protection - which we don't want.

    I opted to go with changing to Multicast mode (rebuilding the cluster) and instantly my issues were resolved - all of them.

    Users are logged into both servers - though not in the manner I would like - evenly distributed, one server can be powered down/taken off line, and users can still RDP to the farm and hit the other server, and there are no network errors and a loss of connectivity.

    Eventually, when done testing, we will move from virtual RDSH servers to physical boxes - so this may have all been just a 'learning experience'. :)
    • Marked as answer by JEPalm Wednesday, January 12, 2011 10:30 PM
    • Unmarked as answer by JEPalm Thursday, January 13, 2011 2:31 PM
    • Marked as answer by Alan ZhuModerator Friday, January 14, 2011 1:54 AM
    Wednesday, January 12, 2011 10:30 PM