| Author | Messages | |
listmail
Posts:824
 | | 04/02/2006 3:20 AM |
| 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"
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 (joe@xxxxxxxxxxx) April 2006\n\n";
$infile=shift;
$outfile=shift;
if (!$infile || !$outfile)
{
print "\nUsage: removecnf.pl inputfile
outputfile\n\n";
exit(1);
}
open IFH, "$outfile" or
die("ERROR: Couldn't open output file ($outfile) - $!\n");
$skipping=0;
foreach $thisline
()
{
if ($thisline=~/^dn: /)
{$skipping=0};
if ($thisline=~/^dn: .+\\0ACNF:.+/)
{$skipping=1};
next if
$skipping;
print OFH $thisline;
}
print
"Completed.\n";
=================
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm | | | |
| lists1
Posts:6
| | 04/02/2006 10:09 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
joeSent: Sunday, April 02, 2006 5:18 AMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: [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 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"
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 (joe@xxxxxxxxxxx) April 2006\n\n";
$infile=shift;
$outfile=shift;
if (!$infile || !$outfile)
{
print "\nUsage: removecnf.pl inputfile
outputfile\n\n";
exit(1);
}
open IFH, "$outfile" or
die("ERROR: Couldn't open output file ($outfile) - $!\n");
$skipping=0;
foreach $thisline
()
{
if ($thisline=~/^dn: /)
{$skipping=0};
if ($thisline=~/^dn: .+\\0ACNF:.+/)
{$skipping=1};
next if
$skipping;
print OFH $thisline;
}
print
"Completed.\n";
=================
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm | | | |
| listmail
Posts:824
| | 04/02/2006 11:04 AM |
| Glad you like it Ulf. I keep everything I write so I can go
back and read how silly I was. :o)
I don't know about a fourth edition, but it will definitely
reappear somewhere at some point.
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
Simon-WeidnerSent: Sunday, April 02, 2006 6:08 AMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
joeSent: Sunday, April 02, 2006 5:18 AMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: [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 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"
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 (joe@xxxxxxxxxxx) April 2006\n\n";
$infile=shift;
$outfile=shift;
if (!$infile || !$outfile)
{
print "\nUsage: removecnf.pl inputfile
outputfile\n\n";
exit(1);
}
open IFH, "$outfile" or
die("ERROR: Couldn't open output file ($outfile) - $!\n");
$skipping=0;
foreach $thisline
()
{
if ($thisline=~/^dn: /)
{$skipping=0};
if ($thisline=~/^dn: .+\\0ACNF:.+/)
{$skipping=1};
next if
$skipping;
print OFH $thisline;
}
print
"Completed.\n";
=================
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm | | | |
| SteveRochford
Posts:10
| | 04/03/2006 8:21 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
Simon-WeidnerSent: 02 April 2006 11:08To:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
joeSent: Sunday, April 02, 2006 5:18 AMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: [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 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"
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 (joe@xxxxxxxxxxx) April 2006\n\n";
$infile=shift;
$outfile=shift;
if (!$infile || !$outfile)
{
print "\nUsage: removecnf.pl inputfile
outputfile\n\n";
exit(1);
}
open IFH, "$outfile" or
die("ERROR: Couldn't open output file ($outfile) - $!\n");
$skipping=0;
foreach $thisline
()
{
if ($thisline=~/^dn: /)
{$skipping=0};
if ($thisline=~/^dn: .+\\0ACNF:.+/)
{$skipping=1};
next if
$skipping;
print OFH $thisline;
}
print
"Completed.\n";
=================
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm | | | |
|
|