I'd suggest shipping the backup media if bandwidth was the original motivator, i.e. replication transport #3 - FedEx. It is possible to reduce the size of the backup by first restoring it and eliminating the unnecessary components before copying or shipping. Since you're replicating the entire forest content, that's going to be expensive in any forest that warranted this approach in the first place. Note that IFM also serves well when needing to build GCs or multiple DCs more quickly or at a lesser bandwidth expense.
Also note that sysvol requires some extra care in order to 1) ensure it is restored at all 2) with the necessary metadata and 3) prevent it from entering into a VV-join (I hate FRS 1). -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruston, Neil Sent: Wednesday, March 09, 2005 11:56 AM To: '[email protected]' Subject: RE: [ActiveDir] AD Database Corrupt IFM is a great feature, but if bandwidth is the concern, then you still have to copy the (huge) backup file over the WAN versus replicating the contents of AD over the WAN as part of dcpromo. Is the former preferable to the latter? I can see IFM as a viable solution in a LAN / MAN environment where the file may be copied around without issue, but when used in a WAN environment, I'm not convinced of its virtue. This is I agree, subjective, but food for thought, never the less. neil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond Sent: 09 March 2005 03:52 To: [email protected] Subject: RE: [ActiveDir] AD Database Corrupt > server and not affect any services. Is was also fortunate that we had > high connectivity between the DCs to allow a full copy of the directory On 2003 though, you don't have this issue anymore. IFM pretty much shoots that down. Ntbackup another DC in the domain, restore it to the file system on the new box, dcpromo /adv. Thanks. --Brian Desmond [EMAIL PROTECTED] Payton on the web! www.wpcp.org v - 773.534.0034 x135 f - 773.534.8101 c - 312.731.3132 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ActiveDir- > [EMAIL PROTECTED] On Behalf Of Ayers, Diane > Sent: Tuesday, March 08, 2005 9:40 PM > To: [email protected] > Subject: RE: [ActiveDir] AD Database Corrupt > > The one instance that we had a corrupt database, we used this method as > well. Fortunately we had enough redundancy to allow the demotion of the > server and not affect any services. Is was also fortunate that we had > high connectivity between the DCs to allow a full copy of the directory > to be replicated to the newly re-promoted server. > > The initial triage process that we started was similar to what ~Eric > suggested but it made sense to just demote and "start over" with a new > clean copy of the directory. > > Diane > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Tuesday, March 08, 2005 7:33 PM > To: [email protected] > Subject: RE: [ActiveDir] AD Database Corrupt > > I would have to tend to agree with this. I am also a fan of wipe the > machine, test for hardware issues, and start over. You may find the > issue if you troubleshoot but in every occasion where I have gone into > the troubleshooting process on a dead DIT I ended up rebuilding anyway, > usually have the DC sitting there dead a day or four with no answers. > > joe > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd > (NIH/CC/DNA) > Sent: Tuesday, March 08, 2005 11:28 AM > To: [email protected] > Subject: RE: [ActiveDir] AD Database Corrupt > > If possible, remove the DC from the domain, and do the NTDSUTIL > clean-up, and just rebuild it. Check your Anti-virus comfit to make > sure it isn't possibly configured to scan the AD databases. Also check > the hardware to make sure you don't have a controller card or HD issue. > > Unless there is a reason to try to save the box, I would just rebuild > them. > > Todd > > -----Original Message----- > From: Jacob Walker [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 08, 2005 7:43 AM > To: [email protected] > Subject: [ActiveDir] AD Database Corrupt > > One of our 60 AD DC's has stopped replicating. All of the others are > still replicating fine. On the problem DC, where are seeing the > following in the Directory Service log in event viewer: > > Event Source: NTDS ISAM > Event Category: Database Corruption > Event ID: 467 > Description: > NTDS (536) NTDSA: Index INDEX_00020078 of table datatable is corrupted > (0). > > > Event Source: NTDS Replication > Event Category: Replication > Event ID: 1084 > Description: > Internal event: Active Directory could not update the following object > with changes received from the following source domain controller. This > is because an error occurred during the application of the changes to > Active Directory on the domain controller. > > Object: > distinguished_name_path_of_object_that_failed_to_write_to_local_database > Object GUID: 32_character_alpha-numeric_object_GUID > Source domain > controller:object_GUID_for_source_domain_controller's_NTDSDSA_object._ms > dcs. > forest > root domain > > Synchronization of the local domain controller with the source domain > controller is blocked until this update problem is corrected. > > This operation will be tried again at the next scheduled replication. > > > We have looked at MS article 837932, but nothing seems to apply. And, > the corruption location seems to be in the domain database from what we > see in the details of the one error above and from the results of > repladmin /showreps. At this point, is there anything that can be done > for this DC other than restoring or demoting and re-promoting. > Unfortunately, we will be unable to do a restore because we backup the > System State on some of our DC's, but not this particular one. The one > saving grace is that it is a remote office DC and not one of our primary > DC's or FSMO role holders. > > Any suggestions? > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ ============================================================================ == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================ == List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
