I recently came across two similar scenarios involving NLB Cluster nodes where outgoing connections failed.  

In the first one we had an NLB Cluster with 2 nodes, each node having one interface on which only the NLB (common) IP address was configured.  The issue was  that, even if the cluster was reachable from other machines - responds to PING, TCP connections etc, the nodes were unable to connect to any other machine. In his case, the nodes could not connect to a network share, but we later found out that they were actually unable to send out any IP packet.  ICMP, DNS, SMB, nothing worked. All connection attempts terminated very fast with various errors.

When we tried to ping other machines, we received the error:

 “PING: transmit failed. General failure”

 This is in fact expected and it functions according to the design. The NLB IP Address is added to the network interface using the “SkipAsSource” flag, meaning it cannot be used as a source IP Address for outgoing connections.

 More on “SkipAsSource” - http://support.microsoft.com/kb/2386184

 You are also prompted that you will not be able to establish outgoing connections when you are configuring the cluster:

The solution in this case was to add a dedicated (unique) IP address on each of the nodes, to be used as a source IP address for the outgoing connections.

One can do this from the NLB Manager -> Select Host -> Host Properties -> Host Parameters -> Add Dedicated IP Address.

In the second scenario we had 2 interfaces on each node, from which one was configured with a dedicated (unique) IP, and the other, used for NLB, was configured with only the NLB (common) IP address.

In this case, we were unable to establish connections from the nodes to the Cluster IP Address. As before, the Cluster was reachable from other machines; this time we could also reach other machines because we had the dedicated IP Addresses on the other Interfaces, but we were unable to connect to the cluster IP Address.

We had the same error when pinging the Cluster IP Address:

What happened: when deciding how to send (in this example - ) the PING packet, TCPIP first chooses the interface on which it will send the Packet, according to the routing table. Obviously, to reach the NLB IP, we would go out through the NLB interface. But, on this interface we don’t have an IP address useable as a source IP for outgoing connections (Remember, the NLB IP has the “SkipAsSource” flag set.)

Therefore, we fail in sending out packets to the NLB IP Address, even if the address is a local one.

 More on Source IP address selection: http://blogs.technet.com/b/networking/archive/2009/04/25/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx

 The solution here was the same as in the first case: add a dedicated (unique) IP address on the NLB interfaces.

Scenario:

Jonny again, this Time I want to tell you a little bit about the Web Client Service (WebDAV) on Windows 7 SP1. Consider the following Scenario:
You are working from your Home Office connected to your ISP for Internet access. You are finished with your work and want to upload your Data to a
IIS 7.5 WebDav Share over HTTP(S) that your co workers can access the Data. You start the upload, you see the Progress Bar moving very quick to
the end and stay's there. After 30 minutes you receive the following Error :
 
Error: 0x80070079 The semaphore timeout period has expired

What happend? You check if the Internet connection is broken => nop, it is not
then you check if your connection from the PC to the Router is broken => nop, it is not

in Short: you check every possible cause but everything works fine and you are going crazy, but don't give up

the Problem is:

1. The Progress Bar moves very fast but the upload takes long time is due to Web Client is copying the file to the WebDAV TFS (WebDAV Temp Files) Store on the Client
and uploads it from there to the IIS WebDAV Share.

2. the bigger issue is that you click on repeat and after 30 minutes the same error occurs

the Cause is the Timeout for upload over Web Client is by default 30 minutes.

The Solution is to modify the following Registry Key in minutes to a higher Timeout:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRxDAV\Parameters
DWORD: FsCtlRequestTimeoutInSec

Ok, but now your coworker is working in teh Home office just like you, he want's to download the file from the IIS Server to his HDD on Windows 7 SP1

using the Web Client and also get's Errors like:

"Cannot Copy FileName: Cannot read from the source file or disk"

Copy Folder

An unexpected error is keeping you from copying the folder. If you continue to receive this error, you can use the error code to search for help with this problem.

Error 0x800700DF: The file size exceeds the limit allowed and cannot be saved.

<file name>

Try again Cancel

Oh men, how to fix this?

again, don't give up, the cause is a 50 MB download Limit on Windows 7 SP1 for Web Client and yes, we have a Registry Key where we can raise the Limit, Huhu :)

Just Modify the following Registry Entry in bytes:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
DWORD: FileSizeLimitInBytes
Default is 50000000 bytes.

Now you are ready to upldoad and download bigger Files by using the WebDAV (Web Client Service) over HTTP(S)

Hope this helps

by Jonny