Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 205
  • Last Modified:

DHCP Failover Relationship caveats

Hi mates,
looking to reinstall DHCP server(Serv-A) from 2012 to 2012R2 with same name and IP. This is partner server in dhcp relationship of two servers.

2nd partner(Serv-B) is already on 2012R2(installed couple of months before). MCLT of failover relationship is 1 hour and it is in load balance mode. Enable message authentication is checked with shared secret.

Now question is

1-)Is it necessary to remove relationship before demoting serv-A as the installation will took more than 1 hour?

Reason this is bothering me to have 2nd opinion is, last time when i was rebuilding serv-B from 2012 to 2012R2, i didnt break failover relationship between DHCPs. every configuration remain the same post promotion(i.e: IP, hostname, new certs in personal store). but under the failover status for partner server, it said:  state of the server :DOWN

So then i had to remove relationship and add both servers(New and Old) in new relationship, and replicate scopes from Serv-A to Serv-B to make them work in load balance mode onwards.

Looking for some guidelines around my question and best way of achieving this task.

Thanks
0
Steve McAuliffe
Asked:
Steve McAuliffe
  • 3
  • 2
1 Solution
 
eeRootCommented:
Yes, remove the relationship of the old server.  Even if the new server name and IP match the old server, the server's AD SID is different.
1
 
Steve McAuliffeAuthor Commented:
Thanks eeRoot, i also wondering some precise guidelines about adding new server(coupling up) into new DHCP relationship. Though gone through some useful technet blogs/articles and have some knowledgebase from past but wanting to vet my below plan.

1-)After building server(serv-a) and adding AD, DNS, DHCP Role. stop dhcp server service and cleanup dhcp folder under system32, then start dhcp server service.

2-)On serv-a, from powershell - Create a failover relationship via add-dhcpserverv4Failover -ComputerName serv-a.abc.com -PartnerServer serv-b.abc.com -Name dhcp1-dhcp2 -ScopeID 10.1.0.0 -LoadBalancePercent 80 -SharedSecret **** -Force


3-)Now on dhcp console of serv-b , underneath in ipv4, click on configure failover scopes and select all scopes and trigger failover scopes replication.

Is this correct?

any sanity check before/after or additional steps or considerations around?
0
 
eeRootCommented:
Yes, that looks correct.
0
Put Machine Learning to Work--Protect Your Clients

Machine learning means Smarter Cybersecurity™ Solutions.
As technology continues to advance, managing and analyzing massive data sets just can’t be accomplished by humans alone. It requires huge amounts of memory and storage, as well as the high-speed power of the cloud.

 
Steve McAuliffeAuthor Commented:
Sorry to be a pain..but looking for some detail answer as

i am slightly confused about the scope id parameter in creating relationship
ScopeID 10.1.0.0
What is this for ? and is this need to be already exist on new server? any tips and tricks
0
 
footechCommented:
The scope that you want to setup for failover should only exist on the source server.  When you set up the failover relationship it creates the scope on the other server.

You can view the ScopeID by running Get-DhcpServerv4Scope (it's one of the properties returned).  You specify it because you're setting up failover for a particular scope, though you can specify multiple scopes to set up if you want.

You could use the Invoke-DhcpServerv4FailoverReplication cmdlet to initiate the scope replication instead of using the GUI if you want.  I would just do it from serv-a.  However, I don't recall if this part is even necessary, or if it's done automatically as part of the creation.
0
 
Steve McAuliffeAuthor Commented:
Thanks Footech
0

Featured Post

Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now