Mike, I agree with what you are saying, that from a best practices standpoint, one SHOULD eventually remove the old CNAMEs.
However, the point of this discussion seems to be centered around what will or will not cause problems with replication. Old CNAMEs pointing to deprecated DC GUIDs is not going to have the same profound effect on replication as old metadata will. My suggestion: Get rid of the old metadata and get replication functioning once again. THEN you are free to worry about DNS records of absolutely no consequence at all. Rick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tetrault, Mike (OFT) Sent: Friday, July 01, 2005 12:47 PM To: [email protected] Subject: RE: [ActiveDir] Corrupted NTDS.dit That is correct. This is the practice I have always followed and it has never done me wrong, which is why I was trying to offer this advice to the person who originally posted the message. Mike Tetrault OFT 40 North Pearl St. Albany, NY (518) 402-9300 -------------------------------------------------------- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hunter, Laura E. Sent: Friday, July 01, 2005 1:32 PM To: [email protected]; [EMAIL PROTECTED] Subject: RE: [ActiveDir] Corrupted NTDS.dit Unless my Google-fu is failing me (and I don't think it is), it looks like Mike is quoting KB 216498, step 15. http://support.microsoft.com/?kbid=216498 - Laura > -----Original Message----- > From: Dean Wells [mailto:[EMAIL PROTECTED] > Sent: Friday, July 01, 2005 1:09 PM > To: Send - AD mailing list > Subject: RE: [ActiveDir] Corrupted NTDS.dit > > When you say 'from Microsoft', may I ask where? > > IMHO, much of the statement is inaccurate at worst and misleading or > confusing at best. > > -- > Dean Wells > MSEtechnology > * Email: [EMAIL PROTECTED] > http://msetechnology.com > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tetrault, > Mike > (OFT) > Sent: Friday, July 01, 2005 1:00 PM > To: [email protected] > Subject: RE: [ActiveDir] Corrupted NTDS.dit > > This is from Microsoft: > > > Remove the cname record in the _msdcs.root domain of forest zone in > DNS. > Assuming that DC is going to be reinstalled and re-promoted, a new > NTDS Settings object is created with a new GUID and a matching cname > record in DNS. You do not want the DC's that exist to use the old > cname record. > > > This is what I was trying to convey to you. Sorry if there was any > confusion. > > Mike- > > Mike Tetrault > OFT > 40 North Pearl St. Albany, NY > (518) 402-9300 > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells > Sent: Friday, July 01, 2005 11:41 AM > To: Send - AD mailing list > Subject: RE: [ActiveDir] Corrupted NTDS.dit > > I don't follow you, ALL remaining DCs will still have the retired DC's > metadata until such time as it is 'cleaned up'. Joe is not suggesting > anything to the contrary, he is stating that the since the DC GUID > will be reseeded during the promotion that CNAME resolution alone will > not cause replication to fail. The replication relationship between > two DCs is expressed by a connection object, the connection object's > fromServer property refers to the DN of a DC's NTDS Settings object > (its metadata), the objectGUID property of the DC's NTDS Settings > object is used to seed each DC's DC GUID which is, in turn, registered > in DNS by each DC's respective NETLOGON service (along with a number > of SRV records and A records). > > Joe's point is simply this; once the source DC used during the > promotion of the newly reborn DC has pushed the new metadata out, a > replication topology will be built by the existing DCs inclusive of > the new DC. > Connection objects will then be created pointing to the new DCs NTDS > Settings object which will in turn provide the existing DCs with a > means of resolving it (replication latency and/or DNS cache TTLs > accepted). > > -- > > Dean Wells > MSEtechnology > * Email: [EMAIL PROTECTED] > http://msetechnology.com > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tetrault, > Mike > (OFT) > Sent: Friday, July 01, 2005 11:11 AM > To: [email protected] > Subject: RE: [ActiveDir] Corrupted NTDS.dit > > That is correct for a new Domain Controller. However, if a Domain > Controller is re-promoted before the old CNAME records are cleaned up, > there may be other Domain Controllers in the Domain that still have > the OLD CNAME record with the old GUID and if there are different > GUIDs for the same host name, replication problems can happen. > > This is why they recommend running a metadata cleanup and removing any > old records before promoting the DC again. It is also recommended that > you remove the old FRS entries using ADSI Edit. > > > Mike Tetrault > OFT > 40 North Pearl St. Albany, NY > (518) 402-9300 > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Friday, July 01, 2005 10:16 AM > To: [email protected] > Subject: RE: [ActiveDir] Corrupted NTDS.dit > > That really still shouldn't be an issue unless I am missing something > here. > Please bear with me. > > The mapping in DNS isn't hostname to GUID, it is GUID to hostname. > When a DC wants to replicate with this new DC, it will use the new > GUID and that shouldn't exist in DNS until the repromoed DC registers > it. > > Prior to registration the GUID would be unresolvable and no > replication would be allowed[1]. I used to use that for stopping DC's > from pulling replication from a specific DC - usually when the > troublesome DC was on the end of a misbehaving WAN connection and I > was experiencing rough RPC and excessive timeouts. > > Once registered, the GUID would be found and translated to a hostname > which can in turn be resolved to an IP. This would in turn allow for > the replication to work again. > > joe > > > > > [1] At least pre-K3 SP1, I haven't checked it since but I know there > are supposed to be changes. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tetrault, > Mike > (OFT) > Sent: Friday, July 01, 2005 9:58 AM > To: [email protected] > Subject: RE: [ActiveDir] Corrupted NTDS.dit > > It will be a problem if the other Domain Controllers have different > CNAME records in root/_msdcs for the new Domain Controller. > > > Mike Tetrault > OFT > 40 North Pearl St. Albany, NY > (518) 402-9300 > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Friday, July 01, 2005 9:44 AM > To: [email protected] > Subject: RE: [ActiveDir] Corrupted NTDS.dit > > > If the server is promoted again the GUID will be different and will > > cause File Replication problems among other things. > > It really shouldn't be an issue. > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tetrault, > Mike > (OFT) > Sent: Friday, July 01, 2005 9:02 AM > To: [email protected] > Subject: RE: [ActiveDir] Corrupted NTDS.dit > > As long as you still have a Domain Controller with a "good" > copy of the > Active Directory Database, I would just demote it and then run dcpromo > to promote it again. Make sure you check that the CNAME and SRV > records in DNS are removed after the demotion. If the server is > promoted again the GUID will be different and will cause File > Replication problems among other things. I would also recommend > running ntdsutil to perform a MetaData cleanup of the server object > you are demoting before you promote it again. > Microsoft has a procedure for doing this on the website if you are not > familiar with it. > > > > > Mike Tetrault > OFT > 40 North Pearl St. Albany, NY > (518) 402-9300 > > > -------------------------------------------------------- > This e-mail, including any attachments, may be confidential, > privileged or otherwise legally protected. It is intended only for the > addressee. > If you received this e-mail in error or from someone who was not > authorized to send it to you, do not disseminate, copy or otherwise > use this e-mail or its attachments. Please notify the sender > immediately by reply e-mail and delete the e-mail from your system. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Thursday, June 30, 2005 12:17 PM > To: [email protected] > Subject: [ActiveDir] Corrupted NTDS.dit > > Hi, > I have a corrupt NTDS.dit file with no backup, although the windows > 2003 DC starts up fine and partially replicates to my other 4 DC's. > Can someone tell me the best steps to restore this file. This > particular DC is also the FSMO holder. I was considering transferring > the role temporarily, demoting and then promoting this DC and having > DCPROMO rewrite the NTDS.dit. > Is this suicide? Thanks in advance > > Kevin Atnip > 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/ > 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/ 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/
