Monday, October 19, 2009

Domain Laptops and Field Connectivity

I have been doing massive amounts of research over the past 6-12 months on the best ways to connect/network domain laptops in the field among our staff while avoiding a plethora of client-network based issues that may arise. I have come to find through my research the best way to set these units up in the field is by using a router. Any consumer based low-cost router should do the trick. This eliminates a number of issues including weak security and allows for more of a controlled environment given the myriad different client network configurations.

I'd like to note some of our key issues and their theoretical solutions (still in testing):

- Unable to connect to other units' shares and resources over a switch/hub/ad hoc wireless network in the field. Typically receiving the notorious "is not accessible" error.

- Software which needs to use the IP address of a particular node on the network to sync with.

Regarding the first said issue, there are a number of different reasons this error could pop up. I'll skip the obvious by linking to THIS page for more information on that error and dig a little deeper. It appears that Microsoft Service Pack 3 has just such a bug that if a unit is part of a domain and is out in the field using cached domain credentials, due to a fault in the netlogon.dll file in SP3, it simply will not connect to another networked laptop. It gets very convoluted at this point. When this happens, I usually need to verify:

1. What type of network medium are the machines using? Switch? Ad Hoc?
2. Are the machines able to ping each other?
3. Is the Windows Firewall enabled?
4. Is NetBIOS over TCP/IP enabled?
5. What is the Node Type for NetBIOS set to? (ipconfig /all)
6. Check static/alternate IP/DNS configuration.

All of these things must be checked and if everything looks good and the machine is running Service Pack 3 for XP but still won't connect...then there isn't much I've been able to do besides reimage that machine to SP2 which in turn successfully connects to other SP2 machines every time I have done this. More info can be found in THIS thread.

The second key issue we here at our firm (completely different animal) is that we'll get out to a client's location and connect to their network and be able to connect to shares etc without a problem but our main piece of software, which functions on being able to resolve a name to the correct IP address of the target node, will not sync. Now, I know that this can be easily corrected by utilizing the hosts/lmhosts file on each machine however this is unreasonable because the entries would have to be removed each time the user got back to the office and logged into the domain. The actual problem is the machines are not getting added properly to the client's DNS server and possibly getting forwarded to some unknown location. I've seen clients that forward our DNS requests out to, and while this typically is not a problem for the client, recently made some modification to their system in that it will ALWAYS return a response even if the machine is not in their records. This poses a problem because Machine A pings Machine B and gets a response from a 208.x.x.x address instead of Machine B's IP address of 192.168.x.x. and therefore any software that relies on being able to correctly resolve hostnames to IP's is now broken. NetBIOS must be used to resolve names if DNS is unavailable or is configured incorrectly at the client.

Now, back to the main topic here, routers will provide the field group with a private network while allowing for internet access via the clients' provided connection as a gateway on the router. If DHCP is disabled on the router (so as to NOT hand out IP addresses, we still need the IP from the client's network), alternate IP's can be configured for each laptop for good. This sidesteps setting a static IP for the network card and having to constantly change it when moving from home to field networks. Now, the real question here is where to point the DNS in the alternate IP configuration? Well, we know we do not want to use the clients' problematic DNS. Nor do we want to point our machines to We need a DNS server capable of providing internet name resolution without registering our machines and thus forcing the machines to use NetBIOS to resolve the name to the IP because Windows will always try the hosts file first, then DNS, THEN NetBIOS.

So far I have a list of Public DNS servers and I've had successful tests using the router with DHCP disabled and with alternate IP/Gateway/DNS configured on each field laptop. I still need to determine if the public DNS servers I'm using are reliable and what stipulates records being added over time?

No comments: