Today I troubleshoot a UAG NLB installation. Creating the array was no problem, but I was unable to assign the external VIP on in the NLB. But I was able to assing it to the internal NIC....
The error that was given to me was:
NLB Settings could not be configured (0xC0040352).
After some troubleshooting, I found this page: http://technet.microsoft.com/en-us/library/dd126855.aspx
which gave an description of the error message:
"The specified virtual IP address VirtualIpAddress is not contained in the NetworkName network, in which the Network Load Balancing cluster resides."
I ran the network assignment wizard again and verified that the external nic was tagged as external, and the internal nic was tagged as internal, and that the IP addresses was correct.
Still no go!
I stated the TMG config tool, and under networks I found that on the internal Network that and IP range for 1-127 was added with all the defined internal networks.
I cleaned up all the addresses that not is internal, saved the config, and started the UAG NLB wizard again.
It now worked like a charm!
Showing posts with label UAG. Show all posts
Showing posts with label UAG. Show all posts
Thursday, September 15, 2011
Thursday, October 7, 2010
Direct Access - UAG - 2003 File Cluster Access
At a customer who has deployed DA, we have a strange problem.
The clients using DA suddenly got disconnected from the networks share on a 2003 FileCluster.
This could be only seconds after they connected, that they got a red cross on the network drive. when accessing the drive, they either got an error saying it could not connect, or it connected as normal. If the error message was thrown, they tried again, and got connected.
After a lot of troubleshooting, the explanation was found. When one user is connected to the fileshare over DA its OK, when a new user connects to the fileshare, the new connection resets the old one. This is because the UAG server is using NAT64 the UAG server is responsible for terminating the DA sessions and transalating them to Ipv4. More info here: http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx.
If the fileserver had been 2008 servere this would not have been an issue, since DA would not use NAT64, and IPv6 could have been used for the entire session.
Due to NAT64 the UAG server needs to create a sessions for each DA user to the 2003 file cluster share. This is not supported in SMB1 http://support.microsoft.com/kb/301673,
but is supported in SMB2.
Microsoft gives you 2 option, block port 445 and use Netbios, or upgrade the file cluster to 2008, which support SMB2.
*************UPDATE*****************
Microsoft has confirmed this issue, and are working on a hotfix KB2444558 that will fix this issue.
This issue can also affect the authentication between DA and 2003 domain controllers, since this also uses SMB.
The expected release date is week 48.
*******************************************
The clients using DA suddenly got disconnected from the networks share on a 2003 FileCluster.
This could be only seconds after they connected, that they got a red cross on the network drive. when accessing the drive, they either got an error saying it could not connect, or it connected as normal. If the error message was thrown, they tried again, and got connected.
After a lot of troubleshooting, the explanation was found. When one user is connected to the fileshare over DA its OK, when a new user connects to the fileshare, the new connection resets the old one. This is because the UAG server is using NAT64 the UAG server is responsible for terminating the DA sessions and transalating them to Ipv4. More info here: http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx.
If the fileserver had been 2008 servere this would not have been an issue, since DA would not use NAT64, and IPv6 could have been used for the entire session.
Due to NAT64 the UAG server needs to create a sessions for each DA user to the 2003 file cluster share. This is not supported in SMB1 http://support.microsoft.com/kb/301673,
but is supported in SMB2.
Microsoft gives you 2 option, block port 445 and use Netbios, or upgrade the file cluster to 2008, which support SMB2.
*************UPDATE*****************
Microsoft has confirmed this issue, and are working on a hotfix KB2444558 that will fix this issue.
This issue can also affect the authentication between DA and 2003 domain controllers, since this also uses SMB.
The expected release date is week 48.
*******************************************
Subscribe to:
Posts (Atom)