• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    Resolving NetBIOS Names Using WINS

    The venerable Windows Internet Name Service (WINS) is an alternative to statically mapping names and IP addresses in Lmhosts. WINS maintains a database of NetBIOS names and IP address mappings that WINS clients use to register their own NetBIOS services and to find the IP addresses of the services running on other WINS clients.

    WINS is based on protocols and services defined in RFC 1001, "Protocol Standard For A NetBIOS Service On A TCP/UDP Transport: Concepts And Methods," and RFC 1002, "Protocol Standard For A NetBIOS Service On A TCP/UDP Transport: Detailed Specifications." These are public standards but, in practice, Microsoft WINS is the only commercial NetBIOS name service.

    Resolving Names over Dial-Up Connections

    The Routing and Remote Access Services (RRAS) service in Windows Server 2003 can be configured to permit broadcast-based name resolution across a dial-in connection. This eliminates the need for Lmhosts files and special mapping procedures on dial-in clients, at least in small networks. For routed networks where the target host lies on the other side of a router, you may still need an Lmhosts file.

    WINS is, without a doubt, the single most pernicious cause of weird, inexplicable behavior in a classic NT network. Managing WINS in a large network is one of the most complex duties of a classic NT administrator. Thankfully, the need for WINS is diminishing thanks to Dynamic DNS.

    This section provides an overview of installing, configuring, and troubleshooting WINS on Windows Server 2003.

    WINS Functional Overview

    WINS works like a bridal registry, where happy couples go to Nordstrom's or Wal-Mart and register their wedding plans so their friends can go to the store and resolve their gift-buying decisions. With WINS, clients go to a WINS server to register their NetBIOS names and services so that other WINS clients can query WINS to resolve NetBIOS names and services into IP addresses. Let's look at registration first.

    Name Registration Using WINS

    Here is a typical sequence of events when a client registers itself with its WINS server:

    1. When the WINS client comes up on the network, it sends a name registration request to its WINS server. The client sends a separate registration request for each of its SMB-based services. For example, if the client is running the Server, Workstation, and Messenger services, it would submit three registration requests to WINS.

      If the client has multiple network adapters (also known as a multihomed WINS client), it submits registration requests for each service on each adapter.

    2. If the WINS database at the server contains no other records that use the name or IP address that the client is requesting, the WINS server returns a positive name registration response and adds the records to its database along with a renewal interval after which the registration expires. The client must renew the registration within this period. By default, the renewal interval is six days.

    3. If the WINS database at the server contains a record with the same name but different IP address, the WINS server tells the client to wait for a short time (five minutes) while it sends a name query request to the client that already has the registration. If the existing client responds, the WINS server sends a negative name registration response to the requesting client.

      If an existing client does not respond to the name query request, the WINS server returns a positive response to the requesting client and modifies the records in the database. It also starts a new renewal interval.

    4. At the halfway point of the renewal interval, the client sends a renewal request to the WINS server for each registered service. The server responds and the renewal interval clock is reset.

    5. If the WINS client goes off the network using a standard shutdown process, it sends a name release to its WINS server.

    6. The server marks the associated records as released and assigns an extinction interval to the record. During the extinction interval, the released record is not replicated. The owner server is free to reassign the name or address to another client, but replication partners are not. This interval simplifies reregistration when the client comes back online.

    In short, the name registration cycle for a WINS client consists of the following:

    • A registration request followed by a registration response informing the client that it owns the name

    • A period of active status during which the client periodically renews its registration

    • A release request followed by a release response telling the client that it no longer owns the name

    • A period of released status during which the client can be reregistered quickly

    Selective Domain Responses

    It sometimes happens that you want to decommission a particular NetBIOS domain. This can happen during domain consolidation or migration from an NT domain to a Windows Server 2003 domain. When the domain is removed from the system, it leaves lingering records in WINS. You can elect to filter out a domain from the list of records that will be returned by a WINS server. The server returns a No-ACK rather than a useless resource record.

    Name Registration Failure Handling

    The WINS name registration process includes the following several features for handling common failure modes:

    • Failure to reregister. If a client releases a registration and does not subsequently reregister, the server waits until the end of the extinction interval and then assigns a status of tombstoned to the record. Tombstoned records are replicated so that other WINS servers know that the name and IP address are available should another client attempt to register using them. An extinction timeout interval is assigned to the tombstoned record. The default interval is six days. After this interval, the record is removed from the database during scavenging.

    • Failure to renew. If a client does not renew a registration within the renewal period, the record is assigned a status of released. The server assigns an extinction interval to the record after which it is tombstoned.

    • Failure to release. If a client does not release a registration within the renewal period, the record is released automatically. The server assigns an extinction interval to the record, after which it is tombstoned.

    • Unable to contact primary WINS server. If the primary WINS server is unavailable when the client attempts to renew a registration, the client can renew with its secondary WINS server, if one has been configured. This can lead to an awkward situation where the primary server has an active record and the secondary server has a released record. To prevent this, if the client releases a registration to a WINS server that is not the owner, the record is immediately tombstoned.

    • Client crash. The WINS server has no way of knowing whether a client goes offline abnormally until the end of the renewal interval. The client record stays active and the server continues to hand out the client's IP address in response to query requests. If a client gets the address for a crashed client and attempts to use it, the connection attempt will fail. The client reports this failure to the WINS server, which checks the status of the client using a name query request. If the WINS server gets no reply, it releases the record with an extinction interval.

    In a small network with one WINS server, this relatively simple sequence of events is sufficient to maintain database integrity, ensure name uniqueness, and give rapid response to lookup queries. In a big network with several WINS servers configured to replicate with each other, the situation becomes much more complex. Details are in "Functional Description of WINS Replication" later in the chapter. First, let's see how name resolution works.

    Name Resolution Using WINS

    When a WINS client needs to resolve a NetBIOS name associated with a service, the Netbt.sys driver sends a name lookup query to the WINS server. If the name contains a dot or is longer than 16 characters, Tcpip.sys considers it a DNS host name and uses the DNS resolver, not Netbt, to resolve the name.

    When a WINS server receives a lookup query, it locates the record in the Jet database that contains the name registrations. If the record exists and if it is marked active, the WINS server returns a name lookup response with the IP address.

    If a client is configured to use two WINS servers, a primary and a secondary, the client will query the secondary server if the primary server is unavailable.

    Client Name Resolution Options

    A Windows client can be configured to register and resolve NetBIOS names in one of two ways, broadcast or WINS. There are several combinations of these two methods. The combination used by a client is determined by its NetBIOS node type. There are four node types:

    • b-node (broadcast). The Netbt driver uses IP multicasts to register and resolve names. If there is a router, L3 switch, or intelligent bridge between the client and server, the name registration is only heard on the local subnet. This results in user complaints such as, "I'm looking in My Network Places and I can see the servers in my building but I can't see the servers in Building 303." b-node is the default node type if WINS is not enabled.

    • p-node (point-to-point). This method uses WINS exclusively. If a p-node client cannot find its WINS server, all registrations and resolutions fail.

    • m-node (mixed). This method avoids the complete reliance on WINS by first using broadcasts to resolve a name on a local subnet and contacting the WINS server if the broadcast fails.

    • h-node (hybrid). This method is not defined in RFC 1001 or 1002. Microsoft introduced it to reduce the broadcast traffic produced by m-node clients. An h-node client contacts WINS first and then falls back on local broadcasts only if the WINS query fails. This is the default node type if WINS is enabled.

    Choosing a node type is a matter of balancing convenience, fault tolerance, and operational stability. b-node is generally a poor choice in all but the smallest networks. If you have a Windows server, you should configure it as a WINS server.

    m-node is inadvisable for pretty much the same reason. Why broadcast if you have a WINS server? You may find situations, though, where an organization has slow WAN links and a single remote WINS server. If the majority of resources used by clients are local to their subnet, you can change the node type from h-node to m-node to increase the speed of local resource access.

    The real choice for node type, in most cases, is between p-node and h-node. Here you have to weigh your alternatives. h-node seems like the rational alternative; in practice, however, h-node clients frequently generate broadcasts even when a WINS server is available. Also, h-node clients exhibit a tendency to hang a long time at logoff because they insist on deregistering both with WINS and by broadcast.

    p-node clients, on the other hand, generate no broadcast traffic and break off the wire cleanly after they deregister at the WINS server, which takes a negligible amount of time. The problem with p-node is that you lose all NetBIOS name resolution if the WINS server goes down or is otherwise unavailable.

    If you have a secondary WINS server and you can respond quickly if a server goes unavailable, you should choose p-node. If you have only one WINS server and want to maintain service continuity if the server goes down, opt for h-node.

    Functional Description of WINS Replication

    It is theoretically possible to handle NetBIOS name resolution for an entire global enterprise with a single WINS server equipped with only moderately powerful hardware (Pentium 400, 64MB RAM, 10MB NIC). Such a server can handle thousands of registrations a minute, enough to support a client community of 30,000 or so nodes.

    Issues of fault tolerance and WAN traffic must also be considered. Generally, you should distribute WINS servers to each major office or LAN installation. If you have hundreds of small networks, such as a retail business, however, you do not need a WINS server in each location. Set up regional WINS servers and use the WAN for name registration/resolution.

    Each WINS server maintains a database of the registration records requested by its clients. The server is said to be the owner of those records. A WINS server can replicate its database entries to other WINS servers that are configured as its replication partners. The servers each maintain a single database with records identified by owner. When a new replication partner is added, its database records are merged with the existing entries.

    WINS uses two replication modes, somewhat reminiscent of Dr. Doolittle—a Push mode and a Pull mode:

    • Push mode. When accumulated changes reach a preset level, the WINS server contacts its replication partners and sends them the updates. Push replication is event driven.

    • Pull mode. A particular WINS server's replication partners periodically poll for updates. Pull replication is time driven.

    Name registrations in the WINS databases of both partners are replicated to each other as they accumulate and at intervals throughout the day. WINS clients can use either these servers or both of them with one configured as a primary and the other as a secondary.

    Registry Tip: Configuring the Netbt Node Type

    You can set the Netbt node type in one of two ways. If you use DHCP, set scope option 44, WINS/NBNS Servers, to point at one or more WINS servers and then set scope option 46, WINS/NBT Node Type, for the desired node type. See Chapter 5 for details on configuring DHCP.

    For non-DHCP clients, configure the node type locally in the Registry as follows:

    Key:

    HKLM | System | CurrentControlSet | NETBT | Parameters

    Value:

    Type

    Data:

    1=b-node, 2=p-node, 4=m-node, 8=h-node

    The default is b-node if the client does not have a WINS server configured for an interface and h-node if it does.

    Registry Tip: WINS Database Parameters

    The WINS database is named Wins.mdb. It is a Jet database, similar to that used by Access but with a different and incompatible format. The database and its support files are located in \Windows\System32\Wins.

    The WINS database location and other WINS parameters are controlled by Registry keys under HKLM | System | CurrentControlSet | Services | WINS. The Partners key under WINS contains the IP address and control parameters for replication partners, if any.

    WINS uses TCP/UDP port 42 for replication. This port was originally designated for Home Name Server (a kind of super Hosts file) that was abandoned in favor of DNS.

    Only updated records are replicated between replication partners. This minimizes network traffic. Each record has a version ID that increments when the record is updated. In push replication, the server sends records with a version ID higher than the last batch that was sent to that particular partner. In pull replication, the pull partner sends a replication request containing the highest version ID it has received from that partner. The partner then sends updates with a higher version ID.

    If you have a slow or expensive WAN link, you can use pull replication and set the replication interval relatively long. There are other possible combination of pushes and pulls, but for the most part they exist only for certification exam scenarios.

    When you set up replication between multiple WINS servers, try to create a defined replication topology. You can use a ring, similar to Active Directory replication, where each WINS server replicates to the server on either side. Or, you can use a hub-and-spoke, where all WINS servers replicate to a central master, which then distributes the updates to the other servers. Most large organizations opt for hub-and-spoke because it is easier to manage and limits the number of hops required to replicate a change to the other WINS servers. Or, you can set up a meshed topology where all servers replicate to each other. This last option gives you the fastest convergence, but is the most prone to database anomalies. Regardless of the topology, be careful not to set yourself up for replication loops.

      Previous Section Next Section