Benefits of a backup domain controller

[Simon Thomson]

We will be adding a second server to our SBS 2008 domain. This will be a
Server 2008 R2 install ( we are Action Pack subscribers) and will primarily
be a file server. I am considering making this second server a backup domain
controller as long as there are no huge issues with having the file server
and DC roles on the one box.

The main reasons for considering a backup DC are to have failover for AD,
DNS and DHCP so that people can continue working if our SBS goes down or I
have to restart it for some reason.

In looking around for the best way to implement this I found a few comments
which indicate that having a backup DC located in the same office as the SBS
box is of little or no benefit. I was wondering if anyone else had an
opinion on this or could elaborate on why it is of little value.

Cheers
Simon.

[Jeff Middleton [SBS-MVP]]

Simon,

The value of a backup DC (properly referred to as a Replica DC) is the same
with SBS 2008 as it is with any other domain configuration, there's no
difference.

Historical discussion of additional DCs offering little value in an SBS
based domain did and still do have some merits, but you have to get all this
in the right context.

In the early years of SBS it was widely documented that an NT BDC was pretty
useless for recovery of an SBS 4.x server for the simple reason that MS had
hardwired the setup so that you couldn't construct an SBS 4.x server in an
existing domain. Therefore, if you ever lost your SBS server, you were
effectively going to lose your domain as well, and the only way to recover
your SBS domain operations was to recover your SBS server from a backup and
restore it as it was previously configured.

In more recent versions MS has allowed SBS servers to be "joined to a
domain" as part of the normal setup process. This does at least on paper
suggest that there's a recovery path documented and support by MS for
recovering your domain, but it doesn't really negate the logic that will
remain true: the best recovery of your domain or SBS server still is to have
a foolproof and predictable plan to restore your preexisting SBS server from
a backup. If you can do that, then you can eliminate the entire "disaster
recovery of the domain" question from the discussion and focus on "what is
the value of a replica DC for continuity during a gap in operations while
your SBS is offline". So in this sense you have asked the right question for
the right reason.

If your SBS 2008 server is offline and it's your Exchange host, while it is
down you have no access to your email services, but you can in fact work
from your "cache mode" resources with Outlook 2003 and later. Therefore,
while you may not be able to "communicate with send and receive transport",
you can work from your cached information or even be queuing up replies
wihle the server is down. So in this sense, it's less of a problem than in
the past to have your Exchange offline.

In SBS 4.x through SBS 2000 you would find most deployments used the SBS
server as the firewall and gateway, typically with the use of the proxy
server (later ISA) as the mechanism. Therefore without your SBS, you had no
access to the Internet for general browsing. Even with SBS 2003 you might
still have configured your SBS as your gateway with a 2-NIC solution, so
that would still mean that losing the SBS prevented you from interacting to
the web at all. With SBS 2008, this too is no longer a concern because SBS
2008 doesn't support using the SBS server as either a gateway, router or
firewall to the Internet.

Certainly if you lose your SBS server and rely upon RWW for inbound activity
this is going to remain a loss of function when your SBS goes down, just as
you will lose your ability to manage any Exchange related tasks for obvious
reasons. So it brings you back to the question of "what exactly do I have
the ability to do with a replica DC present that I couldn't do without it?"
when the SBS server is down.

1. A replica DC can authenticate user logons, but you will need to make some
adjustments to allow logons to proceed normally if the PDC is down for any
length of time (measured in hours).

2. A replicat DC which is a file server can continue to share those files
out, as well as printers or any other LOB applications that are uniquely
hosted by that server. But this points out a flaw in the thinking for many
people approaching this topic: If you have shared files/folders or
applications hosted uniquely from one server, when you lose that one server
you lose that ability to operate on those resources. So in a way, you have
the same risk of losing access to your shared file server as you would if
you lose those resources on your SBS. Either way, you are dependent upon
access to whatever server is hosting those resources, and if that server is
down, you lose those resources.

3. Clearly it can be better in many environments to have "some resources" if
you lose a server than to lose all because you have no additional servers.
You have to weigh the cost of additional server hardware (assuming you add
additional physical machines), or for additional virtualized servers you
still need additional server licenses. It can make a great deal of sense to
have your LOB application which runs from SQL Server to be operated from a
separate machine than your SBS server if only to load balance your
operations and reduce complexity of the LOB product management. Many people
would like to see that separate server as a DC so that you could potentially
operate your LOB application even if our SBS is down, assuming that your LOB
is not Exchange integrated as CRM and therefore dependent upon both servers
for normal operations.

4. In years gone by I always found it convenient to make a separate file
server in my domains, but I rarely made those servers a DC. This is because,
contrary to popular belief, it's really not a problem to reboot your SBS
while people are working in your domain even if it is the only DC as long as
there are no open files (shared files) on that server because the server is
not critical to how communication works to find shared resources on other
servers. If your server is down long enough that you have users needing to
log off and logon a lot, this becomes a bit more complicated but not
necessarily to the point that it justifies having another DC just in case
you confront this condition.

5. If you SBS server should go down for an extended period, you may find it
is more complicated to have another DC in the domain when it comes down to
actually recovering your original SBS itself. I'm not trying to scare anyone
away from adding another DC, I'm just saying that having more DCs involves
more administration and more complicated disaster recovery conditions even
as it preserves more options. More options means more considerations, but
these considerations don't come without added complexity. As a very simple
statement, you can restore the one and only DC (read: yes, even SBS) in your
domain by simply restoring it from any backup from any time and you
immediately go back into operation based upon that restore. But at the point
you have multiple DCs, you have to become with potential synchronization and
replication repairs that are more complicated than simply restoring the one
machine.

As a summary statement I would suggest to people that I don't believe anyone
should fear running an SBS 2008 without an additional DC present, that's
really not an irresposible configuration by any stretch. (You will hear
arguments from people who think in terms of 10 server environments and their
opinion is colored by the scale of their world. Single server environments
don't have the same investments and value judgments.) Therefore, I don't
think anyone needs to rush out to buy more server licenses just to keep up
with the Jones'. (For internationals confused by that phrase, this is
referring to the idea that you have to buy something because everyone else
says you need to have one of those to keep up with everyone else who bought
one without a good reason other than everyone is buying one.)

However, if you are already at the point of chosing an additional server for
your operations, and it's not going to be a dedicated Exchange Server or
Terminal Server (Apps Mode), then it's not a bad idea to make it a DC unless
you confront a specific reason that it will complicate your management of
that machine. For dedicated Exchange Servers and Terminal Servers, running
them as a DC has significant negative concerns you would want to review, you
don't want to make them a DC just because you have another server. It's more
complicated than that.

I think that adding additional DCs to a domain is too often done without
first establishing an impeccable disaster recovery solution for the SBS
itself. Once you have a bullet-proof recovery process for your SBS 2008, you
will likely realize that you should never have a reason you can't get your
SBS server back up in running within 30-60 minutes provided you have another
x64 machine you can spin up a VM of your SBS or even a physical copy of your
SBS. So what I'm suggesting is that having an x64 machine with sufficient
RAM and disk space available to be your virtual or physical host of your SBS
is the key to having redundancy. Having that second piece of hardware
running as a live server may be a complication (or not) to being able to
mount a backup of your SBS on different hardware to resume working again.
You could typically bring a production SBS 2008 up on $700 worth of desktop
workstation hardware (or even less expensive is possible). If you want that
to be spare hardware, recovery hardware or a concurrent use of another
server you use in production, that's up to you. But I would focus upon how
you will get your SBS recovery going first, and look at the backup
implementation of another DC second. Once you have the ability to recovery
your SBS you will be able to really determine what value having another DC
really brings you. I don't think that a replica DC is necessary to reboot
your SBS during the business day, not for most businesses. But there's a
value judgment to be made, and replica DCs are not worth nothing, but they
are going to cost you something you should understand before writing a
check. If you will have the hardware running as a server already, you only
need to review the complications or advantages for your own situation.

- Jeff Middleton SBS-MVP
YC...@SBSmigration.com

"Simon Thomson" <si...@specterra.com.au> wrote in message
news:%23HsD$0lcKH...@TK2MSFTNGP04.phx.gbl...

[Dave Nickason [SBS MVP]]

Wow, d�j� vu : -)

"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:%23usXVZp...@TK2MSFTNGP04.phx.gbl...

[Ace Fekay [MCT]]

"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:%23usXVZp...@TK2MSFTNGP04.phx.gbl...

Excellent explanation. :-)

Ace

[Lanwench [MVP - Exchange]]

Jeff Middleton [SBS-MVP] <je...@cfisolutions.com> wrote:
> Simon,
>
> The value of a backup DC (properly referred to as a Replica DC) is
> the same with SBS 2008 as it is with any other domain configuration,
> there's no difference.
>

<snip>

Jeff, that answer was a bit too brief for me. Could you elaborate on that?
Perhaps some screenshots and callouts. Oh, and I'd also like a cookie.

[Jeff Middleton [SBS-MVP]]

Funny you mention that. I decided to find out if I was quoting myself or
contridicting my past recommendations, so I decided to check the history on:

Googlegroups:*sbs*
Author: Jeff Middleton
Keywords: BDC

And here is (a surprisingly amusing walk down history lane for many people
here) a couple of flashbacks

From 2005: [from reading this thread, I think I bought Lanwench a cookie for
the first time the month before this post]
http://groups.google.com/group/microsoft.public.windows.server.sbs/browse_thread/thread/31cc5fdd75f72d99/cb5bda772471db2d?hl=en&q=%22bdc%22+group:*sbs*+author:jeff+author:middleton

"The idea of a BDC in an SBS network, even if the name doesn't apply
anymore,
it remains a consistent concept that you can use another DC to ensure that
users can logon, and can still access whatever resources are still
operational in the network (with the SBS down)...."

From 2002:
http://groups.google.com/group/microsoft.public.backoffice.smallbiz2000/browse_thread/thread/5cd32623c07c7547/e3de1e6b4dc86693?hl=en&q=%22bdc%22+group:*sbs*+author:jeff+author:middleton

"There is only one really good reason for having a second DC in an SBS
domain, and that is if you have ..."

From 2000:
http://groups.google.com/group/microsoft.public.backoffice.smallbiz/browse_thread/thread/d1dff4c3a592de94/1dd194ec2bd71ff0?hl=en&q=%22bdc%22+group:*sbs*+author:jeff+author:middleton

"A significant consideration for BDC is this: A BDC can never be promoted,
converted, sloshed, or painted as an SBS server....no way to get there. This
means, that the BDC is only useful while..."

And NOW from a previous decade back....
From *** Sept 1999 *** which even predates my first MVP award by a couple
months. :)
http://groups.google.com/group/microsoft.public.backoffice.smallbiz/browse_thread/thread/5f40b8328b357b5b/f37187eb53fa0e0d?hl=en&q=%22bdc%22+group:*sbs*+author:jeff+author:middleton

"As Tom says, your is one of the few cases where a BDC with SBS can make
sense, to a degree. If you have read the technote on BDC with SBS and know
that it has minimal value for recovery of the SBS domain, then you know that
BDC really just provides logon services, that's about it.

To expand on the concept a bit...." [3 pages later]

Jeff Middleton (humbly since 1999) SBS-MVP
YC...@SBSmigration.com

10 years with your my SBS related answers to your BDC questions.

"Dave Nickason [SBS MVP]" <gwdi...@NOSPAM.frontiernet.net> wrote in message
news:OjqXGmrc...@TK2MSFTNGP06.phx.gbl...

[Ace Fekay [MCT]]

"Lanwench [MVP - Exchange]"
<lanw...@heybuddy.donotsendme.unsolicitedmailatyahoo.com> wrote in message
news:ea5QAAsc...@TK2MSFTNGP02.phx.gbl...

Cookie monster.

[Jeff Middleton [SBS-MVP]]

Sounds like a great idea. You bring the milk.

- Jeff

"Lanwench [MVP - Exchange]"
<lanw...@heybuddy.donotsendme.unsolicitedmailatyahoo.com> wrote in message
news:ea5QAAsc...@TK2MSFTNGP02.phx.gbl...

[Simon Thomson]

Thanks for taking the time to write such a detailed answer Jeff.
I smell an in joke in the "cookie" thing but if a cookie is a good thing and
I had one it'd be yours.
You may not have simplified my decision but it will now be more considered
and informed when I make it.

We are in fact a virtualised shop with two VMware ESXi hosts so the restore
process is as simple as starting the most recent full copy (weekly) of the
SBS server from shared storage (or tape if things have really gone pear
shaped) and then restoring that from either of the duplicate SBS backup
(twice daily) USB disks.

I had envisaged that any Replica DC would be read only, although I am still
in the process of investigating that option. In my mind this configuration
would simplfy any restore as no new DC related data could be written to the
Replica DC while the Primary DC (SBS) was down.

I am aware that a Replica DC will not allow continuity of SBS specific
services (Exchange, WSS, RWW) but if a Replica DC also held replicas of DNS
and DHCP then the network would continue to function minus the SBS specific
services. For us it is certainly better to have "some resources" than none.
My general aim is to make any outages as invisible as possible to the users
I support.

Thanks again for the food for thought.

Simon.

"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:%23oK6wrt...@TK2MSFTNGP02.phx.gbl...

[Andrew M. Saucci, Jr.]

I will give one big negative about having additional domain
controllers. If you have only one domain controller, you can easily restore
it from any good image backup with no problem if necessary. Once you
introduce a second domain controller, you have to be much more careful about
reimaging any of the domain controllers. Reimaging one of multiple domain
controllers introduces problems with USN's, replication, and consistency
unless the Active Directory is then restored from a System State backup.

I don't see any great value in a second DC in a network that is
otherwise just a single SBS with no other servers and no offsite locations.
People can usually log on anyway with cached credentials, and too many of
your resources will be on the SBS that is unavailable. What good is being
able to log on if you can't do anything? A second DNS can be very useful,
especially to maintain Internet availability, but you don't have to make the
second machine a DC to make it a DNS.

By the way, you can't have easy failover for DHCP. That's one of the
biggest hurdles in any failover scenario-- one DHCP server maximum. And any
time I've tried to implement any sort of great failover scheme, it always
seems as though some obstacle prevents something important from happening.
Your best bet is to be available when a problem occurs and do what is
necessary to fix it fast if possible.

I have implemented multiple DC's, but always in multi-site
situations. It sounds good when I can tell a business owner that if one
location is destroyed, we have everything replicated at a second site for
easy recovery and possible instant activation.

"Simon Thomson" <si...@specterra.com.au> wrote in message
news:%23HsD$0lcKH...@TK2MSFTNGP04.phx.gbl...

[Andrew M. Saucci, Jr.]

Oh, yes-- one big benefit of a second domain controller is that it's
already built when you want to do a Swing Migration. :)

"Simon Thomson" <si...@specterra.com.au> wrote in message
news:%23HsD$0lcKH...@TK2MSFTNGP04.phx.gbl...

[kj [SBS MVP]]

This is a very good point about multiple DC's and recovery. It should be
noted that with 2008 RODCs can be used for second source authentications
without the issues os USN rolll back. The flip side of that is an RODC can
not be used to recover the domain as no outbound replication occures. RODCs
work well for small remote sites where physical security may be of a concern
as well.

Multiple DHCP servers limitations can be circumvented as well when really
necessary such as for small branch offices.

--
/kj

[david]

Note that if you decide to use the new server ONLY as a file server,
not a domain controller, that gives you a righteous excuse to turn off
packet signing (set it always off on the new server, off unless required
for the workstations, always on for the domain controller. A group
policy change is required).

Packet signing is a security setting which is standard for a domain
controller, because it blocks man-in-the-middle attacks on your
sign-in, particularly on your group policy settings. But it has a noxious
effect on intensive use of your file server, because it enforces packet
serialisation. It really hits things like MYOB and Quicken.

(david)

"Simon Thomson" <si...@specterra.com.au> wrote in message
news:%23HsD$0lcKH...@TK2MSFTNGP04.phx.gbl...