Associate
- Joined
- 16 May 2004
- Posts
- 111
- Location
- Cheltenham
This is probably going to sound a bit backward or a bit overcomplicated, one or the other, but I'm wondering if anyones had some experience working with an AD where the core datacentre site includes a DC at a different geographical location; so say 2 DCs in one datacentre, another DC in another datacentre a fair distance away, all assigned to the same site in AD.
That's the situation I find myself in. This has been done (not by me I hasten to add) with an idea toward providing a DR solution in the event that the core infrastructure crumbles for whatever reason; the estates all but entirely virtualised and the thinking behind the solution is SAN mirroring between the 2 datacentres, so all the services can be restored quickly at the other site in the event of said catastrophe. I assume the thinking from the AD point of view is that all will be smiley and happy on that side of things with an active and up to date DC running in the backup site.
Now, the problem I'm having at the moment is with a sub-project running on some new 2008 servers. The servers have been up and happily running for a couple of months now, all bar one which was having issues applying GPOs; it turns out that whilst this server was happily authenticating to a DC in the main datacentre, it was getting a referral from that DC telling it to use the DC in the backup datacentre for the domain DFS shares etc... this was all denied by firewalls until we opened them up. Problem solved temporarily... or not.
Having rebooted 4 of the new servers this evening I now find that 3 of the 4 are trying to use the DC in the backup datacentre; 2 of them are now exhibiting the same GPO\domain DFS share issues as the one that originally had the problem, and the one that originally had the problem has now actually used this remote DC as it's authenticating logon server (although it's working fine because the firewalls open).
In addition to the firewall changes, a few weeks ago I had to install DNS on this backup DC as for some reason it wasn't installed when the DC was promoted.
Obviously this could cause a lot of problems with the wider estate in the short term so I'll get to the bottom of what's changed tomorrow, but I think it could throw a bit of a spanner in their long term DR plans. Basically I think we have 3 or 4 options..
- there is a hotfix which puts the authenticating DC at the top of the domain DFS referal list (which is normally a random list of all DCs in the site), however I think you would also have to disable DNS round robin for this to work which I think would scupper DC traffic load balancing. To overcomplicate matters there are a handful of servers at the backup datacentre that now use this DC for all AD services.
- turn off the DC in the backup location, however it's a physical box so the AD partitions and database would be out of date when you brought it back online, and obviously someone would have to be onsite to turn it on.
- put the backup DC in a new site (how it really should be) and manually add the subnets if things go wrong... ball ache, could script it though I guess.
- delete the _ldap._tcp.<SITE>._sites.dc._msdcs.<DOMAIN>.<TLD> record for this DC in DNS, but that will stop the other servers in the backup location from being able to do domain lookups, without going back across the WAN to the core DCs
.. tis a vicious circle 
.
I guess I don't really have a specific question but it's a stupid bloody situation to be in and I'm wondering if anyone's encoutered anything similar? I can't think of one way around the problem that doesn't have a drawback..
Sorry for the mammoth read; bit of a braindump
That's the situation I find myself in. This has been done (not by me I hasten to add) with an idea toward providing a DR solution in the event that the core infrastructure crumbles for whatever reason; the estates all but entirely virtualised and the thinking behind the solution is SAN mirroring between the 2 datacentres, so all the services can be restored quickly at the other site in the event of said catastrophe. I assume the thinking from the AD point of view is that all will be smiley and happy on that side of things with an active and up to date DC running in the backup site.
Now, the problem I'm having at the moment is with a sub-project running on some new 2008 servers. The servers have been up and happily running for a couple of months now, all bar one which was having issues applying GPOs; it turns out that whilst this server was happily authenticating to a DC in the main datacentre, it was getting a referral from that DC telling it to use the DC in the backup datacentre for the domain DFS shares etc... this was all denied by firewalls until we opened them up. Problem solved temporarily... or not.
Having rebooted 4 of the new servers this evening I now find that 3 of the 4 are trying to use the DC in the backup datacentre; 2 of them are now exhibiting the same GPO\domain DFS share issues as the one that originally had the problem, and the one that originally had the problem has now actually used this remote DC as it's authenticating logon server (although it's working fine because the firewalls open).
In addition to the firewall changes, a few weeks ago I had to install DNS on this backup DC as for some reason it wasn't installed when the DC was promoted.
Obviously this could cause a lot of problems with the wider estate in the short term so I'll get to the bottom of what's changed tomorrow, but I think it could throw a bit of a spanner in their long term DR plans. Basically I think we have 3 or 4 options..
- there is a hotfix which puts the authenticating DC at the top of the domain DFS referal list (which is normally a random list of all DCs in the site), however I think you would also have to disable DNS round robin for this to work which I think would scupper DC traffic load balancing. To overcomplicate matters there are a handful of servers at the backup datacentre that now use this DC for all AD services.
- turn off the DC in the backup location, however it's a physical box so the AD partitions and database would be out of date when you brought it back online, and obviously someone would have to be onsite to turn it on.
- put the backup DC in a new site (how it really should be) and manually add the subnets if things go wrong... ball ache, could script it though I guess.
- delete the _ldap._tcp.<SITE>._sites.dc._msdcs.<DOMAIN>.<TLD> record for this DC in DNS, but that will stop the other servers in the backup location from being able to do domain lookups, without going back across the WAN to the core DCs
.. tis a vicious circle .I guess I don't really have a specific question but it's a stupid bloody situation to be in and I'm wondering if anyone's encoutered anything similar? I can't think of one way around the problem that doesn't have a drawback..
Sorry for the mammoth read; bit of a braindump
