Tài liệu Windows Server 2008 Inside Out- P18 docx

Automatic replication partners Using automatic replication partners, WINS can automatically confi gure itself for replication with other WINS servers.. Simply start the WINS console, clic

Section/Entry (Command) Description Example/Accepted Values

fAutoCacheUpdate (/secureresponses) Indicates how server caching works 0; default, saves all responses to name queries to cache

1; saves only records in same DNS subtree to cache

fSlave (/isslave) Determines how the DNS

server responds when forwarded queries receive no response

0; default, recursion is enabled If the forwarder does not respond, the server 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 (/norecursion) Indicates whether the server performs recursive name

resolution

0; default, DNS server performs if requested

1; DNS server doesn’t perform recursion

fRoundRobin (/roundrobin) Indicates whether server

allows round robin load balancing when there are multiple A records for hosts

1; default, automatically load balances using round robin for any hosts with multiple A records

0; disables round robin

fStrictFileParsing (/strictfi leparsing) Indicates server behavior when it encounters bad

By default, DNS server is confi gured for compatibility with other DNS server types

1; default, for pre-BIND 4.9.4 compatibility

0; enables compression and multiple transfers on Windows secondaries and others with BIND 4.9.4 or later

fWriteAuthorityNs (/writeauthorityns) Indicates whether the server writes NS records in

the authority section of a response

0; default, writes for referrals only

1; writes for all successful authoritative responses

fLocalNetPriority (/localnetpriority) Determines the order in which host records are

returned when there are multiple host records for the same name

1; returns records with similar

IP addresses fi rst

0; returns records in the order

in which they are in DNS

Troubleshooting the DNS Server Service 817

Section/Entry (Command) Description Example/Accepted Values Aging Confi guration

ScavengingInterval (/scavenginginterval) Indicates the number of hours between scavenging

intervals

0x0; scavenging is disabled

DefaultAgingState (/defaultagingstate) Indicates whether scavenging is enabled by default in new

zones

0; default, scavenging is disabled

1; scavenging is enabled DefaultRefreshInterval

(/defaultrefreshinterval) Indicates the default refresh interval in hours 168 (set in hexadecimal) DefaultNoRefreshInterval

(/defaultnorefreshinterval) Indicates the default no-refresh interval in hours 168 (set in hexadecimal)

ServerAddresses

Addr Count The number of IP addresses

confi gured on the server and the IP address used

1Addr[0] => 192.168.1.50

ListenAddresses

IP addresses confi gured for listening for requests from clients NULL IP Array when there are no specifi c IP addresses that are designated for listening for requests from clients

1Addr[0] => 192.168.1.50

Forwarders

of IP addresses of servers confi gured as forwarders

NULL IP Array when there are

no forwarders

1Addr[0] => 192.168.12.8

Forward timeout (/forwardingtimeout) Timeout for queries to forwarders in seconds 3

enabled 0; recursion is enabled1; 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 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

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 ory used, standard allocations, and allocations from standard to the heap

mem-Save the Stats to a File

Write the output of Dnscmd /Statistics to a fi le so that you don’t overfl ow 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 fi le 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 zones, where ServerName is the name or IP address of the DNS server you want to

/enum-check The output shows a list of the zones that are confi gured 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 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 confi gured as summarized in Table 24-2

Save the Stats to a File

Write the output of Dnscmd /Statistics to a fi le so that you don’t overfl ow 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 fi le to use, such as

dnscmd corpsvr02 /statistics > dns-stats.txt.

Troubleshooting the DNS Server Service 819

Table 24-2 Zone Entries and Their Meanings Column/Entry Description

Type

Cache A cache zone (server cache)

Secondary A secondary 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 fi le

Update Zone is a forward lookup zone confi gured to allow both secure and

nonsecure dynamic updates

Update Rev Zone is a reverse lookup zone confi gured 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

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

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

Troubleshooting the DNS Server Service 821

Windows 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 fi le shares These resources have NetBIOS names as well

NetBIOS Namespace and Scope

WINS architecture is very different from DNS Unlike DNS, WINS has a fl at 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 Confi guration Protocol (DHCP)

WINS Essentials 823

Setting Up WINS Servers 826

Configuring Replication Partners 828

Configuring and Maintaining WINS 832

Enabling WINS Lookups Through DNS 839

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 the same NetBIOS scope can communicate with each other See “Confi guring 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 puter names to Internet Protocol (IP) addresses Computers that need to resolve

com-a ncom-ame send com-a query messcom-age to the server com-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 fi rst try to use broadcasts for name resolution If this fails, the clients then try using a WINS server Still means a lot of broadcast traffi c

H-Node (Hybrid Node) A combination of B-Node and P-Node WINS clients fi rst 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 traffi c

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

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.

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 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 confi gure at least two WINS servers for name resolution When there are multiple WINS servers, you can confi gure 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 fi rst place

WINS supports:

Persistent connections In a standard confi guration, replication partners establish and release connections each time they replicate WINS database changes With persistent connections, replication partners can be confi gured 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 confi gure 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 fi le that can be used for tracking or reporting

on which clients are using WINS

Setting Up WINS Servers

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 confi gure 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 fi nishes installing the WINS service, click Close

After you install the WINS service, the WINS console is available on the 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 confi gure replication ners However, you should check the Transmission Control Protocol/Internet Protocol (TCP/IP) confi guration 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

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 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 confi gure WINS Simply start the WINS console, 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-The command-line counterpart to the WINS console is Netsh WINS From the mand prompt on a computer running Windows Server 2008, you can use Netsh WINS

com-to perform all the tasks available in the WINS console as well as com-to perform some tional tasks that can’t be performed in the WINS console To start Netsh WINS and access a particular WINS server, follow these steps:

prompt changes to netsh>

changes to netsh wins>

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

qualifi ed 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

TROUBLESHOOTING

Resolving WINS replication errors

Most WINS replication errors involve incorrectly confi gured WINS servers If you see replication errors in the event logs, check the TCP/IP confi guration of your WINS serv- ers Every WINS server in the organization should be confi gured 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 confi gure 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)

Confi guring Replication Partners

When you have two or more WINS servers on a network, you should confi gure tion between them When servers replicate database entries with each other, they are

replica-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 notifi es 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-fi gured to use both push and pull replication After a replication partner noticon-fi es a 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 effi ciency Because replication is automatically enabled and confi gured, all you have to do to start replication is tell each WINS server about the other WINS servers that are available

part-On a small network, you can do this using the automatic replication partners feature Because this can cause a lot of broadcast traffi c on medium or large networks that con-tain many clients and servers, you’ll probably want to designate specifi c replication partners to reduce broadcast traffi c

Confi guring Automatic Replication Partners

To confi gure automatic replication partners, follow these steps:

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

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 confi guring 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 confi gured 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

Registrations Remain Until Restart

After a server is discovered and added as a partner through multicasting, the server remains as a confi gured 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.

Configuring Replication Partners 829

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, which would allow the broadcasts to be relayed through two routers

Multicast Through Routers Is Possible

The Multicast TTL is used to allow the discovery broadcasts to be routed between 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 confi gure the routers on each subnet to forward multicast traffi c received from the WINS multicast group address (224.0.1.24)

sub-Using Designated Replication Partners

To designate specifi c 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 confi gured to use both push and pull replication

as well as persistent connections After you confi gure a replication partner, the confi ration is permanent If you restart a server, you do not need to reconfi gure replication partners

gu-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

Multicast Through Routers Is Possible

The Multicast TTL is used to allow the discovery broadcasts to be routed between 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 confi gure the routers on each subnet to forward multicast traffi c received from the WINS multicast group address (224.0.1.24).

the details pane This displays the replication partner’s Properties dialog box Click the Advanced tab, as shown in Figure 25-4

Figure 25-4 Configure replication partner settings

The confi guration 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—Confi gures 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—Confi gures 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 reprep-lication to occur only when a set number of changes have occurred in the local WINS database

Configuring Replication Partners 831

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 specifi c value, that many changes must occur before replication takes place

Confi guring and Maintaining WINS

WINS is fairly easy to confi gure and maintain after you set it up and replication ners are confi gured The key confi guration and maintenance tasks are related to the following issues:

part-Confi guring burst handling as the network grows Checking server status and confi guration

Checking active registrations and scavenging records if necessary Maintaining the WINS database

Confi guring Burst Handling

If you confi gured 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 confi gure 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

Note

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 specifi c value, that many changes must occur before replication takes place.

Set a Custom Threshold for Burst Handling

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 Confi guration

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

Set a Custom Threshold for Burst Handling

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.

Configuring and Maintaining WINS 833

Using Netsh WINS, you can view server statistics by typing the command

netsh wins server ServerName show statistics 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 verifi cation 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)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 192.168.15.18 - 153 - 2

These statistics are useful for troubleshooting registration and replication problems Scavenging and replication are automatic once confi gured 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 verifi cation 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

You can view the confi guration details for a WINS server by typing the command

netsh wins server ServerName show info 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 Verifi cation Interval : 024:00:00 Database consistency checking 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 play Records In the Display Records dialog box, click Find Now without making any selections to see all the available records or use the fi lter 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

Configuring and Maintaining WINS 835

records and write the information to a fi le that you can search To do this, type the command

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:

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 verifi cation interval has expired, the record

is revalidated

Maintaining the WINS Database

The WINS database, like any database, should be maintained You should routinely form the following maintenance operations:

Verify the database consistency Compact the database

Back up the database

Verifying the WINS Database Consistency

WINS can be confi gured to verify the database consistency automatically This tion checks and verifi es the registered names To confi gure automatic database consis-tency checks, follow these steps:

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 Right-click the server entry in the WINS console, and select Properties In

the Properties dialog box, click the Database Verifi cation tab, as shown in Figure 25-6

Figure 25-6 Set automatic verification of the WINS database

3 Select the Verify Database Consistency Every check box, and then set a check

interval Typically, you’ll want to perform this operation no more frequently than once every 24 hours

4 Use the Begin Verifying At section to set the time at which verifi cation checks are

started This time is on a 24-hour clock and the default time is 2 hours, 0 minutes, and 0 seconds, meaning 2:00 A.M If you wanted verifi cation checks to begin at 2:00 P.M instead, you would set the time to 14 hours, 0 minutes, and 0 seconds

5 Set other options as necessary, and then click OK

Configuring and Maintaining WINS 837

Compacting the WINS Database

The WINS database should be compacted periodically, at least once a month or once every other month, depending on how often computers are added to or removed from your network In addition to reducing the size of the database by squeezing out unneeded space that has been allocated and is no longer needed, compacting the data-base can improve performance and make the database more reliable

At the command prompt, you can compact the WINS database by following these steps:

1 Change to the WINS directory by typing cd %SystemRoot%\System32\Wins

2 Stop the WINS service by typing net stop wins

3 Compact the WINS database by typing jetpack wins.mdb winstemp.mdb

4 Start the WINS service by typing net start wins

Backing Up the WINS Database

By default, the WINS database is not backed up—but it should be You can perform manual or automatic backups To back up the WINS database manually, follow these steps:

1 Start the WINS console Right-click the server entry, and then select Back Up

Database

2 In the Browse For Folder dialog box, select the folder where the WINS server

should store the database backup fi les, and then click OK

3 The WINS server will then write the backup fi les to a subfolder of the designated

folder called Wins_bak When it fi nishes, click OK

To confi gure automatic backups of the WINS database, follow these steps:

1 Start the WINS console Right-click the server entry, and then select Properties

2 In the Properties dialog box, click Browse on the General tab

3 Use the Browse For Folder dialog box to select the folder where the WINS server

should store the database backup fi les, and then click OK The WINS server will write backup fi les to a subfolder of the designated folder called Wins_bak

5 Click OK Now whenever you shut down the server or the WINS service on the

server, the WINS service will back up the database to the designated folder

Restoring the WINS Database

If something happens to the WINS database, you can use the backup fi les to recover it

to the state it was in prior to the problem To restore the WINS database from backup, follow these steps:

1 Start the WINS console Right-click the server entry, point to All Tasks, and then

select Stop This stops the WINS service

2 Right-click the server entry again, and select Restore Database

3 In the Browse For Folder dialog box, select the parent folder of the Wins_bak

folder created during backup (not the Wins_bak folder itself), and click OK

4 The WINS server will then restore the database from backup When it fi nishes,

click OK

5 The WINS service will be restarted automatically

Enabling WINS Lookups Through DNS

You can enable WINS lookups through DNS This integration of WINS and DNS vides for an additional opportunity to resolve an IP address to a host name when nor-mal DNS lookups fail Typically, this might be necessary for clients that can’t register their IP addresses in DNS using dynamic updates

You enable WINS name resolution on a zone-by-zone basis from within the DNS sole Follow these steps:

1 In the DNS console, right-click the zone you want to work with, and then select

Properties

2 In the Properties dialog box, click the WINS or WINS-R tab as appropriate for the

type of zone The WINS tab is used with forward lookup zones and the WINS-R tab is used with reverse lookup zones

3 Select Use WINS Forward Lookup or Use WINS Reverse Lookup as appropriate

4 If you’re not using DNS servers running on Windows 2000 or later as secondary

servers, select Do Not Replicate This Record This ensures that the WINS record that is created during this confi guration won’t be replicated to servers that don’t support this feature

5 Type the IP address of a WINS server you want to use for name resolution, and

click Add Repeat this step for other WINS servers that should be used

Print services have changed substantially over the years and the changes for Windows Server 2008 offer many new features and improvements The techniques you need to master to successfully deploy print services are what this chapter is about You’ll fi nd detailed discussions on print services architecture, print server selection and optimization, printer hardware selection and optimization, printer connection deploy-ment, and more

Understanding Windows Server 2008 Print Services

In a perfect world, the printers used by an organization would be selected after ful planning You’d select the best printer for the job based on the expected use of the printer and the features required The reality is that in many organizations printers are purchased separately by departments and individuals without much thought given

care-to how the printer will be used Someone sees that a printer is needed and one is chased The result is that many organizations have a hodgepodge of printers Some printers are high-volume and others are low-volume, low-cost The high-volume print-ers are designed to handle heavy, daily loads from multiple users, and the low-volume, low-cost printers are designed to handle printing for small groups or individuals If you are responsible for printers in your department or the organization as a whole, you might want to look at ways to consolidate or standardize so the hodgepodge of printers spread around the department or throughout the organization is easier to manage and maintain

pur-All printers regardless of type have one thing in common: A device is needed to manage the communication between the printer and the client computers that want to print to

the printers This device is called a print server In most cases, a print server is a

com-puter running the Windows operating system When a Windows comcom-puter acts as a print server, it provides many services It provides clients with the drivers they need for printing It stores documents that are spooled for printing and maintains the associated print queue It provides for security and auditing of printer access

From a process perspective, it helps to understand how printing works so that you can better manage and better troubleshoot printing problems The way printing works

Understanding Windows Server 2008