test

Solaris PC NetLink 1.0 Administration Guide

Chapter 5 Implementing WINS and Maintaining Databases

This chapter provides detailed background information about the Windows Internet Name Service (WINS) that SunLink Server software incorporates, and considers important performance issues that can help you plan your network's implementation of WINS. Major sections dealing with such issues include:

This chapter also describes how to maintain databases--including WINS, the Access Control List (ACL), the NT Registry, the Securities Account Manager (SAM), the Binary Large Object (BLOB), and Share File--on a computer running the SunLink Server program.

The following tasks are covered in this chapter:

"How to Clean Up SunLink Server Databases"

"How to Back Up SunLink Server Databases"

"How to Restore Backed-Up Databases"

"How to Create an Automatic Schedule for Both Database Cleanup and Backup"

"How to View, Modify, or Delete Scheduled Database Maintenance Tasks"

"How to Compact the WINS Database"

About WINS and Its Function

Windows Internet Name Service (WINS) is a database of available network resources and the computers that own them. This database is kept on a WINS server. A computer seeking such a resource "asks" the WINS server to look up the address of the machine that owns the resource. This speeds up network performance and reduces traffic when compared with the alternative "broadcast" scheme of identifying network resources.

WINS for SunLink Server systems is fully compatible with Microsoft WINS client implementations, including Microsoft TCP/IP-32 for Windows for Workgroups 3.11, Windows 98, Windows 95, Windows NT Workstation, Windows NT Server, and the Microsoft Network Client, Version 3.0.

SunLink Server WINS can replicate name databases with other SunLink Server WINS computers, and with WINS for Windows NT systems.

Note -

You manage the NT functions of SunLink Server WINS and maintain it by using WINS Manager, the same Windows NT-based tool that you use to manage WINS for Windows NT. This allows both SunLink Server-based and Windows NT-based WINS servers to be managed from a single administrative tool on a single computer in the network.

About Name Resolution Services

SunLink Server WINS with TCP/IP requires a unique IP address and computer name for each computer on the network. Although programs use IP addresses to connect computers, administrators use "friendly" names to connect them. As a result, TCP/IP internetworks require a name resolution service that converts computer names to IP addresses and IP addresses to computer names.

An IP address is the unique address by which all other TCP/IP devices on the internetwork recognize that computer. For TCP/IP and the Internet, the computer name is the globally known system name, plus a Domain Name System (DNS) domain name. (On the local network, the computer name is the name that was supplied either during SunLink Server or Windows NT setup.) To ensure that both names and IP addresses are unique, a computer using NetBIOS over TCP/IP registers its name and IP address on the network during system startup.

NetBIOS and DNS Computer Names

SunLink Server networking components rely on a naming convention known as NetBIOS. In general, NetBIOS computer names consist of a single part.

In contrast, TCP/IP components rely on the DNS naming convention. DNS computer names consist of two parts: a host name and a domain name, which combined form the fully qualified domain name (FQDN).

Fortunately, NetBIOS computer names are compatible with DNS host names, making interoperability possible between the two types of components. SunLink Server software combines the NetBIOS computer name with the DNS domain name to form the FQDN.

Note -

In a SunLink Server system, the NetBIOS computer name defaults to the same name as the DNS host name. You can change the default if you need unique names.

A computer can use one or more of the following methods to ensure accurate name resolution in TCP/IP internetworks:

NetBIOS over TCP/IP (NetBT) Name Resolution

NetBIOS over TCP/IP (NetBT) is the session-layer network service that performs name-to-IP address mapping for name resolution. In the SunLink Server program, NetBT is implemented through WINS and broadcast name resolution. The two most important aspects of the related naming activities are registration and resolution:

Defined within NetBT are modes that specify how network resources are identified and accessed. The NetBT modes supported by SunLink Server software are:

The two most common node types for Windows client computers are b-node and h-node.

For DHCP users, the node type may be assigned by the DHCP server (depending on how the client has been configured). When WINS servers are in place on the network, NetBT resolves names on a client computer by communicating with the WINS server. When WINS servers are not in place, NetBT uses b-node broadcast messages to resolve names. NetBT also can use LMHOSTS files for name resolution, depending on how TCP/IP is configured on a particular computer.

SunLink Server software can respond to b-node and h-node NetBT modes.

B-Node (Broadcast Node)

The b-node mode uses broadcasts for name registration and resolution. For example, if CLIENT_PC1 wants to communicate with CLIENT_PC2, it will broadcast to all machines that it is looking for CLIENT_PC2 and then will wait a specified time for CLIENT_PC2 to respond.

The b-node mode has two major problems:

H-Node (Hybrid Node)

The h-node mode solves the most significant problems associated with broadcast messages and with routed-environment operations. It is a combination of b-node and another node type that uses broadcast messages as a last effort. If the WINS server is down--making broadcast messages a necessity--the computer continues to poll the WINS server until it can be reached again. The h-node also can be configured to use the LMHOSTS file after broadcast name resolution fails.

No broadcast messages are generated if the WINS server is running, and computers can be on opposite sides of routers. If the WINS server is down, b-node is used, allowing computers on the same side of a router to continue to operate as usual.

Note -

For Microsoft TCP/IP users who configure TCP/IP manually, h-node is used by default unless the user does not specify addresses for WINS servers when configuring TCP/IP.

Other Combinations

Another variation, known as modified b-node, is used in SunLink Server networks to allow messages to go across routers. The modified b-node does not use a WINS server. In this mode, b-node uses a list of computers and addresses stored in an LMHOSTS file. If a b-node attempt fails, the system looks in LMHOSTS to find a name and then uses the associated address to cross the router. However, each computer must have this list, which creates an administrative burden in maintaining and distributing the list.

Windows for Workgroups 3.11 uses a modified b-node system. Windows NT uses this method if WINS servers are not used on the network. In Windows NT, some extensions have been added to this file to make it easier to manage--but modified b-node is not an ideal solution.

WINS and Broadcast Name Resolution

WINS provides a distributed database for registering and querying dynamic computer name-to-IP address mappings in a routed network environment. WINS solves the problems that occur with name resolution in complex internetworks.

WINS reduces the use of local broadcasts for name resolution and allows users to locate systems easily on remote networks. Additionally, when dynamic addressing through DHCP results in new IP addresses for computers that move between subnets, the changes are updated automatically in the WINS database. Neither the user nor the network administrator needs to make changes manually.

The following sections discuss how name resolution is provided by WINS and name query broadcast messages.

WINS in a Routed Environment

WINS consists of the following two components:

Windows networking clients (WINS-enabled Windows NT, Windows 98, Windows 95, or Windows for Workgroups 3.11 computers) can use WINS directly. Non-WINS computers on the internetwork that are b-node compatible (as described in RFCs 1001 and 1002) can access WINS through proxies (WINS-enabled computers that listen to name-query broadcasts and then respond for names that are not on the local subnet).

To allow browsing without WINS, the network administrator must ensure that the users' primary domain has SunLink Server, Windows NT Server, or Windows NT Workstation computers on both sides of the router to act as master browsers. These computers need correctly configured LMHOSTS files with entries for the domain controllers across the subnet.

With WINS, such strategies are not necessary because the WINS servers and proxies transparently provide the support necessary for browsing across routers where domains span the routers.

Note -

If a client computer running Windows NT also is DHCP-enabled, and if the administrator specifies WINS server information as part of the DHCP options, the computer automatically will be configured with WINS server information.

In a WINS and broadcast name resolution environment, a WINS-enabled client computer will behave in a different manner than a non-WINS-enabled client computer. These differences will be apparent in the way these clients handle resolution, registration, release, and renewal, described in the next sections.

Name Resolution

With WINS servers in place on the internetwork, NetBIOS computer names are resolved using two basic methods depending on whether WINS resolution is available and enabled on the client computer. Regardless of which name resolution method is used, the process is not visible to the user after the system is configured.

WINS servers accept and respond to User Datagram Protocol (UDP) name queries. Any name-to-IP address mapping registered with a WINS server can be provided reliably as a response to a name query. However, a mapping in the database does not ensure that the related device is currently running, only that a computer claimed the particular IP address and that it currently is a valid mapping.

Name Registration

Name registration ensures that the NetBIOS computer name and IP address are unique for each device.

After a non-WINS computer claims a name, it must challenge duplicate name registration attempts (with a negative name registration response) and respond positively to name queries issued on its registered name (with a positive name query response). The positive name query response contains the IP address of the computer so that the two systems can establish a session.

Name Release

When a computer finishes using a particular name, it no longer challenges other registration requests for the name. This is referred to as releasing a name.

Name Renewal

Client computers periodically are required to renew their NetBIOS name registrations with the WINS server. When a client computer first registers with a WINS server, the WINS server returns a message that indicates when the client will need to renew its registration, as follows:

If the entry is owned by the local WINS server, the name is released at the specified time unless the client has renewed it. If the entry is owned by another WINS server, the entry is revalidated at the specified time. If the entry does not exist in the database of the WINS server that owns the entry, it is removed from the local WINS database. A name renewal request is treated as a new name registration.

Caution - Caution -

Incorrectly adjusting the renewal interval might adversely affect system and network performance.

WINS Proxy

A WINS proxy is a WINS-enabled computer that helps resolve name queries for non-WINS enabled computers in routed TCP/IP intranets. By default, non-WINS enabled computers are configured as b-node, which uses IP broadcasts for name queries. The WINS proxy computer listens on the local subnet for IP broadcast name queries.

When a non-WINS enabled computer sends an IP name query broadcast, the WINS proxy accepts the broadcast and checks its cache for the appropriate NetBIOS computer name-to-IP-address mapping. If the WINS proxy has the correct mapping in its cache, the WINS proxy sends this information to the non-WINS computer. If the name-to-IP-address mapping is not in cache, the WINS proxy queries a WINS server for the name-to-IP-address mapping.

If a WINS server is not available on the local subnet, the WINS proxy can query a WINS server across a router. The WINS proxy caches (stores in memory) computer name-to-IP-address mappings it receives from the WINS server. These mappings are used to respond to subsequent IP broadcast name queries from b-node computers on the local subnet.

The name-to-IP-address mappings that the WINS proxy receives from the WINS server are stored in the WINS proxy cache for a limited time. (By installation default, this value is six minutes. The minimum value is one minute.)

When the WINS proxy receives a response from the WINS server, it stores the mapping in its cache and responds to any subsequent name query broadcasts with the mapping received from the WINS server.

The role of the WINS proxy is similar to that of the DHCP/BOOTP relay agent, which forwards DHCP client requests across routers. Because the WINS server does not respond to broadcasts, a computer configured as a WINS proxy should be installed on subnets that include computers that use broadcasts for name resolution.

Note -

To configure a Windows NT, Version 4.0, computer as a WINS proxy, you must manually edit that computer's registry. The EnableProxy keyword must be set to 1 (REG_DWORD). This keyword is located in the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters

WINS and Dial-Up TCP/IP Networking Clients

Dial-up TCP/IP networking clients provide remote networking for telecommuters, mobile workers, and system administrators who monitor and manage servers at multiple branch offices. Users of dial-up TCP/IP networking on Windows 98, Windows 95, or Windows NT computers can dial in to access their networks remotely for services such as file and printer sharing, electronic mail, scheduling, and database access.

Windows 98, Windows 95, and Windows NT support routing TCP/IP traffic over dial-up TCP/IP connections through several different types of dial-up TCP/IP networking servers, including the following:

Dial-up Windows 98, Windows 95, and Windows NT computers that are configured to route TCP/IP also can be configured to use WINS servers. (For details, see your Microsoft documentation.)

Dial-up Windows 98, Windows 95, and Windows NT computers that are configured to route TCP/IP and use WINS can access remotely their networks for services, including SunLink Server and Windows NT file and print sharing, electronic mail, scheduling, and database access.

About WINS Server Planning

The number of WINS servers that an enterprise requires is based on the number of WINS client connections per server and the network topology. The number of users that can be supported per server varies according to usage patterns, data storage, and processing capabilities of the WINS server computer.

Planning for WINS server implementation on the network typically requires consideration of the issues presented in the following table.

Table 5-1 WINS Server Implementation Planning Issues

Planning Issue 

Guideline 

How many WINS servers are required to ensure distribution of name query and name registration loads throughout the network? 

One WINS server can handle NetBIOS name resolution requests for 10,000 computers. However, the location of routers on the network and the distribution of clients in each subnet should be considered when deciding how many WINS servers are required. See the following sections: "Planning for WINS Client Network Traffic," "Planning for WINS Server Performance," and "Planning Replication Partners and Proxies." 

Is the WAN bandwidth sufficient to support WINS server and WINS client name registration traffic? 

See the next section, "Planning for WINS Client Network Traffic." 

How many WINS servers are needed for disaster recovery, backup, and redundancy requirements? 

See "Planning for WINS Server Performance." 

How can a planned distribution of WINS servers throughout the network be validated before installation? 

When planning a network configuration, a generally accepted approach is to consider the consequences of two simultaneous failures at different points on the network. 

Planning for WINS Client Network Traffic

WINS clients generate the following types of network traffic:

When a WINS-enabled client starts on the network, it sends a name registration request for the computer name, user name, domain name, and any additional Microsoft network client services running on the computer. In other words, when a WINS client starts on the network, it generates a minimum of three name registration requests and three entries in the WINS database.

A SunLink Server-based WINS client usually registers more NetBIOS names than other WINS-enabled clients. The name registration requests generated by a computer running under the SunLink Server program include the following:

WINS Client Traffic on Routed Networks

When planning for WINS client traffic on large routed networks, consider the effect of name query, registration, and response traffic routed between subnets.

Name requests and responses that occur at the daily startup of computers must pass through the traffic queues on the routers and may cause delays at peak times.

Daily Startup of WINS Clients

An active WINS client name registration in a WINS server database is replicated to all pull partners configured on that WINS server. (See "Configuring Replication Partners" for an explanation of pull partners and push partners.) After some time, the active name registration is replicated to all WINS servers on the network.

When a WINS client is turned off at the end of the day, it releases the name. When the computer is started the next morning, the WINS client registers the name again with the WINS server and receives a new version ID. This new, active name registration entry is replicated to the WINS server's pull partners as on the previous day.

Therefore, the number of name registration entries that are replicated each day is roughly equivalent to the number of computers started each day times the number of NetBIOS names registered at each computer.

On large networks (50,000 or more computers), the biggest traffic load may be the name registration requests generated when WINS clients start on the network. Fortunately, the difference in time zones in large enterprise networks provides some distribution of this WINS client startup load.

Roving User

Name challenge traffic occurs when a user stops the computer and then moves and starts the computer on a different subnet with another primary WINS server.

Typically, the name registration request is answered with a Wait for Acknowledgment message (100 bytes), and the new WINS server, assuming the active entry was replicated, challenges the IP address that is currently in its database for this name (Name Query packet, 92 bytes).

When there is no reply, as can be expected in this case, the WINS server repeats the challenge two more times and then updates the name registration entry with the new IP address and a new version ID. The new version ID indicates that the entry must be replicated from its new "owning" WINS server to other WINS servers on the network.

Estimating WINS Client Traffic

You can estimate WINS client traffic based on the behavior of the WINS clients as described in the preceding sections.

However, when estimating WINS client traffic, you also must consider the network topology and the design or configuration of the routers in the network. In some cases it may not always be possible to predict the traffic load on a specific network router because the routers may be designed or configured to autonomously route traffic based on factors other than traffic load.

Planning for WINS Server Replication Across Wide Area Networks

The frequency of WINS database replication between WINS servers is a major planning issue. You should replicate the WINS database frequently enough that the down-time of any WINS server will not affect the reliability of the mapping information in the database of other WINS servers.

However, when planning WINS database replication frequency, you do not want the frequency to interfere with network throughput. This could occur if replication frequency is set to a short time interval.

Consider the network topology when planning for replication frequency. For example, if your network has multiple hubs connected by relatively slow wide area network (WAN) links, you can configure WINS database replication between WINS servers on the slow links to occur less frequently than replication on the local area network or on fast WAN links. This reduces traffic across the slow link and reduces contention between replication traffic and WINS client name queries.

For example, WINS servers at a central local area network site may be configured to replicate every 15 minutes, while database replication between WINS servers in different WAN hubs might be scheduled for every 30 minutes, and replication between WINS servers on different continents might be scheduled to replicate twice a day.

Planning for WINS Server Performance

When planning for a large-scale power outage where many computers will go on line simultaneously, the conservative recommendation is that you plan to include one WINS server and a backup server for every 10,000 computers on the network. A WINS server typically can service 1,500 name registrations per minute and 4,500 queries per minute.

Two factors enhance WINS server performance. WINS server performance can be increased by almost 25 percent on a computer with two processors. WINS server name replication response time can be improved measurably by using a dedicated disk.

After you establish WINS servers on an intranet, you can adjust the time between a WINS client name registration and name renewal. This is referred to as the Renewal Interval. Setting this interval to reduce the numbers of registrations can help tune server response time. (The Renewal Interval is specified in the WINS Server Configuration dialog box.)

Planning Replication Partners and Proxies

Choosing whether to configure another WINS server as a push partner or pull partner depends on several facts, including the specific configuration of servers at your site, whether the partner is across a wide area network (WAN), and how important it is to distribute changes throughout the network.

You should install only one computer configured as a WINS proxy on each subnet. Configuring more than one WINS proxy per subnet can overload the WINS servers on the same subnet.

In one possible configuration, you can designate one WINS server as the central server, and all other WINS servers as both push partner and pull partner of this central server. Such a configuration ensures that the WINS database on each server contains addresses for every node on the WAN.

Another option is to set up a chain of WINS servers, where each server is both the push partner and pull partner with a nearby WINS server. In such a configuration, the two servers at the ends of the chain would be push and pull partners with each other. Other replication partners can be established for your site's needs.

Configuring WINS Servers and WINS Client Behavior

You should configure multiple WINS servers on your network to increase the availability and balance the load among servers. When using multiple servers, each WINS server should be configured with at least one other WINS server as its replication partner. You should have multiple WINS servers installed on your network for the following reasons:

Configuring a WINS server includes specifying information about when database entries are replicated between partners. A pull partner is a WINS server that pulls in replicas of database entries from its partner by requesting and then accepting replicas. A push partner is a WINS server that sends update notification messages to its partner when its WINS database has changed. When its partner responds to the notification with a replication request, the push partner sends a copy of its current WINS database to the partner.

For each WINS server, you must configure threshold intervals for triggering database replication, based on a specific time, a time period, or a certain number of new records. If you designate a specific time for replication, this occurs one time only. If a time period is specified, replication is repeated at that interval.

Use WINS Manager to configure WINS server management of WINS client mappings by using the configuration options in the WINS Server Configuration - (Local) dialog box. The configuration options allow you to specify time intervals that govern WINS client behavior as described in the following table.

Table 5-2 WINS Server Time Interval Options

Configuration Option 

Description 

Renewal Interval 

Specifies how often a client reregisters its name. The default is six days. 

Extinction Interval 

Specifies the interval between when an entry is marked as released and when it is marked as extinct. The default is dependent on the renewal interval and, if the WINS server has replication partners, on the maximum replication time interval. The default is four days. 

Extinction Timeout 

Specifies the interval between when an entry is marked extinct and when the entry is finally scavenged from the database. The default is dependent on the renewal interval and, if the WINS server has replication partners, on the maximum replication time interval. The default is six days. 

Verify Interval 

Specifies the interval after which the WINS server must verify that old names it does not own are still active. The default is dependent on the extinction interval. The minimum allowable value is 24 days. 

The extinction interval, extinction timeout, and verify interval are derived from the renewal interval and the partner replication interval. The WINS server adjusts the values specified by the administrator to keep the inconsistency between a WINS server and its partners as small as possible.

You can change the following configuration parameters using the Advanced option in the WINS Server Configuration dialog box.

Table 5-3 WINS Server Advanced Configuration Options

Configuration Option 

Description 

Logging Enabled 

Specifies whether logging of database changes to J50.log files should be turned on. (This option is ignored in SunLink Server WINS.)

Log Detailed Events 

Specifies whether logging events is verbose mode. (This requires considerable computer resources and should be turned off if you are tuning for performance.) 

Replicate Only With Partners 

Specifies that replication occurs only with configured WINS pull or push partners. If this option is not checked, an administrator can ask a WINS server to pull or push from or to a non-listed WINS server partner. By default, this option is checked. 

Backup On Termination 

Specifies that the database will be backed up automatically when WINS Manager is stopped except when the computer is stopped. 

Migrate On/Off 

Specifies that static unique and multihomed records in the database are treated as dynamic when they conflict with a new registration or replica. This means that if they are no longer valid, they will be overwritten by the new registration or replica. By default, this option is not checked. 

Starting Version Count 

Specifies the highest version ID number for the database. Usually, you will not need to change this value unless the database becomes corrupted and needs to start fresh. In such a case, set this value to a number higher than appears as the version number counter for this WINS server on all the remote partners that earlier replicated the local WINS server's records. WINS may adjust the value you specify to a higher one to ensure that the database records are replicated quickly to the WINS servers. This value can be seen in the View Database dialog box in WINS Manager. 

Database Backup Path 

Specifies the directory where the WINS database backups will be stored. If you specify a backup path, WINS automatically performs a full backup of its database to this directory. WINS also uses this directory to perform an automatic restoration of the database in the event that the database is found to be corrupted when WINS is started. Do not specify a network directory. 

Configuring Replication Partners

WINS servers communicate among themselves to replicate their databases fully, ensuring that a name registered with one WINS server is eventually replicated to all other WINS servers within the network. All mapping changes converge within the replication period for the entire WINS system, which is the maximum time for propagating changes to all WINS servers. All released names are propagated to all WINS servers after they become extinct, based on the interval specified in WINS Manager.

Use the Replication Partners command in WINS Manager to configure replication partners and replication partner properties. There are two types of replication partners: pull and push:

Choosing whether to configure another WINS server as a push partner or pull partner depends on several considerations, including the specific configuration of servers at your site, whether the partner is across a wide area network (WAN), and how important it is to propagate the changes.

Replication is triggered when a WINS server polls another server to get replicated information. This can begin when the WINS server is started, and is repeated based on the configured update count or time interval, or by using WINS Manager to start immediate replication.

Replication also is triggered when a WINS server reaches a threshold set by the administrator. This is an update count for registrations and changes. In this case, the server notifies its pull partners that it has reached this threshold, and the other servers can then decide to pull replicated information.

It is always a good idea for replication partners to be both push and pull partners of each other. The primary and backup WINS servers must be both push and pull partners with each other to ensure that the primary and backup databases are consistent.

Managing Static NetBIOS-to-IP Address Mappings

Static mappings are non-dynamic database entries of NetBIOS computer name-to-IP address mappings for computers on the network that are not WINS-enabled or for special groups of network devices.

Use the Static Mappings command on the Mappings menu in WINS Manager to view, add, edit, delete, import, or filter static mappings.

Once a static name-to-IP address mapping is entered into the WINS server database, it cannot be challenged or removed except by an administrator who must remove it manually using WINS Manager. All changes made to the WINS server database using WINS Manager take effect immediately.

Note -

A DHCP reserved (or static) IP address for a unique name in a multihomed computer overrides an obsolete WINS static mapping if the WINS server advanced configuration option Migration On/Off is checked On.

Static NetBIOS name mappings can be any of the types listed in the following table.

Table 5-4 Static NetBIOS Name-Mapping Types

Type Option 

Description 

Unique 

A unique name that maps to a single IP address. Contrast with multihomed type.  

Group 

Also referred to as a "Normal Group." When adding an entry to Group using WINS Manager, you must enter the computer name and IP address. However, the IP addresses of individual members of Group are not stored in the WINS database. Because member addresses are not stored, there is no limit to the number of members that can be added to a Group. Broadcast name packets are used to communicate with Group members. Contrast with Internet group type. 

 

Domain 

A NetBIOS name-to-IP address mapping that has 0x1C as the 16th byte. A domain group stores up to a maximum of 25 addresses for members. For registrations after the 25th address, WINS overwrites a replica address or, if none is present, it overwrites the oldest registration. 

Internet group 

Internet groups are user-defined groups that allow you to classify resources such as printers for easy reference and browsing. The default 16th byte of an Internet group name is set equal to 0x20. An Internet group can store up to a maximum of 25 addresses for members. 

When you add an Internet group, three unique records are added: 

  • InternetGroupName<0x20>

  • InternetGroupName<0x3>

  • InternetGroupName<0x0>

This is similar to the domain group. 

Internet group members can be added as the result of dynamic group registrations. However, a dynamic member does not replace a static member that is added by using WINS Manager or by importing the LMHOSTS file. Contrast with Group type.

Multihomed 

A unique name that can have more than one address. This is used for multihomed computers. The maximum number of addresses that can be registered as multihomed is 25. For registrations after the 25th address, WINS overwrites a replica address or, if none is present, it overwrites the oldest registration. Contrast with Unique type. 

You can configure a WINS server to replicate only domain, Internet, and multihomed group to its replication partners, by manually changing the Replication Type Registry parameter to a value of 1.

This procedure eliminates the replication of information (unique names) that is not needed outside the local domain, while allowing replication of special group information. When a group spans multiple domains that are serviced by other WINS servers, it is desirable to reduce replication traffic

Table 5-5 Basic WINS Server Statistics Descriptions

Statistic 

Description 

Server Start Time 

The time when this WINS server was started. 

Database Initialized 

The last time static mappings were imported into the WINS database. 

Statistics Cleared 

The time when statistics for the WINS server were last cleared with the Clear Statistics command from the View menu. 

Last Replication Times 

The times at which the WINS database was last replicated. 

Periodic 

The last time the WINS database was replicated based on the replication interval specified in the Preferences dialog box. 

Admin Trigger 

The last time the WINS database was replicated because the administrator chose the Replicate Now button in the Replication Partners dialog box. 

Net Update 

The last time the WINS database was replicated as a result of a network request, which is a push notification message that requests propagation. 

Total Queries Received 

The number of name query request messages received by this WINS server. Successful indicates how many names were successfully matched in the database, and Failed indicates how many names this WINS server could not resolve. 

Total Releases 

The number of messages received that indicate a NetBIOS application has shut itself down. Successful indicates how many names were successfully released, and Failed indicates how many names this WINS server could not release. 

Total Registrations 

The number of messages received that indicate name registrations for clients. 

You can display additional statistics by clicking Detailed Information on the Server menu. The following table describes these detailed information statistics.

Table 5-6 Detailed WINS Server Statistics Descriptions

Statistic 

Description 

Last Address Change 

The time at which the last WINS database change was replicated 

Last Scavenging Times 

The last times that the database was cleaned for specific types of entries 

Periodic 

The time when the database was cleaned based on the renewal interval specified in WINS Server Configuration (Local) 

Admin Trigger 

The time when the database was last cleaned because the administrator chose the Initiate Scavenging command 

Extinction 

The time when the database was last cleaned based on the Extinction interval specified in the WINS Server Configuration dialog box 

Verification 

The time when the database was last cleaned based on the verify interval specified in WINS Server Configuration dialog box 

Unique Registrations 

The number of name registration requests that have been accepted by this WINS server 

Unique Conflicts 

The number of conflicts encountered during registration of unique names owned by this WINS server 

Unique Renewals 

The number of renewals received for unique names 

Group Registrations 

The number of registration requests for groups that have been accepted by this WINS server 

Group Conflicts 

The number of conflicts encountered during registration of group names 

Group Renewals 

The number of renewals received for group names 

Viewing WINS Server Status

WINS Manager allows you to view administrative and operational information about WINS servers. When you open WINS Manager, the title bar shows the IP address or computer name for the currently selected server, depending on whether you used the address or name to connect to the server. The right pane displays basic statistics about the selected WINS server.

Viewing the WINS Database

You can view actual dynamic and static mappings stored in the WINS database, based on the WINS server that owns the entries. Use WINS Manager to choose the Show Database command from the Mappings menu.

By default, the Show Database dialog box shows all mappings for the WINS database on the currently selected WINS server. You can select a Sort Order option to sort by IP address, computer name, time stamp for the mapping, version ID, or type. To view only a range of mappings, choose the Set Filter button.

This process, called scavenging, is done automatically over intervals defined by the relationship between the Renewal and Extinct intervals defined in the WINS Server Configuration dialog box. You can also clean the database manually.

To scavenge the WINS database, choose the Initiate Scavenging command from the Mappings menu. The following table describes the results of scavenging a WINS database.

Table 5-7 Effects of Scavenging WINS Database

State Before Scavenging 

State After Scavenging 

Owned active names for which the Renewal interval has expired 

Marked released

Owned released name for which the Extinct interval has expired 

Marked extinct

Owned extinct names for which the Extinct timeout has expired 

Deleted 

Replicas of extinct names for which the Extinct interval has expired 

Deleted 

Replicas of active names for which the Verify interval has expired 

Revalidated 

Replicas of extinct or deleted names 

Deleted 

Advanced Configuration Parameters for WINS

This section presents configuration parameters that affect the behavior of WINS and that you can modify only through the Windows NT Registry Editor. For some parameters, WINS can detect Registry changes immediately. For other parameters, you must restart WINS for the changes to take effect.

Caution - Caution -

You can impair or disable WINS if you make incorrect changes in the Registry while using Registry Editor. Whenever possible, use WINS Manager to make configuration changes rather than using Registry Editor. If you make errors while changing values with Registry Editor, you will not be warned because the Registry Editor does not recognize semantic errors.

The following sections describe the value entries for WINS parameters that can only be set by adding an entry or changing values in Registry Editor.

Registry Parameters for WINS Servers

The Registry parameters for WINS servers are specified under the following key:..\SYSTEM\CurrentControlSet\Services\Wins\Parameters

This lists all of the non-replication-related parameters needed to configure a WINS server. It also contains a \Datafiles subkey, which lists all the files that should be read by WINS to initialize or reinitialize its local database.

The following parameters in this subkey can be set using the options available in the WINS Server Configuration dialog box:

Also, the \Wins\Parameters\Datafiles key lists one or more files that the WINS server should read to initialize or reinitialize its local database with static records. If the full path of the file is not listed, the directory of execution for the WINS server is assumed to contain the data file. The parameters can have any names (for example, DF1 or DF2). Their data types must be REG_EXPAND_SZ or REG_SZ.

Registry Parameters for Replication Partners

The \Wins\Partners key has two subkeys, \Pull and \Push, under which are subkeys for the IP addresses of all push and pull partners, respectively, of the WINS server.

Parameters for Push Partners

A push partner, listed under the \Partners\Pull key, is one from which a WINS server pulls replicas and from which it can expect update notification messages. The following parameter appears under the IP address for a specific push partner. You can set this parameter only by changing the value in the Registry:

The following parameters appear under this subkey and can be set in the WINS Server Configuration dialog box:

..\SYSTEM\CurrentControlSet\Services\Wins\Partners\Pull

The following parameters appear under this subkey and can be set using the Preferences dialog box:

..\SYSTEM\CurrentControlSet\Services\Wins\Partners \Pull\<IP Address>

For SpTime, WINS replicates at the set time if it is in the future for that day. After that, it replicates every number of seconds specified by TimeInterval. If SpTime is in the past for that day, WINS replicates every number of seconds specified by TimeInterval, starting from the current time (if InitTimeReplication is set to 1).

Parameters for Pull Partners

A pull partner of a WINS server, listed under the \Partners\Push key, is one from which it can expect pull requests to pull replicas and to which it sends update notification messages. The following parameters appear under this subkey and can be set using the options available in the WINS Server Configuration dialog box:

..\SYSTEM\CurrentControlSet\Services\Wins\Partners\Push

The following parameter appears under this subkey and can be set using the options available in the Preferences dialog box:

..\SYSTEM\CurrentControlSet\Services\Wins\Partners\Push\<IP Address>

About Database Management

All databases need to be backed up and cleaned periodically. SunLink Server Manager and various Solaris commands are the tools you use to maintain the databases; additionally, SunLink Server Manager enables you to schedule a routine for performing most database maintenance tasks automatically.

The following sections describe how to view, back up, restore, clean up, and compact the SunLink Server WINS database.

Compacting the WINS Database

There is no built-in limit to the number of records that a WINS server can replicate or store. The size of the database is dependent on the number of WINS clients on the network. The WINS database grows over time as a result of clients starting and stopping on the network.

The size of the WINS database is not directly proportional to the number of active client entries. Over time, as some WINS client entries become obsolete and are deleted, there remains some unused space.

To recover space and improve performance, you use the Solaris command line on the SunLink Server computer to compact the database. See "How to Compact the WINS Database".

Backing Up and Restoring the WINS Database

You use the Solaris command line or the Windows NT tool, WINS Manager, to back up and restore the WINS database. The following WINS server database files are stored in the /var/opt/lanman/wins directory. This directory was created when you installed the SunLink Server program.

You can also use the Windows NT tool, WINS Manager, to examine the current database backup path and to establish a new one.

Cleaning Up the Databases

Cleaning up (also known as "scavenging") the WINS database is an administrative task related to backing up the database. Like any database, the WINS server database of address mappings needs to be cleaned periodically.

You should periodically clear the local WINS database of released entries and old entries that were registered at another WINS server and replicated to the local WINS server, but for some reason did not get removed from the local WINS database.

Database Maintenance Tasks

The following sections provide detailed instructions for scheduling and performing routine SunLink Server database maintenance tasks. You complete most of the tasks by using the SunLink Server Manager tool; however, some of the tasks require that you use the SunLink Server command line.

How to Clean Up SunLink Server Databases

  1. Using SunLink Server Manager, log on as root to the SunLink Server computer on which you want to clean up one or more databases.

  2. In the View pane, double-click Tasks and then double-click Clean Up Databases.

    The resulting screen presents a list of databases to clean up.

    Graphic

    The Cleanup wizard performs the following tasks on the following databases:

    • Checks, repairs, and prunes obsolete entries in the Access Control List (ACL), and synchronizes ACL information with the Solaris file system

    • Checks and repairs the Registry

    • Checks and repairs the Security Account Manager (SAM)

  3. Choose all of the databases that you want to clean up, then click Next.

  4. Click Finish.

    The resulting screen follows the progress of the cleanup, indicating a completed task with a checkmark and a pending task with an arrow.

    Graphic

    How to Back Up SunLink Server Databases

    1. Using SunLink Server Manager, log on as root to the SunLink Server computer on which you want to back up one or more databases.

  5. In the View pane, double-click Tasks and then double-click Back Up and Restore Databases.

    The resulting screen presents backup and restore options.

    Graphic

  6. Select Back up one or more SunLink Server databases, and then click Next.

    The resulting screen presents a list of databases that you can back up, and includes a text field in which you specify the path to your database backup file. Note that your backup file must be stored as a Solaris file in a directory on the SunLink Server system, rather than locally. If you specify a path to a nonexistent directory, a dialog box will ask whether you want the wizard to create the directory for you.

    Graphic

  7. Select all of the databases that you want to back up, specify the backup file's path name, and then click Next.

    The resulting screen enables you to specify how you want the Database Backup and Restore wizard to handle server shutdown and startup.

    Graphic

    Note that the server software must be shut down and then restarted each time the wizard runs a maintenance task. If you do not choose the option to "Allow Database Backup and Restore to stop processes," you will be unable to continue the backup task. If you do choose to have the wizard automatically shut down the SunLink Server processes for maintenance, then you will also be able to specify that the wizard restarts the server after the tasks are completed.

  8. Choose how you want the Database Backup and Restore wizard to handle server shutdown and startup, then click Finish.

    The resulting screen follows the progress of the cleanup, indicating a completed task with a checkmark and a pending task with an arrow.

    Graphic

How to Restore Backed-Up Databases

  1. Using SunLink Server Manager, log on as root to the SunLink Server computer on which you want to restore one or more backed-up databases.

  2. In the View pane, double-click Tasks and then double-click Back Up and Restore Databases.

    The resulting screen presents backup and restore options.

    Graphic

  3. Select Restore one or more SunLink Server databases, and then click Next.

    The resulting screen presents a text field in which you specify the path to the database backup file that you want to restore.

    Graphic

  4. Enter the path name of the backup file, and then click Next.

    The resulting screen presents a list of databases that you can restore.

    Graphic

  5. Select all of the backed-up database files that you want to restore, and then click Next.

    The resulting screen enables you to specify how you want the Database Backup and Restore wizard to handle server software shutdown and startup.

    Graphic

    Note that the server software must be shut down and then restarted each time the wizard runs a maintenance task. If you do not choose the option to "Allow Database Backup and Restore to stop processes," you will be unable to continue with database restoration. If you do choose to have the wizard automatically shut down the SunLink Server processes for maintenance, then you will also be able to specify that the wizard restarts the server after the tasks are completed.

  6. Choose how you want the Database Backup and Restore wizard to handle server shutdown and startup, then click Finish.

    The resulting screen follows the progress of the restoration, indicating a completed task with a checkmark and a pending task with an arrow.

    Graphic

    How to Create an Automatic Schedule for Both Database Cleanup and Backup

    1. Using SunLink Server Manager, log on as root to the SunLink Server computer on which you want to schedule maintenance tasks.

    2. In the View pane, double-click Tasks and then double-click Schedule Database Maintenance.

      The resulting screen presents both the cleanup and backup options.

      Graphic

    3. Choose one or both both maintenance options, then click Next.

      (Depending on whether you chose one or both tasks, one of the following screens may not be displayed.)

      The resulting screen presents a list of databases to clean up automatically.

      Graphic

    4. Choose all of the databases that you want to clean up, then click Next.

      The resulting screen presents a list of databases to back up automatically, and includes a text field in which you specify the path to your database backup file. Note that your backup file must be stored as a Solaris file in an existing directory on the SunLink Server system, rather than locally. If you specify a path to a nonexistent directory, a dialog box will ask whether you want the wizard to create the directory for you.

      Graphic

    5. Choose all of the databases that you want to back up, specify the backup file's path name, and then click Next.

      The resulting screen enables you to specify how you want the Database Maintenance wizard to handle server shutdown and startup.

      Graphic

      Note that the server software must be shut down and then restarted each time the wizard runs a maintenance task. If you do not choose the option to "Allow the Maintenance wizard to stop processes," you will be unable to continue scheduling the maintenance tasks. If you do choose to have the Maintenance wizard automatically shut down the SunLink Server processes for maintenance, then you will also be able to specify that the wizard restarts the server after the tasks are completed.

    6. Choose how you want the Database Maintenance wizard to handle server shutdown and startup, then click Next.

      The resulting screen enables you to specify the frequency of maintenance tasks: one time only, daily, weekly, or monthly. The default is weekly.

      Graphic

    7. Select how frequently you want the maintenance tasks to be run, then click Next.

      The resulting screen enables you to choose times for the maintenance tasks with greater precision; the options will be different, depending on the frequency you chose:

      • Just Once - You choose a specific date and time.

      • Daily - You choose a specific time of day.

      • Weekly - You choose a specific day of the week and time of day.

      • Monthly - You choose a specific date during the month and time of day.

  7. Specify days, dates, and times, and then click Next.

    The resulting screen presents a summary of your choices, and gives you another opportunity to amend them.

    Graphic

  8. Examine the Maintenance Job Summary, then click Finish to confirm your choices and activate the defined maintenance schedule, or Back to amend any of your choices.

    After you have confirmed your choices and scheduled your maintenance tasks, a summary of the scheduled tasks will be presented to you each time you open the Maintenance Task wizard. It will also appear in the SunLink Server Manager Information panel for that server.

    Once you have scheduled your maintenance tasks, you can change the schedule--or delete it entirely--at any time. For details, see the next section, "How to View, Modify, or Delete Scheduled Database Maintenance Tasks"."

How to View, Modify, or Delete Scheduled Database Maintenance Tasks

  1. Using SunLink Server Manager, log on as root to the SunLink Server computer on which you want to schedule maintenance tasks.

  2. In the View pane, double-click Tasks and then double-click Schedule Database Maintenance.

    The resulting screen presents a summary of the maintenance tasks that have been scheduled.

    Graphic

  3. Do one of the following:

    • Select Delete, click Next, then continue with Step 4.

  4. Click Finish to confirm that you want to delete the specified maintenance task.

How to Compact the WINS Database

  1. Log on to the SunLink Server WINS computer as root.

  2. Stop the WINS server by typing the following command:

    net stop wins

  3. Compact the WINS database by typing the following command:

    winsadm -c

  4. Start the WINS server by typing the following command:

    net start wins