I have changed the DNS settings and created a seperate job for one DC, so i did not have to back up the entire host.
Backup is currently running. Wil post back as soon is i have the chance to do the restore (and the wait for reboots
![Smile :)](https://forums.veeam.com/images/smilies/icon_smile.gif)
As far as I know, DFSR should be enabled by default on WS2008R2 DC. Though, you might want to check it.Might sound like a stupid question, but, is there any other way to know if my 2008R2 servers use DFSR or FRS? Both our DCs are 2008R2 and domain functional level is also 2008R2.
Code: Select all
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState
In order to check this, you can restore previously backed up DCs into isolated virtual environment (Virtual Lab), follow FRS -> DFSR migration steps. After migration process is finished, backup newly-updated servers, then, try to restore them and see whether the restore process is successfully handled by DFSR or not.I am very curious if DFSR would have handeled this better.
True.Unison wrote: DNS order is important for FRS - DNS order IS NOT important for DFSR!
I have just completed a test of this as mentioned above in bold at my site and can confirm the FRS behaviour with DNS settings.Fiskepudding wrote: True.
When using DFSR, the restore process i TRUELY automatic (Like Gostev claims)
![]()
![]()
It would be very interesting to know if you also have problems with the domain, after changnig DNS and restore.
Some times the AD tools actually worked, but after some time, and / or, reboots they were not. Sysvol was not replicating either.
Another good way to see if you use DFSR for replication would be to look in ADUC, under the domain, -> System -> DFSR-GlobalSettings
The "DFSR-GlobalSettings" folder/OU is created during migration. (I guess it is there if you have a new domian with 2008 + server as well.)
Thats right - this is what i have found also when researching DNS configs on DCs.tsightler wrote:Well, to answer my own question, after some research, it appears there's a huge amount of debate on the issue of proper DNS configuration for a DC, even among Microsoft DS professionals. In some cases there are even dueling blog entries from MS employees each pointing to different Technet or KB articles.
Thanks Unison for your reply.Unison wrote:Hey Push3r,
Can you confirm if DC2 is pointing to its self for primary DNS on the NIC?
As we have discovered in this thread (recently) - if you are running FRS and have your DCs pointing to themselves for primary DNS then the DC should recover perfectly fine on its own without having to manually force the DC into authoritative mode with burflags.
But....i have to ask the question.....Why is DC1 still physical? Why not VM it too, replicate it to your alien proof DR site and then you can be far more confident in your DR plan because you will have your DC partner pair in the primary site and in the DR site. I would not consider it a good DR position/site to cut off DC1 when the aliens come......if you cant ever get DC1 back into the fold then you are going to have to manually 'clean up' AD and that is messy.
Dont think there are really any good reasons these days to need a physical DC....think the only good reason i have ever heard is if your SAN Storage Infrastructure requires AD to come online (but i guess if you have enough $$$ to be running a SAN like this, you could probably get one of your VM DCs to run off separate VMFS stores).
push3r wrote:Thanks Unison for your reply.
The DC's are pointing to themselves as primary for DNS and to the other DC's for secondary.
And yes, when I first failover, I did NOT have to do anything (i.e. set burflags, etc) and my DC2 booted up a couple of time and I can login, see Sysvol, etc. Except that I get those FSMO validation errors which is due to the physical DC not being in DR site. As I replied to my post, the only solution for this is to manually remove the physical DC1 records from AD which is very messy. On top of that, failing back would be a complicated as well.
Believe me, I am all for 100% virtual. The big cheese, my boss, is old school who believed in the consultant (who setup the virtual infrastructure) is also somewhat old school. So, they believe in having a physical DC. Now this is making DR plan complicated. I will convince the big cheese to go 100% virtual and see. Do you have any official document from VMWare and/or Microsoft showing that 100% virtual DC is acceptable and is supported?
Code: Select all
repadmin /kcc
I am concerned because of several event 2092 where all of my FSMO function were not working until I had to manually step in and do one of the 3 things (1.metadata cleanup to remove DC1, 2.delete incoming replication links with DC1, or 3.seize all the roles again) I mentioned above to remove the unreachable DC1 from AD in my DR site. And I tested this. I could not add another AD object (i.e. user account) until i seized the the RID Master role again even though DC2 has all the FSMO role.tsightler wrote:I'm a little curious why you are so concerned about the FSMO roles. They should eventually sort themselves out once the KCC runs (every 15 minutes), and who really cares about replication not running since the replication partner (DC-1) is unreachable. It should not cause any actual issues in the mean time and eventually KCC will run and life will be good. Perhaps you can just force KCC to run with the following command:
Code: Select all
repadmin /kcc
Users browsing this forum: Google [Bot] and 189 guests