Sorry; I know I shouldn't criticise spelling but having
just struggled to try and understand the Perl that Joe wrote (and worked out
that I could probably do it in _vbscript_ which I do understand), I really don't
want to have to try and learn Forth as well :-)
Steve
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner
Sent: 02 April 2006 11:08
To: [email protected]
Subject: RE: [ActiveDir] CNF entries and LDIFDE.
Excellent writing buddy - hope you are keeping snippets
like this for the forth edition ;-)
Gruesse - Sincerely,
Ulf B. Simon-Weidner
MVP-Book "Windows XP - Die Expertentipps":
http://tinyurl.com/44zcz
Weblog:
http://msmvps.org/UlfBSimonWeidner
Website: http://www.windowsserverfaq.org
Profile: http://mvp.support.microsoft.com/profile="">
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Sunday, April 02, 2006 5:18 AM
To: [email protected]
Subject: [ActiveDir] CNF entries and LDIFDE.Howdy.At DEC I was approached concerning a problem where an admin was having with LDIFDE and importing CNF (conflict) objects, basically LDIFDE hits an error and stops when it processes one of these DNs. That is not generally the result you are looking for. It certainly puts a crimp in your productivity for the day if it keeps happening and you can't stop it.First some background, these objects appear when an object is created with the same DN on multiple DSAs (Directory Service Agents aka DCs or ADAM instances) within the same replication convergence interval. They replicate and eventually collide and following standard collision rules, the loser gets marked with a newline (\0A), the string literal 'CNF:' and the objectGUID value in friendly format. Looking something likeCN=collision\0ACNF:efc83ba9-412f-452e-ad49-72f91d31c201,CN=Users,DC=duck,DC=comThe winner of the collision is usually determined by the timestamp of the RDN on the various servers because the version of the RDN of both objects is almost always 1 making the version slightly less than helpful for the comparison. Note I was careful not to say the second one created will win, it is the one with the later timestamp, if servers are out of sync in time with each other, it could confuse the situation. However, assuming you have a good time structure, the object created first should be renamed and the object created second will have the "clean" name.So the problem with LDIFDE is related to that darn NEWLINE character. That isn't something you can generally import in for a name and Microsoft specifically used that character to get your attention. When LDIFDE tries to import an object like that the DSA says "No way Jose!". Well it is a little more professional and says NAMING_VIOLATION with an error of 200B which isG:\granamigodelpato>err 200b
# for hex 0x200b / decimal 8203 :
ERROR_DS_INVALID_ATTRIBUTE_SYNTAX winerror.h
# The attribute syntax specified to the directory service is
# invalid.
# 1 matches found for "200b"You do occasionally (or more or less often - YMMV) get these objects in your directory. As a general rule, clean them up when you find them. How you do that is very specific to the objects, you will have to use some judgement and try to figure out which is the right object to keep, the non-CNF stamped object or the CNF stamped object. About the only incorrect answer here is to say that you always keep one or the other simply based on whether it has the CNF or not. As the name indicates they are indicative of a collision and they are a mechanism to protect you from something that could possibly have really hurt. Don't like collision objects you say?? Consider the alternatives which are that something disappears or you get some sort of odd amalgamation of two different objects. Both of those alternatives suck because they are much worse than just having a CNF object. With a CNF object at least you have something you can detect and have a fighting chance to correct.So the admin is having troubles importing the objects because he keeps hitting CNF objects. It would be nice if LDIFDE handled this situation gracefully. And guess what... it can. :o) The latest version of LDIFDE which is in the ADAM SP1 or R2 release has a version of LDIFDE dated 2005/11/23 with a file version of 1.1.3790.2075 which has a '-z' option which tells ldifde to continue importing regardless of errors.Very cool, yet another reason for you to download ADAM SP1 or dig it off your R2 CDs. However.... Do you really want to always do that? I mean come on, keep on going regardless of errors... That is equivilent to the _vbscript_ ON ERROR RESUME NEXT programming mechanism and we don't even have ERROR levels so we can really check to stop our process midstream and correct.So the "right" solution in my mind if you have CNF objects is to clean them up. If that isn't feasible at the time or you already have the LDIF dump you need to import, clean up the file prior to import. This can be done by hand with notepad or if you have a 600MB LDIF file like the admin in question did you will want to script it. Below is a simple script to do this cleanup. It takes the name of an input LDIF file and the name of an output LDIF file and strips out the CNF entries. In the spirit of letting folks learn by doing I purposely left out messages telling you how many CNFs it found as well as logging the CNFs to another file both of which I think are handy and can be added with basic modifications.=================print "\nRemoveCNF V01.00.00pl Joe Richards ([EMAIL PROTECTED]) April 2006\n\n";$infile=shift;$outfile=shift;if (!$infile || !$outfile){print "\nUsage: removecnf.pl inputfile outputfile\n\n";exit(1);}open IFH, "<$infile" or die("ERROR: Couldn't open input file ($infile) - $!\n");open OFH, ">$outfile" or die("ERROR: Couldn't open output file ($outfile) - $!\n");$skipping=0;foreach $thisline (<IFH>){if ($thisline=~/^dn: /) {$skipping=0};if ($thisline=~/^dn: .+\\0ACNF:.+/) {$skipping=1};next if $skipping;print OFH $thisline;}print "Completed.\n";=================joe
