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 like
CN=collision\0ACNF:efc83ba9-412f-452e-ad49-72f91d31c201,CN=Users,DC=duck,DC=com
The
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 is
G:\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"
# 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
