Windows 2000 Infrastructure Services Design and Deployment: DNS, DHCP, and WINS Deployment within Microsoft

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

On This Page

Executive Summary Deployment Environment Dynamic DNS Deployment DHCP Deployment WINS Deployment Conclusion For More Information Appendix

Executive Summary

Microsoft is committed to assuring that the Microsoft® Windows® 2000 operating systems are of higher quality and offer greater business value than previously released versions of Windows. To stand behind this promise, Microsoft deployed the beta of those products within its own environment to ensure that Windows 2000 Professional for the desktop, and Windows 2000 Advanced Server on the back-end, would scale to meet the business challenges of other large enterprises.

Microsoft's Information Technology Group (ITG) has two primary roles within the company. The first role is to manage, monitor, and maintain the computers and software applications that run Microsoft's day-to-day operations. The second role is to deploy beta software in their computing environment to ensure that the beta software will be ready for release.

This document details ITG's experience deploying the beta of Windows 2000 Advanced Server within Microsoft's own internal environment. The emphasis of the document is on strategy, goals, and lessons learned from the deployment of infrastructure services.

Infrastructure services are used within Microsoft to form the underlying framework of software and services on which other applications within the company run. Infrastructure services form the backbone of Microsoft's computing information environment. Microsoft is a company that takes great advantage of its computing infrastructure. Given Microsoft's reliance on computing and computers for so much of its internal operations, a reliable, scalable computing infrastructure is critical to its business operations. This document focuses on the deployment, within Microsoft, of three critical infrastructure services in particular, the Domain Name System (DNS) the Dynamic Host Configuration Protocol (DHCP), and the Windows Internet Name Service (WINS).

Windows 2000 Advanced Server contains features and enhancements that optimized Microsoft's internal deployment of servers. For example, when using Dynamic DNS as the strategic name space, running in the integrated mode of the Active Directory™ service delivers fast performance. This performance is achieved through using the replication of Active Directory. With integration and replication of Active Directory, computer names are automatically registered with Dynamic DNS. This automatic registration has enabled ITG to deploy new Dynamic DNS servers easily and has made it possible for client computers running the Windows 2000 Professional operating system to take full advantage of DNS.

Windows 2000 Advanced Server includes the newest version of DHCP. Microsoft developed DHCP to eliminate the need for IT professionals to keep track of computer names and addresses using manual processes. DHCP initially provided the automatic configuration, assignment, and tracking of IP addresses. In Windows 2000 Advanced Server, the latest version of DHCP includes performance counters as well as beneficial administrative features such as scavenging and tombstoning capabilities. Now, using DHCP in Windows 2000 Advanced Server, ITG has been able to tune the behavior of servers running DHCP to better serve employees throughout the company.

This paper shares what ITG's Infrastructure Engineering group learned as a result of deploying Windows 2000 Advanced Server within Microsoft. Experiences discussed in this document include what that group did to plan their deployment and how that group later configured servers to run DNS, DHCP and WINS. ITG is sharing these experiences with customers so that they may learn from them, and if applicable use them to help successfully deploy infrastructure services based on Windows 2000 Advanced Server in their own unique organizations.

Deployment Environment

All companies are unique and must build a unique and specific plan in order to take full advantage of the many business-oriented features of the Windows 2000 operating systems. The most important considerations in planning the deployment of DNS, WINS and DHCP take into account service layering, network topology, data center classifications, team structure, and a strategy for upgrading. The following discussion describes how each area of focus was significant to the ITG implementation.

Service Layering

Service layering is a phrase that ITG uses to describe the number of Windows 2000-based server services deployed on a single server. Windows 2000 Advanced Server enables sophisticated layering of multiple services, as it has the scalability to execute many services concurrently. At the same time, factors such as number of concurrent users, number of processors, physical memory, and network performance all required consideration in determining the actual number of services ITG deployed on a single server. (See the Appendix for a detailed list of performance counters ITG used in the analysis of performance characteristics for servers running Windows 2000 Advanced Server.)

Effective service layering is critical of ITG's scalability planning and is a key determinant of ITG's efficiency. Microsoft employees accessing computing resources demand that they can use them reliability and that they perform quickly. As a result, ITG considers how many employees are expected to use infrastructure servers wherever they are placed. (The locations that DNS servers were deployed coincided with the placement of domain controllers since ITG is relying heavily on Active Directory.) In areas of the world where few employees work, and server utilization is light, ITG could take advantage of the scalability of Windows 2000 Advanced Server and installed DNS, WINS and DHCP on the same server. In other areas of the company where servers are very heavily utilized ITG configured DNS, WINS and DHCP services to run on separate servers based on server load. This structure ensures that a single point of failure would not have a wide impact on internal users.

The modular design of Windows 2000 Advanced Server makes it possible to efficiently scale servers simply by designing and deploying a server configuration that accommodates the diverse requirements a distributed work force provides. ITG took full advantage of the modularity of Windows 2000 Advanced Server in its deployment planning to ensure that employees would have fast and reliable service from computers that it deployed.

Network Topology

The deployment of DNS, DHCP and WINS took into consideration network design, which was especially important because both services depend on a reliable and scalable network to function. Microsoft's computer network is linked together using a traditional Asynchronous Transfer Mode (ATM) network topology. Areas of the company with a high concentration of employees constitute a hub in the network topology. Areas with relatively fewer employees constitute a spoke in the network topology. The review of network topology helped ITG to ensure that servers deployed would have sufficient network connectivity between them. Figure 1 illustrates a simplified spoke and hub network topology.

Figure 1: Simplified Spoke and Hub Topology of Microsoft's ATM Network

Data Center Classification

The practice and principles associated with the classification of Microsoft's data centers have been refined over time. In 1993 when Microsoft deployed the Windows NT® Server operating system for the first time, a feature called "trust relationships", which provides a secure communication channel between two domains, allowed ITG to reposition servers so that they could be centrally managed. As the repositioning occurred ITG transitioned Microsoft's computing information environment from a highly distributed decentralized model, to a model consisting of highly consolidated servers that are centrally managed. This later design is where ITG began its review of data center placement to help in the deployment planning of DNS DHCP and WINS.

ITG's data center taxonomy calls for three different classes of data centers: enterprise data centers, regional data centers, and site data rooms. The geographic positioning of these data centers corresponds with Microsoft's ATM spoke and hub network topology. Enterprise data centers are located where the majority of employees are located. Regional data centers are geographically dispersed and primarily function as facilities that house networking equipment needed to connect site data rooms with enterprise data centers. Site data rooms are typically located within each of Microsoft's subsidiaries. The majority of site data rooms are networked directly to a regional data center using a network speed greater than 256kb.

If DNS and DHCP services are deployed to site data rooms, then clients running the Windows 2000 Professional operating system in that area of the company use DNS WINS and DHCP servers located there. If such services are unavailable, then employees in subsidiaries access DNS, WINS and DHCP services located in a regional data center. Active Directory multi-master replication of DNS zones ensures that each server will have current and automatically updated records.

Figure 2 illustrates that the majority of employees are physically closest to enterprise data centers. The diagram also illustrates that the majority of site data rooms are physically cabled to enterprise data centers by-way-of a regional data center. Each of these factors is an important consideration that helps ITG to determine the best possible location to deploy servers.

Figure 2: Employee Locations Relative to Data Center Locations

The following discusses some of the primary differences of each data center classification and primary role in more detail.

Enterprise Data Centers — Microsoft has two enterprise class data centers, one located in Redmond, Washington and the other in Dublin, Ireland. Enterprise data centers have staff available on location twenty-four hours each day, seven days a week. These facilities serve the majority of employees, since most employees work from locations that are physically close to enterprise data centers.

Enterprise data centers have a high number of servers and very little layering of Windows 2000-based server services. They also have many large line-of-business applications running on stand-alone servers. The high number of employees who use servers located in enterprise data centers warranted ITG to limit how many services it configures on a single server. For example, DNS, WINS and DHCP server configurations in enterprise data centers call for servers to be configured as either a DNS a WINS server or a DHCP server, but not all three. This determination is based on the number of concurrent users, performance characteristics of the hardware, and impact to the company if the system became unavailable for an extended period of time.

Regional Data Centers — These data centers have fewer servers than enterprise data centers because the majority of employees are located at Microsoft corporate headquarters in Redmond, Washington. Regional data centers generally run smaller distributed applications. These data centers also are used as gateways to the Internet. Each facility typically does not have dedicated staff working on location so the majority of server support is performed remotely from an enterprise data center.

DNS and DHCP server configurations in regional data centers called for both services to run on the same server, to better utilize the equipment. Servers located in regional data centers are not as heavily used as servers located in enterprise data centers, because fewer employees access them.

Site Data Rooms — Nearly every subsidiary office within the company has a site data room capable of securely storing several computers. The servers stored in site data rooms are used to deploy a small infrastructure to serve the needs of employees working at that location. For example, a sales office located in Puerto Rico will have a minimal computing infrastructure that allows employees to securely logon to the network to access shared data, and print documents, with or without network connectivity to a larger facility.

Servers deployed to a site data room use extensive service layering to better utilize the equipment. A typical server in a site data room runs the Windows 2000 Advanced Server operating system, and has been configured to function as a domain controller, global catalog server, DNS server, and DHCP server all at the same time. In many cases these servers will also be configured to provide other services such as print services.

Site data rooms are key to ITG's deployment planning. Site data rooms also help to isolate network traffic by eliminating the need for employees to rely on DNS services from far away locations.

Team Structure

ITG used the following support structure to monitor, manage, and maintain the deployment of Windows 2000-based DNS, WINS, and DHCP:

Infrastructure Engineering — Reviewed the legacy environment and designed the new Windows 2000-based DNS, WINS, and DHCP environments. This team receives escalations from Infrastructure Services Management.

Infrastructure Services Management — Responsible for carrying out the deployment of DNS and DHCP. This team receives escalations from field service technicians and site operations teams.

Field Service Technicians — Responsible for traveling to subsidiary offices and installing server hardware. This team works closely with site operations, and can receive escalations from helpdesk and data center operations.

Site Operations — Provides oversight of regional and enterprise data center support. The team works closely with field service technicians and may receive escalations from helpdesk and data center operations.

Helpdesk — Responsible for supporting desktop computers running the Windows 2000 Professional operating system. This team provides assistance to employees by helping to resolve the majority of issues over the phone, but will also visit an employee's office to make repairs.

Data Center Operations — Provides daily support and maintenance seven days a week on the majority of servers located in enterprise and regional data centers.

Figure 3 illustrates the relationship between each area of support. For example, helpdesk and data center operations collaborate on troubleshooting but are able to escalate to either site operations or field service technicians.

Figure 3: Team structure for deployment of DNS, WINS, and DHCP

Upgrade Strategy

ITG's infrastructure engineering group found the process of upgrading Windows NT Server 4.0-based computers to Windows 2000 Advanced Server to be relatively straightforward.

Planning the deployment of DNS and DHCP and implementing tasks requiring multiple steps were more challenging. First ITG had to design the Windows 2000 domain name space, which served as the logistical road map in the deployment of Dynamic DNS, WINS, and DHCP. The name space design consisted of a graphical representation of domains overlaying geopolitical regions; it was used to join computers to the appropriate domains at an appropriate time in the deployment.

Figure 4 illustrates a highly simplified view of Microsoft's Windows 2000 domain name space. The triangles illustrate domains, such as the Far East, Redmond and European domains. The circles illustrate Organizational Units created within the domains. The arrow to the left of the diagram illustrates the steps that were followed in the deployment of Windows 2000 Advanced Server.

Figure 4: Implementation of Microsoft's Domain Name Space

The following pages detail ITG's deployment of Dynamic DNS, DHCP, and WINS within Microsoft. Each deployment was dependent on the deployment of Windows 2000 Professional and the deployment of Active Directory services.

Dynamic DNS Deployment

The Domain Name System (DNS) began in the early days of the Internet when the Internet was a small network established by the Department of Defense for research purposes. The host names of the computers in this network were managed through the use of a single HOSTS file located on a centrally administered server. Each site that needed to resolve host names on the network downloaded this file. As the number of hosts on the Internet grew, the traffic generated by the update process increased along with the size of the HOSTS file. The need for a new system that would offer features such as scalability, decentralized administration, and support for various data types became obvious.

In a conventional DNS implementation, if the authoritative information needed to be changed, the network administrator had to edit an appropriate zone file manually. DNS was originally designed to support queries against a statically configured database. Although the database file was expected to change, the changes were expected to be infrequent. However, the advent of the dynamic client assignment of addresses using the Dynamic Host Configuration Protocol (DHCP) essentially made manual updating of DNS records impossible. Network administrators simply could no longer keep up with the number of clients that gained the ability to dynamically configure their network address. It was clear that assignment of addresses using DHCP had to be integrated with dynamic DNS updates.

To address this concern Microsoft has significantly enhanced the newest version of DNS. Dynamic DNS included in Windows 2000 Advanced Server is the strategic name space, replacing NetBIOS for name service in previous versions of Windows NT. Now computers running the Windows 2000 operating systems can dynamically register in Windows 2000-based DNS.

Legacy Environment

Prior to deploying Windows 2000-based Dynamic DNS, ITG used DNS within the company in a very limited fashion. DNS was configured to use a single zone called dns.ms.com, which was used to refer all DNS lookups to servers running the Windows Internet Name System (WINS). The DNS zone in earlier versions did not perform any registration or updates. The method of forwarding DNS name queries to WINS was used to resolve DNS queries to names that existed only in WINS. The legacy DNS environment was used to alleviate the need to migrate names stored in WINS to DNS.

Within Microsoft the majority of computers were configured to use NetBIOS for name services. The legacy environment consisted of eight DNS servers running the Windows NT Server 4.0 operating system. The names in a DNS database form a hierarchical tree structure called the domain name space. The internal DNS domain had never been updated to reflect all of the records in the internal name space due to the administrative overhead that would have been required.

Each DNS server was used primarily by legacy systems, such as Web-based applications, and for performing reverse lookups of network routers located throughout the company. The legacy DNS namespace was flat, and was not accessible from the Internet. The legacy name space had its own root domain, and there was no relationship between the internal and external name spaces since each name space existed as a completely separate entity. Figure 5 illustrates the legacy DNS name space.

Figure 5: Microsoft's Legacy DNS Name Space

ITG deployed over forty WINS servers to resolve NetBIOS name queries in the legacy environment. Records in each WINS database were replicated between each WINS server to ensure that each had accurate and up-to-date records. Placement of WINS servers within the company was based on network connectivity and the number of employees expected to work in each area of the company.

Although Dynamic DNS is the preferred method of name resolution using a Windows 2000-based infrastructure, ITG will continue to use WINS for legacy operating systems that require NetBIOS support (i.e. Windows 3.x, Windows 95/98, and Windows NT). Although Windows 2000 Professional has become the standard desktop platform within the company, legacy operating systems are required by employees for testing purposes to ensure backward compatibility and interoperability.

Because Microsoft had used WINS for name services, the internal name space was flat. The deployment of Dynamic DNS transitioned the flat name space to a hierarchical namespace based on geopolitical boundaries. The deployment of Dynamic DNS is the topic of discussion in the following pages. For additional information on the use of WINS within Microsoft, refer to the WINS Deployment section of this paper.

Goals for the Deployment

Prior to beginning the deployment of Windows 2000-based DNS, ITG established several goals for the deployment. Goals included:

• Minimizing administrative overhead by using Active Directory.

• Implementing an internal corpnet.ms.com namespace to differentiate between Internet and intranet-based resources.

• Easing the transition from names used by WINS to the Fully Qualified Domain Names (FQDN) used by DNS.

• Making better use of network bandwidth to ensure that employees benefit from faster name queries.

• Reducing administrative overhead by utilizing DNS where appropriate and using WINS for legacy support.

• Allowing DNS to replace the legacy WINS infrastructure across the company.

Overview of Dynamic DNS

The following sections give a general overview of some of the features and functionality of Dynamic DNS that ITG had to become familiar with prior to the deployment. For more detailed information about Dynamic DNS, refer to the section entitled "For More Information."

Dynamic DNS Records

A DNS database consists of resource records, and each resource record identifies a particular resource within the database. There are various types of resource records in DNS. Table 1 provides information on the structure of many common resource records.

Table 1 Commonly Used Resource Records

Description	Class	Time To Live (TTL)	Type	Description of Data
Start of Authority (SOA)	Internet (IN)	Default TTL is 60 minutes	SOA	Owner Name, Primary Name, Server DNS Name, Serial Number, Refresh Interval, Retry Interval, Expire Time, Minimum TTL
Host	Internet (IN)	Zone (SOA) TTL	A	Owner Name (Host DNS Name), Host IP Address
Name Server	Internet (IN)	Zone (SOA) TTL	NS	Owner Name, Name Server DNS Name
Mail Exchanger	Internet (IN)	Zone (SOA) TTL	MX	Owner Name, Mail Exchange Server DNS Name, Preference Number
Canonical Name (an alias)	Internet (IN)	Zone (SOA) TTL	CNAME	Owner Name (Alias Name), Host DNS Name

The following is a brief description of resource records that were key to ITG's deployment planning.

Service Location Records (SRV) Records — SRV records specify the names of computers running the Windows 2000 Advanced Server operating system that offer specific services such as NetLogon, Clustering, Telnet, and File Transfer Protocol (FTP). The NetLogon service of Windows 2000 Advanced Server-based Domain Controllers registers its SRV record preceded by a "_". For example, the query "_ldap._tcp.dc._msdcs.corpnet.ms.com" will return the names and addresses of all domain controllers in the corpnet.ms.com domain.

Host Records (A) — Host Records are used for computer name to Internet Protocol address translation (i.e. forward lookup).

Pointer (PTR) Records — PTR records are used for Internet Protocol address to computer name translation (i.e. reverse lookup).

Name Server (NS) Records — NS records identify computers that are authoritative in a domain. (i.e. used in delegations).

Start of Authority (SOA) Records — SOA records are used to identify the owner name, primary name server, and serial number of a zone file. They are also used to identify the minimum Time To Live (TTL) as well as expiration time.

Dynamic DNS Registration

ITG had to become familiar with two methods of DNS name resolution, which consisted of client registration (i.e. Windows 2000 Professional-based clients that use DHCP) and DHCP server-based registration support for legacy clients.

When a Windows 2000-based DHCP client initializes, it negotiates a dynamic update procedure with a DHCP server. By default, the Windows 2000-based client attempts to update its host record or "A" record. While this occurs a server running Windows 2000 Advanced Server and the DHCP service attempts to upgrade the clients PTR resource record.

The Windows 2000-based DHCP server can be configured to "Update DNS server according to client request" or "Always update forward and reverse look-ups." If the DHCP server is configured to "Always update forward and reverse lookups," it will update both A and PTR resource records itself regardless of the DHCP client's request. If the DHCP server is not configured to perform dynamic updates, the DHCP client will attempt to update both A and PTR resource records itself.

Following is a brief explanation of a DHCP server's interaction with forward lookup and reverse lookup zones, depending on the capabilities of the client computer:

Forward Lookup — DHCP servers may register "A" records with the forward lookup zone, depending on the client capabilities. If the client supports Dynamic DNS, DHCP will defer registration to the client. DHCP will register resource records on behalf of legacy systems such as Windows 9x and Windows NT Server 4.0 automatically, when configured to do so. (The DHCP server will then own the DNS record. This can pose a challenge if the DNS zone must be configured to use secured updates. See the section entitled DHCP Deployment for details.)

Reverse Lookup — When enabled, the DHCP server will register the client's PTR record with the reverse lookup zone. The DHCP server can be used to clean up the DNS records when a client's lease expires. This means the in-addr.arpa zones must run with "allow updates" enabled.

For more information on Windows 2000-based DHCP refer to the sections of this paper entitled "DHCP Deployment" and "For More Information."

Dynamic DNS Zones

A DNS database can be partitioned into multiple zones. A zone is a portion of the DNS database that contains the resource records with the owner names that belong to the contiguous portion of the DNS namespace. Zone files are maintained on DNS servers. A single DNS server can be configured to host zero, one, or multiple zones.

A zone contains information about all names that end with the zone's domain name. A DNS server is considered authoritative for a name if it loads the zone containing that name. The first record in any zone file is a Start of Authority (SOA) Resource Record. The SOA Resource Record identifies a primary DNS name server for the zone as the best source of information for the data within that zone and as an entity processing the updates for the zone.

Names within a zone can also be delegated to other zone(s). Delegation is a process of assigning responsibility for a portion of a DNS namespace to a separate entity. This separate entity could be another organization, or a department or workgroup within an organization. Delegating essentially means assigning authority over portions of the DNS namespace to other zones. The NS record represents this delegation by specifying the delegated zone and the DNS name of the server authoritative over that zone. Delegating across multiple zones was part of the original design goal of DNS. The main reasons for the delegation of a DNS namespace are:

• To delegate management of a DNS domain to a number of organizations or departments within an organization.

• To distribute the maintenance of one large DNS database among multiple name servers to improve the name resolution performance as well as to create a DNS fault-tolerant environment.

• To allow for a host's organizational affiliations by including them in appropriate domains.

Standard implementations of DNS, such as BIND or Windows NT Server 4.0-based DNS server, provide the capability for server databases to be partitioned into zones. Each zone could be configured as a primary zone (that accepts new registrations) or a secondary zone (where zone information is transferred from the primary).

In addition to the standard configuration offered with previous versions of DNS, Windows 2000 Advanced Server offers the capability to integrate DNS zone information into Active Directory, allowing each zone to run as a Active Directory-integrated primary zone. This capability allows each DNS server to accept registrations and updates from clients running the Windows 2000 Professional operating system. This option is only available when DNS is configured to run on a server that is also a Windows 2000 domain controller.

ITG's Dynamic DNS design called for configuring Dynamic DNS to run in Active Directory-integrated mode for all zones. Integration of the Active Directory service has provided the following benefits to ITG:

• Each Dynamic DNS zone running as Active Directory integrated primary can accept dynamic registrations. This eliminated a single point of failure that had once occurred with its traditional primary and secondary zones under legacy versions of DNS.

• Active Directory, which provides an accurate and reliable representation of the zone information, will perform DNS replication.

• Because zone information can be updated on any domain controller, conflicts are resolved through timestamps of the updates. These checks are performed as part of Active Directory replication.

• Dynamic DNS Integrated zones can run in three modes: Secure, Allow Updates, and No Updates.

Deploying Dynamic DNS

Prior to deploying Dynamic DNS, ITG first had to consider its domain name space design, the integration of Dynamic DNS with Proxy servers, server placement, reverse lookup zones, site configuration, client configuration, and Dynamic DNS server configuration.

Domain Name Space Considerations

The Domain Name System is implemented as a hierarchical and distributed database containing a number of data types including host names and domain names such as corpnet.ms.com.

A Fully Qualified Domain Name (FQDN) uniquely identifies the host's position within the DNS hierarchical tree by specifying a list of names separated by dots on the path from the referenced host to the root.

ITG's Dynamic DNS namespace utilized this hierarchical design. Each Dynamic DNS zone was based primarily on geopolitical boundaries with a few zones based on business requirements. The names were taken from the proposed Windows 2000 domain name space design. The names also were based on other considerations such as feedback from managers from each geographic region.

To differentiate intranet-based resources from Internet-based resources, ITG created each intranet-based zone under a corpnet.ms.com zone, then later created Internet-based zones under a ms.com zone. All zones that were later created were based on one of these two zones.

Figure 6 illustrates the corpnet.ms.com Dynamic DNS name space including the following zones:

SelfHost — This zone was created to isolate the development of the Windows 2000 operating systems. Product development requires that it have control over the zone so that they can manage it.

DNS — ITG joined the legacy DNS environment to the name space based on Windows 2000. The primary function of this legacy zone is to continue forwarding NetBIOS requests from legacy clients to WINS for name resolution. The legacy DNS environment was unaffected by the deployment of Windows 2000 Professional and Windows 2000 Advanced Server. ITG simply joined the legacy zone to its new name space.

Figure 6: Dynamic DNS Name Space for corpnet.ms.com

Proxy Configuration

External DNS servers contain records that are accessible by computers on the Internet. The internal DNS namespace may contain a private root. If this is the case, internal clients may be configured to direct queries to either internal DNS servers, or to a proxy server where the query may be resolved externally. There are several methods that may be used to configure clients to forward queries to proxy servers including a Proxy Auto Configuration File, or Windows Proxy Auto Detection. An alternative approach is to configure an internal DNS server to forward unresolved queries to the Internet. Depending on the type of the clients that require DNS name resolution, the DNS configuration may be quite different.

Because Microsoft's corporate Intranet namespace was created under corpnet.ms.com (or dns.ms.com for legacy client support) all multi-label queries for hosts that are not included in these domain suffixes are sent to a Windows 2000-based proxy server to allow a DNS server on the Internet to resolve the query. ITG considered four methods of configuring clients to resolve queries by way of a proxy to the Internet, before decided that Automatic Detection using DHCP was the better approach. The four methods ITG considered included:

Winsock Proxy — Used to configure a file called mspclnt.ini on the proxy server so the proxy server forwards queries to the Internet.

Auto Configuration through Scripting — Takes advantage of the Microsoft Proxy Server administration tools to simplify auto configuration.

Manually Configure — Several 3rd party tools are available to configure proxy servers for specific domain names. ITG has used the 3rd party application WS_FTP to configure its proxy servers.

Automatic Detection — Windows Proxy Auto Detection (WPAD) automates the process of detecting a proxy server. The WPAD entry may either use a DHCP inform to notify DHCP clients of proxy servers, or WPAD may be assigned by way of a CNAME in a DNS domain. ITG prefers the DHCP inform approach because it has allowed them to configure client computers to forward queries to proxy servers using DHCP.

Reverse Lookup Zones

Reverse lookup zones contain PTR records that are used to translate IP addresses to computer names. ITG's Dynamic DNS design called for fully distributed reverse lookup zones. To accommodate this design requirement ITG configured each Dynamic DNS server in each domain to be authoritative over the network subnets that the domain serves.

For example, Microsoft's European Dynamic DNS servers are configured to be authoritative over network subnets at each site in Europe. This required each reverse lookup zone to be located in close proximity to the client and to the DHCP server that registered it.

The configuration of the reverse lookup zones is not based on the Windows 2000 domain structure. It is based on the range of IP addresses assigned to a company. For example, if a company is assigned B class IP addresses such as 172.56.X.Y., then a reverse lookup zone of 56.172.in-addr.arpa. will be created.

Site Configurations

ITG developed a Dynamic DNS configuration for each type of data center that it supports. The following pages illustrate each of the site configurations ITG used to deploy Dynamic DNS.

DNS Configuration for Enterprise Data Centers — Each data center in this classification has local WINS, Dynamic DNS, Global Catalog and domain controller traffic. Table 2 illustrates the authoritative domain, role, and WINS referral of Windows 2000-based domain controllers and Dynamic DNS servers that are located within each of these enterprise data centers.

Table 2 Enterprise data center Dynamic DNS configuration

Authoritative Domain	Role	WINS Referral
Root "."	Active Directory integrated primary No updates	Local WINS servers.
Corpnet.ms.com	Active Directory integrated primary Allow only Secure updates	None
Local domain	Active Directory integrated primary Allow only Secure updates	None
dns.corpnet.	Primary	Local WINS servers.
in-addr.arpa zones for subnets associated with site	Active Directory integrated primary Allow updates	None

DNS Configuration for Regional Data Centers — These data centers are positioned regionally throughout the world. Table 3 illustrates the authoritative domain, role and WINS referral of Windows 2000-based domain controllers and Dynamic DNS servers located within these regional data centers.

Table 3 Regional data center Dynamic DNS configuration

Authoritative Domain	Role	WINS Referral
Local domain	Active Directory integrated primary	None
dns.corp.	Secondary	Local WINS server as primary and data center server as secondary.
in-addr.arpa zones for subnets associated with site	Active Directory integrated primary	None

DNS Configuration for Site Data Rooms— These data rooms are typically located in field sales offices. Table 4 illustrates the authoritative domain role and WINS referral of Windows 2000-based Dynamic DNS servers and domain controllers located in site data rooms.

Table 4 Site Data Room Dynamic DNS configuration

Server	Authoritative Domain	Role	WINS Referral
Local Domain Controller	Local domain	Active Directory Integrated Primary	None
Local Domain Controller	Authority for in-addr.arpa zones for subnets associated with site	Active Directory Integrated Primary	None

Hardware Standards

Each DNS server was configured to use the following components:

• Compaq ProLiant 1850R, 512K Cache, 128MB RAM

• Compaq Smart Array 3200 Controller, PCI, 64MB Cache

• Compaq NC3120 10/100 TX PCI Intel UTP 100BASE-T, Full Duplex

• Compaq 9.1GB Pluggable Wide-Ultra2 SCSI 10,000RPM Hard Drive, 1.0"" (LVD)

Client Configuration and Site Considerations

ITG used DHCP to configure Windows 2000 Professional-based clients to use an appropriate DNS zone. The DNS zone was chosen based on the client's membership in a Windows 2000 domain.

DHCP was configured to use the following rules to configure clients located in each site:

• Client computers that participate in Redmond and European domains were configured to use both a primary and secondary DNS server located in the enterprise data centers of Redmond, Washington and Dublin, Ireland respectively. Client computers in these areas of the company represented the majority of Windows 2000 Professional-based clients.

• Client computers that authenticate against domain controllers located in regional data centers were configured to use a DNS server located in the closest regional data center as well as a DNS server located within an enterprise data center. The preferred DNS server is located in the regional data center, and the alternate DNS server is located in the enterprise data center. (Note that this configuration causes the client to use the closest DNS server before attempting to use a DNS farther away.) This configuration approach ensures that the majority of regional DNS traffic will be resolved by DNS servers located in that region.

• DNS traffic is further isolated by positioning additional DNS servers in site data rooms closer to employees. In these areas of the company, computers are configured to resolve DNS queries against servers located in the local site data room first. If the local DNS server is unavailable, the client computer will resolve DNS queries against servers located upstream, at the regional data centers level.

Each client was configured to first use a preferred Dynamic DNS server located in that region before attempting to use a Dynamic DNS server located elsewhere. The majority of the time the preferred Dynamic DNS server is physically closer to the client than the alternate. This strategy has made it possible for ITG to minimize the amount of network traffic that leaves each geographic region. Figure 7 illustrates the use of preferred and alternate Dynamic DNS client configuration settings.

Figure 7: Use of preferred and alternate Dynamic DNS configuration settings by site

Dynamic DNS Server Configuration

ITG's Dynamic DNS design calls for the following default configurations:

Allow Only Secure Updates — This feature was enabled on all forward lookup zones. This configuration prevents client computers from using a computer name already recorded in Dynamic DNS. (Note: If DHCP is used to register the client's records the DHCP server will then own the record. If a legacy client is later updated to Windows 2000 it would not be able to update its own record.)

Allow Updates — This Feature was enabled on all reverse lookup zones. This configuration has made it possible for both the DHCP server and the DHCP client to change their records after receiving a new IP address.

Access Control Lists (ACLs) — ACLs were used to secure root and corpnet.ms.com and all sub-zones of corpnet.ms.com. This precaution was taken to prevent anyone other than qualified Dynamic DNS engineers from adding records to the root and corpnet.ms.com DNS zones. Access Control Lists (ACLs) were modified to prevent authenticated users from creating DNS records in these domains.

Record Aging and Scavenging — This feature was enabled to tombstone any Active Directory-integrated forward lookup DNS zones.

Lessons Learned

The following are a few of the key lessons ITG learned from its deployment of Dynamic DNS.

Name space designs helped solve logistical challenges. — ITG learned that its Windows 2000 domain name space design documentation later helped in deploying Dynamic DNS. The documentation also helped them determine the appropriate steps needed to deploy the internal DNS names space. ITG followed its documentation by first beginning at the root of the domain name space, and then implementing branches in the hierarchical tree structure by working down the tree structure. Branches were implemented by deploying servers within geopolitical regions, and then configuring the servers according to standards developed for each data center.

In many cases configuring servers using Windows 2000 Advanced Server to run Dynamic DNS required that ITG simply invoke dcpromo.exe, included with Windows 2000 Advanced Server and then promote the server into an appropriate Windows 2000 domain. Once this was done, the Dynamic DNS server performed much of the configuration using information stored in Active Directory.

Gaining Dynamic DNS expertise was essential. — Deploying Dynamic DNS widely within the company was something that ITG had not done prior to the deployment of Windows 2000 Advanced Server. The deployment team had to first gain an understanding of DNS before they could deploy the technology. Becoming experts on DNS was later beneficial in supporting the deployment. While learning DNS was not difficult, ITG needed to plan accordingly.

Multi-master replication simplified the deployment of DNS servers. — As ITG deployed DNS to support the hierarchical domain name space, multi-master replication was found to greatly reduce the amount of information that needed to be keyed in manually during installation. The majority of the DNS configuration was performed automatically after having specified the name of a DNS domain to join.

DHCP Deployment

Microsoft integrated Dynamic Host Configuration Protocol (DHCP) into Windows NT to resolve a long-standing problem among network administrators. Prior to the release of DHCP services, network administrators had been required to manually configure computers one by one so that the computers could take advantage of the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols. The manual configuration process was time-consuming and prone to errors that often would take considerable time to resolve. These errors and the time that was required for administrators to manually configure thousands of computers prevented many large organizations from adopting TCP/IP.

At Microsoft, the release of DHCP services made it possible for the Information Technology Group (ITG) to kick off the company-wide deployment of TCP/IP. Since that deployment was completed, ITG has eliminated the use of many older and inefficient network protocols, making it possible to make better use of network resources. Now using DHCP services, network administrators within the company have greater control over the network, because the configuration is easier to manage and scale.

To ensure that the version of DHCP included in Windows 2000 Advanced Server offers even greater business value, ITG deployed the software company-wide while it was in the beta testing stages. Rather than upgrading older versions of DHCP to the latest version, ITG thoughtfully evaluated their existing environment and then determined how they should configure Windows 2000-based DHCP to improve reliability and benefit the company. The following discussion details the legacy DHCP environment, what ITG considered to improve it, and how they configured Windows 2000-based DHCP within the company.

Legacy Environment Review

Prior to deploying Windows 2000-based DHCP within the company, ITG already had been using earlier versions of the product throughout the company. The legacy environment consisted of over 150 DHCP servers, and over 100,000 DHCP clients.

The deployment of DHCP eliminated the need for ITG to update and distribute an LMHOSTS file to thousands of computers across the company. Using DHCP and Dynamic DNS ITG can manage the majority of desktops from a central location. DHCP servers are deployed to enterprise data centers, regional data centers, and site data rooms throughout the company. However, more than 80,000 DHCP clients used just five DHCP servers, located at corporate headquarters.

The legacy DHCP environment greatly influenced ITG's approach of deploying Windows 2000 Advanced Server. It was obvious that a DHCP environment based on Windows 2000 Advanced Server would need to provide the same functionality that the legacy environment provided. More importantly ITG was determined to improve it. Before they could make improvements, however, they needed to learn about the enhanced capabilities of Windows 2000-based DHCP.

ITG needed to improve using the new capabilities of Windows 2000-based DHCP, and undertook a review of the legacy DHCP environment.

DHCP Scope Implementation

One of the first areas ITG reviewed was how scopes were implemented in the legacy environment. Upon review, ITG found that its legacy implementation of DHCP scopes had not been properly balanced.

The majority of computers are located on the corporate campus in Redmond, Washington. DHCP servers located there are responsible for over 80,000 TCP/IP addresses. Of that total, 40 percent of the DHCP servers in that area were responsible for up to 71 percent of the total TCP/IP addresses needed. The lack of balance among DHCP servers, and the fact that the hardware that the DHCP services were running on was inadequate, had caused two DHCP servers to perform less favorably than the others.

Table 5 illustrates the distribution of legacy DHCP scopes and addresses on the five most heavily used DHCP servers within the company.

Table 5 Legacy DHCP Scopes and Number of IP Addresses

System name	Scopes	Addresses Total	Addresses In Use
DHCP-1	69	51000	25852
DHCP-2	56	61960	31333
DHCP-3	54	26058	13191
DHCP-4	27	18842	10097
DHCP-5	126	3119	2197

The analysis of legacy DHCP scopes helped ITG locate even small bottlenecks in performance and then formulate deployment plans to eradicate them. ITG determined that the server performance would increase if the number of addresses were evenly distributed across all available DHCP servers.

DHCP Server Location

Further review of the legacy environment continued with the review of how DHCP servers had been positioned within the company. Based on network analysis and on the observation of network latency, ITG determined that several locations within the company had DHCP servers located too far away from employees.

Improper placement of DHCP servers within the company increased the likelihood of network latency. Additionally, lack of proper server placement across the company increased the chance that network outages would impact more employees than if those servers were located properly. The analysis and review of proper server placement was used to properly redistribute servers to ensure higher availability and increased reliability.

Fault Tolerance and Redundancy

ITG reviewed the legacy environment to locate individual areas of the design that would have a wide impact on the company if they stopped working. It was determined that a catastrophic hardware failure on a legacy DHCP service would have a considerable effect on the employees' ability to perform their jobs.

ITG determined that disaster recovery plans that were to be used following such an incident would take considerable time to execute. ITG's disaster recovery plans required that a new DHCP server be built and configured with a new scope, and that network routers in affected locations be configured with new subnet information. The procedure then called for configuring network routers to forward UDP port 67 broadcasts to the new DHCP server so that it would issue new addresses. Once ITG regained control over the environment, the plans called for cleaning up the environment by removing the temporary subnet and reconfiguring the network routers. While these plans could be used in the future, they did not scale to the size of ITG's DHCP environment. For example, a catastrophic hardware failure on a critical DHCP server would require ITG to use the plans repeatedly to manually configure 70 network routers.

The review of the legacy environment for fault tolerance and redundancy pinpointed areas within the company that ITG must keep highly available. In these areas of the environment ITG's configuration called for deploying Windows Clustering to improve reliability and availability of DHCP servers.

Scope Lease Time

Further review of the legacy environment continued with the investigation of each DHCP scope to ensure optimal configuration. The review revealed that a number of DHCP scopes issued leases that were too short for the given situation. It was also determined that the legacy DHCP environment lacked a standardized lease time that could be applied to all DHCP scopes. Some scope lease times were configured completely improperly.

Still other scopes had so few addresses available for lease that the scopes had been configured to expire leases every few hours. The legacy environment called for configuring scopes to expire leases quickly when the scope had nearly depleted available leases. This configuration was used in the legacy design as a work around, which prevented scopes from becoming full. Ideally this work around would not be required if the DHCP scope had an adequate range of addresses to lease.

The review and analysis of the legacy environment identified a number of problem prone areas. ITG's deployment plans took those areas into consideration to ensure that the deployment of Windows 2000-based DHCP would eradicate them.

UDP Port 67 Forwarding

As part of the review of the legacy environment ITG determined that it could increase the value of event logs on DHCP servers by making a configuration change involving UDP port 67 forwarding. Improper configuration of UDP port 67 forwarding was determined to cause the event logs on many DHCP servers to quickly become full.

DHCP clients use the IP broadcast address 255.255.255.255 to discover a DHCP server. These network broadcasts are sent to UDP port 67. By default these broadcasts are not forwarded across routers. In the legacy environment it was not practical for ITG to place a DHCP server on each network subnet. Instead, ITG configured its routers to forward these broadcast to DHCP servers on other subnets. If a DHCP server received the broadcast but did not own the scope for the network subnet, the DHCP server responded with a Negative Acknowledgment (NACK).

Each time DHCP servers responded with a NACK, an event was written in the system event log of the DHCP server. Over time, NACKs became the majority of events written in the event logs. Event logs are a valuable aid in troubleshooting that allow ITG to proactively look for problems with each server. Overuse of UDP port 67 forwarding essentially filled the event logs with NACK events, making them of little value in troubleshooting. UPD port 67 forwarding was also found to result in a high number of DHCP discoveries that had an impact on ITG's ability to monitor servers as well as DHCP address allocation.

The result of the review identified issues with UDP port 67 forwarding allowing ITG to account for those issues and plan to correct them as part of the deployment of Windows 2000 Advanced Server. ITG's configuration calls for continuing to use UDP port 67 forwarding; however, their plans call for UDP port 67 forwarding to be used in a more controlled way.

Name Service Load Balancing

In the review of the legacy environment, ITG also examined how efficiently DHCP was distributing clients among WINS and DHCP servers throughout the company. An important role of DHCP is to configure client computers to use a name server such as WINS and DNS.

As part of the client configuration DHCP provides a primary and a secondary name server. The client always attempts to use the primary name server first, and if no timely response is returned, the client begins to use the secondary name server.

In the legacy environment secondary name servers were infrequently used, unless the primary name servers were used too heavily. The new DHCP configuration calls for distributing clients evenly across primary and secondary servers so that both are used equally.

Goals for the Deployment

The review of the legacy DHCP environment resulted in the development of the following goals for the deployment of Windows 2000-based DHCP:

• Migrating from Windows NT Server 4.0-based DHCP to Windows 2000 Advanced Server-based DHCP without impact to internal users.

• Using Windows Clustering capabilities of Windows 2000 Advanced Server to increase server reliability and availability.

• Resolving existing IP address shortages without reducing the time IP addresses are leased.

• Balancing client load effectively across DHCP servers and name servers.

• Making effective use of Windows 2000 Advanced Server features, such as Dynamic DNS registrations, vendor-specific options, and user support.

Overview of Windows 2000-based DHCP

The following briefly discusses a number of features that are new to Windows 2000-based DHCP. These features were especially important for ITG to consider in its deployment planning:

Integration of DHCP with DNS — DNS servers provide name resolution for network resources and are closely related to DHCP services. For Windows 2000, DHCP servers and DHCP clients may register with DNS. Standards for managing DHCP and DNS interactions are still being developed by the Internet Engineering Task Force (IETF), and Microsoft is committed to supporting these standards as they are completed.

Enhanced Monitoring and Statistical Reporting for DHCP Servers — Enhanced monitoring and statistical reporting has been added to the DHCP server for Windows 2000. This new feature provides notification when IP addresses are running below a user-defined threshold. For example, an alert could be triggered when 90 percent of IP addresses assigned for a particular scope have been assigned. A second alert can be triggered when the pool of IP addresses is exhausted. To alert network managers, a visual alert indicates that addresses are falling below a defined level, or completely depleted.

New DHCP Vendor Specific and Class ID Option Support — User classes allow DHCP clients to differentiate themselves by specifying what type of client they are. An administrator can then configure the DHCP server to assign different options, depending on the type of client receiving them. These variations include lease length, as well as WINS and DNS settings. This feature gives administrators greater flexibility in configuring clients. If client class options are unused, default settings are assigned.

Multicast Address Allocation — The multicast address allocation feature has two components: a server side implementation to hand out multicast addresses; and client side APIs that applications can use to request, renew, and release multicast addresses. To use this capability, the administrator first configures the multicast scopes and the corresponding multicast IP ranges on the server using administrative tools included in Windows 2000 Advanced Server. The multicast addresses are then managed like normal IP addresses. The client can call the APIs to request a multicast address from a scope. The underlying implementation uses DHCP protocol–style packet formats between client and server.

Rogue DHCP Server Detection — Windows 2000-based DHCP has management features to prevent unauthorized deployment and to detect existing unauthorized DHCP servers. In the past, anyone could bring up a DHCP server on a network. Now, using the latest version of DHCP an authorization step is required.

Windows Clustering — Windows Clustering can automatically detect the failure of an application or a server and quickly restart the application on a second server; users experience only a brief pause in service. Using Windows Clustering, administrators can quickly inspect the status of all cluster resources and easily move workload onto a second server within the cluster. This is useful for performing rolling updates on the servers without taking important data and applications offline for a long time.

Windows Clustering allows DHCP servers to be virtualized so that if a node in a two-node cluster crashes, the name space and all the services are transparently restarted on the second node. This means that the client is able to continue to use DHCP no matter what node in the cluster is running the DHCP service.

Deploying DHCP

All environments are different and therefore administrators must plan different solutions to deploy DHCP services. ITG's DHCP server deployment called for development of a standard cluster configuration, optimized scope configuration, legacy client configuration, and Windows 2000 Professional-based client configuration.

Cluster Configuration

ITG's configuration calls for using Windows Clustering, included in Windows 2000 Advanced Server, to increase the reliability and improve the fault tolerance of DHCP servers. Windows Clustering allows two servers to be managed as a single system. DHCP servers can use Windows Clustering to provide higher availability, easier manageability, and greater scalability.

The clusters that ITG deployed use an "active-passive" configuration. An active-passive cluster configuration calls for two nodes that each have DHCP services installed. In an active passive cluster, DHCP is running on the "active" node. The "passive" node in the cluster remains in a waiting-to-run state. While the passive node is in this state, it monitors the health of the active node. If the passive node detects that the active node is no longer running, the passive node will begin running DHCP. The passive node initiates a "fail-over" when it detects that the active node is no longer running. Since both nodes in the cluster share a common disk and configuration, either node in the cluster is capable of leasing addresses. Figure 8 illustrates a two-node cluster consisting of Windows Clustering and Windows 2000-based DHCP.

Figure 8: DHCP Service Running in Windows Clustering Environment

The passive node will initiate fail-over when it detects that the active node is no longer running. Administrators using the Cluster Administration User Interface included in Windows Clustering may also initiate fail-over.

Clustering DHCP services using Windows Clustering has made it easier for ITG to maintain and upgrade servers running DHCP by allowing technicians to work on the passive node at any time. After maintenance has been completed on the passive node, ITG initiates a fail-over of the DHCP service. Initiating a fail-over causes DHCP to stop on the active node, and start on the passive node. Once DHCP is running on the passive node, that node is considered active. Initiating the fail-over allows ITG to continue maintenance and upgrade on the passive node.

Four DHCP clusters were deployed at Microsoft's corporate headquarters to replace the five stand-alone DHCP servers that had been used previously. The majority of employees within the company use one of these four DHCP clusters. Each cluster currently handles approximately 20,000 active leases, and is expected to handle many more if necessary.

ITG deployed DHCP clusters at corporate headquarters, located in Redmond Washington and stand-alone DHCP servers at each regional data center, and nearly every site data room within the company. Each of these stand-alone DHCP servers is responsible for the local subnet(s). Should a remote location not have a DHCP server of its own, a DHCP server located within the closest regional data center will serve the location.

Should a failure occur, a DHCP server will begin to lease IP addresses to servers outside of its normal location. The 80/20 split is not used. Outside of the Redmond area, redundant DHCP servers are not deployed. This decision was based on the infrequency of failures and analysis of impact to the company at those locations. At most remote locations failure of a single DHCP server is considered relatively minor, and could be worked around quickly by implementing scopes on another DHCP server if needed. However failure of a single DHCP server located at corporate headquarters would be very significant, which is why clusters have been deployed there.

Server Configuration

Each node within DHCP clusters was deployed using the following hardware:

• Compaq ProLiant 1850R, 512K Cache, 128MB RAM

• Compaq ProLiant 1600/1850 Pentium III 500Mhz Processor Kit

• Compaq Netelligent 10/100 TX Intel UTP Controller, Full Duplex PCI

• Compaq 9.1GB Pluggable Wide-Ultra2 SCSI LVD drive, 10,000RPM Hard Drive, 1.0""

Shared External Disk System

Each cluster was deployed using the following disk components:

• Fibre Channel 12 Disk Drive Bay/Controller

• Fibre Channel Storage Redundant Power Supply

• 2x Fibre Channel Host Adapter Kit/PCI HBA

• 2x 4GB Compaq Drives

Optimized Scope Configuration

Leases from DHCP servers typically have predetermined lease times. If the lease expires, the DHCP server will reclaim that address into a pool of available leases. Clients using a specific lease retain that lease by sending renewal requests to the DHCP server.

The client attempts to renew the DHCP lease after it has used one half of the assigned lease time. Lease times can range from one minute to 999 days, twenty-three hours and fifty-nine minutes. Additionally, there is an option to configure DHCP scopes with unlimited lease time. This option ensures that DHCP leases will never expire for a specific scope.

Proper lease duration takes into consideration how frequently client computers must obtain new IP leases. At Microsoft many employees travel with their laptop computer. When these employees arrive at their travel destination and begin using their computers, they will be required to obtain a new IP address.

A situation in which a large number of computers are frequently relocated requires ITG to configure DHCP with a shorter lease time. An example of this would be a conference center that sees many new employees every day. These employees bring in their own laptops, connect them to a network in the morning, remove them at the end of the day, and may not return for many months. A reasonable lease time for this type of situation would be no more than twelve hours. In contrast, a longer lease time would be beneficial in an environment in which large numbers of machines remain on the same IP network for extended periods of time. The lease time is an important consideration because it allows ITG to configure its DHCP scopes to reclaim addresses so that they may be leased to new clients as needed.

Windows NT Server 4.0 did not include analysis tools that network administrators could easily use to optimize DHCP scopes for a given situation. Windows 2000 Advanced Server addresses this concern by integrating performance counters in DHCP. ITG used Performance Monitor, included with Windows 2000 Advanced Server, and the new performance counters to conduct detailed DHCP analysis on Windows 2000 Advanced Server-based DHCP servers.

ITG used a small-scale environment consisting of six DHCP scopes on two computers running the Windows 2000 Advanced Server network operating system. Studies of that environment revealed only minor changes in server utilization as scope lease times were changed from a four-day lease to an eight-day lease. During the same study only a slight decrease in the number of available leases was noted as the duration of lease time was doubled. The study was beneficial to gain experience interpreting the behavior of the performance counters.

Other study results were used to determine that a six-day lease time would benefit scopes that previously were configured with much longer or shorter lease durations. This determination was based on the observation that a six-day lease would allow IP addresses to return to the available lease pool before the lease pool had been significantly depleted. The standard was also based on the observation that DHCP servers were used less frequently when lease times were increased. The engineers who conducted the analysis found the performance counters included with Windows 2000-based DHCP to be very useful in the analysis of the behavior of DHCP scopes.

ITG found that a six-day lease time worked best for the Microsoft environment. Prior to deploying the six-day standard, ITG had used lease times ranging from one to eight days. ITG noted the following additional benefits after having used Performance Monitor to tune scope lease times to best fit their environment:

Reduction in Network Traffic — Many scopes used lease times that were too short in duration, resulting in excessive network traffic due to clients frequently renewing leases. Increasing the lease time on those scopes helped to reduce DHCP traffic considerably.

Improved Server Performance — Increasing the lease times on scopes that previously had used shorter lease times improved server performance by decreasing the number of requests from clients attempting to renew leases.

Anticipated Reduction in Helpdesk Support Calls — Performance Monitor will allow ITG to proactively monitor DHCP scopes to ensure that scopes have adequate leases. In the past ITG often relied on helpdesk technicians to report that scopes had become full. Now using Windows 2000-based DHCP, Performance Monitor provides technicians with information they need to take immediate action.

Legacy Client Configuration

The ability to add Dynamic DNS updates on behalf of legacy clients has been added to Windows 2000-based DHCP. This feature adds the capability to register both a forward and reverse lookup record in Dynamic DNS on behalf of the legacy client. The record may be recorded using either a secured or unsecured method.

ITG decided to configure Windows 2000-based DHCP servers to register records on behalf of legacy clients using the unsecured method. This configuration ensures that legacy clients will be able to update their own record if the legacy client is later upgraded to Windows 2000 or moves to another subnet. Had ITG used the secured method, the DHCP server would have become listed as the owner of records registered on behalf of legacy clients.

Windows 2000 Professional-based Client Configuration

Before ITG began using Windows 2000 Advanced Server, all DHCP clients were treated equally, and the DHCP server was unaware of the specific client types. This meant that the client configuration issued by DHCP servers needed to be common for all DHCP clients.

As an example, if a network scope had run low on available leases in the legacy environment, ITG would need to reduce lease times on the scope to increase the availability of leases. The method of reducing lease times caused all clients that used the scope to renew their IP addresses as often as every twelve hours. The side effect of reducing the lease times was an increased load on DHCP servers, and an increased potential for client related problems if the DHCP server stopped responding.

In the legacy environment DHCP allowed client computers to retain their lease even when the client was turned off. DHCP server would not expire a client's lease until the lease duration had expired. Windows 2000-based DHCP introduces a feature called Class ID's. A Class ID makes it possible to use a specific configuration based on the client type. Class ID's also make it possible to release unused addresses to the address pool before the client's lease has expired.

ITG's Windows 2000-based DHCP configuration calls for taking advantage of Class ID's on scopes that previously had shortages of addresses. This configuration ensures that if a client computer running the Windows 2000 operating system is properly shut down, the network address owned by the client will be returned to the active pool, so that other Windows 2000 Professional-based clients that need the address will receive it. Class ID's have provided the same benefits that short lease times had offered without any of the negative side effects associated with short lease times.

Lessons Learned

The following are a few key lessons ITG learned from its deployment of Windows 2000-based DHCP:

Reviewing the legacy DHCP environment was key to making improvements. — The review process was essential. The review helped to identify areas in the legacy environment that needed to be resolved, and allowed ITG to develop goals. By reviewing the legacy environment, and learning about new features integrated in Windows 2000 Advanced Server, ITG was able to significantly improve their environment.

Considering support for legacy clients was important. — ITG decided not to configure DHCP to register records on behalf of legacy clients using the unsecured method. This configuration ensures that legacy clients will be able to update their own records after the client has been upgraded to Windows 2000 or moved to another subnet.

DHCP automated the process of configuring clients to use DNS. — ITG's DNS design called for the association of network adapter configuration settings, such as domain name, to match the Windows 2000-based domain name that each computer needed to join. Windows 2000 domains essentially became a collection of network subnets, allowing ITG to use DHCP to automatically configure clients to use Dynamic DNS.

WINS Deployment

The Windows Internet Name Service (WINS) provides a distributed database for registering and querying dynamic computer name-to-IP address translations in a routed Transmit Control Protocol/ Internet Control Protocol (TCP/IP) network environment. WINS is required in legacy environments to provide support for dynamic registration of NetBIOS computer names to provide easy configuration and administration of Windows-based TCP/IP networks. WINS is included in Windows 2000 Advanced Server, to provide support for legacy environments, in which support for the Domain Name System (DNS), is not viable.

WINS allows employees to refer to computers using static easy-to-remember names, rather than by using the IP address associated with each computer; it also frees network administrators from the demands of updating static mapping files, such as LMHOST files. WINS, automatically updates the WINS database when dynamic addressing through DHCP results in new IP addresses for computers that move between subnets. Neither the user nor the network administrator needs to make manual accommodations for such name resolutions.

The latest version of WINS included in Windows 2000 is necessary to support computers running the Windows 95, Windows 98 and Windows NT Server operating systems. Dynamic DNS is the preferred name space in Windows 2000 Advanced Server, because it is based on standards more commonly used on the Internet. ITG took full advantage of Windows 2000-based WINS in the beta deployment of Windows 2000 Advanced Server to design an infrastructure that would support the interoperability of Windows 2000-based computers with those running older versions of Windows.

Windows NT Server, Windows 95 and Windows 98 rely on WINS to translate computer names to IP addresses. Within Microsoft, WINS is of vital importance to supporting older versions of Windows needed for compatibility testing. The following pages discuss areas within the legacy environment that ITG first reviewed to plan its deployment, the goals ITG established, and the actual deployment of WINS.

Deployment Planning

As a best practice, ITG keeps accurate and up-to-date network and server configuration records on file at all times. This practice greatly reduces the time that would otherwise be required to collect the information. ITG included details in its documentation that were specific to how the legacy WINS infrastructure and associated network components had been deployed.

The documentation included such things as diagrams illustrating the placement of:

• WINS servers, and those servers replication schedules

• ATM switches

• Regional carrier ATM switches

• Hub routers

• Leased lines

• Satellite networks

Prior to upgrading the internal computing infrastructure, ITG documented its legacy environment. The documentation consisted of complete and accurate inventory records, server placement, hardware and software standards, and logical and physical architecture diagrams. The documentation and diagrams helped ITG to develop goals for deploying Windows 2000 Advanced Server and to execute the deployment in a very careful and controlled fashion. The documentation included detailed information on server placement, WINS replication, client configuration and server configuration.

The legacy WINS environment consisted of thirty-four Windows NT Server 4.0-based WINS servers. The WINS servers were configured to replicate with one another every fifteen minutes on the Local Area Network (LAN) and one hour across the Wide Area Network (WAN). WINS replication ensures that each WINS server has accurate and up-to-date information.

Goals for the Deployment

After documenting and reviewing the legacy WINS environment, ITG developed the following goals for deploying Windows 2000-based WINS within the company:

• Retain existing server placement.

• Improve availability and fault tolerance of WINS environment.

• Standardize WINS server configurations throughout the company.

• Use WINS as an interim solution for name resolution until Dynamic DNS is fully deployed.

Overview of Windows 2000-based WINS

As part of its deployment planning, ITG needed to become familiar with new features included in the latest version of WINS, to understand the benefits of each, and formulate a deployment strategy to take advantage of them. The following are many of the key features of WINS that ITG took advantage of in its deployment.

The WINS administrative tools included in Windows 2000 Advanced Server have been enhanced to include improved management support such as enhanced filtering, faster record searching, dynamic record deletion, and improved export functionality. The tools include a new Microsoft Management Console (MMC) snap-in as well as a new console-based tool that may be used to script the administration of WINS. The Microsoft Management Console snap-in, used in performing WINS administration is included in Windows 2000 Advanced Server, and provides the following new functionality:

Enhanced filtering and record searching — simplifies WINS record searches. Administrators can now search for WINS records based on the type of record, such as File Server [20], RAS Client [21], and Domain Controller [1C]. The ability to more discreetly locate records simplified troubleshooting by allowing ITG to locate records faster than it could have in the past.

Dynamic record deletion — simplifies deletion of many records at once. Multi-select may be used to delete a number of records at once, using point-and-click record deletion.

Export function — simplifies exporting configuration details stored within the WINS database to an ASCII text file. Once the data is exported, administrators can easily import the data into Microsoft Excel to conduct any needed reporting and statistical analysis.

Manual tombstoning — The feature permits the state of deleted records to be recorded and replicated across all WINS servers, preventing records marked for deletion from being re-replicated.

The latest version of WINS, included in Windows 2000 Advanced Server includes built-in support for Persistent Connections, which provides the ability for WINS servers to maintain a constant connection with associated WINS replication partners. Persistent connections virtually eliminate the overhead of opening and closing network connections, noted in earlier versions of the product. ITG noted that persistent connections increased replication performance, resulting in servers replicating more quickly, and consistently.

Deploying WINS

Dynamic DNS is the preferred name space used within a Windows 2000-based infrastructure, replacing the legacy WINS infrastructure. DNS provides the name space used on the Internet, and Windows 2000 Advanced Server provides support for this natively with Dynamic DNS. Dynamic DNS is based on the same set of DNS standards that are widely used on the Internet.

However, within Microsoft WINS is required to support legacy clients, and Windows 2000 Advanced Server includes support for such an environment by including WINS. ITG upgraded its Windows NT Server 4.0-based WINS servers to Windows 2000 Advanced Server in order to take advantage of greater scalability and reliability while also providing the WINS support needed in interoperability testing.

For desktops that would not require support for WINS, upgrading them to Windows 2000 Professional, and then configuring those desktops to take advantage of Dynamic DNS, using DHCP, performed the transition to Dynamic DNS. The reliance on WINS diminished as desktop computers were upgraded to Windows 2000 Professional and configured to utilize Dynamic DNS.

Server Configuration Standards

The deployment of Windows 2000-based WINS within Microsoft called for developing two standard configurations for WINS servers. The configurations are specific to Microsoft's own unique infrastructure.

WINS servers are extremely disk-intensive. ITG configures its WINS servers to store the database on at least five spindles configured for hardware RAID 5. Table 6 illustrates standards that were deployed in Internet data centers. Table 7 illustrates standards that were deployed Intranet data centers. Computers running in the Internet data center are isolated from other areas of the company; therefore a separate standard was developed for those servers.

Table 6 WINS Standards Developed for Internet Data Center Use

Value	Data
Backup Path	D:\wins_database\backup
Backup dB on shutdown	Yes
Renew Interval	6 Days
Extinction Interval	6 Days
Extinction Timeout	6 Days
Verification Interval	24 Days
Enable periodic dB consistency Check	No
Log Database Changes	Yes
Log Detailed Events	No
Enable Burst Handling	Medium
Database Path	D:\wins_database\wins.mdb
Start Version Count	0
Replicate Only with Partners	Yes
Persistent Connections Push/Pull	Enabled
Migrate	No
Trigger Pull replication on initial start	Yes

Table 7 WINS Standards Developed for Servers Accessible Inside of Microsoft

Value	Data
Backup Path	D:\wins_database\backup
Backup dB on shutdown	Yes
Renew Interval	4 Days
Extinction Interval	4 Days
Extinction Timeout	6 Days
Verification Interval	24 Days
Enable periodic dB consistency Check	No
Log Database Changes	Yes
Log Detailed Events	No
Enable Burst Handling	Medium
Database Path	D:\wins_database\wins.mdb
Start Version Count	0
Replicate Only with Partners	Yes
Migrate	No
Trigger Pull replication on initial start	Yes
Persistent Connections Push/Pull	Enabled

Deploying Windows 2000 Advanced Server

Within Microsoft the majority of computers running Windows NT Server 4.0-based WINS were upgraded in place to Windows 2000 Advanced Server. The in place upgrade was simple and performed automatically by the Windows 2000 Advanced Server installation routine.

However, in a few cases ITG performed new installations of Windows 2000 Advanced Server while deploying WINS. In each case, the new installation was needed to also deploy faster hardware to take advantage of greater scalability in Windows 2000 Advanced Server. A backup and restore of vital WINS configuration settings had been required when an in-place upgrade was not viable.

The following precautions were taken deploying new hardware had been required. Prior to performing the new installations of Windows 2000 Advanced Server-based WINS, ITG backed up vital WINS configuration information, on its legacy servers, to ensure a smooth transition. The backup consisted of saving the following information on each Windows NT Server 4.0-based WINS server prior to performing the new installation:

• The WINS databases

• The registry key HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/WINS

After ensuring that it had backed up the legacy WINS server, ITG deployed Windows 2000 Advanced Server, to new hardware, and then installed WINS using the Windows Component Wizard included in Windows 2000 Advanced Server. The wizard made installing WINS easy to do.

Once the WINS service was installed, ITG stopped the WINS service, restored the WINS database and registry key, which had been backed up earlier, then restarted the WINS service. To complete the configuration, ITG verified that the server was configured according to standards illustrated in Table 6 and Table 7. For information on monitoring and troubleshooting the WINS service, refer to the appendix.

Lessons Learned

Following are the key lessons learned from the deployment of Windows 2000-based WINS within Microsoft.

Careful planning was beneficial — ITG was able to upgrade its Windows NT Server 4.0-based WINS infrastructure to Windows 2000 Advanced Server without any significant disruption to the company. ITG was able to deploy in a very careful and controlled fashion, using documentation developed early in the planning stages. Having accurate and up-to-date network diagrams as well as software and hardware inventories helped ITG to assure that the deployment would not negatively impact internal employees.

Seamless upgrade from Windows NT Server 4.0 infrastructure — No change to the legacy Windows NT Server 4.0-based infrastructure was required to begin the transition to Windows 2000 Advanced Server. ITG carefully reviewed the placement of WINS servers and the WINS replication matrix early in the planning stages. Benchmarks were conducted to determine if any changes to the WINS infrastructure would be required. The findings indicated that server placement and network performance used in the legacy infrastructure were sufficient to begin the deployment of Windows 2000 Advanced Server-based WINS.

Higher reliability through a more robust database — The WINS database included in the latest version of WINS was found to be more robust and reliable than earlier versions. Since deploying Windows 2000 Advanced Server-based WINS within Microsoft, ITG has not experienced any form of corruption in the Jet database of its WINS servers.

WINS administrative tools are significantly better — The WINS administration tools included in Windows 2000 Advanced Server perform significantly better than older WINS administration tools. The new Microsoft Management Console administration tool adds support for filtering and record searching. The new NETSH WINS helper provides all of the functionality of the snap-in and provides an easy method to script WINS commands.

Conclusion

Microsoft's internal computing environment is a critical test bed on which to deploy beta products to ensure that they are fit for other large enterprises. Before releasing Windows 2000 Advanced Server and Windows 2000 Professional, ITG must sign off on the product by first deploying the products internally.

The deployment of Windows 2000-based DNS, WINS, and DHCP gave ITG an opportunity to improve Microsoft's own internal computing environment. The review of the legacy environment and the study of new features in Windows 2000 allowed ITG to plan its deployment to take full advantage of the many business-oriented features in Windows 2000.

Deploying the beta required careful planning, and then deploying in a very controlled fashion. ITG is sharing its experiences in deploying DNS, WINS, and DHCP within the company so that when applicable customers may learn from the experience. In the coming months, ITG will continued to share its deployment story with customers, so that customers may be more successful in deploying Windows 2000 Advanced Server and Windows 2000 Professional in their own environments.

For More Information

The latest information on Microsoft Windows 2000 Advanced Server and Windows 2000 Professional can be found at: https://www.microsoft.com/windows2000

For any questions, comments or suggestions on this document, or to obtain additional information about Microsoft IT Showcase, please send e-mail to showcase@microsoft.com

Appendix

Dynamic DNS Performance Monitor Counters

The following table illustrates Performance Monitor counters included in Windows 2000 Advanced Server that may be used to conduct detailed analysis of servers running the Dynamic DNS service. ITG used many of these counters in their analysis to better understand the characteristics of Dynamic DNS in their environment.

Performance Counter	Description
AXFRREQUESTRECEIVED	AXFR Request Received is the total number of full zone transfer requests received by the master DNS server.
AXFRREQUESTSENT	AXFR Request Sent is the total number of full zone transfer requests sent by the secondary DNS server.
AXFRRESPONSERECEIVED	AXFR Response Received is the total number of full zone transfer responses received by the secondary DNS server.
AXFRSUCCESSRECEIVED	AXFR Success Received is the total number of successful full zone transfers received by the secondary DNS server.
AXFRSUCCESSSENT	AXFR Success Sent is the total number of successful full zone transfers of the master DNS server.
CACHINGMEMORY	Caching Memory is the total caching memory used by DNS server.
DATABASENODEMEMORY	Database Node Memory is the total database node memory used by DNS server.
DYNAMICUPDATENOOP	Dynamic Update NoOperation is the total number of No-operation/Empty dynamic update requests received by the DNS server.
DYNAMICUPDATENOOP/Sec	Dynamic Update NoOperation/sec is the average number of No-operation/Empty dynamic update requests received by the DNS server in each second.
DYNAMICUPDATEQUEUED	Dynamic Update Queued is the total number of dynamic updates queued by the DNS server.
DYNAMICUPDATERECEIVED	Dynamic Update Received is the total number of dynamic update requests received by the DNS server.
DYNAMICUPDATERECEIVED/Sec	Dynamic Update Received/sec is the average number of dynamic update requests received by the DNS server in each second.
DYNAMICUPDATEREJECTED	Dynamic Update Rejected is the total number of dynamic updates rejected by the DNS server.
DYNAMICUPDATETIMEOUT	Dynamic Update Timeouts is the total number of dynamic update timeouts of the DNS server.
DYNAMICUPDATEWRITETODB	Dynamic Update Written to Database is the total number of dynamic updates written to the database by the DNS server.
DYNAMICUPDATEWRITETODB/Sec	Dynamic Update Written to Database/sec is the average number of dynamic updates written to the database by the DNS server in each second.
IXFRREQUESTRECEIVED	IXFR Request Received is the total number of incremental zone transfer requests received by the master DNS server.
IXFRREQUESTSENT	IXFR Request Sent is the total number of incremental zone transfer requests sent by the secondary DNS server.
IXFRRESPONSERECEIVED	IXFR Response Received is the total number of incremental zone transfer responses received by the secondary DNS server.
IXFRSUCCESSRECEIVED	IXFR Success Received is the total number of successful incremental zone transfers received by the secondary DNS server.
IXFRSUCCESSSENT	IXFR Success Sent is the total number of successful incremental zone transfers of the master DNS server.
IXFRTCPSUCCESSRECEIVED	IXFR TCP Success Received is the total number of successful TCP incremental zone transfers received by the secondary DNS server.
IXFRUDPSUCCESSRECEIVED	IXFR UDP Success Received is the total number of successful UDP incremental zone transfers received by the secondary DNS server.
NBSTATMEMORY	Nbstat Memory is the total Nbstat memory used by DNS server.
NOTIFYRECEIVED	Notify Received is the total number of notifies received by the secondary DNS server.
NOTIFYSENT	Notify Sent is the total number of notifies sent by the master DNS server.
RECORDFLOWMEMORY	Record Flow Memory is the total record flow memory used by DNS server.
RECURSIVEQUERIES	Recursive Queries is the total number of recursive queries received by DNS server.
RECURSIVEQUERIES/Sec	Recursive Queries/sec is the average number of recursive queries received by DNS server in each second.
RECURSIVEQUERYFAILURE	Recursive Query Failure is the total number of recursive query failures.
RECURSIVEQUERYFAILURE/Sec	Recursive Query Failure/sec is the average number of recursive query failures in each second.
RECURSIVETIMEOUT	Recursive Timeouts is the total number of recursive query sending timeouts.
RECURSIVETIMEOUT/Sec	Recursive TimeOut/sec is the average number of recursive query sending timeouts in each second.
SECUREUPDATEFAILURE	Secure Update Failure is the total number of secure updates failed of the DNS server.
SECUREUPDATERECEIVED	Secure Update Received is the total number of secure update requests received by the DNS server.
SECUREUPDATERECEIVED/Sec	Secure Update Received/sec is the average number of secure update requests received by the DNS server in each second.
TCPMESSAGEMEMORY	TCP Message Memory is the total TCP message memory used by DNS server.
CPQUERYRECEIVED	TCP Query Received is the total number of TCP queries received by DNS server.
TCPQUERYRECEIVED/Sec	TCP Query Received/sec is the average number of TCP queries received by DNS server in each second.
TCPRESPONSESENT	TCP Response Sent is the total number of TCP responses sent by DNS server.
TCPRESPONSESENT/Sec	TCP Response Sent/sec is the average number of TCP responses sent by DNS server in each second.
TOTALQUERYRECEIVED	Total Query Received is the total number of queries received by DNS server.
TOTALQUERYRECEIVED/Sec	Total Query Received/sec is the average number of queries received by DNS server in each second.
TOTALRESPONSESENT	Total Response Sent is the total number of responses sent by DNS server.
TOTALRESPONSESENT/Sec	Total Response Sent/sec is the average number of responses sent by DNS server in each second.
UDPMESSAGEMEMORY	UDP Message Memory is the total UDP message memory used by DNS server.
UDPQUERYRECEIVED	UDP Query Received is the total number of UDP queries received by DNS server.
UDPQUERYRECEIVED/Sec	UDP Query Received/sec is the average number of UDP queries received by DNS server in each second.
UDPRESPONSESENT	UDP Response Sent is the total number of UDP responses sent by DNS server.
UDPRESPONSESENT/Sec	UDP Response Sent/sec is the average number of UDP responses sent by DNS server in each second.
WINSLOOKUPRECEIVED	WINS Lookup Received is the total number of WINS lookup requests received by the server.

The following are DNS-specific objects and counters that helped ITG to assess system requirements based on server activity, as well as to identify issues that were consuming an inordinate amount of system resources.

DNS-Specific Triggers	Description
CACHINGMEMORY	Caching Memory is the total caching memory used by DNS server.
DYNAMICUPDATEQUEUED	Dynamic Update Queued is the total number of dynamic updates queued by the DNS server.
DYNAMICUPDATERECEIVED/Sec	Dynamic Update Received/sec is the average number of dynamic update requests received by the DNS server in each second.
RECURSIVEQUERIES/Sec	Recursive Queries/sec is the average number of recursive queries received by DNS server in each second.
RECURSIVEQUERYFAILURE/Sec	Recursive Query Failure/sec is the average number of recursive query failures in each second.
RECURSIVETIMEOUT/Sec	Recursive TimeOut/sec is the average number of recursive query sending timeouts in each second.
TCPQUERYRECEIVED/Sec	TCP Query Received/sec is the average number of TCP queries received by DNS server in each second.
TOTALQUERYRECEIVED/Sec	Total Query Received/sec is the average number of queries received by DNS server in each second.
TOTALRESPONSESENT/Sec	Total Response Sent/sec is the average number of responses sent by DNS server in each second.
WINSLOOKUPRECEIVED/Sec	WINS Lookup Received/sec is the average number of WINS lookup requests received by the server in each second.
WINSRESPONSESENT/Sec	WINS Response Sent/sec is the average number of WINS lookup responses sent by the server in each second.
WINSREVERSELOOKUPRECEIVED/Sec	WINS Reverse Lookup Received/sec is the average number of WINS reverse lookup requests received by the server in each second.
WINSREVERSERESPONSESENT/Sec	WINS Reverse Response Sent/sec is the average number of WINS Reverse lookup responses sent by the server in each second.
ZONETRANSFERFAILURE	Zone Transfer Failure is the total number of failed zone transfers of the master DNS server.
ZONETRANSFERSUCCESS	Zone Transfer Success is the total number of successful zone transfers of the master DNS server.

Dynamic DNS Specific Event Log Entries

DNS specific events are displayed using the Windows NT Event Viewer. The Events are located in the DNS event log and must be viewed with a Windows 2000 Event Viewer. The following are DNS events that ITG monitors.

Event ID	7052
Error	Error
Description	DNS server send {} function failed. The data is the error
Action	Check for other error such as aborted zone transfers.

WINS Events

Any event logged on a WINS server should be investigated to determine if the event warrants any needed action. Following are WINS-specific events that ITG will investigate.

Event ID	Description
4224	WINS encountered a database error. This may or may not be a serious error. WINS will try to recover from it. You can check the database error events under 'Application Log' category of event viewer for the ESEXX source to find out more details about database errors. If you continue to see a large number of these errors consistently over time (a span of few hours), a restore of the database may be needed. The error number is in the second DWORD of the data section below. (This database error is registered in the Application log as an ESENT event 404, 405, or 406)
4187	The Name Registration Response could not be sent due to some error. This error was encountered by the Name Challenge Thread.
4202	An attempt to connect to the remote WINS server with address XXXX.XXXX.XXXX.XXXX returned with an error. Check to see that the remote WINS server is running and available, and that WINS is running on that server.
4243	WINS Pull thread encountered an exception during the process of sending a push notification to another WINS. The exception code is given below in the data section.
4260	WINS handled an error while registering replicas. It will not register any additional replicas of this WINS (address is in data section 4th-8th byte; also check previous log entry) at this time. Check a previous log entry to determine the reason for this. If this error persists over time, that is, you get the same error during subsequent replication with the above partner WINS, a restore of the database may be needed.
4302	WINS encountered an error doing backup of the database to directory d:\wins-database\backup\wins_bak.

WINS Capacity Triggers

Following are WINS-specific performance objects and counters that helped assess system requirements based on client activity. The objects and counters may be viewed using the Performance Monitor tool, included in Windows 2000.

WINS Objects and Counters	Description
Failed Queries/sec	Total Number of Failed Queries/sec
Failed Releases/sec	Total Number of Failed Releases/sec
Group Conflicts/sec	Group Conflicts/sec is the rate at which group registration received by the WINS server resulted in conflicts with records in the database.
Group Registrations/sec	Group Registrations/sec is the rate at which group registrations are received by the WINS server.
Group Renewals/sec	Group Renewals/sec is the rate at which group renewals are received by the WINS server
Queries/sec	Total Number of Queries/sec is the rate at which queries are received by the WINS server.
Releases/sec	Total Number of Releases/sec is the rate at which releases are received by the WINS server.
Successful Queries/sec	Total Number of Successful Queries/sec
Successful Releases/sec	Total Number of Successful Releases/sec
Total Number of Conflicts/sec	Total Number of Conflicts/sec is the sum of the Unique and Group conflicts per sec. Conflicts were seen by the WINS server at this total rate.
Total Number of Registrations/sec	Total Number of Registrations/sec is the sum of the Unique and Group registrations per sec. This is the total rate at which registration are received by the WINS server.
Total Number of Renewals/sec	Total Number of Renewals/sec is the sum of the Unique and Group renewals per sec. Renewals are received by the WINS server at this total rate.
Unique Conflicts/sec	Unique Conflicts/sec is the rate at which unique registrations/renewals received by the WINS server resulted in conflicts with records in the database.
Unique Registrations/sec	Unique Registrations/sec is the rate at which unique registration are received by the WINS server.
Unique Renewals/sec	Unique Renewals/sec is the rate at which unique renewals are received by the WINS server.