1. Module 5: WINS As a Solution for NetBIOS Name Resolution

2. Overview Introducing WINS Designing a Functional WINS Solution Securing a WINS Solution Enhancing a WINS Design for Availability Optimizing a WINS Design for Performance

3. The use of network basic input/output system (NetBIOS) names in a Transmission Control Protocol/Internet Protocol (TCP/IP) network requires resource names to be resolved throughout a network infrastructure. WINS in Microsoft® Windows® 2000 implements an RFC- compliant NetBIOS Name Server (NBNS).

4. At the end of this module, you will be able to: Evaluate WINS as a solution for NetBIOS name resolution. Evaluate and create a functional design for baseline name resolution. Select appropriate strategies to secure a WINS solution Select appropriate strategies to enhance a WINS design for availability. Select appropriate strategies to improve a WINS design for performance.

5.  Introducing WINS Design Decisions WINS Features Integration Benefits A A B B Share Shared Resource Windows Clients Exchange Server Windows 95 Using NetBIOS Client Running Outlook NetBIOS name resolution is required by many clients

6. Within an organization's intranet, the potentially large number of available NetBIOS resources, such as file and print services, creates the need for meaningful device and logical resource names to simplify the user's access to resources. WINS resolves NetBIOS resource names to IP addresses. WINS can also integrate with other Windows 2000 services to extend name resolution capabilities.

7. To design a strategy for locating NetBIOS resources by using WINS, you must: Collect the network and host configuration data required to make the design decisions necessary for developing a WINS solution. Identify the features provided by WINS and how these features support the design requirements. Identify the benefits provided by integrating WINS with other services in Windows 2000.

8. Design Decisions for a WINS Solution Establishing the Need for WINS Identifying the Design Decisions File Servers Exchange Server Broadcast Domain NetBIOS CD Server WAN Link Router

9. Design Decisions for a WINS Solution To successfully develop a WINS solution, you must assess the number of hosts, the number of resources, and the routing or network configuration. When you understand the configuration of the network, resources, and hosts for the infrastructure, you can make decisions on the requirements for a WINS-based NetBIOS name resolution service.

10. Establishing the Need for WINS In a TCP/IP routed or switched network, where broadcast packets may not pass between segments, a nonbroadcast-based service is required to accommodate a dynamic NetBIOS name resolution and registration service. WINS meets this service need by providing unicast NetBIOS name registration and resolution. Note: In a simple, nonrouted TCP/IP network, such as a single-segment local area network (LAN), WINS may be optional. A non-WINS solution works in those instances where the broadcast domain is small, broadcast traffic is acceptable, and hosts are configured as b-node (broadcast nodes).

11. Identifying the Design Decisions After you have established the network infrastructure requirements and configuration, the design decisions you must make include the: Number and placement of WINS servers within the network. Plan for replication schedules, and architecture and configuration options for multi-WINS server environments. Configuration of WINS Client. Placement of WINS Proxy Agents to ensure unique non- Windows host names.

12. Features of a WINS Service Name Resolution Services RFC Compliance DNS Integration Burst-Mode Name Registration Secure and Centralized Administration Multiple WINS Servers WINS Server WINS Client Register Renew Release Resolve WINS Database Client1 10.0.1.11 Client2 10.0.3.12 Client3 10.0.3.13 Remove

13. When designing a WINS-based NetBIOS name resolution service, you must understand the WINS features and how you can use these features to support the needs of your network infrastructure.

14. Name Resolution Services A WINS infrastructure builds and maintains a database of available NetBIOS resources and resolves NetBIOS names to IP addresses based on client requests. WINS accomplishes name resolution in four distinct phases: Registers new network device names as they become available. Resolves NetBIOS names to IP addresses for WINS clients. Renews name registrations for WINS clients. Releases NetBIOS names during normal WINS client computer shutdown. And, in addition, the WINS service: Removes names from the registration database if the client fails to renew its entries.

15. RFC Compliance WINS provides NetBIOS name service support that is compliant with RFC 1001 and RFC 1002. The implementation of WINS in Windows 2000 extends the RFC-compliant NetBIOS name service by supporting multiple distributed servers with replicated databases.

16. DNS Integration To fulfill DNS client queries, the WINS service integrates with DNS in Windows 2000 to allow forward and reverse lookup of NetBIOS resources by DNS servers. You can also configure WINS clients to support name resolution by using both DNS and WINS records.

17. Burst-Mode Name Registration When a large number of WINS clients simultaneously try to register their NetBIOS names, the WINS server can become saturated. Burst-mode name registration supports a high volume of WINS client name registrations. By default, when the queue of registration requests exceeds 500, a WINS server begins to positively respond to new registration requests with a shorter (5 - 50 minutes) Time to Live (TTL). The short TTL lease forces these WINS clients to reregister after the excessive WINS registration traffic has subsided.

18. Secure and Centralized Administration You can centrally administer WINS, thereby reducing name resolution-related support issues. WINS clients automatically register and release their NetBIOS names, so no other administration is necessary. Administration is secure because only specific Windows 2000-based groups can modify a WINS server configuration or database.

19. Multiple WINS Servers WINS provides a critical service for the network, so availability and performance are key design goals. Multiple WINS servers provide greater availability and improve the performance of any WINS implementation. The WINS architecture supports multiple servers that you can configure to replicate their database information. In addition, you can configure WINS clients with a list of available WINS servers that are sequentially referenced in the case of a server failure.

20. Integration Benefits DHCP Integration DNS Integration DHCP Server DNS Server Name Registration Name Resolution WINS Server

21. WINS clients that have DHCP-allocated IP addresses must be registered in WINS to allow other clients to resolve resources. The integration of WINS with other Windows 2000 networking services such as DNS allows the other services to use these dynamic registrations.

22. The integration of WINS with DHCP and DNS allows: DNS servers to forward unresolved DNS queries to WINS servers for resolution of host names that have dynamic IP addresses. DNS resolution for resources located on other operating systems, such as previous versions of Microsoft Windows. Note: In addition to the server-to-server integration, you can configure the WINS client to query a DNS server with unresolved WINS queries.

23.  Designing a Functional WINS Solution Designing a WINS Service for a LAN Designing a WINS Service for a Routed Network Supporting WINS Clients Supporting Non-WINS Clients Supporting Multiple WINS Servers Discussion: Evaluating WINS Functional Requirements

24. You can create a WINS design for a LAN or routed network that supports both WINS and non-WINS clients. If multiple WINS servers are required, you can create a solution to control replication of the WINS databases between partners.

25. In this lesson you will learn about the following topics: Designing a WINS service for LAN Designing a WINS service for a routed network Supporting a WINS clients Supporting non-WINS clients Supporting multiple WINS servers Evaluating WINS functional requirements

26. Designing a WINS Service for a LAN LAN Considerations Client Considerations h-node Register, Renew, Release, and Query by Unicast traffic then use Lmhosts and Broadcasts h-node Register, Renew, Release, and Query by Unicast traffic then use Lmhosts and Broadcasts WINS Server Client BClient AClient C WINS Clients (h-node) Unicast reduces broadcasts

27. In a nonrouted LAN, you can register and resolve NetBIOS names by using broadcasts, but all hosts must process these broadcasts, which reduces the performance of the hosts. WINS provides a NetBIOS name service that uses a unicast protocol, which can eliminate NetBIOS-related broadcast traffic.

28. LAN Considerations When designing a WINS solution for a nonrouted LAN, consider doing the following: Enable all clients to use WINS to reduce broadcast traffic on the LAN. Set conservative client counts for a WINS server to minimize client query response times. A single WINS server can support thousands of WINS clients, but the performance depends on the configuration of the hardware. The WINS service might be installed on a computer providing other services, which can further reduce performance. In a larger network, you might need a dedicated WINS server, or more than one WINS server.

29. Designing a WINS Service for a Routed Network WINS Clients Sydney WINS Servers WAN Connection WINS Server WINS Client New York Replication Router

30. Client Consideration All Windows 2000-based clients-and most of the earlier Microsoft-based WINS clients-are configured by default as hybrid node (h-node) clients. These WINS clients use any of the following methods, in the order listed, to handle requests to resolve names not already in the client NetBIOS name cache: 1. Direct (unicast) contact with a WINS server. 2. Host lookup by using the Lmhosts file. 3. Broadcast of the NetBIOS request to the local subnet.

31. If your entire network supports broadcasts and is made up of a single, non-routed LAN that occupies one physical segment or a single, non-routed LAN that occupies switched network segments with few clients, you probably do not need a WINS server. For these small networks, using Lmhosts entries and broadcasts may be an effective and simple solution for providing NetBIOS name service to a small number of clients.

32. Designing a WINS Service for a Routed Network In a routed network where broadcast domains are restricted, a nonbroadcast-based NetBIOS name service is required to allow network-wide resource name registration and resolution. The unicast protocol used by WINS provides NetBIOS name resolution for WINS clients in a routed TCP/IP environment. Client performance issues, and WINS server redundancy and replication requirements, determine the required number and placement of WINS servers. In a routed LAN, it is best to position servers to minimize cross-subnet query and registration traffic, and to maximize performance and fault tolerance for client queries.

33. In a geographically dispersed wide area network (WAN), in which there may be restricted bandwidth between locations, you must place the WINS servers to: Maximize client response to registrations and queries. Minimize database convergence times between WINS partners. Important: In a multiple WINS server solution, database convergence affects decisions on replication. In a LAN environment, persistent connections allow incremental replication updates. Restricted bandwidth WAN environments may require the use of schedules or database change counts to trigger replication updates, which increases convergence times. Minimize the number of WINS servers required by using only as many WINS servers as you need to support all clients.

34. Supporting WINS Clients WINS Client Features WINS Client Considerations WINS Server WINS Client Windows 2000 Router WINS Server WINS Client Subnet 1 Subnet 2 Subnet 3 WINS Clients Unicast communications through routers Router

35. Supporting WINS Clients All versions of Windows support a WINS client, resulting in reduced broadcast traffic.

36. WINS Client Features The WINS client in Windows 2000 provides the following features: Communication with a WINS server by using unicast packets to reduce broadcast traffic. Support of up to 12 WINS servers for redundancy. Note: Earlier Windows versions support either one or two WINS servers. Support for multiple node types as defined in RFC 1001.

37. WINS Client Considerations When designing a WINS Service that supports WINS clients, consider doing the following: Specifying multiple WINS servers for clients to provide service redundancy. Increasing the NetBIOS name registration renewal period-the default is six days-to reduce client-to-server renewal traffic.

38. Supporting Non-WINS Clients WINS Proxy Agent Static Entries NetBIOS Broadcasts Non-WINS Client Non-WINS Client WINS Client with WINS Proxy Agent Subnet 1 Subnet 2 WINS Clients Windows 2000 Router with WINS Proxy Agent Broadcast Unicast Subnet 3 WINS Server Router

39. For resources not on the local subnet, non-WINS clients that use NetBIOS need to have name registrations and requests resolved. Name services extended to these hosts deal with both registration and resolution issues. You can use any combination of the following methods to support these non-WINS clients: Including WINS Proxy Agents on the subnet containing non-WINS clients. Including static WINS or Lmhosts entries to enable remote name resolution. Enabling NetBIOS broadcast traffic across all routers.

40. WINS Proxy Agent The WINS Proxy Agent receives the broadcast-based NetBIOS name service interaction from non-WINS clients and forwards the requests to a WINS server. The WINS Proxy Agent: Ensures unique NetBIOS names within the routed network. Extends name resolution services to the non-WINS clients. By default, does not register the resource names with WINS.

41. You can configure any WINS client to provide WINS Proxy Agent functionality to a network segment. Any subnets that contain non-WINS clients, and do not have any WINS servers, need to have at least one WINS Proxy Agent. Note: If you plan multiple WINS Proxy Agents on a single segment for redundancy, keep them to a minimum, because all WINS Proxy Agents on the network segment forward each non-WINS client request to the server.

42. Static WINS and Lmhosts Entries Non-WINS client registrations are not added to the WINS database automatically. To resolve these resources network-wide, you must manually add the registrations as a static entry to the WINS database, or include them in client Lmhosts files. Static name entries for non-WINS resources that are added to the WINS database allow WINS clients to resolve these resources. In Windows-based computers that use TCP/IP, entries to resolve remote resource names are made in an Lmhosts file. To minimize administration of multiple Lmhosts files, you can enter resource names in a centrally maintained Lmhosts file referenced as a #INCLUDE in the client Lmhosts file.

43. NetBIOS Broadcasts Across Routers Enabling NetBIOS broadcasts across all routers in a network allows operation without WINS, but is not recommended, because it increases the size of the broadcast domain. This would only be considered a viable solution for small network designs.

44. Supporting Multiple WINS Servers WINS Replication Convergence Time hub and spoke replication minimizes convergence times WINS clients access multiple WINS Servers push/pull Subnet B WINS-B 192.168.3.5 WINS-C WINS-E WINS-D WINS-A 192.168.2.5 TCP/IP Settings for WINS Clients on Subnet B First WINS Server:192.168.3.5 Second WINS Server:192.168.2.5

45. Multiple WINS servers distribute the NetBIOS name service across LAN and WAN environments, confining WINS client traffic to localized areas. To ensure consistent network-wide name resolution, WINS servers must replicate their locally acquired entries to configured partners.

46. WINS Replication You can configure WINS replication by using: Scheduled push or pull intervals. Push, pull or push/pull partners. Automatic partner discovery with a two-hour schedule over a multicast group (224.0.1.24). Caution: Multicast announcements between WINS servers add traffic to your network. Automatic partner replication is recommended only if you have a small number of installed WINS servers (typically, three or fewer) on the reachable network. Push updates based on the number of changes to the database.

47. Convergence Time Convergence time is the time it takes for a new entry in a WINS database to be replicated from the originating WINS server to all other partner WINS servers. When planning placement and replication for WINS servers, you must decide an acceptable convergence time for your network.

48. Convergence Time To minimize replication paths and convergence times: Select push/pull when planning replication partners. Avoid the use of limited replication partnerships ( push only or pull only) between WINS servers, unless required for slow WAN links. Select persistent connections between partners to improve replication performance in high-bandwidth networks. Plan for a hub-and-spoke model for WINS replication. This provides the shortest convergence times.

49. Discussion: Evaluating WINS Functional Requirements Remote Access Server Windows 2000-based Router File and Print Server WINS Clients Subnet 1 Subnet 2 Subnet 3 WINS Clients Non-WINS Clients Subnet 4 WINS Clients Router A2 Subnet 5 CD Server Router A1

50. To provide a functional WINS solution for NetBIOS name resolution, you must decide on the number and placement of servers, where and when to use proxy agents, and how to ensure NetBIOS names are resolved for both WINS and non-WINS clients

51. The following scenario describes an organization's current network configuration.

52. Scenario An organization has decided to restructure an existing network and include WINS as a solution for NetBIOS name resolution. You are assigned the task of evaluating how WINS can be used to provide a solution for this scenario. The current network configuration provides: Intranet access to all shared folders and Web-based applications. Support for the existing infrastructure shown in the diagram. Support for a mission-critical Web-based application that requires 24-hours-a-day, 7-days-a-week operation. Support for a non-WINS compliant CD server by using NetBIOS access in Subnet 3. Support for non-WINS clients.

53.  Securing a WINS Solution WINS Server Internet Securing WINS Traffic with Tunnels Integrating into Screened Subnets

54. In a WINS solution, both replication and client traffic often occur across public networks such as the Internet. Passing the NetBIOS names and IP addresses of hosts within the organization over these public networks poses a security risk. You can include strategies to support encryption in your WINS solution, which secures WINS traffic. Windows 2000 enhances WINS security by: Supporting Internet Protocol Security (IPSec) or virtual private network (VPN) tunnels for data encryption. Integrating WINS servers into screened subnets.

55. Securing WINS Traffic with Tunnels Queries WINS Servers Internet Replication WINS Clients VPN or IPSec Tunnel

56. Securing WINS Traffic with Tunnels To secure WINS replication, decide whether to use IPSec or VPN tunnels for query and registration traffic, based on the existing network configuration and the public networks used to transfer data. For example, you can configure two WINS servers to replicate the WINS database across the Internet. To secure WINS replication, encrypt this traffic by using IPSec or VPN tunnels between the servers.

57. When choosing to encrypt replication traffic by using IPSec or VPN tunnels, consider: Using the strongest level of encryption or VPN tunnel authentication possible. Using Routing and Remote Access in Windows 2000 to provide the IPSec or VPN tunnel between servers. Selecting Kerberos version 5 protocol or other certificate-based authentication for secure communication channels.

58. Integrating into Screened Subnets Shared Resource Server Screened Subnet Private Network Internal Firewall External Firewall WINS Server Web and Shared Resource Server WINS Server Internet

59. Integrating into Screened Subnets Place WINS in a screened subnet, or outside the corporate firewall, if you must avoid exposing intranet NetBIOS names and WINS data to a public network. This placement also protects corporate resources, while providing a NetBIOS name service to external clients that need access to these resources.

60. For example, if you must make read/write data files securely available to public clients across the Internet, the following solutions are viable: A Web-based solution can provide read-only access to the resources, but it requires a file upload facility to complete the read/write function, or a Web-based editing solution to allow online updates. The Common Internet File System (CIFS) is a NetBIOS implementation that makes data shareable across public networks. Because CIFS is a NetBIOS implementation, you can use WINS to provide the NetBIOS name service for these resources. Clients are granted direct read/write access to the resource.

61. CIFS uses the Server Message Block (SMB) protocol found in Microsoft Windows for file and printer access, and allows all applications, not just Web browsers, to access files across the Internet. Note: The NetBIOS name service uses ports 137/tcp, 137/udp, 138/udp, and 139/tcp for name service and connections. To allow NetBIOS operation through a firewall, enable these ports. Refer to RFC 1002 for further details.

62.  Enhancing a WINS Design for Availability Secondary WINS Server WINS Server WINS Server Cluster IP Address Cluster Primary WINS Server Using Multiple Servers Using Windows Clustering

63. In an ideal situation, a WINS Service would be available whenever required. The availability of the service is defined as the percentage of time that clients are able to resolve names by using WINS. You can design the WINS infrastructure to enhance the availability of the service by: Providing support for multiple WINS servers that use WINS replication. Providing WINS servers configured to use Windows Clustering.

64. Using Multiple WINS Servers WINS Clients Sydney New York WINS Servers WAN Connection WINS Server WINS Client Replication Adding WINS Servers with Replicated WINS Databases Timely WINS Database Replication WINS Server Router

65. Using Multiple WINS Servers Designing a WINS solution by using multiple servers configured with replication increases availability. The placement of the servers depends on the network infrastructure, the service performance, and the location constraints. Adding additional WINS servers to remote locations provides name service redundancy in case a server or router fails.

66. Adding WINS Servers with Replicated WINS Databases You can configure multiple WINS servers to provide redundancy and load balancing. When you use replication, all servers contain the same WINS database information.

67. Timely WINS Database Replication Highly available WINS implementation designs call for timely WINS database replication. As the length of time for synchronizing redundant WINS databases increases, the probability increases that a WINS server failure will result in the use of an outdated database by the remaining WINS servers. For WINS servers that are experiencing a significant delay in database replication, consider: Reducing the length of time between WINS database replications. Replacing the existing WINS server with a server that provides enhanced performance. Using Windows Clustering to provide a higher level of availability.

68. Using Windows Clustering Single Logical WINS Server WINS Server WINS Server Cluster IP Address Cluster Multiple Physical Computers

69. Using Windows Clustering By using a Windows Clustering solution, you increase the availability of an individual WINS server. You can install the WINS server on a cluster to provide immediate recovery in the event of hardware or service failure. Windows Clustering provides a higher level of availability for individual servers; however, this solution generally requires more computing resources than multiple WINS servers that use replication.

70. By configuring WINS with Windows Clustering, you can: Provide immediate failover and restart in the event of a failure. Restore failed servers sooner, because database resynchronization is not required. Note: Windows Clustering provides a solution that is appropriate for solving availability issues associated with a single WINS server. Windows 2000-based servers that belong to the same cluster require persistent, high- speed connections between all servers in the cluster.

71. Discussion: Evaluating WINS Availability Requirements File and Print Server NetBIOS CD Server Subnet 1 Proxy Server Subnet 2 Subnet 3 Router A1Router A2 VPN Servers Link to Internet File and Print Servers Firewall

72. To enhance a functional WINS solution for availability, you must determine the minimal requirements for servers, how to use replication, and the options that enhance a single server.

73. The following scenario describes an organization's current network configuration

74. Scenario An organization has decided to restructure an existing WINS-based network. You are assigned the task of enhancing the availability of the WINS solution. The current network configuration provides: Intranet access to all shared folders and Web-based applications at all locations. Internet access to all locations. Support for the existing infrastructure as shown in the preceding diagram. Support for a remote access server in Subnet 3 that provides VPN access for the Internet. Support for a mission-critical Web-based application that requires 24- hours-a-day, 7-days-a-week operation. Isolation of the organization's network from the Internet by using a firewall and a proxy server. Support for a non-WINS compliant CD server by using NetBIOS access in Subnet 3.

75.  Optimizing a WINS Design for Performance Reducing Response Time Replication Strategies

76. You can optimize the performance of WINS to provide the fastest possible response to client and replication requests. You can address the performance of an individual server from the following perspectives: Reducing response time to requests on the server. Reducing the time taken to replicate between servers.

77. Reducing Response Time WINS Server WINS Client CPUs Memory Disk

78. Reducing Response Time The WINS server response time to queries and requests is the indicator of server performance. Optimizing the performance of the WINS server minimizes the response time for client requests. WINS in Windows 2000 enhances performance by supporting: The use of multiple CPUs by the multithreaded WINS service. An optimized database to provide the best query response times. Burst-mode client registrations to prevent server saturation during periods of high activity. Multiple WINS servers that replicate the WINS database to partners.

79. Improving the Performance of a WINS Server You can improve the performance of a WINS server by: Adding multiple CPUs. Providing ample memory to support the service. Providing high performance disks. Using a high bandwidth network card. Using burst-mode name registration if periods of high activity cause server saturation.

80. Improving the Performance of the WINS Service You can improve the performance of the WINS service by: Adding multiple WINS servers. Placing servers on either side of restricted bandwidth WAN links. Reducing response times of DNS where WINS refers queries to DNS. Distributing clients across multiple servers to balance the client load.

81. Replication Strategies SEA-WINS SYD-WINS MEX-WINS ATL-WINS Australia 1 hour 3 hour 12 hours

82. Replication Strategies Replication traffic between servers in a multiple-server environment reduces the performance of WAN links. The replication schedule controls both the replication traffic and the convergence time. You can plan a schedule that minimizes replication traffic, while meeting the design goal for convergence time.

83. Replication Strategies To reduce the impact of replication, you can: Use partner replication schedules to control the frequency of traffic across WAN links. Use persistent connections to maintain inter-server connections and allow updates to be sent in smaller increments. Modify the schedule to replicate during non-peak hours of operation.

84. Replication Strategies The number of NetBIOS resources registered on a network sets the size of the WINS database and the amount of replication traffic. Consider disabling File and Printer Sharing for Microsoft Networks on computers that do not need to share resources with other network users. When File and Printer Sharing for Microsoft Networks is disabled, the server component is not registered, thereby reducing the number of registrations for a WINS client, and consequently, the amount of replication traffic.

85. Lab A: Designing a WINS Solution

86. Exercise 1 Designing a WINS Solution Objectives Develop a WINS solution that meets the requirements of a given scenario. After completing this lab, you will be able to: Evaluate a scenario specifying a WINS solution. Create a WINS solution for the given situation.

87. Prerequisites Before working on this lab, you must have: Knowledge of WINS features and functionality. Knowledge of WINS security, availability, and performance concepts.

88. In this exercise, you are presented with the task of creating a WINS solution for an organization that wants to restructure its existing network. You will design a WINS solution that supports the organization's requirements. You will record your solution on a Design Worksheet. Review the scenario, diagrams, and design limitations and requirements. Follow the Design Worksheet instructions to complete the Design Worksheet.

89. Scenario An organization has decided to restructure an existing network and wants to include WINS as a solution for their NetBIOS name resolution requirements. As a consultant, you have been given the task of redesigning the network infrastructure. The current network configuration provides: Intranet access to all shared folders and Web-based applications at all locations. Access to the Internet from all locations. Support for the existing infrastructure as shown in the scenario diagrams. Support for the number of hosts per location, which includes router interfaces and the proxy server intranetwork interface. Support for a remote access server at LocationA that provides VPN access for the Internet. Support for a mission-critical Web-based application that requires 24-hours- a-day, 7-days-a-week operation. Isolation of the organization's network from the Internet by using a firewall and a proxy server, both situated at LocationA.

90. Design Limitations and Requirements Your assessment of the existing network configuration and your investigation of future configuration requirements reveal the following design requirements, which you must meet in your WINS solution: Existing configuration information. The existing configuration includes: Bandwidth limitations, client data access patterns, and performance requirements mandate that under normal circumstances, WINS queries are not passed across WAN links. Tests conducted on the WAN links indicate that there is enough available bandwidth to allow any required WINS replication between locations. Servers are available on all subnets in all locations that can act as WINS proxies. Each location has an equipment room that houses all servers, routers, and the cable plant; any required WINS server(s) for a location will be installed here. Tests on the rack-mounted WINS servers indicate that each WINS server can support up to 3,000 hosts, while providing performance that meets the required client response times. All clients are WINS-compliant, except for a small number of non-Windows- based CD servers in LocationB.

91. Future configuration requirements. Future requirements include: WINS redundancy such that no single point of failure, except the routers, affects WINS availability. Performance within pilot test response times. Pilot tests on approved WINS servers indicate that each WINS server can support no more than 3,000 hosts while providing performance within the given response times. WINS servers must be positioned to minimize traffic across subnets wherever possible. Single function rack-mounted computers are to be used for the WINS servers. No other network services will be installed on these computers.

92. Design Worksheet Instructions To complete the Design Worksheet that follows, you need to: 1. Select the number of WINS servers to support the solution, and the location of these servers within the network. 2. Select the number of WINS Proxy Agents needed to support the solution, and designate their location within the network. 3. Describe a WINS replication strategy for the network. 4. Describe the required WINS client configuration to suit the requirements. 5. Describe options to increase the availability of the WINS solution.

93. Entire Network Configuration 1283 Hosts 129 Hosts LocationC LocationA T1 Link 833 Hosts LocationB T1 Link Fractional T1 Link Internet

94. LocationA Network Configuration Subnet A1A Link to LocationC Link to LocationB Subnet A3A Subnet A2A Link to ISP/Internet Router A1 Router A3 Router A2 Proxy Server VPN Server File and Print Servers Subnet A3B Subnet A1B Firewall

95. LocationB Network Configuration Link to LocationA Router B1 Subnet B1ASubnet B1B File and Print Server CD Servers

96. LocationC Network Configuration Link to LocationA Subnet C1A Router C1 File and Print Server

97. Review Introducing WINS Designing a Functional WINS Solution Securing a WINS Solution Enhancing a WINS Design for Availability Optimizing a WINS Design for Performance