Active Directory Replication
BJ
Win 2000 servers, but not much including an SBS. I have a small SBS 2000
network set up by guidelines in this newsgroup, MS white papers, and
sbs2000.info: exchange, ISA, TS via VPN, Trend OfficeScan, Backup exec 8.6
for SBS with OFO, 8 w2k, 3 win98, couple of VPN mail clients and 3 VPN app
clients. I have recently added a Win 2000 member server with the thought of
making it a second domain controller under SBS, replicating active directory
in case the SBS goes out, LAN clients could still log on, and also to
replicate the Company and User folders so they could keep working on data
and "server living" database files even though mail and internet would be
out for a time. My question is, is this feasible with SBS 2000? Is there
anything different about replicating active directory with SBS, anything I
should be aware of? And regarding file replication, is this feasible? Is
it too network resource intensive to be practical and/or are there pitfalls
I should be aware of about it?
I have to tell all the MVP's and everyone else, that this newsgroup made my
first SBS 2000 implementation relatively painless with virtually no network
downtime at all after building a new server to replace an old SBS 4.5
server, no data loss, exchange or otherwise and without you guys, it could
have been a whole lot worse, so thanks a million.
...and thanks in advance for any advice on active directory, etc.
BJ
Jeff Middleton [SBS-MVP]
you are more stable, less troublefree, easier to manage system......as well
as the time to relax and enjoy your SBS crash. I think this is just as
likely to raise a continuum of issues day in and day out, and not really
make your network survive when the SBS is down.
You have to keep in mind that when "the gurus of domains" speak in terms of
using secondary DC to preserve up-time in the network, typically they are
expecting that you have a dedicated DC, and that whatever additional DC you
have for failover support has ALL the services also running on it to
maintain transparent operations. This means at a minimum WINS/DNS, DC for
accounts, and in the case of mail enabled networks, you wouldn't expect
Exchange to be running on either DC.
The point I'm hinting at is that a secondary DC is fine if the primary DC
does nothing but primary DC roles, and all other server hosted applications
are scattered to entirely different servers.
It would be very difficult to anticipate what would happen to a network when
the SBS goes down, and depending upon how long it is down, how many failover
services would be sustained without a second server vs. having to have an
immediate role assumption.....plus the issues of all the files and services
that are defacto offline when the SBS is offline. Keep in mind, most of the
Intellimirror services specifically state not to use more than one sync
service on a given set of files, so this excludes many kinds of things like
roaming profiles, .PST files, database applications.....it's not that
simple.
"BJ" <wjeffri...@triad.rr.com> wrote in message
news:Ye268.61780$a07.10...@typhoon.southeast.rr.com...
BJ
the servers on this network are just about identical as far as hardware
goes. If I were to replicate AD (and DNS/WINS if needed) and my common data
files, and the SBS totally crashed, wouldn't I be able to, with SBS offline,
turn the W2K server into an SBS box, restore exchange from backup, etc.,
then wipe the old SBS box and bring it back up as a W2K server again, just
really switching the two boxes? I'm not looking for a 10 minute solution to
have the network back up and running. I realize this would be a major task.
If this is not feasible, what role would you recommend a second server play
on the network? Member server as file server for company data and just let
it keep a copy of the browse list? AD, WINS, DNS replication partner
knowing SBS would probably have to be added to it in the event of a
disaster? Since the server is there, I want to utilize it in the most
efficient way possible and am open to suggestions.
Thanks again
"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:#Ejxt1pqBHA.2324@tkmsftngp03...
Jeff Middleton [SBS-MVP]
Here....cut n paste from another thead to follow.
Summary statement: I don't believe there is a recovery course to plan for
that will ever be superior to a restore of backup from earlier version of
the SBS itself. All of my disaster recovery plans start with a 4hr maximum
view of recovery of operations by restoring a backup. Anything else looks
more like 2 days and isn't pretty. By that I mean you start looking at
losing 1000 man-hours/day in work. Think about it. 10 users, 8
hrs.....that's 80 manhours/day of work you could lose. Now, figure it both
ways....how much previously complete data would you forfeit while incurring
even more losses while you fiddle around with a "I've never actually needed
to recover a domain before using a different server" approach to recovery.
Really, any recovery scenario you can think of is nothing but a crisis
timeframe plan to an upgrade/migration. Trying doing your plan some day as
migration plan and see if you like the idea of doing it without a full
backup of the original server.....and when you look at that, you realize the
full backup of the original server is the only thing that will save you.
My earlier post:
!!!!!!!!!!!!!!!!!!!
Best answer: Tape Restore, or Image Restore the server plus tape
restore to current conditions.
Wrong answer: Backup domain controller. Doesn't make sense for an SBS,
really only complicates things in the long run. Not that there's no good
use for a BDC in SBS or SBS 2000, just that it's value is not in
disaster recovery or prevention, only in issues outside of that.
Disaster Recovery of SBS: Requires recovery of the SBS. Period. Forget
messing with other stuff, just rebuild or recover the SBS, and restore
the SBS from tape. It's the only thing that works in the scale of SBS
budget, priorities, and the typical skill set available for supporting
an SBS.
Don't get me wrong. You are in good shape on the disaster recovery of
SBS 2K. You have several reasonable solutions available to you. The
right answer for you will depend upon your priorities, technical skills,
willingness to invest in additional servers (licenses!) and how "slick"
and automatically you need this recovery to be done. Here's a list of
ideas to follow, but to answer your question immediately, yes, you can
add a backup DC and run/recover the domain in the traditional manner for
non-SBS domains. I'll explain a bit on the catches involved.
As is commonly known, you can rebuild from scratch on an SBS domain in
many cases because it's by definition a fairly small network. However, I
think of that like moving a fairly small piano...it's still a lot of
work for one person. Certainly rebuilding a large network of 100-200
computers is out of the question for 1 person, but does that make it out
of the question for a staff of 5? I think the answer is the same...it's
still a lot of work, and you can't get it done quickly or transparently,
so that's why large networks don't even consider scratch recovery. Small
networks should only consider it as long as it involves a modest amount
of labor. I think anyone who views a scratch recovery as a best option
in recovery of an SBS had better not anticipate spending more than 4
hours on it, because a decent Disaster Recovery plan should always
involve less than 4 hrs of labor...even if it is delayed 24hrs. to start
when you obtain a replacement hardware device. As a result, I see that
you really want to match up your skills, resources, priorities and
aversion to downtime with the proper preparations. As I said earlier in
the thread, making a more complicated LAN doesn't ensure faster
recovery, just more complications.
There are three general directions that you can use to recover a
failed SBS domain without losing the domain structure and SAM/SIDs:
1. Repair: Direct repair the SBS hardware/OS/installed config on the
current installation, current hardware.
2. Rollback: Restore a backup, drive image to the current system or
suitably similar hardware
3. Fault-tolerant Domain: Have another DC in place, use it at the
pivot point to a recovery.
Each of these has some subtle sub-divisions:
1a. Repair a fault or corruption: That's right, find the wrench in the
gears, pull it out, polish the gears and restart the machinery. This is
great if you have the time and talent to spot such issues.
1b. Replace failed hardware and hope it runs again on it: This is the
argument for why you either want really generic hardware, or the
knowledge of how to port an existing OS installation to new hardware.
Replacing virtually any hardware component in a server can be done with
an existing SBS OS installed and preserved, but you may find it a
challenge to migrate motherboards without any practice. NICS can be
changed, same with VGA cards, but both can present the appearance of
critical problems in the process. Generally, the issue here is whether
or not you can diagnose and complete a hardware repair fast enough to
make it transparent, or even preferable to having a fault tolerant
domain (another domain controller)...and if that 2nd DC is cost
effective for your business.
2. Rollback is always the most consistent recovery method because you
are returning in time to a known working installation. This is the best
option for Virus crisis repairs, corrupted Exchange, or file disaster,
even for new upgrades gone badly.
2a. Rollback with a tape backup is always the best idea, the
fundemental solution for any network. The question is whether or not you
understand how to accomplish this fully, either on a partially damaged
system, or a bare metal restore. Unfortunately, many administrators
never practice a bare metal recovery, or server to server migration as a
recovery technique. They wait until they have lost their server to find
out if they really can recover the damn thing.
2b. Drive Imaging is a great tool, particularly if you have the time
and opportunity to keep a current image handy, one that is less than 2-3
months old. A new installation is usually easy to image, but after than,
most imaging programs require taking the server down to do the image,
and this isn't transparent. However, a good solution is to use an image
to get the server running, then restore a current tape backup to get the
job finished up to the previous night. Keep in mind, the "Independent
Disaster Recovery" or the so called "one disk restore" methods almost
always have catches that might not work as expected. Frankly, I don't
like or use 1-disk restores....I don't trust unique answers I can't
easily test....and I'm not likely going to wipe out my server to find
out if it really recovers correctly....on a regular basis.
2c. Parallel rollback: This is my favorite answer. It's easy to test
routinely, and it's a more sane answer. If you have a server fail, you
can bring in another computer and rollback a restore on that
computer....without destroying the previous server or it's contents.
Consider this a "loaner" server if you must, and it might not even be
the same class of hardware. I've recovered many servers by grabbing a
"workstation" to either substitute parts, or ultimately to restore the
entire OS onto another box as the fastest way to get running
again....while still preserving the option to inspect the other system.
2d. Parallel Drive Restore: More often than not, just having another
suitable hard drive to load is enough. By this I mean, if you run a SCSI
RAID on your server, but you already know and have tested the method to
bare metal restore the entire system onto an EIDE drive of similar size,
you have a golden key to rapid recovery. I actually practice this on
every server upgrade I do: restore a backup of the old server to a new
drive and test it to make a safety drive. This means that I have the
ability to recover any server provided the only problem is a hard drive
failure but having a good backup to use. If you think of it, this
accounts for 95% of most server out-of-service situations.
3. Fault-tolerance in the domain requires another DC. You have to have
it in, running, synchronized.....and oh yeah, the entire network needs
to be willing to run for some time from this server as the only domain
controller. Is there a catch? You bet.
SBS is not designed for a second DC, even though it's perfectly happy
to see one and let it be used. Two basic reasons:
i: SBS design is based upon all primary resources being located on a
single server, both in the licensing as well as the "installation"
manner. Every client computer has all the shared resources, drive maps,
client server hooks, logon scripts....everything....pointing
specifically at the SBS server. If that server is down, unless you have
another server take it's place with the identical Netbios name, domain
name, SAM, SIDs, shares and IP designation, something isn't going to be
transparently retained in operations. Therefore, you can't simply "run"
like this, you are merely limping along...holding head above water until
the SBS itself is back online. The only way to have a pair of DCs in a
LAN (i.e. SBSserver and BDCserver, both as AD domain controllers) make a
transparent operation continue when the primary DC fails (the SBS), is
to actually have THREE servers. You would need to have the two DCs doing
nothing but DC roles, and all the shared resources present on the third
server hosting all the BO products, file shares, printer shares, etc.
That way, if the SBS fails, the DC roles could be migrated to the other
backup DC (BDCserver) and all the BackOffice stuff is transparently
continuing to operate on the same server, same location, same everything
other than the SBS. Obviously, that can't happen with SBS....it violates
the license and allowed installations. Besides, even if you did have
that option, you wouldn't install TWO domain controllers with no other
resources and place everything on the THIRD server, would you? Why spend
that much money for so little fault tolerance.....ON THE THIRD server?
No, if you are going to buy THREE servers, you would actually buy FOUR,
right? Think of it. Your cost increase is negligible, but the domain
fault tolerance is now remarkably improved. Guess what? You are now
running full BackOffice, not SBS!
ii: That second reason is that SBS licensing requires that if the SBS
is operating, it has all server roles. If the backup DC takes over those
server roles in a SBS out-of-service condition....that is only a
temporary answer. Either you will have to recover the original SBS, and
then figure out how to move all the AD server roles back to the SBS, or
you will have to recover the "SBS-role" by installing all the SBS
software on the backup BDCserver, effectively migrating the former
backup server to become the SBS server now, and you retire the original
SBS. If this is confusing, I can understand why, so let me explain this
a bit more.
Active Directory has something like 6 key AD Server Roles. In a
regular W2K/AD domain, these roles can be distributed to other servers,
almost even across 6 different servers. I'm refering to the FSMO role,
Global Catalog server, AD root, etc. These are things that the typical
SBS Administrator simply doesn't have any interest in reviewing or
playing with because in a typical SBS server, these roles all fall to
the SBS itself. If you add a new DC as backup DC, you might move a few
roles to this server just for grins, but you are soooooo tied to the SBS
due to licensing, you can't really build full fault tolerance with the
second DC, just a bit of "persistence" in the AD structure itself....but
that's not to be under-rated....just properly understood.
If your SBS server goes down, the "content" of the Active Directory
itself can be preserved on this Backup DC, but the SBS licensing
required you to install all of the BackOffice products on the SBS
server. Therefore, your DC is preserving the AD information, but it's
not keeping the SBS BackOffice operations running. Therefore, no ISA, no
Exchange, no Shared modem or fax, no console, no SQL, no License manager
(that's right! unique license manager). You can't run the domain from
the backup DC, you can only authenticate logons and ACL access to
shares. You could run the second DC as your file server and still have
basic file/folder operations running, but you still have some problems
to resolve without so much infrastructure. Now here's the real problem.
You either need to "migrate" your commitment of SBS to the backup DC, or
bring the old SBS back online. You can't simply rename the backup DC to
the SBS name and pretend it's the SBS now! Doesn't work. AD won't let
you do that. You can't just assume that pushing the AD server roles
around gets you closer to home any faster either. Here are some
analytical processes:
RENAME the BDCserver to SBSserver?
The only way to make AD allow you to recreate the old SBS server is to
build it back from scratch while you preserve the AD on another server
in the meantime. Okay, we got this so far, because the backup DC
preserves the domain. If I wanted to rename the backup DC from BDCserver
to SBSserver, I would actually need to install yet ANOTHER DC to
preserve the domain so that I could transfer all server roles to the
THIRD server, delete the previous existence of both the SBSserver and
BDCserver in the AD, then reintroduce the former-BDCserver now renamed
for Netbios purposes as the SBSserver....and then transfer all the AD
server roles back to this server! If you do the math, you had to
transfer server roles once from the original SBSserver to the BDCserver,
then from BDCserver to 3RDserver, then redefine the BDCserver as
SBSserver, then move the roles back from 3RDserver to (new)SBSserver.
That's WAAAAY too much work....it just wouldn't happen. You would
rebuild the SBS first, and forget about transfering between two other
servers so many times. So let's look at that.
REBUILD the SBSserver from scratch?
Okay, the SBSserver died, but the BDCserver is holding the AD for you.
You could recreate the SBS server from scratch as a member server
without yet installing any SBS specific applications. At this point, the
SBSserver is that in name only, it's really just a W2K server with that
name, but then using the very same Netbios name for this server as the
previous SBS server, you make it a DC in the existing AD being preserved
by the BDCserver. Now you transfer the AD server roles from the
BDCserver to this SBSserver. Now you have the original SBSserver name,
it's the root of an existing AD domain, you have all the user accounts
preserved. Now, you run the SBS setup to reinstall everything from CD
again to rebuild the SBS. Okay, so this takes you how long to finish????
Recover the SBSserver from any form of backup and use the BDCserver to
preserve operations meanwhile?
Remember, the SBSserver died. Your AD was preserved on the BDCserver,
and you have logon authentication as a result from the BDCserver, but
none of the BackOffice Suite, none of the SBS based shares, resources.
All you have is the AD structure.
If you modified all of the logon scripts to point at %logonserver%
rather than literally MYSBSservername, and redirected the Users Shared
Folders locations to the BDCserver, plus making all of the other SBS
specific configuration steps non-unique in reversals to make it look at
the BDCserver, or alternately at either server.....man have you created
a complicated domain to manage for very little fault tolerance! Think of
it, unless you all of the tools of an Enterprise, including DFS
definition of all shares, fault-tolerant naming of all scripts, shares,
and resources, you actually have increased the possible problems, not
lessened them. You now must manage synchronization of EVERYTHING on both
servers, because otherwise a failure of either server means you lose
some significant aspect of operations.....on Synchronized domain
controllers that are also BackOffice Application server and resource
servers with files, folders, and the like. Recovery of a backup DC is
enough trouble, but if you can't actually run the network properly
without either of these machines, and if recovery means resynchronizing
the DCs after you have recovered whatever data was lost in the original
failure.....this gives you confidence that you have decreased your risk
of downtime, and decreased the technical complexity, and decreased the
time to recover your domain!??
No, I don't think so. I think the BDCserver was a false promise for
you to trust in. The BDCserver is handy for allowing you to reboot an
SBS mid-day, to locate in a remote office, or to use in a special
application...but I don't think that a BDC is a disaster recovery tool
in SBS.
Recover the SBSserver as fast as possible...forget a BDC server role.
This is the ONLY answer that makes sense.
Having a second DC is fine if you like, it may even have some benefit
if you want to upgrade the SBS during the day to add service packs for
Exchange or whatever, and you just tell the entire office "from noon to
2pm today, do not logoff, Exchange will be down, and the Internet
connection is going to also be down, but your files located on the
fileserver (also a BDC) will be available." Meanwhile, you disconnect
the SBS from the LAN and do the work on it, then put it back online.
You may still find that you have to run DNS and WINS on both servers,
and there could be some glitches in resolving the two after the SBS
returns to service, but this is not a big deal in the long run.
If you have a dead SBS, the only thing that really gets you whole
again is getting the very same SBS back online from a tape backup, or an
image restore. Anything else you do while the SBS is down is just a
delay in the time you spend on getting the SBS back online....you are
just wasting time moving server roles, shares, files/folders. The key is
quite simple: You need the ability to get your SBS recovered on the same
machine, or one nearly like it, and you need the resources and skills to
get it done as fast as possible.
If you look at all the technical issues involved in on the one hand
...preserving and recovering a domain with an alternate AD domain
controller, then compare it to what skills and resources are needed to
recover an SBS server from a backup or image....there's no comparison!
It's more predictable to recover an SBS with an extra hard drive, or
alternate computer and then restore from tape ....than expecting that
you can step through the processes to recover a domain by migrating
server roles, and rolling AD around between servers.
I would recommend that secondary AD Domain Controllers have nothing to
do with Disaster Recovery in SBS, they are only convenient for periodic
maintenance on the SBS during business hours.
SBS Disaster Recovery comes from brute-force recovery of the SBS
server. You time, investment and skills need to be focused only here.
You can recover on the same hardware by restoring an image of the
server followed by a current tape restore, or doing a bare metal restore
from tape using whatever tricks you can, such as 1-disk recovery.
With Windows 2000, you can even restore from tape to a different
server hardware as a form of migration. What is required for this is
built into the Windows 2000 Backup program, as well as most 3rd party
tape restore programs. You need only have a basic W2K installation on a
server, then restore from tape with an Authoritative Restore of AD from
the old server. The restore program will automatically ignore server
specific hardware settings and restore everything else. This means that
a valid tape backup in hand is the key to recovery in almost any
situation....and it's likely to be faster than any other option you can
pursue.
"BJ" <wjeffri...@triad.rr.com> wrote in message
news:avx78.51579$A51.21...@typhoon.southeast.rr.com...
BJ
Thanks so much for this very comprehensive post. I've read through it
several times as well as everything else in the group that you've posted
regarding active directory. I particularly liked the one about
Organizational Units in AD. You've convinced me that a second DC as a means
of network fault tolerance is not what SBS is designed to do. Let me see if
I understand a coupld of things.
1. Just for informational purposes, in the event of a complete SBS meltdown,
with AD replicated on a second DC (the two servers on the network in
question are identical in hardware except the SBS has the tape drive and a
CD burner and I am doing full backups every night), I could, theoretically
anyway, install SBS on the second DC, and though probably not without
problems, restore backup and get going again, then bring up the old SBS
formatted and loaded as a win 2k server, really switching the roles of the
two boxes.
2. Forgetting recovery and fault tolerance, making the win 2k server a DC
and having the directory on it would not be a bad thing as it would allow me
to do things such as reboot the SBS if a service pack or something needed to
be applied in the middle of a business day, or would I be better off to
leave it as a member server, in other words, are there issues such as
network traffic, etc., that could cause problems with the directory
replicating (network is 100Base-T and the two servers are on a small switch
by themselves which is linked to the main switch for the workstations)?
3. ....and finally, the issue of user data replication to the second server.
The data I'm talking about is Word docs, Excel spreadsheets, a couple of
small Access databases and most importantly, 4 Peachtree Accounting company
databases). Is replication of this data something that should even be
considered; data is also being backed up with full backup every night along
with Exchange Information Store and mailboxes via BUE 8.6 for SBS 2000 with
Open File Option, or would it be better to just rely on the tapes to restore
in the event of data loss?
I really appreciate your time and input on this one, and just want to make
sure I understand.
Thanks,
Bill
"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:eTRmP6frBHA.2088@tkmsftngp03...