Benefits of a backup domain controller

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.

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





"Simon Thomson" <> wrote in message
news:%23HsD$...
> 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.
>

Wow, déjà vu : -)


"Jeff Middleton [SBS-MVP]" <> wrote in message
news:%...
> 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
>
>
>
>
>
> "Simon Thomson" <> wrote in message
> news:%23HsD$...
>> 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]" <> wrote in message
news:%...
> 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
>
>

Excellent explanation. :-)

Ace

Jeff Middleton [SBS-MVP] <> 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.

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/micro...thor: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/micro...thor: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/micro...thor: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/micro...thor: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


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


"Dave Nickason [SBS MVP]" <> wrote in message
news:...
> Wow, déjà vu : -)
>
>
> "Jeff Middleton [SBS-MVP]" <> wrote in message
> news:%...
>> 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
>>
>>
>>
>>
>>
>> "Simon Thomson" <> wrote in message
>> news:%23HsD$...
>>> 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.
>>>
>>
>>
>

"Lanwench [MVP - Exchange]"
< hoo.com> wrote in message
news:...
> Jeff Middleton [SBS-MVP] <> 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.
>
>

Cookie monster.

Sounds like a great idea. You bring the milk.

- Jeff


"Lanwench [MVP - Exchange]"
< hoo.com> wrote in message
news:...
> Jeff Middleton [SBS-MVP] <> 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.
>
>

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]" <> wrote in message
news:%...
> Sounds like a great idea. You bring the milk.
>
> - Jeff
>
>
> "Lanwench [MVP - Exchange]"
> < hoo.com> wrote in
> message news:...
>> Jeff Middleton [SBS-MVP] <> 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.
>>
>>
>
>

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" <> wrote in message
news:%23HsD$...
> 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.
>