DHCP Failover best practices

I have two file servers running server 2012 R2, Server1 and Server2.  They are both configured as AD, DHCP, DNS servers.  Server2 hold the FSMO records. DFSR is deployed.

I have DHCP configured for failover  if either server should go down for some reason.  The Options replicate from Server2 to Server1, but the leases and Reservations do not seem to update, and I cannot add a reservation to server1.

When first set up, the list of leases and reservations seemed to update from either server.  

The mode is Hot standby.

What are the best practices for DHCP failover?  There are up to 50 users connected to the network

Obviously this will not function as a hot standby because if Server2 failed,  Server1 would not have the reservations necessary.  Creating reservations is necessary to accommodate the network scanner that directs scans to a specific IP address.
WilfAsked:
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.

Paul MacDonaldDirector, Information SystemsCommented:
Setting aside "best practices", let's deal with your situation.

To begin with, whatever your network numbering scheme is, why not reserve part of your IP address space so it's excluded from DHCP to begin with?  If you have a simple Class 'C' network, you could have your DHCP scope start at .50 or .100,  This would give you 205 or 155 IP addresses (respectively) to hand out via DHCP.  Since the first 49 or 99 IP addresses (respectively) are not in the DHCP scope, they're effectively "reserved", and can't be stepped on by clients.  This solves your core issue of your reservations not replicating.

As to fault tolerance, if you use a split scope instead of failover, you would eliminate replication problems altogether.  Going back to my example above with a Class 'C' network where DHCP starts at .50 or .100, you have either 205 or 155 IP addresses to hand out.  Divide either by two and assign each server a scope that encompasses one of those ranges:
Class 'C' network = 255 addresses
Client IP address range starts at .50, effectively reserving .1 - .49 for static assignment
Server 1 gets a DHCP scope of .50 to .153
Server 2 gets a DHCP scope of .154 to .254

Now, if either server goes down, clients can always get a valid IP address because both servers have enough IP addresses to accommodate the entire network.  A client that gets a DHCP address from a server that goes down will simply get a different IP address from the other server.
WilfAuthor Commented:
Is there a method to ensure the client gets the same IP address each time.  Are there any disadvantages to manually creating a static IP address on each work station?  The above solution may prevent the client from scanning to their workstation as the scanner only scans to a static IP address.
WilfAuthor Commented:
As per above,  with static IP addresses entered on work stations, I have had occasions when those stations would not connect to the network.  I would revert back to DHCP, and they would connect.  As long as they are reserved, they get the same IP and programs dependent on the same IP are not affected
Introduction to R

R is considered the predominant language for data scientist and statisticians. Learn how to use R for your own data science projects.

Paul MacDonaldDirector, Information SystemsCommented:
"Is there a method to ensure the client gets the same IP address each time."
Traditionally, this is done by either by giving the client a static IP or establishing a DHCP reservation for the MAC address.   My suggestion is to use static IP addresses rather than DHCP reservations.

"Are there any disadvantages to manually creating a static IP address on each work station?"
Just the time investment.  Also, DHCP provides its own reporting so you don't have to create a spreadsheet or anything.

"The above solution may prevent the client from scanning to their workstation as the scanner only scans to a static IP address."
I can't speak to this, as I'm not conversant with the problem, but you're right:  My suggestion may not work for you.

"I have had occasions when [static IP] stations would not connect to the network."
I would wager those clients were using an IP address that DHCP was also handing out.  With two clients on the network using the same IP address, you get bad behavior.  In my scenario, all the static IPs come from a pool that cannot be stepped on by DHCP, because the DHCP scope is outside the static pool.

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
WilfAuthor Commented:
The original setup for this unit is to assign the address pool from 155 to 195.

the reservations were in the .1 to .130 range [not restricted, but those were all that were used.  The servers are assigned addresses in the .240 to.250 range and the default gateway was.254.

I will assign static IPs to the clients that do not have them until I can get Server1 to replicate from Server2
WilfAuthor Commented:
thank you for the information.  It is helpful, and I will use it in the future
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
DHCP

From novice to tech pro — start learning today.