Setting up Domain Controller in Disaster Recovery site

Discussion:

Setting up Domain Controller in Disaster Recovery site - AD issues!

(too old to reply)

Wolfman099

2006-08-04 00:52:38 UTC

I have been assigned a task to setup our current domain in another
site. This secondary site will be used for Disaster Recovery purposes.
About a year ago we had our file server replicating out to the DR
site, but no one could access their files because there was no domain
controller. We are running a 2003 Active Directory Domain with a
direct T1 line to the DR site. The DR site has the exact same servers
setup as we do in our main office. I am having some trouble getting
the Domain Controller in the DR site to communicate properly with our
Office Domain Controllers.

Let me explain our routing setup as this is what is causing the most
confusion. We are using a 10.0.0.0 scheme in our main office. Our
servers in our DR site are setup with the exact same IP's. For
example, if DC01 in our office has an IP of 10.0.0.1 then the DR
version DCDR01 would have an IP of 10.0.0.1. We have routing setup so
that DC01 can talk to DCDR01 through a 192.168.134.78 IP and DCDR01 can
talk back to DC01 through an IP of 192.168.132.78 IP.

This scheme works great for our Unix systems, but I am having trouble
getting the DC in the DR site to communicate completely with the DC's
in the main office. When I originally tried to run the DCPROMO on the
DR domain controller, I received an error stating that the domain could
not be found. I added a second entry for DC01 in the main office DNS
with the 192.168.134.78 IP. So in the main office DNS, I have two
entries for DC01. One with the 10.0.0.1 IP and the other with the
192.168.134.78 IP. After adding this entry, AD installed fine.

The next day I tried to login to the DCDR01 server, but received an
error that the domain could not be found. I could not login at all
until I added an entry back on our main office DNS with the
192.168.132.78 IP. When I open DNS on DCDR01, it says "Cannot contact
the DNS server." When I look at the services, DNS is started and
running. When I look at the Event Viewer, the last entry always says
that the DNS Server has shutdown I also get this entry in the event
viewer which I think tells me that DNS will not work until AD starts
working. How can I get AD working without DNS!?

"The DNS server was unable to open the Active Directory. This DNS
server is configured to use directory service information and can not
operate without access to the directory."

I am very confused as how to get my DR server to communicate properly
with the main office Domain Controllers. Currently, I have a DNS entry
in the main office for DC01 with the 10.0.0.1 and also an entry for
DCDR01 with the IP of 192.168.132.78.

Can someone please help out with this situation? This is a high
priority project and I have spent hours and hours and cannot get this
to work. I'd be happy to provide more information if anyone needs it.
Thank you in advance!!

Wolfman099

2006-08-04 01:04:25 UTC

Permalink

I also wanted to add that I have the DCDR01 setup with itself as the
DNS server. The primary is 10.0.0.1 and the secondary DNS is
192.168.132.78 (DC01).

Anthony

2006-08-04 06:42:11 UTC

Permalink

It looks like you are trying to do your DR by multihoming all the servers.
There's a bunch of stuff about setting up multihomed domain controllers.
Basically it comes down to preventing the standby DC from registering the
10.0.0.0 addresses in DNS, and removing any traces of existing
registrations. The server will then communicate on the 192.168 address. The
main DC would only have a 10.0.0.0 address. In a DR situation you would need
to change the standby DC to register its 10.0.0.0 address. You would also
need to make sure that the DNS and WINS registration of the existing DC were
completely cleared first. I am not sure you would be achieving anything as
you could just as easily change the standby DC address when needed.

I am interested in your DR strategy of using duplicate addresses, and
possibly names, you don't say. I don't fully understand how it would work.
If you had a different name, and registered a different address in DNS, I
don't follow what you would have achieved. If it had a duplicate name but
only used the 192.168.0 address I don't follow how it would join the domain.
Its an interesting idea though. Would you mind explaining a bit more about
how it works?

Anthony

Post by Wolfman099
I have been assigned a task to setup our current domain in another
site. This secondary site will be used for Disaster Recovery purposes.
About a year ago we had our file server replicating out to the DR
site, but no one could access their files because there was no domain
controller. We are running a 2003 Active Directory Domain with a
direct T1 line to the DR site. The DR site has the exact same servers
setup as we do in our main office. I am having some trouble getting
the Domain Controller in the DR site to communicate properly with our
Office Domain Controllers.
Let me explain our routing setup as this is what is causing the most
confusion. We are using a 10.0.0.0 scheme in our main office. Our
servers in our DR site are setup with the exact same IP's. For
example, if DC01 in our office has an IP of 10.0.0.1 then the DR
version DCDR01 would have an IP of 10.0.0.1. We have routing setup so
that DC01 can talk to DCDR01 through a 192.168.134.78 IP and DCDR01 can
talk back to DC01 through an IP of 192.168.132.78 IP.
This scheme works great for our Unix systems, but I am having trouble
getting the DC in the DR site to communicate completely with the DC's
in the main office. When I originally tried to run the DCPROMO on the
DR domain controller, I received an error stating that the domain could
not be found. I added a second entry for DC01 in the main office DNS
with the 192.168.134.78 IP. So in the main office DNS, I have two
entries for DC01. One with the 10.0.0.1 IP and the other with the
192.168.134.78 IP. After adding this entry, AD installed fine.
The next day I tried to login to the DCDR01 server, but received an
error that the domain could not be found. I could not login at all
until I added an entry back on our main office DNS with the
192.168.132.78 IP. When I open DNS on DCDR01, it says "Cannot contact
the DNS server." When I look at the services, DNS is started and
running. When I look at the Event Viewer, the last entry always says
that the DNS Server has shutdown I also get this entry in the event
viewer which I think tells me that DNS will not work until AD starts
working. How can I get AD working without DNS!?
"The DNS server was unable to open the Active Directory. This DNS
server is configured to use directory service information and can not
operate without access to the directory."
I am very confused as how to get my DR server to communicate properly
with the main office Domain Controllers. Currently, I have a DNS entry
in the main office for DC01 with the 10.0.0.1 and also an entry for
DCDR01 with the IP of 192.168.132.78.
Can someone please help out with this situation? This is a high
priority project and I have spent hours and hours and cannot get this
to work. I'd be happy to provide more information if anyone needs it.
Thank you in advance!!

Wolfman099

2006-08-04 12:27:35 UTC

Permalink

Anthony, thanks for the response.

I am as confused as much as you are as far as the strategy that my
company has chosen to take. The IP/Naming scheme was already put into
place before I started. The most confusing part about all this to me
is how two servers with different names are using the same IP address
and are expected to communicate with each other. For example...

The DCDR01 server uses the DC01 DNS as its primary. So as I stated in
my previous post, the Primary DNS in TCP/IP is 192.168.132.78. The
secondary is itself. I could only get AD to talk to each other
(partially, it doesn't work properly... and this is required for me to
be able to login) by adding an entry in DNS on DC01 for DC01 with the
IP of 192.168.132.78. So I have two entries for one server with
different IP's. The 192 entry is automatically deleted after about 10
minutes. There has to be a better way.

Post by Anthony
If you had a different name, and registered a different address in DNS, I
don't follow what you would have achieved. If it had a duplicate name but
only used the 192.168.0 address I don't follow how it would join the domain.
Its an interesting idea though. Would you mind explaining a bit more about
how it works?

All of the servers at the DR site have a different name, but share an
IP with a server at our main office. I assumed in a DR scenario that I
could setup DNS with alias's so that if someone was trying to map to
DC01, I would setup DNS to automatically point to DCDR01.

The main thing I am trying to acheive is having AD replicate out to DR
so that we can access our file shares at the DR site. I noticed that
there are not really any SRV records in DNS on DC01. I thought that
this might be a problem, but I don't know where to create the SRV
records for DCDR01. Does anyone have any more information on
"multihoming?"

Post by Anthony
It looks like you are trying to do your DR by multihoming all the servers.
There's a bunch of stuff about setting up multihomed domain controllers.
Basically it comes down to preventing the standby DC from registering the
10.0.0.0 addresses in DNS, and removing any traces of existing
registrations. The server will then communicate on the 192.168 address. The
main DC would only have a 10.0.0.0 address. In a DR situation you would need
to change the standby DC to register its 10.0.0.0 address. You would also
need to make sure that the DNS and WINS registration of the existing DC were
completely cleared first. I am not sure you would be achieving anything as
you could just as easily change the standby DC address when needed.
I am interested in your DR strategy of using duplicate addresses, and
possibly names, you don't say. I don't fully understand how it would work.
If you had a different name, and registered a different address in DNS, I
don't follow what you would have achieved. If it had a duplicate name but
only used the 192.168.0 address I don't follow how it would join the domain.
Its an interesting idea though. Would you mind explaining a bit more about
how it works?
Anthony

Anthony

2006-08-04 13:17:26 UTC

Permalink

It won't work, unless you have a subtle plan I am not aware of.
Forget the DCs for a moment. Lets say a live server has the same IP address
as a DR server. They can only have the "same" IP address by those two
subnets not communicating. It sounds like they have actually all been given
two addresses, and are communicating on the alternates. This does not really
achieve anything. In effect, your whole DR network is communicating as
192.168.132.0 and not as 10.0.0.0. You can't use an alias for a network
share, so you can't swap in the alternate file server without changing the
name and registering the correct IP address. You have achieved nothing by
using the duplicate IP addressing.
Now for the DC's. If you look up the stuff on multihoming, you will see that
you can only multihome a DC by preventing registration of one of the
addresses, and removing any reference to it. So the DR DC can have a
duplicate 10.0.0.0 address, but it must be disabled as far as DNS is
concerned, and it won't communicate on it. That means all the communication
is going on via the alternate 192.168.132.0 address. It may as well not have
the 10.0.0.0 address. If you were to go live with the DR DC, and assuming
you want to take the same address as the existing DC for DNS etc, you would
need to flush DNS and WINS of the registration of the existing DC before you
reuse the address for a different DC.
I think you just need to review your DR design for AD and domain services.
You need to take each service (DC, DNS, WINS, DHCP, Profiles, Files, Print)
and work out how to make them resilient or recover them as services. They
are each slightly different. At the moment your design is implicitly to run
everything on 192.168.132.0 and then swap it to a 10.0.0. address. But that
plan does not work:
- DNS and WINS need to be flushed fully before you can use the existing
addresses.
- DHCP won't know what addresses have already been assigned
- File shares can't be reached on a different name
- Print shares can't be reached on a different name
- Profiles won't be found on a different path
If you stick to running the DR DC on 192.168.132.0 then at least you will
have a secondary DC and DNS available. But that's as far as it goes,
Anthony

Post by Wolfman099
Anthony, thanks for the response.
I am as confused as much as you are as far as the strategy that my
company has chosen to take. The IP/Naming scheme was already put into
place before I started. The most confusing part about all this to me
is how two servers with different names are using the same IP address
and are expected to communicate with each other. For example...
The DCDR01 server uses the DC01 DNS as its primary. So as I stated in
my previous post, the Primary DNS in TCP/IP is 192.168.132.78. The
secondary is itself. I could only get AD to talk to each other
(partially, it doesn't work properly... and this is required for me to
be able to login) by adding an entry in DNS on DC01 for DC01 with the
IP of 192.168.132.78. So I have two entries for one server with
different IP's. The 192 entry is automatically deleted after about 10
minutes. There has to be a better way.

All of the servers at the DR site have a different name, but share an
IP with a server at our main office. I assumed in a DR scenario that I
could setup DNS with alias's so that if someone was trying to map to
DC01, I would setup DNS to automatically point to DCDR01.
The main thing I am trying to acheive is having AD replicate out to DR
so that we can access our file shares at the DR site. I noticed that
there are not really any SRV records in DNS on DC01. I thought that
this might be a problem, but I don't know where to create the SRV
records for DCDR01. Does anyone have any more information on
"multihoming?"

Wolfman099

2006-08-04 16:23:19 UTC

Permalink

Post by Anthony
Forget the DCs for a moment. Lets say a live server has the same IP address
as a DR server. They can only have the "same" IP address by those two
subnets not communicating. It sounds like they have actually all been given
two addresses, and are communicating on the alternates. This does not really
achieve anything. In effect, your whole DR network is communicating as
192.168.132.0 and not as 10.0.0.0.

The DR servers can only communicate to the live servers by routing over
a direct T1 link. The servers at the DR site have only one IP address
setup in TCP/IP. The routing does the conversion from the 10.0.*.* IP
to the 192.168.*.* IP. DC01 only knows of DCDR01 by its 192.168 IP.
It can't see the 10.0 IP at all.

The way that it will work is if our building gets blown away by a
torando, our users will VPN directly into the DR site. When connected
to the VPN, you can only access the servers by their 10.0.*.* IP, not
by the 192 IP, because the 192 IP's only exist through the routing
between the two sites. If I login to the VPN and try to ping
192.168.132.78 or 134.78, I would not get a response. If I pinged by
the 10.0.0.1 IP, it would work fine. These servers will only be used
in a total disaster scenario where our building will be completely gone
and users will VPN into the DR site.

I tried looking into the Multihoming thing, but couldn't find anything
relating to what i'm trying to setup.

Anthony

2006-08-04 17:23:18 UTC

Permalink

OK, we can forget multihoming, you are trying to replicate over a NAT
connection. I don't think that can work, but maybe someone will help you out
with a solution. You can see the problem. The DR DC has to register its
10.0.0.0 address in the AD integrated DNS. The DNS has to be replicated with
the main DC. But the main DC can't contact the DR DC on that address.
Anthony

Post by Wolfman099

The DR servers can only communicate to the live servers by routing over
a direct T1 link. The servers at the DR site have only one IP address
setup in TCP/IP. The routing does the conversion from the 10.0.*.* IP
to the 192.168.*.* IP. DC01 only knows of DCDR01 by its 192.168 IP.
It can't see the 10.0 IP at all.
The way that it will work is if our building gets blown away by a
torando, our users will VPN directly into the DR site. When connected
to the VPN, you can only access the servers by their 10.0.*.* IP, not
by the 192 IP, because the 192 IP's only exist through the routing
between the two sites. If I login to the VPN and try to ping
192.168.132.78 or 134.78, I would not get a response. If I pinged by
the 10.0.0.1 IP, it would work fine. These servers will only be used
in a total disaster scenario where our building will be completely gone
and users will VPN into the DR site.
I tried looking into the Multihoming thing, but couldn't find anything
relating to what i'm trying to setup.

Wolfman099

2006-08-04 18:25:22 UTC

Permalink

I asked for help at the DR site and here is what they told me.

"You need to somehow turn off dns replication.
setup DCDR01 DNS with the following:
192.168.134.78 IP for DC01 and 10.0.0.1 IP for DCDR01.

setup DC01 dns with the following:
192.168.132.78 IP for DCDR01 and 10.225.154.78 IP for DC01"

With the setup listed above, DNS on DC01 will only see DCDR01 through
the 192 IP and the setup of DNS on DCDR01 would only see DC01 through
the 192 IP. Which means that they would be able to communicate through
the proper channels. The only problem is, I can't get DNS setup on
DCDR01, because AD is not working propelry because AD can't
communicate! I tried setting up a temporary DNS server at the DR site
to point it to, but that didn't help at all.

This is so confusing and I need to get this setup as soon as possible.
We have several hundred gigs of data that we need to start replicating
as well.

I really appreciate all your help so far!

Anthony

2006-08-04 19:43:33 UTC

Permalink

The plan does not work. The best thing to do is to have the DC and the DR
servers in a separate subnet.
Anthony

Post by Wolfman099
I asked for help at the DR site and here is what they told me.
"You need to somehow turn off dns replication.
192.168.134.78 IP for DC01 and 10.0.0.1 IP for DCDR01.
192.168.132.78 IP for DCDR01 and 10.225.154.78 IP for DC01"
With the setup listed above, DNS on DC01 will only see DCDR01 through
the 192 IP and the setup of DNS on DCDR01 would only see DC01 through
the 192 IP. Which means that they would be able to communicate through
the proper channels. The only problem is, I can't get DNS setup on
DCDR01, because AD is not working propelry because AD can't
communicate! I tried setting up a temporary DNS server at the DR site
to point it to, but that didn't help at all.
This is so confusing and I need to get this setup as soon as possible.
We have several hundred gigs of data that we need to start replicating
as well.
I really appreciate all your help so far!

Wolfman099

2006-08-06 22:20:13 UTC

Permalink

Let me ask this question then to see if this will make a difference.

DCDR01 has its primary DNS server set to DC01 (192.168.132.78). This
means that whenever DCDR01 wants to talk to DC01, it thinks the IP is
10.0.0.1 because that is the entry in DNS on DC01.

Can I setup a 2nd DNS server at the DR site and point DCDR01 to that
DNS server? In this DNS server, I would setup a zone that matches the
domain name of our site and create an entry for DC01 with the
192.168.132.78 IP only. This way, when DCDR01 would want to talk to
DC01, it would be looking at the DNS server at the DR site which has
the appropriate IP. When DC01 wants to talk back to DCDR01, it would
be using itself as the DNS server and it would have the appropriate
entry to DCDR01 which is 192.168.134.78. Would I have to manually
setup the SRV records so that the new zone that I create knows about
the other domain controllers? This is the part of DNS that I am
unfamiliar with. It sounds like this would work. If you say no, then
my next question will be about changing the subnets out there.

Thanks everyone for helping out so far!

Anthony

2006-08-07 09:45:12 UTC

Permalink

I think what you are proposing breaks down into two parts:
1) Hack the DNS (no offense, just a simplification)
2) Replicate over two-way NAT so that their real addresses are hidden.

1) Maybe its possible in some way, but it raises all kinds of problems.
Basically it amounts to preventing the DC from registering its correct
address and manually creating dummy addresses. I can't see where this gets
you that is better than having a real 192 address, and preventing
registration of the 10. address (which you are already doing in the hack
solution). Lets say you switch over to the DR site. What DNS will VPN
clients use? They can't use the hacked one as it has the wrong addresses.
2) Lets put aside for a moment whether the DNS hack works, and assume that
each thinks the other is on a 192 network. I am surprised if that works for
a secure connection between DC's, but maybe someone will tell us it does.

I can see where you (or the network guys) are coming from. However it seems
an awfully difficult way just to avoid having redundancy in your VPN
connections. If you do it the other way, with a separate segment like
10.0.1.0, then you can achieve proper resilience with both sites providing
network services and failover if one is unreachable. If the main site goes
down, you are still going to have to do a bunch of recovery steps.
It will be interesting to hear other people's views on this.
Anthony

Post by Wolfman099
Let me ask this question then to see if this will make a difference.
DCDR01 has its primary DNS server set to DC01 (192.168.132.78). This
means that whenever DCDR01 wants to talk to DC01, it thinks the IP is
10.0.0.1 because that is the entry in DNS on DC01.
Can I setup a 2nd DNS server at the DR site and point DCDR01 to that
DNS server? In this DNS server, I would setup a zone that matches the
domain name of our site and create an entry for DC01 with the
192.168.132.78 IP only. This way, when DCDR01 would want to talk to
DC01, it would be looking at the DNS server at the DR site which has
the appropriate IP. When DC01 wants to talk back to DCDR01, it would
be using itself as the DNS server and it would have the appropriate
entry to DCDR01 which is 192.168.134.78. Would I have to manually
setup the SRV records so that the new zone that I create knows about
the other domain controllers? This is the part of DNS that I am
unfamiliar with. It sounds like this would work. If you say no, then
my next question will be about changing the subnets out there.
Thanks everyone for helping out so far!

Wolfman099

2006-08-08 00:46:17 UTC

Permalink

Post by Anthony
1) Hack the DNS (no offense, just a simplification)
1) Maybe its possible in some way, but it raises all kinds of problems.
Basically it amounts to preventing the DC from registering its correct
address and manually creating dummy addresses. I can't see where this gets
you that is better than having a real 192 address, and preventing
registration of the 10. address (which you are already doing in the hack
solution). Lets say you switch over to the DR site. What DNS will VPN
clients use? They can't use the hacked one as it has the wrong addresses.

I understand what you are saying. I never thought of it this way.

Post by Anthony
2) Lets put aside for a moment whether the DNS hack works, and assume that
each thinks the other is on a 192 network. I am surprised if that works for
a secure connection between DC's, but maybe someone will tell us it does.
I can see where you (or the network guys) are coming from. However it seems
an awfully difficult way just to avoid having redundancy in your VPN
connections. If you do it the other way, with a separate segment like
10.0.1.0, then you can achieve proper resilience with both sites providing
network services and failover if one is unreachable. If the main site goes
down, you are still going to have to do a bunch of recovery steps.
It will be interesting to hear other people's views on this.
Anthony

I see that segmenting the network will be about the only way that this
will work. The networking portion is definitley my weakpoint. I don't
really understand what it will take for us to setup the network at the
DR site on a different segment. What will this take? I believe the
routing with the 192 IP's is all done through the routers/switches.
Will it be easy to change this?(This was setup through corporate).
If I had the network at the DR site segmented with a 10.0.1.0 IP
scheme, will it mess up the 10.0.0.1 scheme that is already inplace on
the rest of the servers at the DR site? Could I setup this new segment
just for the windows servers? The windows servers don't really need to
communciate with the unix servers for what we do. If I did need the
10.0.0.1 IP's to communicate with the 10.0.1.0 IP's, this could be done
with routing anyways, right?

Our main office is on a corporate WAN that is using most of the
10.*.*.* IP's. Could I setup the DR site with 192 or 172 IPs? Would
the question I asked earlier still apply? Could the 10.0.0.1 servers
communicate through routing with a 192.168 network?

I feel bad for asking so many questions, but this is pretty stressful
task. :-)

Anthony

2006-08-08 07:32:27 UTC

Permalink

To set up a separate subnet, you need first to obtain from the network guys
an address range that is not in use. It really makes no difference to you
whether it is a 10, 172 or 192 address range. They will all communicate with
the corporate WAN when routing is set up.
Then you need the network guys to set up the switch/router to handle the
address range and create a LAN segment for you with routing from the
corporate LAN. Then you put the DR servers into this address range. In AD
Sites and Services you create a new site and site link. All exactly the same
as if you were setting up a new site. Set the DC up as a Global Catalogue.
This DC will now provide full resilience in the event the main DC is
unavailable for any reason, as it is advertised in the DNS used by clients.
If you really want, you can create a slight lag in the replication so that
any destruction at the main site is not replicated immediately to the
secondary site.
You can then ask the networking people to use this DC as the authentication
and DNS server for their redundant VNP connections.
Anthony

Post by Wolfman099

I understand what you are saying. I never thought of it this way.

I see that segmenting the network will be about the only way that this
will work. The networking portion is definitley my weakpoint. I don't
really understand what it will take for us to setup the network at the
DR site on a different segment. What will this take? I believe the
routing with the 192 IP's is all done through the routers/switches.
Will it be easy to change this?(This was setup through corporate).
If I had the network at the DR site segmented with a 10.0.1.0 IP
scheme, will it mess up the 10.0.0.1 scheme that is already inplace on
the rest of the servers at the DR site? Could I setup this new segment
just for the windows servers? The windows servers don't really need to
communciate with the unix servers for what we do. If I did need the
10.0.0.1 IP's to communicate with the 10.0.1.0 IP's, this could be done
with routing anyways, right?
Our main office is on a corporate WAN that is using most of the
10.*.*.* IP's. Could I setup the DR site with 192 or 172 IPs? Would
the question I asked earlier still apply? Could the 10.0.0.1 servers
communicate through routing with a 192.168 network?
I feel bad for asking so many questions, but this is pretty stressful
task. :-)