New Domain vs new site?

  • Thread starter Thread starter Hank B
  • Start date Start date
H

Hank B

Hello, Guidence: Our Mgt. wants to set up a server to
REMOVE off site, in case of major disaster, they want to be
able to retrieve this server (Win2000) plug it into the
newtork and keep working. I had a thought that we could
configure it as a "site" as uposed to creating another
domain. That way all the printers\logins dns and etc. etc.
would be reletavely CURRENT. We could bring it in once a
week for updating. I know this would not be the "best"
idea, due to AD replication, but any thoughts or guidence
would be appreciated. Hank B PS. Two Win2000 servers,
running AD. is all we have. Most of our internet functions
run Free BSD..(dirty word) HA HA!
 
In this case, you do NOT want a new domain and you may not even need to set
it up as a different site. If you can have a persistent link to it, put it
in another site and replicate infrequently as you wish. Detaching it, you
don't really have the need for it to be site-aware, just for it to
replicate. Then the only benefit of setting it up as a different site is
that you're using IP rather than RPC as the replication protocol.

DO NOT forget about this and allow it to stay offline for too long. The
object tombstone timeout is 60 days by default. If you exceed this, you
generally have to scrap the server and re-install.

A better overall solution might be to have 2 DCs at your main site and
another off site for DR, but it sounds like you are trying to avoid this.
 
Hank B said:
Hello, Guidence: Our Mgt. wants to set up a server to
REMOVE off site, in case of major disaster, they want to be
able to retrieve this server (Win2000) plug it into the
newtork and keep working. I had a thought that we could
configure it as a "site" as uposed to creating another
domain.
Click to expand...

Neither domains NOR sites make sense for that.

(That you might put it in anthother site is somewhat
incidental.)
That way all the printers\logins dns and etc. etc.
would be reletavely CURRENT. We could bring it in once a
week for updating. I know this would not be the "best"
idea, due to AD replication, but any thoughts or guidence
would be appreciated. Hank B PS. Two Win2000 servers,
running AD. is all we have. Most of our internet functions
run Free BSD..(dirty word) HA HA!
Click to expand...

You should just put another DC for the same domain in another
site that is CONNECTED. Let it replicate normally.
Make it a DC, and a GC.

If you lose the first DCs or the entire location (fire, flood)
you can keep working -- from any client that is still on the
net. (You may -- eventually -- have to move the single
master roles IF the other DCs are permanently lost.)
 
Thanks for the help, we probally do not have the luxuary
of an off site connection. So as long as it is in the
network 'bout every 15 days it should be (reasonably)
workable just setting it up as a domain controller! Any
other pitfalls to worry about? TIA HB>-----Original
Message-----
 
You should place it in a site even if artificial IF
it will not be on the network.

Then you should replicate it at least once a week
if you wish to avoid (a lot) of spurious errors from
AD (in the event logs) due to inability to replicated.

With it in a separate site, you can make it available
ONLY to replicate a certain day (e.g., Saturday) etc.

The only reason for putting PHYSICALLY offsite
is to avoid catastrophic loss situations (fire, flood,
etc.)

The reason for putting it in a separate Site is to
control the replication -- whether due to WAN or
just your practice (disconnecting it) issues.

There is really no reason to disconnect it if the
network reaches it's location.
 
The only reason I suggested it not being in a site was that it would
replicate "relatively" immediately when it came on line and would not be
troubled by replication intervals and the like.

I WAS WRONG; HERB IS RIGHT. (I hate being wrong <smirk>)

If it expects to see it in the same site, you'll deal with constant whining
in the error logs that the replication partner is unavailable. This should
be in a site, with replication tied to a certain time and day. When the
server is connected, I would force replication and then run a verify to
ensure the replication had completed. I would do this since it seems that
you are trying to tie this down to a small window, but need it to be
complete.

If at all possible, spend the money to make this available for more regular
replication. Even if you have to do something like dial on demand routing.
Automated processes are usually preferable.
 
Ryan Hanisco said:
The only reason I suggested it not being in a site was that it would
replicate "relatively" immediately when it came on line and would not be
troubled by replication intervals and the like.

I WAS WRONG; HERB IS RIGHT. (I hate being wrong <smirk>)

If it expects to see it in the same site, you'll deal with constant whining
in the error logs that the replication partner is unavailable. This should
be in a site, with replication tied to a certain time and day. When the
server is connected, I would force replication and then run a verify to
ensure the replication had completed. I would do this since it seems that
you are trying to tie this down to a small window, but need it to be
complete.

If at all possible, spend the money to make this available for more regular
replication. Even if you have to do something like dial on demand routing.
Automated processes are usually preferable.
Click to expand...

He still hasn't explained why he is going to take
it off the network most of the time.
 
Back
Top