Install and Configure NLB (WLBS) on Windows Server 2008

In this article I will load balance 2 servers and take you through the process step-by-step. Load Balancing takes 2 or more servers and lets them share one IP address so both servers can serve client requests. At the end of this article you should be able to configure NLB.

Gathering Information

Log onto both of the servers and run IPCONFIG /ALL from the command prompt. We need the name, domain and IP address of each server that will be in the NLB Cluster. We will also need to make up an additional name for the cluster in this example we will use SERVER-LB for the virtual cluster name.

The 2 servers we will be Load Balancing are PL2008-01 and PL2008-02. The virtual cluster name will be PL2008-V. So if this was a web server users would go to http://PL2008-V, depending how we configure NLB either PL2008-01, PL2008-02 or both servers will service the web request.

SERVER NAME	IP ADDRESS	TYPE
PL2008-01.pintolake.net	192.168.1.180	Server 1
PL2008-02.pintolake.net	192.168.1.181	Server 2
PL2008-V.pintolake.net	192.168.1.182	Virtual cluster name and IP address of Servers 1/2

 

In this example both servers only have one network card. If you have multiple network cards you will still be able to load balance the 2 servers. You need to configure one NIC per server for NLB, both NIC’s should be on the same VLAN and be they should able to contact each other.

PL2008-01

PL2008-02

Installation of NLB feature on all NLB nodes

This should be done on ALL NODES in the NLB Cluster. In this case we are performing this installation on PL2008-01 and PL2008-02.

Open Server Manager, you can open this several different ways in Windows Server 2008. Probably the quickest way to open Server Manager is to right click "My Computer" and choose "Manage", another way is open "Control Panel" go to "Program and Features" and select "Turn Windows features on or off". A third way to open it is "Server Manager" option under Administrative Tools.

• Select "Features" from the Server Manager menu on the left
• Press "Add Features"

• Select the checkbox next to "Network Load Balancing"
• Press "Next"

• Press "Install"

Installation will proceed to install the necessary components

Installation has successes. It is highly recommended that you repeat this process on all nodes in the NLB cluster at this point before continuing with configuration

• Press "Close"

NOTE: Network Load Balancing may also be installed from a command prompt with elevated privileges (right click on the command prompt in the Start menu and select Run as administrator) by running theservermanagercmd -install nlb command. For example: C:\Windows\system32>servermanagercmd -install nlb ...... Start Installation... [Installation] Succeeded: [Network Load Balancing]. <100/100> Success: Installation succeeded.

 

Configuring NLB on NODE 1 (PL2008-01)

Network Load Balanced clusters are built using the Network Load Balancing Manager which you can start from Start -> All Programs -> Administrative Tools menu or from a command prompt by executing nlbmgr.

• Under the Cluster Menu option select "New"

• Enter the first node in the cluster which is PL2008-01
• Press "Connect"

You will have the option to choose which network adapter you want to use, the NIC should be on the same subnet as the other servers in the NLB cluster

• Press "Next"

• Enter the Priority ID as, 1 (each node in the NLB cluster should have a UNIQUE ID)
• Make sure the correct adapter was selected under "Dedicated IP Address"
• Select "Started" for the "Initial host state" (this tells NLB whether you want this node to participate in the cluster at startup)
• Press "Next"

• Press "Add"
• Enter the Cluster IP and Subnet mask
• Press "OK"

You can add multiple IP Addresses for the cluster, enter as many as you want.

• Make sure the "Cluster IP addresses" are correct
• Press "Next"

• Select the IP Address for this cluster
• Enter the NLB address "PL2008-V.pintolake.net"
• Enter "Unicast" as the "Cluster operation mode"
• Press "Next"

Unicast vs Multicast Unicast/Multicast is the way the MAC address for the Virtual IP is presented to the routers. In my experience I have almost always used Multicast, which if you use you should enter a persistent ARP entry on all upstream switches or you will not be able to ping the servers remotely. In the unicast method: The cluster adapters for all cluster hosts are assigned the same unicast MAC address. The outgoing MAC address for each packet is modified, based on the cluster host’s priority setting, to prevent upstream switches from discovering that all cluster hosts have the same MAC address. In the multicast method: The cluster adapter for each cluster host retains the original hardware unicast MAC address (as specified by the hardware manufacture of the network adapter). The cluster adapters for all cluster hosts are assigned a multicast MAC address. The multicast MAC is derived from the cluster’s IP address. Communication between cluster hosts is not affected, because each cluster host retains a unique MAC address. Selecting the Unicast or Multicast Method of Distributing Incoming Requestshttp://technet.microsoft.com/en-us/library/cc782694.aspx

I am leaving all the default for the port rules; by default its set to all ports with Single affinity, which is sticky. For more information on Port Rules, see my Note below.

• Press "Finish"

NOTE: Add/Edit Port Rule Settings For most scenarios I would keep the default settings. The most important setting is probably the filtering mode. "Single" works well for most web application, it maintains a users session on one server so if the user server requests go to PL2008-01, PL2008-02 will continue to serve that request for the duration of the session. None You want to ensure even load balancing among cluster hosts Client traffic is stateless (for example, HTTP traffic). Single You want to ensure that requests from a specific client (IP address) are sent to the same cluster host. Client state is maintained across TCP connections (for example, HTTPS traffic). Class C Client requests from a Class C IP address range (instead of a single IP address) are sent to the same cluster host. Clients use multiple proxy servers to access the cluster, and they appear to have multiple IP addresses within the same Class C IP address range. Client state is maintained across TCP connections (for example, HTTPS traffic). For more information on this please see this TechNet article: Specifying the Affinity and Load-Balancing Behavior of the Custom Port Rule http://technet.microsoft.com/en-us/library/cc759039.aspx

You should see a couple of things in the NLB Manager, this will let us know that this node successfully converged on our new PL2008-V.pintolake.net NLB Cluster

• Make sure the node’s status changes to "Converged"
• Make sure you see a "succeeded" message in the log window

Configuring NLB for NODE 2 (PL2008-02)

We will configure PL2008-02 from PL2008-01. If we wanted to configure this from PL2008-02 then we would need to connect to the PL2008-V cluster first then add the host to the cluster.

• Right click the cluster name "PL2008-V.pintolake.net" and select "Add Host to Cluster"

• Enter PL2008-02 and press "Connect"

A list of Network adapters will show up

• Select the network adapter you want to use for Load Balancing
• Press "Next"

This step is very important; each node in the NLB cluster should have a unique identifier. This identifier is used to identify the node in the cluster.

• Enter the Priority ID as, 2 (each node in the NLB cluster should have a UNIQUE ID)
• Make sure the correct adapter was selected under "Dedicated IP Address"
• Select "Started" for the "Initial host state" (this tells NLB whether you want this node to participate in the cluster at startup)
• Press "Next"

• Press "Finish"

You should see a couple of things in the NLB Manager, this will let us know that both nodes successfully converged on our new PL2008-V.pintolake.net NLB Cluster

• Make sure that both node’s status changes to "Converged"
• Make sure each node has a unique "host priority" ID
• Make sure each node is "started" under "initial host state"
• Make sure you see a "succeeded" message in the log window for the second node

A closer look at the configuration information for this NLB cluster

Testing

• Go to the command prompt and type "wlbs query", as you can see HOST 1 and HOST 2 converged successfully on the cluster. This means things are working well.
• Ping each server locally and remotely
• Ping the virtual IP locally and remotely – you should do this three times from each location. If you cannot ping remotely you may need to add a static ARP entry in your switches and/or routers where the host machines reside
  • 1 – Both nodes up
  • 2 – Node 1 down
  • 3 – Node 2 down

NLB Documentation (from Windows Help)

Availability, scalability, and clustering technologies

Windows Server 2008 provides two clustering technologies: failover clusters and Network Load Balancing (NLB). Failover clusters primarily provide high availability; Network Load Balancing provides scalability and at the same time helps increase availability of Web-based services.

Your choice of cluster technologies (failover clusters or Network Load Balancing) depends primarily on whether the applications you run have long-running in-memory state:

Failover clusters are designed for applications that have long-running in-memory state, or that have large, frequently updated data states. These are called stateful applications, and they include database applications and messaging applications. Typical uses for failover clusters include file servers, print servers, database servers, and messaging servers.

Network Load Balancing is intended for applications that do not have long-running in-memory state. These are called stateless applications. A stateless application treats each client request as an independent operation, and therefore it can load-balance each request independently. Stateless applications often have read-only data or data that changes infrequently. Front-end Web servers, virtual private networks (VPNs), File Transfer Protocol (FTP) servers, and firewall and proxy servers typically use Network Load Balancing. Network Load Balancing clusters can also support other TCP- or UDP-based services and applications.

Network Load Balancing overview

The Network Load Balancing (NLB) service enhances the availability and scalability of Internet server applications such as those used on Web, FTP, firewall, proxy, virtual private network (VPN), and other mission-critical servers.

What are NLB clusters?

A single computer running Windows can provide a limited level of server reliability and scalable performance. However, by combining the resources of two or more computers running one of the products in Windows Server 2008 into a single virtual cluster, NLB can deliver the reliability and performance that Web servers and other mission-critical servers need.

Each host runs a separate copy of the desired server applications (such as applications for Web, FTP, and Telnet servers). NLB distributes incoming client requests across the hosts in the cluster. The load weight to be handled by each host can be configured as necessary. You can also add hosts dynamically to the cluster to handle increased load. In addition, NLB can direct all traffic to a designated single host, which is called the default host.

NLB allows all of the computers in the cluster to be addressed by the same set of cluster IP addresses, and it maintains a set of unique, dedicated IP addresses for each host. For load-balanced applications, when a host fails or goes offline, the load is automatically redistributed among the computers that are still operating. When a computer fails or goes offline unexpectedly, active connections to the failed or offline server are lost. However, if you bring a host down intentionally, you can use the drainstop command to service all active connections prior to bringing the computer offline. In any case, when it is ready, the offline computer can transparently rejoin the cluster and regain its share of the workload, which allows the other computers in the cluster to handle less traffic.

Hardware and software considerations for NLB clusters

• NLB is installed as a standard Windows networking driver component.
• NLB requires no hardware changes to enable and run.
• NLB Manager enables you to create new NLB clusters and to configure and manage clusters and all of the cluster’s hosts from a single remote or local computer.
• NLB lets clients access the cluster by using a single, logical Internet name and virtual IP address—known as the cluster IP address (it retains individual names for each computer). NLB allows multiple virtual IP addresses for multihomed servers.

Note:

In the case of virtual clusters, the servers do not need to be multihomed to have multiple virtual IP addresses.

NLB can be bound to multiple network adapters, which allows you to configure multiple independent clusters on each host. Support for multiple network adapters is different from virtual clusters in that virtual clusters allow you to configure multiple clusters on a single network adapter.

Installing the NLB feature

To use Network Load Balancing (NLB), a computer must have only TCP/IP on the adapter on which NLB is installed. Do not add any other protocols (for example, IPX) to this adapter. NLB can load balance any application or service that uses TCP/IP as its network protocol and is associated with a specific Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port.

To install and configure NLB, you must use an account that is listed in the Administrators group on each host. If you are not using an account in the Administrators group as you install and configure each host, you will be prompted to provide the logon credentials for such an account. To set up an account that NLB Manager will use by default: in NLB Manager, expand the Options menu, and then click Credentials. We recommend that this account not be used for any other purpose.

You can use Initial Configuration Tasks or Server Manager to install NLB. To install NLB, in the list of tasks, click Add features and in the list of features in the wizard, click Network Load Balancing.

Managing NLB

Server roles and features are managed by using Microsoft Management Console (MMC) snap-ins. To open the Network Load Balancing Manager snap-in, click Start, click Administrative Tools, and then click Network Load Balancing Manager. You can also open Network Load Balancing Manager by typing Nlbmgr at a command prompt.

Deploying a 2012 / 2012R2 Remote Desktop Services (RDS) farm

Deploying a 2012 / 2012R2 Remote Desktop Services (RDS) farm

Applies to: Windows Server 2012 and 2012 R2

A lot of people were pretty excited when Microsoft released RDS for 2012 and for good reason. Not only did they overcome the shortcomings of the previous release of RDS on Windows 2008 R2, they have also made it very easy to setup and configure. One of the many great features of 2012 and 2012 R2 is the ability to push roles and features to multiple servers in an environment from a single Server Manager console. Not only does this save time when rolling out a new RDS environment, it also makes it easy.

The following will cover the step by step process in deploying the base components of a RDS 2012 /2012 R2 farm. Before we begin the process, let’s look at the different roles we will be deploying.

 

Remote Desktop Connection Broker (RD Connection Broker):

Connects or reconnects a client device to RemoteApp programs, session-based desktops and virtual desktops.

 

Remote Desktop WebAccess (RD Web Access)

Enables users to connect to resources provided by session collections and virtual desktop collections by using the Start menu or a web browser.

 

Remote Desktop Session Host (RD Session Host RDSH):

Enables a server to host RemoteApp programs or session-based desktops.

 

Remote Desktop Gateway (RD Gateway):

Enables authorized users to connect to virtual desktops, RemoteApp programs, and session-based desktops on the corporate network or over the Internet.

In our deployment, we will be logged into a single server and through Server Manager we will deploy our new Remote Desktop farm. Each of the servers designated in the environment are virtual, domain joined and were created from a template with the latest Windows updates. No other special changes or configurations were done to any of the servers with the exception of the RD Session Host servers. Some applications were installed on the RD Session Host servers in order for us to deploy our RemoteApp programs.

Here is a list of the servers which will be deployed in our RD Farm:

RDBROKER01:

RD Connection Broker and RD Web Access Server

RDBROKER02:

RD Connection Broker which will be used at later time for configuring HA for the RD connection brokers in the farm.

RDSH01:

RD Session Host servers

RDSH02:

RD Session Host servers

RDGWY01:

RD Gateway Server

Log into a domain joined 2012 or 2012 R2 server and launch Server Manager.

From the Dashboard, let’s create a new server group. This is not a requirement, however this is a good practice and helps organize the servers you will be managing.

Enter a name for the server group. Here we will call it RDS Farm.

Go to the Active Directory tab and search for the designated RD servers.

Once we find our servers, add them and hit ok.

Once the servers are added, you will see a new node in Server Manager with the server group name RDS Farm.

Now that we have all of our designated RD servers organized, go to the top right of Server Manager, click Manage and select Add Roles and Features.

On the before you begin screen, hit Next.

Here, Microsoft has separated the option of deploying Remote Desktop Services from all other roles and features. Select the option Remote Desktop Services Installation and hit next.

There are two different deployment types: Standard and Quick Start. Quick start is an option to be used mainly for testing purposes or for a proof of concept. The Quick start option will deploy each role for Remote Desktop Services on a single server. In this case we are doing a full deployment and will use the standard deployment option. Select Standard deployment and hit next.

There are two different deployment scenarios. The first is for a Virtual machine-based desktop deployment (VDI). Since we are focusing on the traditional form of Remote Desktop Services, we will choose the Session-based desktop deployment option. Click next.

On the Review Role Services screen it will list a description of the three minimum roles required for the deployment. Review the items and hit next.

Now we need to specify which server will be our RD Connection Broker. In our environment we have already determined the server RDBROKER01 will be our RD Connection Broker. Select and add RDBROKER01 and hit next.

The RD Web Access server has a very small footprint and a lot of times it is easier and more practical to share this role on the designated RD Connection Broker server(s). In some big environments, the RD Web Access role can be installed on its own servers, however for our environment we will be adding the role to our designated RD Connection Broker server RDBROKER01. To do this, check the box listed to install the RD Web Access role service on the RD Connection Broker server and hit next.

For the RD Session Host servers, we have 2 designated servers. Add both servers RDSH01 and RDSH02 and hit next.

On the confirmation screen we can see our proposed configuration. A message will appear stating the RD Session Host servers may require a restart. In order to proceed from this screen, you must check the box to “Restart the destination server automatically if required”. Once checked, hit Deploy.

During the deployment, you will be able to view the progress of each role as it is being deployed. Should there be any issues, it will list the issue along with an error. Wait for the deployment to be completed and hit close.

Go back to Server Manager and you will notice a new node called Remote Desktop Services. Go ahead and click on the Remote Desktop Services node.

In the Remote Desktop Services node, you will see the entire configuration for the new farm. This is where you can begin publishing RemoteApps or session based desktops, add more session host servers, configure HA for the RD Connection Brokers, etc…  It is your single console for managing and configuring the Remote Desktop Farm. THANK YOU MICROSOFT!

Now that we have our farm deployed, we will need to install certificates. A Remote Desktop deployment requires certificates for server authentication, single sign on, and establishing secure connections. These certificates should be created prior to the RDS deployment. Since there are multiple roles which require a certificate, you can use a wildcard certificate to make things easier. In our deployment, I’ve already generated a wildcard certificate and placed it in the following location: \\dc01\d$\Certs\. To begin installing the certs, click on the Tasks drop-down and select the option “Edit Deployment Properties”

Highlight the Role service RD Connection Broker – Enable Single Sign On. Then click on the “Select Existing certificate” button.

On the select existing certificate window, click on the browse button.

Locate and select the certificate and hit the open button.

Enter the password for the certificate and check the box “Allow the Certificate to be added to the Trusted Root Certification Authorities store on the destination computers”.  Hit OK.

Back on the deployment properties screen, hit apply.

Once the certificate is applied for the single sign on role service, go ahead and highlight the RD Connection Broker – Publishing option and click on the Select existing certificate button.

Browse and locate the certificate. Once found hit the open button.

 

Enter the password for the certificate and check the box “Allow the Certificate to be added to the Trusted Root Certification Authorities store on the destination computers”.  Hit OK.

Back on the deployment properties screen, hit apply.

Once the certificate is applied for the publishing role service, go ahead and highlight the RD Web Access role service and click on the Select existing certificate button.

Browse and locate the certificate. Once found hit the open button.

 

Enter the password for the certificate and check the box “Allow the Certificate to be added to the Trusted Root Certification Authorities store on the destination computers”.  Hit OK.

Back on the deployment properties screen, hit apply.

Once completed, hit OK.

You have successfully deployed a 2012 RDS farm. Now on to publishing RemoteApp programs.