Protech
New Friend (or an Old Friend who Built a New Account)
Registered:1453143188 Posts: 39
Posted 1496396210
Reply with quote
#1
Hi all,
The following is an issue I have seen at least 3 times over the past few months in different environments and wonder if you guys have any ideas.
Example situation:
You have an environment with Hyper-V hosts and Hyper-V replicas. On the Hyper-V hosts are based 2 DC's with 1 being the FSMO as per normal. The Domain runs fine.
One of the following situations occur:
- A failure occurs that means that you have to recover one or all of the DC’s
or
- You export one of the servers (normally the FSMO) in order to bring it up in another location, for example in an a totally isolated testing environment.
It used to be that generally you could achieve the above to get things working again without too much trouble, but recently when we have needed to do one of the above, although the recovered Server(s) boot up fine, AD fails to function. Investigation has shown that the reason this happens is probably to do with
the RID master.
There are 2 fixes we use for this which are documented below:
https://support.microsoft.com/en-gb/help/290762/using-the-burflags-registry-key-to-reinitialize-file-replication-service
https://support.microsoft.com/en-us/help/947022/the-netlogon-share-is-not-present-after-you-install-active-directory-domain-services-on-a-new-full-or-read-only-windows-server-2008-based-domain-controller
So…
Why does bringing up a copy of a previously fine DC (FSMO) in a new/test environment cause AD to have to be repaired in order to function?
Cheers
PT
wkasdo
Administrator
Registered:1451582051 Posts: 229
Posted 1496607116
Reply with quote
#2
What to say... AD was not designed to be recovered in isolation. Any time you restore a DC, it expects to have a working replication partner. This: > Why does bringing up a copy of a previously fine DC (FSMO) in a new/test environment cause AD to have to be repaired in order to function? means recovering a DC in a nonworking environment, otherwise known as forest recovery. Search for that if you look for documentation. Details depend on: - OS version, 2003, 2008 R1/R2, or 2012 and later. - Hypervisor (does it support vm-gen-id) - SYSVOL mode (FRS vs DFSR); the burflag thing is only for FRS. - proper restore (BMR) vs snapshot restore - Forest structure (one domain or more) - DC role (FSMO or not), GC or not - and probably more.
__________________ [MSFT]; Blog: https://blogs.technet.microsoft.com/389thoughts/
Protech
New Friend (or an Old Friend who Built a New Account)
Registered:1453143188 Posts: 39
Posted 1496757457
Reply with quote
#3
Thanks for your comments:
A few thoughts:
"Any time you restore a DC, it expects to have a working replication partner." So this issue does not apply if you only have one DC? Does it expect to see one working replication partner or all DC's you may have?
In a disaster you may only have one DC so I take it your comments are still valid?
I/We know from experience that, in the past, you could take just one DC (FSMO/GC) to an isolated enviroment and AD would function correctly even if it's other DC's were not available.
Thoughts?
Thanks
PT
wobble_wobble
Associate Troublemaker Apprentice
Registered:1451575798 Posts: 871
Posted 1496792542
Reply with quote
#4
Quote:
Originally Posted by
Protech ...
"Any time you restore a DC, it expects to have a working replication partner." So this issue does not apply if you only have one DC?
If its a single DC then no - you can pull out the one and restore it in a new private locationQuote:
Does it expect to see one working replication partner or all DC's you may have?
In a disaster you may only have one DC so I take it your comments are still valid?
If you are restoring 1 of many (say 1 of 5 DC's) you will need to do metadata cleanup to remove all of the old/ missing DC's. I'd generally fix the recovered DC before anything else comes up, get AD working and then if there is Exchange in the environment, start that server second as you'll have to look around ADSI to edits its DNS/ GCs for Exchange lookups.Quote:
I/We know from experience that, in the past, you could take just one DC (FSMO/GC) to an isolated enviroment and AD would function correctly even if it's other DC's were not available.
As per above...you will need to do metadata cleanup to remove all of the old/ missing DC's. I'd generally fix the recovered DC before anything else comes up, get AD working and then if there is Exchange in the environment, start that server second as you'll have to look around ADSI to edits its DNS/ GCs for Exchange lookups.
__________________ Have you tried turning it off and walking away? The next person can fix it!New to the forum? Read this
Protech
New Friend (or an Old Friend who Built a New Account)
Registered:1453143188 Posts: 39
Posted 1497079244
Reply with quote
#5
Hi Many thanks for your explanation. One other question is that has it always been the case that a copy of a DC/FSMO placed in an isolated enviroment requires the removal of the now non-exsistent DC's in order for AD to function? I am sure that in that past I have undertaken such work and the FSMO/DC, although not happy that is can't see other DC's still allows AD to function. Additionally, take an example where 2 DC's in one Domain are in different physical locations connected by a VPN. e.g. DC1 (FSMO)--VPN================VPN=DC1 If the VPN goes down, would you expect DC1 to not be able to run AD as it could not see the other DC's in the Domain?
cj_berlin
Senior Member
Registered:1451592353 Posts: 268
Posted 1497083391
Reply with quote
#6
Quote:
Originally Posted by
Protech One other question is that has it always been the case that a copy of a DC/FSMO placed in an isolated enviroment requires the removal of the now non-exsistent DC's in order for AD to function?
yes.Quote:
Originally Posted by Protech If the VPN goes down, would you expect DC1 to not be able to run AD as it could not see the other DC's in the Domain?
As a rule, AD will survive a connectivity outage of hours or days quite nicely, but if your VPN were to go down for months, I would expect things to start falling apart at some point. And where you'd really get in trouble is if you restore connectivity after DCs get tombstoned in the other site. Guys running IT on shipping fleets need to consider this stuff and maybe reengineer their AD for longer 'outages' if they define a ship as an AD site of a larger forest (which they often do) but do not maintain permanent connectivity (which can cost you an arm an a leg over INMARSAT).
__________________ Evgenij Smirnov My personal blog (German): http://www.it-pro-berlin.de/ My stuff on PSGallery: https://www.powershellgallery.com/profiles/it-pro-berlin.de/