Watch your bindings order

Just got back from installing an additional NIC in an ISA2004 firewall. The ole network bindings order gotcha hit me yet again so I thought it was time to write this down to remind me – and hopefully save you from this grief.


When adding a new network interface (phyiscal, wireless, 1394 etc) to a Windows machine (and I’m considering XP & Windows Server 2003 here but the same may well apply to other versions) you need to make sure you set the bindings order for all the network cards correctly in order to maintain proper operation.


For example, in your typical SBS2003 server there are 2 netowrk interface cards (NICs) and the server, when performing operations such as DNS lookups etc, needs to check with the internal NIC first because that’s where things like DNS and WINS are bound first. Get the network card binding order wrong and you’ll find DNS lookups will fail (this is why you ALWAYS USE THE WIZARDS!!! (excuse the shouting)).


Anyway, back to the story at hand. I installed an additional NIC into this firewall, giving it 3 interfaces in total. All appeared to be OK so I left the site. Got a call about 10 minutes later to be told “I can’t browse the Internet from my computer”. After spending some time RDP’d into the server (using my new Telstra Next-G card which totally rocks!!) I thought I’d disable the new NIC for now. Also noticed an error in the event logs about the proxy service not being able to bind to the internal NIC.


It was about this time that I thought of those darn network binding order settings. I checked them and sure enough the new NIC (for the DMZ) was at the top of the list. Moved it down to the bottom, restarted the ISA services but that didn’t fix it.


We restarted the server and this proved the winner as everything was then able to start up & bind appropriately.


So, the lesson here is when installing an additional NIC into anything, in particular a server, check the bindings order. “Where is that?” I hear you ask?


Open your network connections folder and select the “Advanced” menu item. Click on “Advanced Settings…”.


Check the list of connections for the order of the network cards – make sure the internal NIC (the one things are bound to) is the top one. {and one of these days I’ll work out how to attach images to this thing so I can show you what to look for}.


Remembering this would have saved me from sitting on the side of the road for 25 minutes and let my client get out of the office a bit ealier.


 

Stymied by RWW & RDP 6?

We’ve had a few cases where RWW won’t work on machines where they’ve had RDP 6 installed. The resolution when this happens is to uninstall RDP 6 as it appears there is a problem between the full RDP 6 client and the RDP 5.2 ActiveX component that RWW uses.


Whilst I’ve not personally tested this (I know – but it takes time!!) our “fix” in the meantime is to remove the RDP 6 client. Go to Add/Remove Programs, click the show updates checkbox at the top of the list and uninstall update KB925876. This takes you back to RDP 5.2 (in Windows XP).


Guess I’ll do some trawling around to see if there are other articles about this anywhere but for the moment this is what we’ll do.


If you know another “fix” that doesn’t require removal of RDP 6 please let me know.