Deployment in a Microsoft Windows Server 2003, 2008, and 2012 Environment

Prepare Microsoft Windows Server 2003, 2008, and 2012 for DSR

To make servers that are running Microsoft Windows Server 2003, 2008, and 2012 ready for Direct Server Return (DSR), you must complete the following steps on each server:

Step 1. Disable the Windows Firewall

To enable traffic to the loopback adapter:

• For Microsoft Windows Server 2003, 2008, and 2012, you need to disable the built in firewall or manually change the rules to enable traffic to and from the loopback adapter. By default, the Windows firewall blocks all connections to the loopback adapter.

Step 2. Install the Loopback Adapter

Windows Server 2003

To install the Microsoft Loopback Adapter, refer to How to install the Microsoft Loopback Adapter in Microsoft Windows Server 2003.

Windows Server 2008 and 2012

To install the Microsoft KM-TEST Loopback Adapter, refer to Installing the Microsoft Loopback Adapter in Windows 8 and Windows Server 2012. 

Windows Server 2008 or Windows Server 2008 R2

1. Open Device Manager. On the Start menu, click Run and type devmgmt*.msc at the prompt.

2. Right-click on the server name and click Add legacy hardware.

3. When prompted by the wizard, choose to Install the hardware that I manually select from a list (Advanced).
4. Find Network Adapter in the list, and click Next.
5. From the listed manufacturers select Microsoft, and then select Microsoft Loopback Adapter:
    
   This adds a new network interface to your server.

Step 3. Make the Windows Networking Stack Use the Weak Host Model

This step is required to allow the modified packet to be accepted by Windows Server 2008 servers.

 If you are using Windows Server 2003, you can skip to Step 4 Add the Loopback Adapter to your Site Bindings. If you are using Windows Server 2008 or Windows Server 2008 R2, use the steps in this section to make the Windows networking stack use the weak host model (which is the same model used in Windows Server 2003).

1. Open a command prompt with elevated permissions. To determine the interface ID for both the loopback adapter and the main NIC on the server, type:
   netsh interface ipv4 show interface


2. Note the IDX for both the main network interface and the loopback adapter you created. If you have not changed the interface names for this server then usually the main NIC displays as Local Area Connection, and the loopback adapter is named Local Area Connection 2.
3. An entry displays that includes the IDX numbers for both your loopback adapter and your Internet facing NIC. For each of these adapters enter the following commands:
   netsh interface ipv4 set interface <IDX number for Server NIC> weakhostreceive=enabled
netsh interface ipv4 set interface <IDX number for loopback> weakhostsend=enabled
netsh interface ipv4 set interface <IDX number for loopback> weakhostreceive=enabled

   
   For example: 
   netsh interface ipv4 set interface 23 weakhostreceive=enabled
netsh interface ipv4 set interface 24 weakhostsend=enabled
netsh interface ipv4 set interface 24 weakhostreceive=enabled
 

Step 4. Add the Loopback Adapter to your Site Bindings (IIS only)

Use the following steps to bind the loopback adapter.

1. Open the Internet Information Services (IIS) Manager, and expand the Sites folder.
2. Click Default Web Site or click the name of the site you are modifying.
3. Click Bindings on the Actions panel.
4. Click Add and click HTTP or HTTPS in the Type list. Enter the IP address of your loopback adapter and the port:
   
5. Click OK to add the Site Binding:
    
6. On the Actions panel, click Restart under Manage Web Site to ensure the new binding takes effect.

Step 5. Verify Direct Server Return Deployment

When you are done adding the loopback adapters, try to ping the Real Servers and the VIP, and telnet to the Real Servers. If the ping doesn’t work or if in response to the telnet you get a connection refused from the VIP, then the loopback adapter has not been configured correctly.

Try to verify that the loopback adapters are non-ARPing. On either Linux or Windows systems, use the arp -a command. Also, check the systems event logs to check for IP address conflicts.

If, later, once the Service is set up, the client tries to connect but is unable to access the application, then the IIS (Windows) or application has not been associated with the real IP address and the VIP.