redundant dhcp and wins

I need a little bit of help with dhcp and wins. As part of my disaster recovery plan I am installing a dhcp and win server in our recovery site. I am running win2k on all servers. I want to create a redundant wins and dhcp server on our recovery site. the recovery site is in one of our branches and located on a different subnet.

I want to accomplish the follwoing:

redundant wins server where the headquaters wins server is setup as a push partner and dr server setup as pull. To reduce traffic I want replication to occur nightly. Also are there issue with doing replication over on a separate network?

redundant dhcp server, from all the articles I read the only way i can do this is by introducing an 80/20 split scope. Can someone provide me with good documentation on how to do an 80/20 split. Will it be best to setup a dhcp relay agent?
MaquinalocaAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Mike KlineCommented:
Nice work setting up a disaster recovery plan!!

What is the link speed between your branch office and your head office.   Replication to a separate network is fine.  We replicate between our child domain and our parent across the country but we have a fast link.

The 80/20 split is a good idea for redudancy.  I'll get you a guide on that.  Are you currently backing up your WINS and DHCP databases?

This article is a little dated but I'm such a huge Mark Minasi fan I wanted to include it

http://www.windowsitpro.com/Windows/Article/ArticleID/4976/4976.html
DHCP recovery

Thanks
Mike
0
BlackmoorianDirector of Professional ServicesCommented:
You will definitey need a relay agent to be able to go across the router to the different subnet. That is the only way a DHCP request will be able to reach the server.

As far as setting up the DHCP split, it depends on the number of machines that request addresses from your DHCP Server. I myself use a 50/50 split and both are online at all times and service requests. If one fails the other picks up the slack but then again I never have more machines online than half the number available for the total scope.
0
Nirmal SharmaSolution ArchitectCommented:
You both are talking about your own and now talking about his requirement for WINS...first read the question carefully note all lines and then start answering.

Advice.

I need a little bit of help with dhcp and wins. As part of my disaster recovery plan I am installing a dhcp and win server in our recovery site. I am running win2k on all servers. I want to create a redundant wins and dhcp server on our recovery site. the recovery site is in one of our branches and located on a different subnet.

I want to accomplish the follwoing:

>>>redundant wins server where the headquaters wins server is setup as a push partner and dr server setup as pull. To reduce traffic I want replication to occur nightly.
>>>Also are there issue with doing replication over on a separate network?

That's what they said....Speed and Convergenece Time.

Configuring WINS replication

Before configuring replication, you should first carefully design and review your WINS replication topology. For wide area networks (WANs), this planning can be critical to the success of your deployment and use of WINS. In general, WINS offers you the following options and possibilities to choose from when you are configuring replication:

    * You can manually configure WINS replication for a WAN environment.
    * For some larger campus networks, you might also configure WINS to replicate within a LAN environment.
    * In smaller or bounded LAN installations, you might consider enabling and using WINS automatic partner configuration for simplified setup of WINS replication.
    * In some larger or more global installations, you might have to configure WINS across untrusted Windows NT domains.

***********Replication across wide area networks**************

When configuring WINS replication, the two most important planning issues are:

    * Whether your WINS replication occurs over slower WAN links.
    * The length of time required for all replicated changes in the WINS database to converge and achieve consistency on the network.

The frequency of WINS database replication between WINS servers is a major planning issue. The WINS server database should be replicated frequently enough to prevent the downtime of a single WINS server from affecting the reliability of the mapping information in other WINS servers. However, the time interval between replications should not be so small that it interferes with network throughput.

Network topology can influence your decision on replication frequency. For example, if your network has multiple hubs connected by relatively slow 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, as shown in the following figure, the intervals used for configuring pull replication for WINS servers could be set according to proximity between servers and the likelihood of a high-speed link connecting servers configured as replication partners of each other.
Art Image

In this example, two WINS servers--SEA-WINS and ATL-WINS--are located in Seattle and Atlanta. Another two servers--MEX-WINS and SYD-WINS--are located outside the United States in Mexico City and Sydney. Because SEA-WINS and ATL-WINS are located across a higher-speed WAN link, they are configured to replicate once every hour. For the servers outside the United States, replication intervals might be set higher, such as either 3 or 12 hours, because lower-speed links are associated with these connections.
Planning the convergence time

Convergence time is the time needed to replicate a new entry in a WINS database from the WINS server that owns the entry to all other WINS servers on the network. When planning for WINS servers, you must decide what is acceptable as the convergence time for your network.

Using the previous example, if a WINS client in Seattle registers its name with the WINS server in the figure labeled SEA-WINS, other WINS clients in remote locations might query for the client name and not find it in WINS. In some cases, if the address of the client has been changed, the remote locations would only have a mapping for the previous IP address of the client in their local server databases.

WINS clients that query any of the other WINS servers in the figure (that is, ATL-WINS, MEX-WINS, SYD-WINS) only receive a positive and correct response when the new or updated mapping for the client has been fully replicated from the owning WINS server, SEA-WINS, to all of the other servers. Replications from SEA-WINS could be triggered in one of two ways:

    * A push replication trigger is sent based on the frequency of updates made at SEA-WINS.
    * A pull replication trigger is sent to other WINS servers based on the configured Replication interval set in Replication Partners Properties at SEA-WINS.

Given this configuration, a new or updated entry at SEA-WINS is only replicated when the pull replication interval expires, but queries at remote sites for the new name mapping might not succeed until later. This is because the time interval for replication to ATL-WINS is one hour; it is three hours for MEX-WINS; and it is 12 hours for SYD-WINS. In this case, WINS convergence time is calculated as:

12 hours + 2 * (1 hour) = 14 hours

In reality, name query requests can succeed before the convergence time elapses. This happens when the entries replicate over a shorter path than the worst-case path. It also happens when the Number of changes in version ID before replication threshold in push replication settings passes before the Replication Interval expires in pull replication settings. This results in earlier replication of the new entry. The longer the replication path, the longer the convergence time.

Notes

    * After each administrator configures the respective WINS server, you can use Replicate Now (in the WINS console) to start immediate replication between the configured WINS servers.
    * When replication occurs, you can use Display Records to view records for the remote WINS server database. However, to make changes to the remote WINS database, you must be logged on under an account with required user rights in the respective domains for both servers involved.
    * Replication can also occur between two separate stand-alone servers that participate in a workgroup.

Replication across local area networks

When configuring WINS replication for local area networks (LANs), the issues are similar to those that occur in WAN environments, although less critical.

Because the speed of the underlying network links for LANs are much greater than for WANs, it might be acceptable to increase the frequency of WINS database replication, by optimizing push and pull parameters for LAN-based replication partners. For push/pull partners, you can do this by decreasing the Number of changes in version ID before replication and Replication interval settings accordingly, from what you would use for WAN-based partners on slower links.

For example, between LAN-based replication partners it often works to enable WINS to use a persistent connection between the servers. If a persistent connection was not used, the normal update count threshold would default to a minimum of 20. With persistence, a smaller update count value can be specified.

Next, you could specify a much smaller number, such as a value of one to three in Number of changes in version ID before replication before WINS sends a push replication trigger to the other partner. For pull partners, you might also consider setting the Replication interval to a value in minutes, instead of hours.

As in WAN replication planning, the WINS server database should be replicated frequently enough to prevent the downtime of a single WINS server from affecting the reliability of the mapping information in other WINS servers. However, the time interval between replications should not be so small that it interferes with network throughput.

For network-intensive environments, it is a good idea to use a network monitoring tool such as Network Monitor to help measure and determine how to optimize your WINS replication strategy.
Automatic partner configuration

You can configure a WINS server to automatically configure other WINS server computers as its replication partners. With this automatic partner configuration, other WINS servers are discovered when they join the network and are added as replication partners.

Automatic configuration is possible because each WINS server announces its presence on the network through periodic multicasts. These announcements are sent as IGMP messages for the multicast group address of 224.0.1.24 (the well-known multicast IP address reserved for WINS server use).

Automatic replication configuration monitors multicast announcements from other WINS servers and automatically performs the following configuration steps:

    * Adds the IP addresses for the discovered servers to its list of replication partner servers.
    * Configures the discovered servers as both push and pull partners.
    * Configures pull replication at two-hour intervals with the discovered servers.

If a remote server is discovered and added as a partner through multicasting, it is removed as a replication partner when WINS shuts down properly. To have automatic partner information persist when WINS restarts, you must manually configure the partners.

To manually configure replication with other WINS servers, use the WINS console to specify roles for each partner and any related information.

Ref: - http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/standard/proddocs/en-us/sag_WINS_imp_ConfiguringReplication.asp

>>>redundant dhcp server, from all the articles I read the only way i can do this is by introducing an 80/20 split scope. Can someone provide me with good documentation on how to do an 80/20 split. Will it be best to setup a dhcp relay agent?

You have to configure Relay Agent because ordinary routers does not pass brodcast send by client machines (DHCPDISCOVER) . If you setup Relay Agent on both sides you have redudency if not then there is no use of two DHCP Servers across the sites.
80/20 is the best configuration as suggested by Mike because it is recommended by Microsoft also. So we follow MS.

Are you running DNS on your Network ?

Let me know.

Thanks
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Nirmal SharmaSolution ArchitectCommented:
One more thing..you also need to protect your WINS Servers...any hacker can execute a code.

WINS Replication IPSec Script
Download from here: -
http://www.microsoft.com/downloads/details.aspx?FamilyID=20f8df98-7eee-4293-b80a-c34bb1208828&displaylang=en

***Quote***

Overview
This is a sample script that can be used to automate the creation of a local registry based IPSec policy on a WINS server.

WINS Replication Blocker Script version 1.0

Purpose:
The purpose of this script is to create an IPSec policy on Windows 2000 or later WINS servers that will protect them from remote hosts exploiting a vulnerability in the WINS Replication protocol operating over TCP or UDP port 42.

This script accomplishes this by creating an IPSec policy with two filter rules that:
1. Block inbound packets destined for TCP or UDP port 42 from any host
2. Block outbound packets destined for TCP or UDP port 42 to any host

These default block rules will break WINS replication between any configured WINS replication partners, so in addition to the rules defined above; if the script is run interactively with no command line parameters it will prompt the user to enter the IP addresses of any WINS replication partners to exempt them from the default ‘block’ rule and allow WINS replication to continue functioning between trusted replication partners.

If you chose to enter IP addresses of WINS replication partners, the IP addresses you specify will be allowed to communicate with the local WINS server (i.e. these IP addresses will be exempt from the ‘block’ policy being created on the local WINS server).

All other IP addresses will be unable to communicate with the WINS server on TCP or UDP port 42.

This script can be run interactively and will guide the user through creating the policy and entering the IP addresses of the WINS replication partners or the script can be used with command line parameters to automate deployment from other scripts such as a logon script or machine startup script.

For more information please refer to the following knowledge base article:
890710 How to help protect against a WINS security issue
http://support.microsoft.com/?id=890710

***End Quote***
0
Nirmal SharmaSolution ArchitectCommented:
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows 2000

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.