GlobalNames Zones and the Long Overdue Demise of WINS
When any administrator worth their salt heard that Windows Server 2008 finally provided a mechanism to eliminate the need for WINS servers on the network, they pumped their fist in the air and said, "Yes!"
Left over from the days when Microsoft networks were mainly broadcast based, NetBIOS name resolution has long been a thorn in the side of the Windows administrator.
Though most networks eventually mature into a state where the WINS servers stand quietly and dish out simple name resolution, getting the proper configuration in place can be a nightmare. Even after the configuration is set, problems can creep up when users move locations or when DHCP or DNS servers are removed, relocated or added.
Often these network issues look like something else, so the admins end up spending way too much time troubleshooting the issue.
Still, there has really been nothing the administrator can do about it, thanks to legacy applications and user’s understandable inability to work with complicated Fully Qualified Domain Names (FQDN).
(I’ve literally seen something like: Sever5.Austin.RemoteOffice.District7.Operations.Users.TheBigCompany.com)
All of this changes in Windows Server 2008 …
Introducing: GlobalNames Zone
Windows Server 2008 comes with IPv6 installed and enabled (if you haven’t already, check out my article on Windows Server 2008 IPv6 – The Future of Internet Protocol).
IPv6 makes no provision for WINS and Microsoft has wisely chosen not to shoehorn something in specifically for Microsoft networks.
IPv6 works with DNS, and DNS only. So, Microsoft came up with a rather ingenious solution to the problem of simple-name resolution, a special forward lookup zone.
The GlobalNames Zone (GNZ) is a regular issue, standards compliant forward lookup zone.
That means no interoperability issues for administrators. (And there was much rejoicing.) It does require a special name – GlobalNames – but otherwise, it is indistinguishable from other forward lookup zones.
It does take a specific configuration though. Specifically, it must be set to replicate to all DNS servers in the forest. It should not be set for dynamic updates, and GlobalNames Zone support has to be enabled on the DNS server.
How GlobalNames Zone Works
So how does this new bad boy work?
Basically, if a DNS server receives a request that it can’t resolve in its normal way by using local zones, it will then try and resolve the name with the GlobalNames Zone.
So, when that request comes in for AustinServer, the DNS servers will check its normal local zones (filled with FQDN) and come up empty. Then, it will check the GlobalNames Zone — where it will find AustinServer, and match it to its FQDN.
No extra configuration needed on the client to point to a WINS server, and no extra configuration on server to add a WINS role. You’ll be using DNS anyway, so everything that has to be there is already installed.
How to Setup GlobalNames Zone
Setting up GNZ is pretty straightforward as well. Just logon to your Domain Controller and fire up Server Manager.
Next, expand the DNS section under Roles until you come to Forward Lookup Zones. Inside Forward Lookup Zones, create a new zone.
The new zone should be a Primary Zone and needs to be set to Store the Zone in Active Directory. (Don’t forget this checkbox!)
Click Next to move on to the next page. Here, name the zone “GlobalNames” (this name is required).
Also, do not enable Allow Dynamic Updates. That is it for configuration only.
The one semi-bumpy spot is enabling GNZ support on the server. This requires issuing a command via the command-line. The command is:
dmscmd /config /EngalbeGlobalNamessupport 1
Where you are most likely to mess this up is the two "s". It is Global Names Support not Global Name Support. Remember that and you’ll be fine.
This support has to be enabled on all the DNS servers in the forest. Don’t waste time typing it in all those times. Make a simple batch file and schedule it to replicate and run on all the servers.
In order to avoid any forgetfulness on new servers, make sure enabling GNZ support is included as standard operating procedure for all new DNS server installations.
All that is left is to build the forward lookup zone. Each entry will be a CNAME record with the corresponding Fully Qualified Domain Name.
Will You Ever Need WINS Again?
It is possible that some applications seem to require a WINS server. Unless the application interacts via specific WINS commands (not very common), it is usually possible to trick it by giving the program the address of a DNS server instead of a WINS server.
When your DNS server gets the name request, it will find the name and respond. Any application still being supported shouldn’t need this crutch for very long since most applications are being readied to work with IPv6 and there is no WINS in IPv6.
If you are tempted to configure both WINS and GNZ, don’t.
While it isn’t specifically forbidden, if you think your simple-name resolution is flakey now, wait until sometimes a WINS server responds and sometimes a GNZ server responds.
Not to mention you’ll have to add new entries to both places every time you add a resource to the network. The whole point of GNZ is to make things simpler not more complicated.
Say Goodbye to WINS and Say Hello to GNZ
Victory! WINS is no longer needed on your network. How do you celebrate?
Step One: Go into your DHCP configuration for the domain and find the setting: "WINS Is Not Required".
Invite the whole systems administrator team and have everyone gather around. This is a big moment for your network.
Select the no WINS setting and start the high-fives.
Step Two: Go to happy hour. Get the Jalapeno Poppers, you’ve earned them.