N
Nyobi
I have read a number of articles and it seems that there are a number of people who have problems with DNS and workstations with both WLAN and LAN adapters. I haven't however found workable solutions.
Workstation Connection Objective:
To enable DNS discovery and Ip connection to client workstations regardless of whether the client is using the WLAN or LAN. Enabling users to use either Wireless or LAN adapter adhoc. ie they dock their laptops at their desks, and undock to take their laptops to meetings or consulations with peers. I need to be able to discover and connect to the workstations irrespective of the adapter being used at any time.
Most people seem to try to control which interface is used on the workstations, ie disable WLAN and only use LAN etc. Trying to disable interfaces isn't going to be feasible and its very inflexible.
I believe I can ensure that the workstations use the NICs in our preferred order:
1. LAN
2. WLAN - Our wireless network isn't as fast as the LAN.
By setting specific DHCP metric for the WLAN Router to be higher(ie 2) than the LAN(1). When the LAN isn't connected traffic will route via the WLAN adapter and when the LAN adapter is connected, its router metric will be lower and it will be the preferred gateway/route.
But how do I solve the DNS resolution for connection to that asset?
If I disable DHCP Server updates into DNS and allow secure updates from the client. It would be really good if DNS client behaved in the following manner
1. The LAN adapter(referred to as primary ie LAN) with the lowest metric(ie 1) registers/auto updates DNS with the ip(both A and PTR). Any other Adapters don't register. - ie the WLAN
2. The Laptop is undocked and the LAN adapter goes offline, the DNS Client then triggers a registration/auto updates its existing DNS entry with the ip from the next adapter(WLAN) with the next lowest gateway metric(2)...hence replacing the first ip registered.
3. The laptop is docked again, and DNS Client triggers a registration/auto updates its existing DNS entry with the IP from the primary adapter(LAN), replacing the WLAN ip.
So there is only ever 1 ipaddress registered for a workstation and it will always be a valid address. Then I don't need to be concerned about whether the user has the wireless turned on and docked.
Being able to discover and communicate with all our workstations in our sites is crucial requirement....
This microsoft article says, Understanding Dynamic Update
Dynamic updates can be sent for any of the following reasons or events:
* An IP address is added, removed, or modified in the TCP/IP properties configuration for any one of the installed network connections.
* An IP address lease changes or renews with the DHCP server any one of the installed network connections. For example, when the computer is started or if the ipconfig /renew command is used.
* The ipconfig /registerdns command is used to manually force a refresh of the client name registration in DNS.
* At startup time, when the computer is turned on.
* A member server is promoted to a domain controller.
However from what I am reading, both adapters(LAN,WLAN), if configured to update DNS, will register their Ip addresses. Which leads to an invalid DNS entry if the laptop is undocked, as the IP for LAN adapter isn't removed.
Has anyone solved this problem for their organizations without
1. Controlling which adapter is used - large management overhead
2. Only allowing one adapter to register with DNS
- If using LAN adapter for DNS, then anytime the user is using WLAN, their workstation doesn't have a valid DNS entry. Which also impacts Kerberos.
- If using the WLAN, then we would have to invest a large amount of money into Wireless to provide the necessary bandwidth
3. Setting GPO's to configure dns updates every 30mins on clients
- Inconsistent results...which I think is sometimes a worse problem
4. Defining separate DNS suffixes for their WLAN networks (I read some people did this)
- This doesn't remove an invalid DNS entry ie the ip(LAN adapter) DNS entry if the laptop is undocked
- It also creates problems with kerberos, if the host is registered under a separate DNS suffix from the Active Directory domain name
Continue reading...
Workstation Connection Objective:
To enable DNS discovery and Ip connection to client workstations regardless of whether the client is using the WLAN or LAN. Enabling users to use either Wireless or LAN adapter adhoc. ie they dock their laptops at their desks, and undock to take their laptops to meetings or consulations with peers. I need to be able to discover and connect to the workstations irrespective of the adapter being used at any time.
Most people seem to try to control which interface is used on the workstations, ie disable WLAN and only use LAN etc. Trying to disable interfaces isn't going to be feasible and its very inflexible.
I believe I can ensure that the workstations use the NICs in our preferred order:
1. LAN
2. WLAN - Our wireless network isn't as fast as the LAN.
By setting specific DHCP metric for the WLAN Router to be higher(ie 2) than the LAN(1). When the LAN isn't connected traffic will route via the WLAN adapter and when the LAN adapter is connected, its router metric will be lower and it will be the preferred gateway/route.
But how do I solve the DNS resolution for connection to that asset?
If I disable DHCP Server updates into DNS and allow secure updates from the client. It would be really good if DNS client behaved in the following manner
1. The LAN adapter(referred to as primary ie LAN) with the lowest metric(ie 1) registers/auto updates DNS with the ip(both A and PTR). Any other Adapters don't register. - ie the WLAN
2. The Laptop is undocked and the LAN adapter goes offline, the DNS Client then triggers a registration/auto updates its existing DNS entry with the ip from the next adapter(WLAN) with the next lowest gateway metric(2)...hence replacing the first ip registered.
3. The laptop is docked again, and DNS Client triggers a registration/auto updates its existing DNS entry with the IP from the primary adapter(LAN), replacing the WLAN ip.
So there is only ever 1 ipaddress registered for a workstation and it will always be a valid address. Then I don't need to be concerned about whether the user has the wireless turned on and docked.
Being able to discover and communicate with all our workstations in our sites is crucial requirement....
This microsoft article says, Understanding Dynamic Update
Dynamic updates can be sent for any of the following reasons or events:
* An IP address is added, removed, or modified in the TCP/IP properties configuration for any one of the installed network connections.
* An IP address lease changes or renews with the DHCP server any one of the installed network connections. For example, when the computer is started or if the ipconfig /renew command is used.
* The ipconfig /registerdns command is used to manually force a refresh of the client name registration in DNS.
* At startup time, when the computer is turned on.
* A member server is promoted to a domain controller.
However from what I am reading, both adapters(LAN,WLAN), if configured to update DNS, will register their Ip addresses. Which leads to an invalid DNS entry if the laptop is undocked, as the IP for LAN adapter isn't removed.
Has anyone solved this problem for their organizations without
1. Controlling which adapter is used - large management overhead
2. Only allowing one adapter to register with DNS
- If using LAN adapter for DNS, then anytime the user is using WLAN, their workstation doesn't have a valid DNS entry. Which also impacts Kerberos.
- If using the WLAN, then we would have to invest a large amount of money into Wireless to provide the necessary bandwidth
3. Setting GPO's to configure dns updates every 30mins on clients
- Inconsistent results...which I think is sometimes a worse problem
4. Defining separate DNS suffixes for their WLAN networks (I read some people did this)
- This doesn't remove an invalid DNS entry ie the ip(LAN adapter) DNS entry if the laptop is undocked
- It also creates problems with kerberos, if the host is registered under a separate DNS suffix from the Active Directory domain name
Continue reading...