Windows Server 2008 Inside Out- P18

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:50

0
48
lượt xem
8
download

Windows Server 2008 Inside Out- P18

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tham khảo tài liệu 'windows server 2008 inside out- p18', công nghệ thông tin, quản trị mạng phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Chủ đề:
Lưu

Nội dung Text: Windows Server 2008 Inside Out- P18

  1. Troubleshooting the DNS Server Service 817 Section/Entry (Command) Description Example/Accepted Values fAutoCacheUpdate Indicates how server caching 0; default, saves all responses (/secureresponses) works. to name queries to cache. 1; saves only records in same DNS subtree to cache. fSlave (/isslave) Determines how the DNS 0; default, recursion is server responds when enabled. If the forwarder forwarded queries receive no does not respond, the server response. attempts to resolve the query itself using recursion. 1; recursion is disabled. If the forwarder does not respond, the server terminates the search and sends a failure message to the resolver. fNoRecursion Indicates whether the server 0; default, DNS server (/norecursion) performs recursive name performs if requested. resolution. 1; DNS server doesn’t perform recursion. fRoundRobin (/roundrobin) Indicates whether server 1; default, automatically load allows round robin load balances using round robin balancing when there are for any hosts with multiple A multiple A records for hosts. records. 0; disables round robin. fStrictFileParsing Indicates server behavior 0; default, continues to load, (/strictfileparsing) when it encounters bad logs error. records. 1; stops loading DNS file and logs error. fBindSecondaries Indicates the zone transfer 1; default, for pre-BIND 4.9.4 (/bindsecondaries) format for secondaries. compatibility. By default, DNS server is 0; enables compression and configured for compatibility multiple transfers on Windows with other DNS server types. secondaries and others with BIND 4.9.4 or later. fWriteAuthorityNs Indicates whether the 0; default, writes for referrals (/writeauthorityns) server writes NS records in only. the authority section of a 1; writes for all successful response. authoritative responses. fLocalNetPriority Determines the order in 1; returns records with similar (/localnetpriority) which host records are IP addresses first. returned when there are 0; returns records in the order multiple host records for the in which they are in DNS. Chapter 24 same name.
  2. 818 Chapter 24 Implementing and Managing DNS Section/Entry (Command) Description Example/Accepted Values Aging Configuration ScavengingInterval Indicates the number of 0x0; scavenging is disabled. (/scavenginginterval) hours between scavenging intervals. DefaultAgingState Indicates whether scavenging 0; default, scavenging is (/defaultagingstate) is enabled by default in new disabled. zones. 1; scavenging is enabled. DefaultRefreshInterval Indicates the default refresh 168 (set in hexadecimal) (/defaultrefreshinterval) interval in hours. DefaultNoRefreshInterval Indicates the default no- 168 (set in hexadecimal) (/defaultnorefreshinterval) refresh interval in hours. ServerAddresses Addr Count The number of IP addresses 1 configured on the server and Addr[0] => 192.168.1.50 the IP address used. ListenAddresses Addr Count The number and value of 1 IP addresses configured for Addr[0] => 192.168.1.50 listening for requests from clients. NULL IP Array when there are no specific IP addresses that are designated for listening for requests from clients. Forwarders Addr Count The number and value 1 of IP addresses of servers Addr[0] => 192.168.12.8 configured as forwarders. NULL IP Array when there are no forwarders. Forward timeout Timeout for queries to 3 (/forwardingtimeout) forwarders in seconds. Slave Indicates whether recursion is 0; recursion is enabled enabled. 1; recursion is disabled Another useful command for troubleshooting a DNS server is Dnscmd /Statistics. This command shows you the following information: DNS server time statistics, including server start time, seconds since start, and Chapter 24 stats of last cleared date and time Details on queries and responses, including total queries received, total responses sent; the number of UDP queries received and sent, UDP responses
  3. Troubleshooting the DNS Server Service 819 received and sent; and the number of TCP queries received and sent, TCP responses received and sent Details on queries by record, including the exact number of each type of record sent Details on failures and where they occurred, including recursion failures, retry limits reached, and partial answers received Details on the total number of dynamic updates, the status for each update type; later breakdowns on number and status of secure updates, the number of updates that were forwarded, and the types of records updated Details on the amount of memory used by DNS, including total amount of mem- ory used, standard allocations, and allocations from standard to the heap Save the Stats to a File Write the output of Dnscmd /Statistics to a file so that you don’t overflow the history buffer in the command prompt. This also allows you to go through the stats at your leisure. Type dnscmd ServerName /statistics > FileName, where ServerName is the name or IP address of the DNS server and FileName is the name of the file to use, such as dnscmd corpsvr02 /statistics > dns-stats.txt. Examine Zones and Zone Records Dnscmd provides several useful commands for helping you pinpoint problems with records. To get started, list the available zones by typing dnscmd ServerName /enum- zones, where ServerName is the name or IP address of the DNS server you want to check. The output shows a list of the zones that are configured as follows: Enumerated zone list: Zone count = 4 Zone name Type Storage Properties . Cache File _msdcs.cpandl.com Primary AD-Forest Secure 1.168.192.in-addr.arpa Primary AD-Legacy Secure Rev cpandl.com Primary AD-Domain Secure Aging Chapter 24 The zone names you can work with are listed in the fi rst column. The other values tell you the type of zone and the way it is configured as summarized in Table 24-2.
  4. 820 Chapter 24 Implementing and Managing DNS Table 24-2 Zone Entries and Their Meanings Column/Entry Description Type Cache A cache zone (server cache). Primary A primary zone. Secondary A secondary zone. Stub A stub zone. Storage AD-Forest Active Directory–integrated with forest-wide replication scope. AD-Legacy Active Directory–integrated with legacy replication scope to all domain controllers in the domain. AD-Domain Active Directory–integrated with domain-wide replication scope. File Indicates the zone data is stored in a file. Properties Secure Zone allows secure dynamic updates only and is a forward lookup zone. Secure Rev Zone allows secure dynamic updates only and is a reverse lookup zone. Secure Aging Zone allows secure dynamic updates only and is configured for scavenging/aging. Aging Zone is configured for scavenging/aging but isn’t configured for dynamic updates. Update Zone is a forward lookup zone configured to allow both secure and nonsecure dynamic updates. Update Rev Zone is a reverse lookup zone configured to allow both secure and nonsecure dynamic updates. Down Secondary or stub zone hasn’t received a zone transfer since startup. After you examine the settings for zones on the server, you can print out the zone records of a suspect zone by typing dnscmd ServerName /zoneprint ZoneName at the command prompt, where ServerName is the name or IP address of the DNS server and ZoneName is the name of the zone as reported previously. Consider the following example: dnscmd corpsvr02 /zoneprint cpandl.com Chapter 24
  5. Troubleshooting the DNS Server Service 821 Here, you want to examine the cpandl.com zone records on the CORPSVR02 server. The output from this command shows the records in this zone and their settings. Here is a partial listing: ; ; Zone: cpandl.com ; Server: corpsvr02.cpandl.com ; Time: Wed Mar 10 18:38:14 2008 UTC ; @ [Aging:3534235] 600 A 192.168.1.50 [Aging:3534235] 3600 NS corpsvr02.cpandl.com. 3600 SOA corpsvr02.cpandl.com. hostmaster. 383 900 600 86 400 3600 3600 MX 10 exchange.cpandl.com._msdcs 3600 NS corpsvr01.cpandl.com._gc._tcp.Default-First-Site-Name._sites [Aging:35265] 600 SRV 0 100 3268 corpsvr02.cpandl.com._kerberos._tcp.Default-First-Site-Name._sites [Aging:35235] 600 SRV 0 100 88 corpsvr02.cpandl.com._ldap._tcp.Default-First-Site-Name._sites [Aging:35335] 600 SRV 0 100 389 corpsvr02.cpandl.com._gc._tcp [Aging:3534265] 600 SRV 0 100 3268 corpsvr02.cpandl.com._kerberos._tcp [Aging:3534235] 600 SRV 0 100 88 corpsvr02.cpandl.com._kpasswd._tcp [Aging:3534235] 600 SRV 0 100 464 corpsvr02.cpandl.com.corpsvr02 [Aging:3534281] 3600 A 192.168.1.50 corpsvr17 3600 A 192.168.15.22 DomainDnsZones [Aging:3534265] 600 A 192.168.1.50 _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones [Aging:35365] 600 SRV 0 100 389 corpsvr02.cpandl.com._ldap._tcp.DomainDnsZones [Aging:3534265] 600 SRV 0 100 389 corpsvr02.cpandl.com.ForestDnsZones [Aging:3534265] 600 A 192.168.1.50 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones [Aging:35365] 600 SRV 0 100 389 corpsvr02.cpandl.com._ldap._tcp.ForestDnsZones [Aging:35365] 600 SRV 0 100 389 corpsvr02.cpandl.com.ny 3600 NS ns1.ny.cpandl.com.ns1.ny 3600 A 10.10.10.52 www 3600 CNAME corpsvr17.cpandl.com. As you can see from the listing, Dnscmd /Zoneprint shows all the records, even the ones created by Active Directory. This is particularly useful because it means you don’t have to try to navigate the many subfolders in which these SRV records are stored. Chapter 24
  6. CHAPTER 25 Implementing and Maintaining WINS WINS Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823 Configuring and Maintaining WINS . . . . . . . . . . . . . . . . 832 Setting Up WINS Servers . . . . . . . . . . . . . . . . . . . . . . . . 826 Enabling WINS Lookups Through DNS . . . . . . . . . . . . . 839 Configuring Replication Partners . . . . . . . . . . . . . . . . . . 828 W indows Internet Naming Service (WINS) enables computers to register and resolve NetBIOS names on IPv4 networks. WINS is not used with IPv6 net- works. WINS is maintained primarily for backward support and compatibility with legacy applications and early versions of Microsoft Windows, including Windows 95, Windows 98, and Windows NT, that used WINS for computer name resolution; or for networks running Windows 2000 or Windows Server 2003 that don’t have Active Directory deployed and thus don’t require DNS. On most large networks, WINS is needed to support legacy applications and computers running Windows 95, Windows 98, and Windows NT. If you are setting up a new network, you probably don’t need WINS. On an existing network running all Windows 2000, Windows XP, and Windows Server 2008 systems, only the Domain Name System (DNS) is needed because these computers rely exclu- sively on DNS for name resolution if Active Directory is deployed. Because WINS is not required, WINS support could be removed from the network. Doing so, however, would mean that legacy applications and services that rely on NetBIOS, such as the computer Browser service, would no longer function. WINS Essentials Like DNS, WINS is a client/server protocol. All Windows servers have a WINS service that can be installed to provide WINS services on the network. All Windows computers have a WINS client that is installed automatically. The Workstation and Server services on computers are used to specify resources that are available, such as file shares. These resources have NetBIOS names as well. NetBIOS Namespace and Scope WINS architecture is very different from DNS. Unlike DNS, WINS has a flat namespace and doesn’t use a hierarchy or tree. Each computer or resource on a Windows network has a NetBIOS name, which can be up to 15 characters long. This name must be unique on the network—no other computer or resource can have the same name. Although there are no extensions to this name per se that indicate a domain, a NetBIOS scope can be set in Dynamic Host Configuration Protocol (DHCP). 823
  7. 824 Chapter 25 Implementing and Maintaining WINS The NetBIOS scope is a hidden 16th character (suffi x) for the NetBIOS name. It is used to limit the scope of communications for WINS clients. Only WINS clients with Chapter 25 the same NetBIOS scope can communicate with each other. See “Configuring TCP/IP Options” on page 717 for details on setting the NetBIOS scope for computers that use DHCP. NetBIOS Node Types The way WINS works on a network is determined by the node type set for a client. The node type defi nes how name services work. WINS clients can be one of four node types: B-Node (Broadcast Node) Broadcast messages are used to register and resolve names. Computers that need to resolve a name broadcast a message to every host on the local network, requesting the IP address for a computer name. Best for small networks. P-Node (Peer-to-Peer Node) WINS servers are used to register and resolve com- puter names to Internet Protocol (IP) addresses. Computers that need to resolve a name send a query message to the server and the server responds. Best if you want to eliminate broadcasts. In some cases, however, resources might not be seen as available if the WINS server isn’t updated by the computer providing the resources. M-Node (Mixed Node) A combination of B-Node and P-Node. WINS clients first try to use broadcasts for name resolution. If this fails, the clients then try using a WINS server. Still means a lot of broadcast traffic. H-Node (Hybrid Node) A combination of B-Node and P-Node. WINS clients first try to use a WINS server for name resolution. If this fails, the clients then try broadcasts for name resolution. Best for most networks that use WINS servers because it reduces broadcast traffic. Small Networks Might Not Need a WINS Server On a small network without subnets and a limited number of computers, WINS clients can rely on broadcasts for name resolution. In this case, it isn’t necessary to set up a WINS server. WINS Name Registration and Cache WINS maintains a database of name to IP address mappings automatically. Whenever a computer or resource becomes available, it registers itself with the WINS server to tell the server the name and IP address it is using. As long as no other computer or resource on the network is using that name, the WINS server accepts the request and registers the computer or resource in its database.
  8. WINS Essentials 825 Name registration isn’t permanent. Each name that is registered has a lease period associated with it, which is called its Time to Live (TTL). A WINS client must reregister Chapter 25 its name before the lease expires and attempts to do so when 50 percent of the lease period has elapsed or when it is restarted. If a WINS client doesn’t reregister its name, the lease expires and is marked for deletion from the WINS database. During normal shutdown, a WINS client will send a message to the WINS server requesting release of the registration. The WINS server then marks the record for deletion. Whenever records are marked for deletion, they are said to be tombstoned. As with DNS clients, WINS clients maintain a cache of NetBIOS names that have been looked up. The WINS cache, however, is designed to hold only names looked up recently. By default, names are cached for up to 10 minutes and the cache is limited to 16 names. You can view entries in the NetBIOS cache by typing nbtstat -c at the com- mand prompt. WINS Implementation Details On most networks that use WINS, you’ll want to configure at least two WINS servers for name resolution. When there are multiple WINS servers, you can configure replica- tion of database entries between the servers. Replication allows for fault tolerance and load balancing by ensuring that entries in one server’s database are replicated to its replication partners. These replication partners can then handle renewal and release requests from clients as if they held the primary registration in the first place. WINS supports: Persistent connections In a standard configuration, replication partners establish and release connections each time they replicate WINS database changes. With persistent connections, replication partners can be configured to maintain a per- sistent connection. This reduces the overhead associated with opening and clos- ing connections and speeds up the replication process. Automatic replication partners Using automatic replication partners, WINS can automatically configure itself for replication with other WINS servers. To do this, WINS sends periodic multicast messages to announce its availability. These mes- sages are addressed to the WINS multicast group address (224.0.1.24), and any other WINS servers on the network that are listening for datagrams sent on this group address can receive and process the automatic replication request. After replication is set up with multicast partners, the partners use standard replication with either persistent or nonpersistent connections. Manual tombstoning Manual tombstoning allows administrators to mark records for deletion. A record marked for deletion is said to be tombstoned. This state is then replicated to a WINS server’s replication partners, which prevents the record from being re-created on a replication partner and then being replicated back to the original server on which it was marked for deletion. Record export The record export feature allows administrators to export the entries in the WINS database to a file that can be used for tracking or reporting on which clients are using WINS.
  9. 826 Chapter 25 Implementing and Maintaining WINS Setting Up WINS Servers Chapter 25 To make a computer running Windows Server 2008 into a WINS server, you must install the WINS service. This service doesn’t require a dedicated server and uses lim- ited resources in most cases. This means you could install the WINS service on a DNS server, DHCP server, or domain controller. The only key requirement is that the WINS service can be installed only on a computer with a static IPv4 address. Although you can install WINS on a server with multiple IPv4 address or multiple network interfaces, this isn’t recommended because the server might not be able to replicate properly with its replication partners. In most cases, you won’t want to configure a domain controller as a WINS server. You can install the WINS service by following these steps: 1. In Server Manager, select the Features node in the left pane and then click Add Features. This starts the Add Features Wizard. 2. On the Select Features page, select WINS Server and then click Next. 3. Click Install. When the wizard finishes installing the WINS service, click Close. After you install the WINS service, the WINS console is available on the Administra- tive Tools menu. Start the console by clicking Start, Administrative Tools, WINS. Then, select the WINS server you are working with to see its entries, as shown in Figure 25-1. Figure 25-1 The WINS console. The only key postinstallation task for the WINS service is to configure replication part- ners. However, you should check the Transmission Control Protocol/Internet Protocol (TCP/IP) configuration of the WINS server. It should have only itself listed as the WINS server to use and shouldn’t have a secondary WINS server. This prevents the WINS client on the server from registering itself with a different WINS database, which can cause problems. To set the server’s primary WINS server address to its own IP address and clear out any secondaries from the list, click Start and then click Network. In Network Explorer, click Network And Sharing Center on the toolbar. In Network And Sharing Center, click Manage Network Connections. In Network Connections, right-click the connection you
  10. Setting Up WINS Servers 827 want to work with and then select Properties. In the Properties dialog box, open the Internet Protocol (TCP/IP) Properties dialog box by double-clicking Internet Protocol Chapter 25 Version 4 (TCP/IPv4). Click Advanced to display the Advanced TCP/IP Settings dialog box, and then click the WINS tab. Set the WINS server’s IP address as the WINS server to use and remove any additional WINS server addresses. When you’re fi nished, click OK twice and then click Close. You can remotely manage and configure WINS. Simply start the WINS console, right- click the WINS node in the left pane, and select Add Server. In the Add Server dialog box, select WINS Server, type the name or IP address of the WINS server, and then click OK. The command-line counterpart to the WINS console is Netsh WINS. From the com- mand prompt on a computer running Windows Server 2008, you can use Netsh WINS to perform all the tasks available in the WINS console as well as to perform some addi- tional tasks that can’t be performed in the WINS console. To start Netsh WINS and access a particular WINS server, follow these steps: 1. Start a command prompt, and then type netsh to start Netsh. The command prompt changes to netsh>. 2. Access the WINS context within Netsh by typing wins. The command prompt changes to netsh wins>. 3. Type server followed by the Universal Naming Convention (UNC) name or IP address of the WINS server, such as \\wins2 or \\10.10.15.2. If the WINS server is in a different domain from your logon domain, you should type the fully qualified domain name (FQDN) of the server, such as \\wins2.cpandl.com. 4. The command prompt changes to netsh wins server>. You can now work with the selected server. If you later want to work with a different server, you can do this without having to start over. Simply type server followed by the UNC name or IP address of that server. Note Technically, you don’t need to type the double backslashes (\\) when you specify an IP address. You must, however, type \\ when you specify a server’s name or FQDN. Because \ of this discrepancy, you might want to use \\ all the time so that you won’t leave it out by accident when you need it.
  11. 828 Chapter 25 Implementing and Maintaining WINS TROUBLESHOOTING Resolving WINS replication errors Chapter 25 Most WINS replication errors involve incorrectly configured WINS servers. If you see replication errors in the event logs, check the TCP/IP configuration of your WINS serv- ers. Every WINS server in the organization should be configured as its own primary WINS server, and you should delete any secondary WINS server addresses. This ensures that WINS servers register their NetBIOS names only in their own WINS databases. If you don’t configure WINS in this way, WINS servers might register their names with other WINS servers. This can result in different WINS servers owning the NetBIOS names that a particular WINS server registers and, ultimately, to problems with WINS itself. For more information on this issue, see Microsoft Knowledge Base article 321208 (http://support.microsoft.com/default.aspx?scid=kb;en-us;321208). Configuring Replication Partners When you have two or more WINS servers on a network, you should configure replica- tion between them. When servers replicate database entries with each other, they are said to be replication partners. Replication Essentials There are two replication roles for WINS servers: Push partner A push partner is a replication partner that notifies other WINS servers that updates are available. Pull partner A pull partner is a replication partner that requests updates. By default, all WINS servers have replication enabled and replication partners are con- figured to use both push and pull replication. After a replication partner notifies a part- ner that there are changes using push replication, the partner can request the changes using pull replication. This pulls the changes down to its WINS database. In addition, all replication is done using persistent connections by default to increase efficiency. Because replication is automatically enabled and configured, all you have to do to start replication is tell each WINS server about the other WINS servers that are available. On a small network, you can do this using the automatic replication partners feature. Because this can cause a lot of broadcast traffic on medium or large networks that con- tain many clients and servers, you’ll probably want to designate specific replication partners to reduce broadcast traffic.
  12. Configuring Replication Partners 829 Configuring Automatic Replication Partners To configure automatic replication partners, follow these steps: Chapter 25 1. Start the WINS console. Right-click the WINS node in the left pane, and select Add Server. In the Add Server dialog box, select WINS Server, type the name or IP address of the WINS server, and then click OK. 2. Expand the server entry, right-click the Replication Partners entry in the left pane, and then select Properties. In the Replication Partners Properties dialog box, click the Advanced tab, as shown in Figure 25-2. Figure 25-2 Enable automatic replication. 3. Select the Enable Automatic Partner Configuration check box. 4. Use the Multicast Interval options to set the interval between multicast broadcasts to the WINS server group address. These broadcasts are used to tell other WINS servers about the availability of the server you are configuring. The default interval is 0 minutes, which disables WINS broadcasts. Registrations Remain Until Restart After a server is discovered and added as a partner through multicasting, the server remains as a configured partner until you restart the WINS service or until you restart the server. When WINS is shut down properly, part of the shutdown process is to send mes- sages to current replication partners and remove its registration.
  13. 830 Chapter 25 Implementing and Maintaining WINS 5. Use the Multicast Time To Live (TTL) combo box to specify how many links multicast broadcasts can go through before being discarded. The default is 2, Chapter 25 which would allow the broadcasts to be relayed through two routers. 6. Click OK. Multicast Through Routers Is Possible The Multicast TTL is used to allow the discovery broadcasts to be routed between sub- nets. This means you could use automatic replication partners on networks with subnets. However, routing isn’t automatic just because a datagram has a TTL. You must configure the routers on each subnet to forward multicast traffic received from the WINS multicast group address (224.0.1.24). Using Designated Replication Partners To designate specific replication partners, start the WINS console. Right-click the WINS node in the left pane, and select Add Server. In the Add Server dialog box, select WINS Server, type the name or IP address of the WINS server, and then click OK. Right-click the Replication Partners entry in the left pane, and select New Replication Partners. In the New Replication Partner dialog box, type the name or IP address of the WINS server that should be used as a replication partner, and then click OK. The repli- cation partner is added and listed as available in the WINS console. As shown in Figure 25-3, replication partners are listed by server name, IP address, and replication type. Figure 25-3 View replication partners in the WINS console. By default, the replication partner is configured to use both push and pull replication as well as persistent connections. After you configure a replication partner, the configu- ration is permanent. If you restart a server, you do not need to reconfigure replication partners. To view or change the replication settings for a replication partner, start the WINS console. Expand the server entry for the server you want to work with, and then select the Replication Partners entry in the left pane. Double-click the replication partner in
  14. Configuring Replication Partners 831 the details pane. This displays the replication partner’s Properties dialog box. Click the Advanced tab, as shown in Figure 25-4. Chapter 25 Figure 25-4 Configure replication partner settings. The configuration options are used as follows: Replication Partner Type—Sets the replication type as push, pull, or push/pull. Pull Replication Use Persistent Connection For Replication—Configures pull replication so a persistent connection is used. This reduces the time spent opening and closing connections and improves performance. Start Time—Sets the hour of the day when replication should begin using a 24-hour clock. Replication Interval—Sets the frequency of replication. The default is every 30 minutes. Push Replication Use Persistent Connection For Replication—Configures push replication so a persistent connection is used. This reduces the time spent opening and closing connections and improves performance. Number Of Changes In Version ID Before Replication—Can be used to limit rep- lication by allowing replication to occur only when a set number of changes have occurred in the local WINS database.
  15. 832 Chapter 25 Implementing and Maintaining WINS Note Chapter 25 By default Number Of Changes In Version ID Before Replication is set to 0, which allows replication at the designated interval whenever there are changes. If you set a specific value, that many changes must occur before replication takes place. Configuring and Maintaining WINS WINS is fairly easy to configure and maintain after you set it up and replication part- ners are configured. The key configuration and maintenance tasks are related to the following issues: Configuring burst handling as the network grows Checking server status and configuration Checking active registrations and scavenging records if necessary Maintaining the WINS database Configuring Burst Handling If you configured the WINS server on a network with more than 100 clients, you should enable burst handling of registrations. As your network grows, you should change the burst-handling sessions as appropriate for the number of clients on the network. To configure burst handling of registration and name refresh requests, start the WINS con- sole. Right-click the server entry in the WINS console, and then select Properties. In the Properties dialog box, click the Advanced tab, as shown in Figure 25-5. Select the Enable Burst Handling check box, and then select a burst-handling setting. The settings available are the following: Low for handling up to 300 registration and name refresh requests Medium for handling up to 500 registration and name refresh requests High for handling up to 1,000 registration and name refresh requests
  16. Configuring and Maintaining WINS 833 Set a Custom Threshold for Burst Handling Chapter 25 You can also set a custom threshold value for burst handling. To do this, select Custom and then enter a threshold value between 50 and 5,000. For example, if you set the threshold to 5,000, up to 5,000 requests could be queued at once. Keep in mind that you would do this only if your network environment needs this setting. If you set the value to 5,000 but only need a queue that allows up to 100 name registration requests, you would waste a lot of server resources maintaining a very large queue that you don’t need. Figure 25-5 Set burst handling for medium and large networks. Checking Server Status and Configuration Using the WINS console, you can do the following: View the status of all WINS servers on the network by clicking the Server Status entry in the left pane. The status of the servers is then displayed in the right pane. View the current replication partners for a server by expanding the server entry and selecting Replication Partners in the left pane. The replication partners for that server are displayed in the right pane. View server statistics for startup, replication, queries, releases, registrations, and replication partners by right-clicking the server entry in the left pane and select- ing Display Server Statistics.
  17. 834 Chapter 25 Implementing and Maintaining WINS Using Netsh WINS, you can view server statistics by typing the command netsh wins server ServerName show statistics Chapter 25 where ServerName is the name or IP address of the WINS server you want to work with, such as \\WINS02 or 10.10.12.15. An example of the statistics follows: ***You have Read and Write access to the server corpsvr02.cpandl.com*** WINS Started : 3/10/2008 at 14:46:1 Last initialization : 3/12/2008 at 02:14:12 Last planned scavenging : 3/19/2008 at 12:30:25 Last admin triggered scavenging : 3/10/2008 at 16:52:24 Last replicas tombstones scavenging : 3/21/2008 at 09:12:26 Last replicas verification scavenging : 3/23/2008 at 12:38:9 Last planned replication : 3/10/2008 at 16:20:39 Last admin triggered replication : 3/27/2008 at 08:27:30 Last reset of counter : 4/01/2008 at 18:23:45 Counter Information : No of U and G Registration requests = (250 222) No of Successful/Failed Queries = (812/67) No of U and G Refreshes = (213 144) No of Successful/Failed Releases = (68/12) No of U. and G. Conflicts = (12 10) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WINS Partner IP Address -No. of Replication -No. of Comm Failure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 192.168.15.18 - 153 - 2 These statistics are useful for troubleshooting registration and replication problems. Scavenging and replication are automatic once configured. Problems to look for include the following: Replication If there are problems with replication, you should see a high number of communication failures relative to the number of replications. Check the links over which replication is occurring to see if there are intermittent failures or times when links aren’t available. Name resolution If WINS clients are having problems with name resolution, you’ll see a high number of failed queries. You might need to scavenge the data- base for old records more frequently. Check the server statistics for the renew interval, extinction interval, extinction timeout, and verification interval or the Intervals tab in the server’s Properties dialog box. Registration release If WINS clients aren’t releasing registrations properly, you’ll see a high number of failed releases. Clients might not be getting shut down properly.
  18. Configuring and Maintaining WINS 835 You can view the configuration details for a WINS server by typing the command netsh wins server ServerName show info Chapter 25 where ServerName is the name or IP address of the WINS server. The output looks like this: WINS Database backup parameter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Backup Dir : Backup on Shutdown : Disabled Name Record Settings(day:hour:minute) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Refresh Interval : 006:00:00 Extinction(Tombstone) Interval : 004:00:00 Extinction(Tombstone) TimeOut : 006:00:00 Verification Interval : 024:00:00 Database consistency checking parameters : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Periodic Checking : Disabled WINS Logging Parameters: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Log Database changes to JET log files : Enabled Log details events to System Event Log : Enabled Burst Handling Parameters : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Burst Handling State : Enabled Burst handling queue size : 500 Checking Active Registrations and Scavenging Records Using the WINS console, you can view the active registrations in the WINS database by expanding the server entry, right-clicking Active Registrations, and choosing Dis- play Records. In the Display Records dialog box, click Find Now without making any selections to see all the available records or use the filter options to specify the types of records you want to view, and then click Find Now. To tombstone a record manually, right-click it, and then select Delete. This deletes it from the current server, and this deletion is then replicated to other WINS servers; that is, the record will be replicated marked as Tombstoned. Netsh provides many ways to examine records in the WINS database. Because this is something you won’t use that frequently, the easiest way to do it is to list all available
  19. 836 Chapter 25 Implementing and Maintaining WINS records and write the information to a file that you can search. To do this, type the command Chapter 25 netsh wins server ServerName show database Servers={} where ServerName is the name or IP address of the WINS server. The output shows you the registration entries in the database as follows: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NAME -T-S-VERSION -G- IPADDRESS - EXPIRATION DATE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Retrieving database from the Wins server 192.168.1.50 CPANDL [1Bh]-D-A- 2 -U- 192.168.1.50 -3/25/2008 2:46:01 PM CORPSVR02 [00h]-D-A- 7 -U- 192.168.1.50 -3/25/2008 2:46:01 PM CORPSVR02 [20h]-D-A- 6 -U- 192.168.1.50 -3/25/2008 2:46:01 PM CPANDL [00h]-D-A- 4 -N- 192.168.1.50 -3/25/2008 2:46:01 PM CPANDL [1Ch]-D-A- 3 -I- 192.168.1.50 -3/25/2008 2:46:01 PM CPANDL [1Eh]-D-A- 1 -N- 192.168.1.50 -3/25/2008 2:46:01 PM WINS automatically scavenges the database to mark old records for deletion. To see when this is done, check the server statistics for the renew interval, extinction interval, extinction timeout, and verification interval on the Intervals tab in the server’s Proper- ties dialog box. You can initiate scavenging (referred to as an admin-triggered scavenging in the server statistics) by right-clicking the server entry in the WINS console and selecting Scav- enge Database. To initiate scavenging at the command prompt, type netsh wins server ServerName init scavenge, where ServerName is the name or IP address of the WINS server. After scavenging, the renew interval, extinction interval, extinction timeout, and verifi- cation interval are used to mark each record as follows: If the renew interval has not expired, the record remains marked as Active. If the renew interval has expired, the record is marked as Released. If the extinction interval has expired, the record is marked as Tombstoned. If the record was tombstoned, it is deleted from the database. If the record is active and was replicated from another server but the verification interval has expired, the record is revalidated. Maintaining the WINS Database The WINS database, like any database, should be maintained. You should routinely per- form the following maintenance operations: Verify the database consistency Compact the database Back up the database
Đồng bộ tài khoản