Originally posted Wednesday, October 24, 2007 4:08 PM
If you are using NLB (Network Load Balancing), you may be forced to use Unicast (as I am). This forces you to create another IP address on another NIC to do operations other than NLB, such as domain access, administration, and connecting to a database.
You may also have the misfortune of being required to set this NIC to use the same subnet.
If you are able to have different subnets, then you need to force all traffic to the database to go out the non-NLB NIC. Do this with Route Add
e.g. route -p ADD <IP of SQL> MASK 255.255.255.255 <gateway of non-NLB NIC>
If you aren't able to do separate subnets, then you still need to make your packets "signed" by the non-NLB NIC. I think I was having a problem caused by SQL not being able to respond to the requesting NIC, because it's in unicast mode serving up NLB. The solution is to force SQL traffic to go out the non-NLB NIC.
Here is one of the errors I was having:
Source: Windows SharePoint Services 3
Event ID: 27745
Login failed for user ''. The user is not associated with a trusted SQL Server connection.
Unable to connect to the database SharePoint_Config on <server>\<instance>. Check the database connection information and make sure that the database server is running.
The fix is pretty much the same as above, only you can't use the gateway of the non-NLB NIC, because it's the same as the NLB NIC (same subnet, remember?)! I tried to use the IF parameter, but the second NIC is designated as 0x10004, which is 65540. The route command didn't like either one of those numbers.
Well, you can just specify the IP address as the gateway, and Route is smart enough to use that NIC as the appropriate interface. So the command is:
route -p ADD <IP of SQL> MASK 255.255.255.255 <IP of non-NLB NIC>
If this ends up not working, I'll just delete the article. =)