The Best Damn Windows Server 2003 Book Period- P76 ppt

Push Partnerships As the name implies, when a push partnership is configured, changes in the WINS database are pushed to the remote WINS server.. More accurately, a WINS server with reco

Normally, routers do not forward IGMP traffic, so this configuration is best used on small, unsegmented LANs However, it is possible to configure routers to forward this traffic, allowing automatic partner configuration to be used in a routed environment If there are only a few routers

in the environment, the amount of multicast broadcast traffic should be minimal

Push Partnerships

As the name implies, when a push partnership is configured, changes in the WINS database are

pushed to the remote WINS server More accurately, a WINS server with records to replicate sends a

push notification to target servers (those configured to use it as a pull partner), alerting them that it has records to update on the target WINS servers.The push notification includes an owner table that lists the owner IDs and the highest version ID for each owner.The target servers compare this information with their own owner tables to determine which records to replicate.The target servers reply to the push notification with a pull request, and the transfer of records takes place

Accordingly, since a transfer of records will not take place until a pull request has been received by the server that sent the push notification, pull replication is the single mechanism for replication The process for push replication occurs as follows:

1 The source WINS server receives updates to its database and, based on a configurable threshold, sends a push notification to the destination WINS server (its push partner), indi-cating that it has updates to replicate

2 The destination WINS server for the notification (the push partner) responds by initiating

a pull request to its pull partner (the WINS server that sent the notification), and the repli-cation is initiated between the replirepli-cation partners

Push replication is not schedulable according to an interval of time Rather, the WINS adminis-trator configures an update threshold that will trigger a push notification For example, the WINS server could be configured to send a notification to its push partner after it has received 100

updates Figure 20.21 shows the Push Replication tab of the Replication Partners Properties

dialog box with the default settings for push replication

Figure 20.21 Push Replication Settings

The settings that you enter here will determine the threshold trigger for the push notification.

In the configuration shown in Figure 20.21, a push notification is sent to the replication partner as

soon as an update occurs in the WINS database.This is the result of setting the value for Number

of changes in version ID before replication to 0 However, the value could be set to a higher

number, such as 100 It is also possible to configure a push notification to occur when the service starts up or when there is an address change in a WINS registration

The setting to Use persistent connections for push replication partners allows the

con-nections between WINS servers to remain open.This is a useful feature when the WINS servers are connected by a high-speed LAN Earlier versions of WINS would close the connection after each replication cycle Opening the connection to initiate a new replication cycle could cause delays, however modest, that are not acceptable in an environment where records need to be synchronized

as soon as possible

It is also possible to manually initiate the push notification, as shown in Figure 20.22 When you manually initiate the push notification, you can choose to push the notification to the replication partner or to trigger the replication to send a notification to all of its partners as well As an example, consider a replication topology where three WINS servers are configured as push replica-tion partners WINS-A replicates to WINS-B, which replicates to WINS-C So, if you manually sent

a push notification from WINS-A to its replication partner, WINS-B, you could force WINS-B to also send a push notification to its other replication partner, WINS-C

In certain rare situations, it might be desirable to use a push-only replication partnership for

one-way replication, for example, from a head office to a branch office For example, suppose that WINS-A in the head office configures WINS-B in the branch office as its push-only partner

(WINS-B should also configure WINS-A as its pull-only partner.) When WINS-A receives updates

to its records, it notifies WINS-B, which sends an update (pull) request to WINS-A for the changed records since the last replication cycle In this scenario, WINS-B never sends its updated records to WINS-A

Figure 20.22 Manually Starting Push Notification

Push partnerships are generally configured in LAN environments where bandwidth is not an issue, and it is not necessary to schedule replication to occur during off-peak hours In general, you should use push replication partnerships in the following situations:

■ There is ample bandwidth over LAN or WAN connections

■ There is a need to ensure that updates are replicated as soon as possible and the frequency

of replication traffic is not a consideration

Pull Partnerships

Pull replication differs from push replication in that the replication frequency is defined as an interval of time At regularly scheduled intervals, a pull partner requests updates from other WINS servers (those configured to use it as a push partner) for updated records that have a higher version

ID than the ones it currently has in its database

Pull replication is configured similarly to push replication.The primary difference is that the WINS administrator schedules the times that the pull replication will take place Figure 20.23 shows the settings for pull replication that an administrator can configure for individual replication partners

In some situations, it might be desirable to configure pull-only replication between replication

partners Usually, this configuration is implemented where WAN links are operating close to capacity and there is a need to schedule WINS replication during off-peak hours Pull-only replica-tion has an advantage over push-only replicareplica-tion in that the replicareplica-tion schedule can be known in advance With push-only replication, replication is triggered by reaching a configured threshold of updates, and you can only estimate when this would occur based on experience with the network However, a disadvantage of pull-only replication is that the WINS server could potentially have acquired a large number of updates to replicate between cycles

Figure 20.23 Choosing Replication Partnership Type and Push/Pull Settings

In general, you should use pull replication partnerships in the following situations:

■ There is limited bandwidth between WINS servers that requires replication to be sched-uled during off hours

■ There is a need to consolidate updates and reduce frequency and amount of replication traffic

■ There is a need to exercise finer control over the timing and frequency of replication traffic

Push/Pull Partnerships

A push/pull partnership is the default when you configure replication between WINS servers In fact, Microsoft recommends a push/pull partnership as a best practice and it further recommends that all WINS partnerships be set up this way, unless there is an overriding need to implement a limited partnership.The only need that Microsoft cites for a limited partnership is the presence of a large network connected by relatively slow WAN links Microsoft often stresses the need for sim-plicity in a WINS environment

With a push/pull partnership, a WINS server will be configured both to send push notifications and to make pull requests to its replication partner.The replication partner will also be configured in a similar way Such a configuration helps to ensure that synchronization among WINS server is optimal, depending on the pull schedule and the configured threshold for push notifications, among other fac-tors For example, suppose that a WINS server that suddenly experiences a large number of updates immediately sends a push notification to its push partner.The push partner would immediately request these updates, without waiting for the request to be triggered by its pull schedule Conversely, a WINS server always pulls up-to-date records from its pull partner according to the replication schedule, regardless of how few records have been updated on the pull partner WIN server

You should always try to deploy a push/pull partnership, unless there is an overriding concern that requires the implementation of a limited partnership

Replication Models

As we mentioned earlier, the replication model you design will have an effect on the convergence time for replicated WINS records and fault tolerance for replicated records A replication model that

is appropriate for your network topology will ensure the shortest convergence time for replicated WINS records Where possible, it is recommended that your replication model mirror your network topology and that you keep this model as simple as possible

In WINS environments where there are three or more WINS servers, you can employ either a

ring replication model or a hub-and-spoke replication model In more complex environments, these

models can be combined to ensure optimal convergence time and fault tolerance for a given net-work topology In the following sections, we will discuss each of these models in more detail

Ring Model

In a ring model, three or more WINS servers are configured to replicate with one another in a cir-cular fashion.The ring model provides for good convergence times for all replication partners when there are no more than four WINS servers Figure 20.24 shows a ring replication model

In this model, fault tolerance for replication of WINS records is given priority Imagine that a record is updated on WINS-A.The record must travel through either WINS-B or WINS-B before

it is replicated to C However, suppose that the WAN link connecting A and

WINS-D fails.The updated record can still arrive at WINS-C and WINS-WINS-D (via WINS-C) Conversely, a record created on WINS-D can still be replicated to WINS-A via WINS-C and WINS-B

Hub-and-Spoke Model

In the hub-and-spoke model, all WINS servers replicate with a centrally located hub WIN server The hub-and-spoke model provides for the shortest convergence time in a replication environment that comprises five or more WINS servers, because it provides for the shortest replication paths between any two WINS servers Furthermore, by implementing a hub-and-spoke model, you reduce the number of replication partnership agreements that you need to maintain Figure 20.25 shows a typical hub-and-spoke implementation

Figure 20.24 Ring Replication Model for WINS Servers

Push/Pull Partnership

Push/Pull Partnership

Push/Pull Partnership

Push/Pull Partnership

WINS-A

WINS-B

WINS-C WINS-D

Even though there are five WINS servers that replicate information, there are only four replica-tion agreements to maintain Furthermore, no server is more than two hops from any other server, regardless of the number of servers added to the topology

A disadvantage of this model is that it is not as fault tolerant as the ring model If WINS-A fails,

no WINS server will be able to replicate its records to other WINS servers Furthermore, depending

on the average number of records the spoke WINS servers need to replicate and the settings for the push and pull triggers, WINS-A can be continuously replicating with other servers and processing updates It should be well connected to the other WINS servers and have the capacity to handle the load

A Windows cluster gives you the ability to set up separate WINS servers, known as cluster nodes,

that use the same database located in a shared SCSI or Fibre Channel device When the WINS

server that is the active node in the cluster fails, the services will failover to another node Failover is

the process of taking resources offline in one node and bringing them online on a new node.The primary advantage of using a Windows cluster is that in the event of a failure of a WINS server, no subsequent replication needs to occur to synchronize records when the failed server is brought online, since only a single database is used Windows Server 2003 Standard, Enterprise, and Datacenter editions support clustering For more information about clustering, see the Windows Server 2003 help files

Hybrid Replication Model

In many situations, it is desirable to combine replication models As an example, consider a large organization that has three divisions in different geographic locations Each of these divisions has a number of branch offices that are connected to their respective divisional offices It might be advan-tageous to use a ring model of WINS replication among the divisional offices and use hub-and-spoke replication for replication between the divisional offices and their respective branch offices

Figure 20.26 shows a conceptual representation of a hybrid model Many other variations are

Figure 20.25 Hub-and-Spoke Replication Model for WINS Servers

WINS-A

WINS-B

WINS-D

WINS-E

push/pull

push/pull partnership

WINS-D

push/pull partnership

possible A hybrid replication model can employ any mixture of full and limited replication partner-ships, driven by the contingencies of the network topology

WINS Issues

After establishing the need for WINS planning for the replication topology of the WINS infrastruc-ture, the WINS servers need to be installed and configured In this section, we will look at the var-ious configuration issues that a WINS administrator needs to be familiar with to ensure an efficient and secure WINS infrastructure, such as handing static WINS entries, client configurations, database maintenance, and WINS infrastructure security

Static WINS Entries

One of the advantages of using WINS is that it provides a way to dynamically register NetBIOS names, eliminating the need for static entries in LMHOSTS files However, there are situations that require the use of static mappings in the WINS server database For example, if you have non-WINS clients that are running NetBIOS applications, you might find it desirable to have entries for these clients in the WINS database, so that you can allow WINS clients to resolve the NetBIOS names of those clients Static mappings are superior to entries in an LMHOSTS file because they can be replicated throughout the WINS infrastructure

The use of static mappings can create problems on your network Unlike dynamic mappings, static mappings stay in the WINS database until they are manually removed (The expiration date for

the static mapping entry in the WINS database is labeled as infinite.) Furthermore, unless the migrate

on setting is enabled, static mappings are not overwritten by dynamic mappings For example, a client computer might be given a static mapping in the WINS database, or an LMHOSTS file might be imported to the WINS database, creating a number of static WINS entries If the clients

Figure 20.26 Hybrid Replication Model

Hub and spoke replication

Hub and spoke replication

Hub and spoke replication

Toronto

London Dallas

that are associated with the static mappings were later configured as WINS clients, they would not

be able to perform dynamic registration of their NetBIOS names, unless the migrate on setting was

enabled Figure 20.27 shows the Replication Partners Properties dialog box, where the Overwrite unique static mappings at this server (migrate on)setting is enabled

In general, static entries should never be created for WINS-capable client computers However,

it is sometimes desirable for security purposes to use static entries for mission-critical servers to pre-vent redirection

Using Static Entries to Prevent Redirection

Unlike with Active Directory-integrated DNS zones, you cannot restrict clients from dynamically registering names according to Windows group memberships.The only mechanism by which WINS prevents clients from registering duplicate names is to send a challenge to the IP address of the active record If the client responds to the challenge, the duplicate name registration is denied

However, during periods when WINS clients are offline for maintenance or are being rebooted, a rogue computer could register the same name as the original computer, with the malicious intent of redirecting traffic to the rogue computer In high-security environments, it might be desirable to

enter static mappings for critical computers and to ensure that the Overwrite unique static map-pings at this server (migrate on) setting is disabled

Multihomed WINS Servers

A multihomed WINS server is one that has more than one active network connection.You should avoid this configuration of a WINS server Name resolution and replication problems are often the result of using a multihomed computer as a WINS server

Figure 20.27 Configuring Static Entries to Be Overwritten

Client Configuration

WINS client configuration is accomplished either through a DHCP server or manually by

config-uring the settings in the WINS tab of the Advanced TCP/IP Settings property pages of the

TCP/IP properties Figure 20.28 shows these settings for a Windows XP client

With the configuration shown in Figure 20.28, the client will use an LMHOSTS file if WINS name resolution fails.This is the default configuration Also, the client is configured to get informa-tion about whether NetBT should be enabled from the DHCP server (This informainforma-tion is provided

by a special Microsoft-specific DHCP option.) If the client does not get this information from the DHCP server, it will default to enabling NetBT.You would disable NetBT only when you need to, such as on the Internet-facing interface of a multihomed server or if you have determined that the interface does not need to be able to provide access to NetBIOS applications

If you are using a DHCP server, you do not need to specify static addresses for WINS servers in this dialog box If you do configure WINS addresses here, these settings will override those that are supplied by the DHCP server If you are using DHCP to supply the client settings, you will need to configure two DHCP options:

■ Option 044 WINS/NBNS Servers You use this option to provide DHCP clients with the IP addresses of WINS servers to contact

■ Option 046 WINS/NBT Node Type This option governs the order of NetBIOS name resolution mechanisms that will be used.The hybrid setting option (0x08) is the one most commonly used With the hybrid node option specified, the WINS client will contact a WINS server before using broadcasts and other methods to resolve names.The mixed node setting option (0x04) forces WINS clients to use broadcasts before contacting the WINS server.This setting is useful in situations where there is a single subnet in a small branch office connected by a slow WAN link In this case, you might want broadcasts to

Figure 20.28 Advanced TCP/IP Settings for WINS Client Configuration

resolve local NetBIOS names before contacting the remote WINS server (NetBIOS node types and name resolution were discussed earlier in this chapter.)

Figure 20.29 shows the configuration of DHCP server options to support WINS client configurations

Multiple WINS Server Addresses

If you specify multiple WINS server addresses in the client configuration, the client will try to use the first WINS server in the list for registration and name resolution requests If the primary server fails to respond, the client will then attempt to contact the alternate WINS servers in the order listed Up to 12 WINS servers can be specified for Windows XP and Windows 2000 clients

WINS Proxy Agent

For the rare case where you have a NetBIOS client that is not capable of querying a WINS server for NetBIOS name resolution, you can set up a WINS proxy agent.The WINS proxy agent is a WINS client that is set up on a subnet to provide limited WINS support for b-node and non-WINS NetBIOS clients A non-WINS proxy agent listens for name registration and name query broad-casts, and it forwards these to its configured WINS server.This process ensures that the b-node client does not initialize with a duplicate name that is already registered in the WINS database and provides name resolution on behalf of the b-node client

A common misconception is that a WINS proxy client will register the name on behalf of the non-WINS client.This is not the case.The WINS proxy merely contacts the WINS server to verify that the non-WINS client name does not exist If there is a duplicate name in the WINS database, the WINS proxy client will send a negative response to the b-node client

The proxy agent will use its NetBIOS name cache to temporarily store the results of responses

to its queries to the WINS server Performance of the WINS proxy agent could, therefore, be

Figure 20.29 DHCP Options for WINS Client Configurations