Many Microsoft-based networks deploy a WINS infrastructure in their environment. WINS is an alternative name resolution protocol to DNS, and in many cases a supplement to DNS as well. It is a service that uses NetBIOS over TCP/IP (NetBT), mainly used in operating systems such as Windows 9x and Windows NT 4.0.
When Windows 2000 Active Directory arrived, the requirement for WINS was no more, at least it was possible to run a networked environment without it. However, certain dependencies were required to make this statement true. First, legacy clients (pre-Windows 2000) had to be upgraded to at least Windows 2000. Second, you had to ensure that no applications on your network were dependent on NetBIOS.
Even with the introduction to Windows 2008, Microsoft continues to offer WINS, now as a “feature”. However, they also offer a new option called GlobalNames Zones in DNS which can be used in place of WINS. However, it is not an apples-to-apples trade-off.
This new feature in DNS does not function identically to WINS and may not be a suitable replacement in your environment. So, to help customers migrate to DNS for all name resolution, the DNS Server role in Windows Server 2008 supports a special GlobalNames Zone (also known as GNZ) feature.
Unlike WINS, which is dynamic in nature, GNZ is completely static, which requires the DNS administrator to manually create and manage the records. GNZ is intended to assist the retirement of WINS, not as a replacement for WINS. GNZ is not intended to support the single-label name resolution of records that are dynamically registered in WINS, records which typically are not managed by IT administrators.
Support for these dynamically registered records is not scalable, especially for larger customers with multiple domains and/or forests. In GNZ, after the creation and enabling of the GlobalNames zone, the administrators must manually manage records from that zone. GNZ does not support dynamic updates.
How to Deploy a GlobalNames zone
Step 1: Create the GlobalNames zone
The first step in deploying a GlobalNames Zone is to create the zone on a DNS server that is a domain controller running Windows Server 2008. The GlobalNames Zone is not a special zone type. It is an AD DS-integrated forward lookup zone called “GlobalNames”.
Step 2: Enable GlobalNames zone support
The GlobalNames zone is not available to provide name resolution until GlobalNames zone support is explicitly enabled by using the following command on every authoritative DNS server in the forest:
dnscmd dnsServerName/config /enableglobalnamessupport 1
Step 3: Replicate the GlobalNames zone
To make the GlobalNames zone available to all DNS servers and clients in a forest, by setting the appropriate replication scope on the zone.
Step 4: Populate the GlobalNames zone
Add all of the appropriate records in the zone.
Step 5: Publish the location of the GlobalNames zone in other forests
If you want DNS clients in other forests to use the GlobalNames zone for resolving names, add service location (SRV) resource records to the forest-wide DNS application partition, using the service
name _globalnames._msdcs and specify the FQDN of the DNS server that hosts the GlobalNames zone.
In addition, you must run the
dnscmdServerName/config /enableglobalnamessupport 1 command on every authoritative DNS server in the forests that do not host the GlobalNames zone.
- By default, an authoritative DNS server uses local zone data first to respond to a query, before trying the GlobalNames zone to see if the name exists.
- Dynamic updates that are sent to an authoritative DNS server are checked against GlobalNames zone data first before being checked against local zone data.
- No software updates are required for clients to enable them to resolve the names that are configured in the GlobalNames zone.
- DNS client registration is not affected unless a computer tries to register a name that is already configured in the GlobalNames zone.