| Author | Messages | |
klas9574
Posts:1
 | | 02/21/2006 2:56 AM |
| I try to keep up on new or updated MS KB articles and often check to see how
they correlate with my environment. I noticed that 875495, dealing with USN
rollbacks, was updated earlier this month. As I've experienced two AD
issues, both of which needed PSS involvement (one dealing with sysvol
inconsistency and the other which wound up being the RID master going on
temporary strike) I figured that I'd do a quick check as described in the
article. On the good side, the USN's are consistent between controllers.
On the disconcerting side, I got a little more information than I was
expecting. Besides my DC's, I also got USN listings for several GUIDs. I
assume these are leftovers from DC demotions and only remain in the form of
historical data. Do I need to worry about these (especially the DC1
(retired) listing) and is there a way I can resolve the GUIDs to names, find
where this info is hiding, and clear them out?
Thanks,
Scott Klassen
>repadmin /showutdvec dc1 dc=domain,dc=com
Caching GUIDs.
..
Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20 20:08:20
2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
00:02:34
6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
11:53:16
Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20 20:10:50
Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
06:36:16
e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
20:52:04
ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
14:29:20
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/ | | | |
| dwells
Posts:53
| | 02/21/2006 2:00 AM |
| The GUIDs returned in this scenario are not used by the directory in the
traditional manner and, as such, using a GUID-based binding string won't
locate the owning object. The invocation IDs (which are indeed GUIDs but
not objectGUIDs) are maintained on the DC's NTDSDSA instance (its NTDS
Settings object) by the "invocationId" property ... retired invocation IDs
are maintained by retiredReplDSASignatures.
ADfind can likely hit these ... but the GUIDS needs to be expressed as part
of the query filter, not the base. I'll leave joe (why does he insist on
using a little "j"?) to provide the ADfind syntax (it seems that no matter
how hard I try, joe will always have a better switch ... and if he doesn't
have one, I'm fairly certain he quickly adds it, quietly releases the new
binary with the same version number, posts the reply, ridicules my
uneducated attempt at using a "real tool" (joe's words, not mine) and
professes his innocence :0).
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Thommes, Michael M.
Sent: Tuesday, February 21, 2006 7:44 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to the rescue!
I recently had to do this and got it accomplished with the following syntax
(with a little help from joe :) ):
adfind -default -binenc -f
objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
("adfind /???" For lots of good info!)
Mike Thommes
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
Sent: Monday, February 20, 2006 8:56 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] repadmin info oddity
I try to keep up on new or updated MS KB articles and often check to see how
they correlate with my environment. I noticed that 875495, dealing with USN
rollbacks, was updated earlier this month. As I've experienced two AD
issues, both of which needed PSS involvement (one dealing with sysvol
inconsistency and the other which wound up being the RID master going on
temporary strike) I figured that I'd do a quick check as described in the
article. On the good side, the USN's are consistent between controllers.
On the disconcerting side, I got a little more information than I was
expecting. Besides my DC's, I also got USN listings for several GUIDs.
I
assume these are leftovers from DC demotions and only remain in the form of
historical data. Do I need to worry about these (especially the DC1
(retired) listing) and is there a way I can resolve the GUIDs to names, find
where this info is hiding, and clear them out?
Thanks,
Scott Klassen
>repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
..
Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
20:08:20
2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
00:02:34
6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
11:53:16
Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
20:10:50
Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
06:36:16
e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
20:52:04
ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
14:29:20
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/ | | | |
| klas9574
Posts:1
| | 02/21/2006 2:24 AM |
| Thanks Michael and Dean. Very good information. ADFind came up empty on
the GUIDs, so wherever Repadmin is getting this info from, it is well
buried. I'm not going to lose any sleep over it. The more I learn on this
list, the more things I don't want to mess with. :)
Scott Klassen
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Thommes, Michael M.
Sent: Tuesday, February 21, 2006 6:44 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to the rescue!
I recently had to do this and got it accomplished with the following
syntax (with a little help from joe :) ):
adfind -default -binenc -f
objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
("adfind /???" For lots of good info!)
Mike Thommes
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
Sent: Monday, February 20, 2006 8:56 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] repadmin info oddity
I try to keep up on new or updated MS KB articles and often check to see
how
they correlate with my environment. I noticed that 875495, dealing with
USN
rollbacks, was updated earlier this month. As I've experienced two AD
issues, both of which needed PSS involvement (one dealing with sysvol
inconsistency and the other which wound up being the RID master going on
temporary strike) I figured that I'd do a quick check as described in
the
article. On the good side, the USN's are consistent between
controllers.
On the disconcerting side, I got a little more information than I was
expecting. Besides my DC's, I also got USN listings for several GUIDs.
I
assume these are leftovers from DC demotions and only remain in the form
of
historical data. Do I need to worry about these (especially the DC1
(retired) listing) and is there a way I can resolve the GUIDs to names,
find
where this info is hiding, and clear them out?
Thanks,
Scott Klassen
>repadmin /showutdvec dc1 dc=domain,dc=com
Caching GUIDs.
..
Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
20:08:20
2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
00:02:34
6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
11:53:16
Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
20:10:50
Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
06:36:16
e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
20:52:04
ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
14:29:20
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/ | | | |
| dwells
Posts:53
| | 02/21/2006 3:18 AM |
| These are DSA invocation IDs (which are maintained for the directory's
lifetime) within the up-to-dateness vector table, the stale (irresolvable)
entries are normal (assuming they truly represent demoted or forcibly
removed DCs) and are typically of no concern. The "retired" notation refers
to DCs whose invocation ID has changed due to a restore operation or the
removal and
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
Sent: Monday, February 20, 2006 9:56 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] repadmin info oddity
I try to keep up on new or updated MS KB articles and often check to see how
they correlate with my environment. I noticed that 875495, dealing with USN
rollbacks, was updated earlier this month. As I've experienced two AD
issues, both of which needed PSS involvement (one dealing with sysvol
inconsistency and the other which wound up being the RID master going on
temporary strike) I figured that I'd do a quick check as described in the
article. On the good side, the USN's are consistent between controllers.
On the disconcerting side, I got a little more information than I was
expecting. Besides my DC's, I also got USN listings for several GUIDs. I
assume these are leftovers from DC demotions and only remain in the form of
historical data. Do I need to worry about these (especially the DC1
(retired) listing) and is there a way I can resolve the GUIDs to names, find
where this info is hiding, and clear them out?
Thanks,
Scott Klassen
>repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
..
Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20 20:08:20
2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
00:02:34
6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
11:53:16
Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20 20:10:50
Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
06:36:16
e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
20:52:04
ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
14:29:20
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/ | | | |
| davidadner
Posts:0
| | 02/21/2006 3:44 AM |
| Oh no, Dean's fallen and can't get up!
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> Sent: Monday, February 20, 2006 9:17 PM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
> These are DSA invocation IDs (which are maintained for the directory's
> lifetime) within the up-to-dateness vector table, the stale
> (irresolvable) entries are normal (assuming they truly
> represent demoted or forcibly removed DCs) and are typically
> of no concern. The "retired" notation refers to DCs whose
> invocation ID has changed due to a restore operation or the
> removal and
>
> --
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
> Sent: Monday, February 20, 2006 9:56 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: [ActiveDir] repadmin info oddity
>
> I try to keep up on new or updated MS KB articles and often
> check to see how they correlate with my environment. I
> noticed that 875495, dealing with USN rollbacks, was updated
> earlier this month. As I've experienced two AD issues, both
> of which needed PSS involvement (one dealing with sysvol
> inconsistency and the other which wound up being the RID
> master going on temporary strike) I figured that I'd do a
> quick check as described in the article. On the good side,
> the USN's are consistent between controllers.
> On the disconcerting side, I got a little more information
> than I was expecting. Besides my DC's, I also got USN
> listings for several GUIDs. I assume these are leftovers
> from DC demotions and only remain in the form of historical
> data. Do I need to worry about these (especially the DC1
> (retired) listing) and is there a way I can resolve the GUIDs
> to names, find where this info is hiding, and clear them out?
>
> Thanks,
>
> Scott Klassen
>
> >repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
> ..
> Default-First-Site-Name\DC2 @ USN 455091 @ Time
> 2006-02-20 20:08:20
> 2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time
> 2005-08-04
> 00:02:34
> 6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time
> 2004-07-24
> 11:53:16
> Default-First-Site-Name\DC1 @ USN 1717571 @ Time
> 2006-02-20 20:10:50
> Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time
> 2005-08-05
> 06:36:16
> e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time
> 2004-12-28
> 20:52:04
> ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time
> 2005-06-08
> 14:29:20
>
>
> 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/ | | | |
| dwells
Posts:53
| | 02/21/2006 3:55 AM |
| LOL, I've no idea what caused that, there I was typing away and ... off it
went to my Sent Items ... c'est la vie. I posted the "back on my feet" copy
within a minute or so or the original but as is often the case, I find some
posts come through quickly while others take the scenic route (wherever the
heck that is).
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David Adner
Sent: Monday, February 20, 2006 10:43 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Oh no, Dean's fallen and can't get up!
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> Sent: Monday, February 20, 2006 9:17 PM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
> These are DSA invocation IDs (which are maintained for the directory's
> lifetime) within the up-to-dateness vector table, the stale
> (irresolvable) entries are normal (assuming they truly represent
> demoted or forcibly removed DCs) and are typically of no concern. The
> "retired" notation refers to DCs whose invocation ID has changed due
> to a restore operation or the removal and
>
> --
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
> Sent: Monday, February 20, 2006 9:56 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: [ActiveDir] repadmin info oddity
>
> I try to keep up on new or updated MS KB articles and often
> check to see how they correlate with my environment. I
> noticed that 875495, dealing with USN rollbacks, was updated
> earlier this month. As I've experienced two AD issues, both
> of which needed PSS involvement (one dealing with sysvol
> inconsistency and the other which wound up being the RID
> master going on temporary strike) I figured that I'd do a
> quick check as described in the article. On the good side,
> the USN's are consistent between controllers.
> On the disconcerting side, I got a little more information
> than I was expecting. Besides my DC's, I also got USN
> listings for several GUIDs. I assume these are leftovers
> from DC demotions and only remain in the form of historical
> data. Do I need to worry about these (especially the DC1
> (retired) listing) and is there a way I can resolve the GUIDs
> to names, find where this info is hiding, and clear them out?
>
> Thanks,
>
> Scott Klassen
>
> >repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
> ..
> Default-First-Site-Name\DC2 @ USN 455091 @ Time
> 2006-02-20 20:08:20
> 2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time
> 2005-08-04
> 00:02:34
> 6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time
> 2004-07-24
> 11:53:16
> Default-First-Site-Name\DC1 @ USN 1717571 @ Time
> 2006-02-20 20:10:50
> Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time
> 2005-08-05
> 06:36:16
> e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time
> 2004-12-28
> 20:52:04
> ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time
> 2005-06-08
> 14:29:20
>
>
> 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/ | | | |
| davidadner
Posts:0
| | 02/21/2006 4:12 AM |
| Ah, the dreaded CTRL-Enter "feature".
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> Sent: Monday, February 20, 2006 9:54 PM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
>
> LOL, I've no idea what caused that, there I was typing away
> and ... off it went to my Sent Items ... c'est la vie. I
> posted the "back on my feet" copy within a minute or so or
> the original but as is often the case, I find some posts come
> through quickly while others take the scenic route (wherever
> the heck that is).
>
> --
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David Adner
> Sent: Monday, February 20, 2006 10:43 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Oh no, Dean's fallen and can't get up!
>
> > -----Original Message-----
> > From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> > Sent: Monday, February 20, 2006 9:17 PM
> > To: Send - AD mailing list
> > Subject: RE: [ActiveDir] repadmin info oddity
> >
> > These are DSA invocation IDs (which are maintained for the
> directory's
> > lifetime) within the up-to-dateness vector table, the stale
> > (irresolvable) entries are normal (assuming they truly represent
> > demoted or forcibly removed DCs) and are typically of no
> concern. The
> > "retired" notation refers to DCs whose invocation ID has
> changed due
> > to a restore operation or the removal and
> >
> > --
> > Dean Wells
> > MSEtechnology
> > * Email: dwells@xxxxxxxxxxxxxxxxx
> > http://msetechnology.com
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
> SCOTT KLASSEN
> > Sent: Monday, February 20, 2006 9:56 PM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > Subject: [ActiveDir] repadmin info oddity
> >
> > I try to keep up on new or updated MS KB articles and often
> check to
> > see how they correlate with my environment. I noticed that 875495,
> > dealing with USN rollbacks, was updated earlier this month.
> As I've
> > experienced two AD issues, both of which needed PSS
> involvement (one
> > dealing with sysvol inconsistency and the other which wound
> up being
> > the RID master going on temporary strike) I figured that I'd do a
> > quick check as described in the article. On the good side,
> the USN's
> > are consistent between controllers.
> > On the disconcerting side, I got a little more information
> than I was
> > expecting. Besides my DC's, I also got USN listings for several
> > GUIDs. I assume these are leftovers from DC demotions and
> only remain
> > in the form of historical data. Do I need to worry about these
> > (especially the DC1
> > (retired) listing) and is there a way I can resolve the GUIDs to
> > names, find where this info is hiding, and clear them out?
> >
> > Thanks,
> >
> > Scott Klassen
> >
> > >repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
> > ..
> > Default-First-Site-Name\DC2 @ USN 455091 @ Time
> > 2006-02-20 20:08:20
> > 2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time
> > 2005-08-04
> > 00:02:34
> > 6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time
> > 2004-07-24
> > 11:53:16
> > Default-First-Site-Name\DC1 @ USN 1717571 @ Time
> > 2006-02-20 20:10:50
> > Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time
> > 2005-08-05
> > 06:36:16
> > e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time
> > 2004-12-28
> > 20:52:04
> > ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time
> > 2005-06-08
> > 14:29:20
> >
> >
> > 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/ | | | |
| dwells
Posts:53
| | 02/21/2006 4:15 AM |
| These are DSA invocation IDs (which are maintained for the directory's
lifetime) within the up-to-dateness vector table, the stale (irresolvable)
entries are normal (assuming they truly represent demoted or forcibly
removed DCs) and are typically of no concern. The "retired" notation refers
to DCs whose invocation ID has changed due to a restore operation or the
removal and subsequent re-addition of a NDNC (again, a normal occurrence),
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
Sent: Monday, February 20, 2006 9:56 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] repadmin info oddity
I try to keep up on new or updated MS KB articles and often check to see how
they correlate with my environment. I noticed that 875495, dealing with USN
rollbacks, was updated earlier this month. As I've experienced two AD
issues, both of which needed PSS involvement (one dealing with sysvol
inconsistency and the other which wound up being the RID master going on
temporary strike) I figured that I'd do a quick check as described in the
article. On the good side, the USN's are consistent between controllers.
On the disconcerting side, I got a little more information than I was
expecting. Besides my DC's, I also got USN listings for several GUIDs. I
assume these are leftovers from DC demotions and only remain in the form of
historical data. Do I need to worry about these (especially the DC1
(retired) listing) and is there a way I can resolve the GUIDs to names, find
where this info is hiding, and clear them out?
Thanks,
Scott Klassen
>repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
..
Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20 20:08:20
2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
00:02:34
6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
11:53:16
Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20 20:10:50
Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
06:36:16
e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
20:52:04
ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
14:29:20
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/ | | | |
| klas9574
Posts:1
| | 02/21/2006 10:13 AM |
| Too bad Joe picked today to be MIA.
Scott Klassen
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: Tuesday, February 21, 2006 7:59 AM
To: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
The GUIDs returned in this scenario are not used by the directory in the
traditional manner and, as such, using a GUID-based binding string won't
locate the owning object. The invocation IDs (which are indeed GUIDs but
not objectGUIDs) are maintained on the DC's NTDSDSA instance (its NTDS
Settings object) by the "invocationId" property ... retired invocation IDs
are maintained by retiredReplDSASignatures.
ADfind can likely hit these ... but the GUIDS needs to be expressed as part
of the query filter, not the base. I'll leave joe (why does he insist on
using a little "j"?) to provide the ADfind syntax (it seems that no matter
how hard I try, joe will always have a better switch ... and if he doesn't
have one, I'm fairly certain he quickly adds it, quietly releases the new
binary with the same version number, posts the reply, ridicules my
uneducated attempt at using a "real tool" (joe's words, not mine) and
professes his innocence :0).
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Thommes, Michael M.
Sent: Tuesday, February 21, 2006 7:44 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to the rescue!
I recently had to do this and got it accomplished with the following syntax
(with a little help from joe :) ):
adfind -default -binenc -f
objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
("adfind /???" For lots of good info!)
Mike Thommes
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
Sent: Monday, February 20, 2006 8:56 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] repadmin info oddity
I try to keep up on new or updated MS KB articles and often check to see how
they correlate with my environment. I noticed that 875495, dealing with USN
rollbacks, was updated earlier this month. As I've experienced two AD
issues, both of which needed PSS involvement (one dealing with sysvol
inconsistency and the other which wound up being the RID master going on
temporary strike) I figured that I'd do a quick check as described in the
article. On the good side, the USN's are consistent between controllers.
On the disconcerting side, I got a little more information than I was
expecting. Besides my DC's, I also got USN listings for several GUIDs.
I
assume these are leftovers from DC demotions and only remain in the form of
historical data. Do I need to worry about these (especially the DC1
(retired) listing) and is there a way I can resolve the GUIDs to names, find
where this info is hiding, and clear them out?
Thanks,
Scott Klassen
>repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
..
Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
20:08:20
2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
00:02:34
6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
11:53:16
Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
20:10:50
Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
06:36:16
e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
20:52:04
ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
14:29:20
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/ | | | |
| MThommes
Posts:106
| | 02/21/2006 12:45 PM |
| Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to the rescue!
I recently had to do this and got it accomplished with the following
syntax (with a little help from joe :) ):
adfind -default -binenc -f
objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
("adfind /???" For lots of good info!)
Mike Thommes
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
Sent: Monday, February 20, 2006 8:56 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] repadmin info oddity
I try to keep up on new or updated MS KB articles and often check to see
how
they correlate with my environment. I noticed that 875495, dealing with
USN
rollbacks, was updated earlier this month. As I've experienced two AD
issues, both of which needed PSS involvement (one dealing with sysvol
inconsistency and the other which wound up being the RID master going on
temporary strike) I figured that I'd do a quick check as described in
the
article. On the good side, the USN's are consistent between
controllers.
On the disconcerting side, I got a little more information than I was
expecting. Besides my DC's, I also got USN listings for several GUIDs.
I
assume these are leftovers from DC demotions and only remain in the form
of
historical data. Do I need to worry about these (especially the DC1
(retired) listing) and is there a way I can resolve the GUIDs to names,
find
where this info is hiding, and clear them out?
Thanks,
Scott Klassen
>repadmin /showutdvec dc1 dc=domain,dc=com
Caching GUIDs.
..
Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
20:08:20
2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
00:02:34
6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
11:53:16
Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
20:10:50
Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
06:36:16
e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
20:52:04
ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
14:29:20
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/ | | | |
| dwells
Posts:53
| | 02/22/2006 2:19 AM |
| As I'd hoped, joe does indeed have another way ... one that does the
encoding for you. There's a prefix that can be supplied within the filter
that extends to any attribute of your choosing (this instructs ADfind to
manipulate the byte ordering and related structure); {{GUID=}}. The query below exploits that feature permitting repadmin's GUID
format to be supplied directly.
C:\>adfind -config -binenc -f
(retiredReplDSASignatures=*{{GUID:6cc4a8e0-2019-4e4f-81cd-f35926de38a3}}*)"
-dn
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: Tuesday, February 21, 2006 7:09 PM
To: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
Hmmm, I would guess he's probably adding a new switch to deal with this
particular thread.
Anyway, since he's not responded, I'll take a stab at what ADfind can or
cannot do here (not really ADfind's problem if my lazy research is
accurate). The attribute in question's syntax is a single-valued "octet
string" which can typically be filtered against assuming the correct
notation is supplied. This particular attribute, however, will often
contain multiple GUIDs within the flat value (a pack of them) making it
difficult to successfully construct a reliable and/or optimal filter
(remember, medial queries are painful without the necessary index).
To further complicate the issue, the byte ordering is maintained differently
internally to the way it's displayed. Since ADfind AFAIK cannot yet decode
"retiredReplDSASignatures", in order to query against it we have to reorder
it ourselves. Here's an example of how to convert repadmin's display format
to the internally maintained byte ordering (this is a little painful) -
repadmin's output = 6cc4a8e0-2019-4e4f-81cd-f35926de38a3
internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38 A3
... now trim the hyphens and pad repadmin's output to pair up the bytes -
repadmin's output = 6c c4 a8 e0 20 19 4e 4f-81 cd f3 59 26 de 38 a3 (padded
& trimmed) internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38
A3
... now, re-order the 1st 4 octets, then the next 2 octets and again the
next 2 octets. I've added extra spaces for legibility (essentially, you're
re-ordering the first double-word, the next word, the next word and the rest
remains as is ... this is known as "network" or "pretty" byte ordering) -
repadmin's output = e0 a8 c4 6c 19 20 4f 4e 81 cd f3 59 26 de 38
a3 (re-ordered)
internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38
A3
OK, having done all of that, you now have two possible options:
option 1) use a fairly concise query and parse the output as follows ...
... create a string of 8 words (or 8 octet pairs if you prefer) to match
ADfind's output format -
resulting structure = E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3
... then use the following syntax -
C:\>adfind -config -f
"&(objectcategory=ntdsdsa)(retiredReplDSASignatures=*)" -csv -nocsvheader
retiredReplDSASignatures | findstr "E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3"
... this returns the DN of the "NTDS Settings" object of the DC that owns
the retired invocation ID. If no results are returned, one of two things
occurred; 1) you fat-fingered it or 2) the DC no longer exists.
option 2) submit the following v. expensive query (note, it's a medial
query) -
C:\>adfind -config -f
"retiredReplDSASignatures=*\E0\A8\C4\6C\19\20\4F\4E\81\CD\F3\59\26\DE\38\A3*
" retiredReplDSASignatures
Fingers crossed that Joe will have a hidden switch to do the decoding for
you, until then, this is it I'm afraid.
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klassen
Sent: Tuesday, February 21, 2006 5:11 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Too bad Joe picked today to be MIA.
Scott Klassen
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: Tuesday, February 21, 2006 7:59 AM
To: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
The GUIDs returned in this scenario are not used by the directory in the
traditional manner and, as such, using a GUID-based binding string won't
locate the owning object. The invocation IDs (which are indeed GUIDs but
not objectGUIDs) are maintained on the DC's NTDSDSA instance (its NTDS
Settings object) by the "invocationId" property ... retired invocation IDs
are maintained by retiredReplDSASignatures.
ADfind can likely hit these ... but the GUIDS needs to be expressed as part
of the query filter, not the base. I'll leave joe (why does he insist on
using a little "j"?) to provide the ADfind syntax (it seems that no matter
how hard I try, joe will always have a better switch ... and if he doesn't
have one, I'm fairly certain he quickly adds it, quietly releases the new
binary with the same version number, posts the reply, ridicules my
uneducated attempt at using a "real tool" (joe's words, not mine) and
professes his innocence :0).
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Thommes, Michael M.
Sent: Tuesday, February 21, 2006 7:44 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to the rescue!
I recently had to do this and got it accomplished with the following syntax
(with a little help from joe :) ):
adfind -default -binenc -f
objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
("adfind /???" For lots of good info!)
Mike Thommes
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
Sent: Monday, February 20, 2006 8:56 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] repadmin info oddity
I try to keep up on new or updated MS KB articles and often check to see how
they correlate with my environment. I noticed that 875495, dealing with USN
rollbacks, was updated earlier this month. As I've experienced two AD
issues, both of which needed PSS involvement (one dealing with sysvol
inconsistency and the other which wound up being the RID master going on
temporary strike) I figured that I'd do a quick check as described in the
article. On the good side, the USN's are consistent between controllers.
On the disconcerting side, I got a little more information than I was
expecting. Besides my DC's, I also got USN listings for several GUIDs.
I
assume these are leftovers from DC demotions and only remain in the form of
historical data. Do I need to worry about these (especially the DC1
(retired) listing) and is there a way I can resolve the GUIDs to names, find
where this info is hiding, and clear them out?
Thanks,
Scott Klassen
>repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
..
Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
20:08:20
2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
00:02:34
6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
11:53:16
Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
20:10:50
Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
06:36:16
e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
20:52:04
ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
14:29:20
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/ | | | |
| klas9574
Posts:1
| | 02/22/2006 2:51 AM |
| I personally like the idea of being able to resolve further on down the
road. Can potentially save a step in troubleshooting.
Scott Klassen
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brett Shirley
Sent: Wednesday, February 22, 2006 1:35 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Cc: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
I wouldn't make a "hard feature" on such parsing, b/c it is not documented
and could change at Brett or (lets call him) Greg's willy nilly.
Oh and I just rememberd ... I should also note, isn't a 100% accurate to
use retired DSA signatures, we punted a bug in repadmin relating around
this, IIRC ... IFM maintains the same retired DSAs list as the original
source DC, meaning it is tricky to figure who is the real slim shady when
deal with retired IIDs.
It may be probabalistically or even deterministically possible by looking
at when the IID was retired, and matching against active IIDs, and
matching retired IIDs, to figure out who originally owned the IID. That's
what joe should work on...
We've also debated when we delete a DSA or stamping all related IIDs, into
a never cleared place in the DS, so that repadmin /showutdvec could always
resolve DSAs even after they've been deleted for 10 years.
On Tue, 21 Feb 2006, Dean Wells wrote:
> Hmmm, I would guess he's probably adding a new switch to deal with this
> particular thread.
>
> Anyway, since he's not responded, I'll take a stab at what ADfind can or
> cannot do here (not really ADfind's problem if my lazy research is
> accurate). The attribute in question's syntax is a single-valued "octet
> string" which can typically be filtered against assuming the correct
> notation is supplied. This particular attribute, however, will often
> contain multiple GUIDs within the flat value (a pack of them) making it
> difficult to successfully construct a reliable and/or optimal filter
> (remember, medial queries are painful without the necessary index).
>
> To further complicate the issue, the byte ordering is maintained
differently
> internally to the way it's displayed. Since ADfind AFAIK cannot yet
decode
> "retiredReplDSASignatures", in order to query against it we have to
reorder
> it ourselves. Here's an example of how to convert repadmin's display
format
> to the internally maintained byte ordering (this is a little painful) -
>
> repadmin's output = 6cc4a8e0-2019-4e4f-81cd-f35926de38a3
> internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38 A3
>
> ... now trim the hyphens and pad repadmin's output to pair up the bytes -
>
> repadmin's output = 6c c4 a8 e0 20 19 4e 4f-81 cd f3 59 26 de 38 a3
(padded
> & trimmed)
> internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38 A3
>
> ... now, re-order the 1st 4 octets, then the next 2 octets and again the
> next 2 octets. I've added extra spaces for legibility (essentially,
you're
> re-ordering the first double-word, the next word, the next word and the
rest
> remains as is ... this is known as "network" or "pretty" byte ordering) -
>
> repadmin's output = e0 a8 c4 6c 19 20 4f 4e 81 cd f3 59 26 de 38
> a3 (re-ordered)
> internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38
> A3
>
> OK, having done all of that, you now have two possible options:
>
> option 1) use a fairly concise query and parse the output as follows ...
>
> ... create a string of 8 words (or 8 octet pairs if you prefer) to match
> ADfind's output format -
>
> resulting structure = E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3
>
> ... then use the following syntax -
>
> C:\>adfind -config -f
> "&(objectcategory=ntdsdsa)(retiredReplDSASignatures=*)" -csv -nocsvheader
> retiredReplDSASignatures | findstr "E0A8 C46C 1920 4F4E 81CD F359 26DE
38A3"
>
> ... this returns the DN of the "NTDS Settings" object of the DC that owns
> the retired invocation ID. If no results are returned, one of two things
> occurred; 1) you fat-fingered it or 2) the DC no longer exists.
>
> option 2) submit the following v. expensive query (note, it's a medial
> query) -
>
> C:\>adfind -config -f
>
"retiredReplDSASignatures=*\E0\A8\C4\6C\19\20\4F\4E\81\CD\F3\59\26\DE\38\A3*
> " retiredReplDSASignatures
>
> Fingers crossed that Joe will have a hidden switch to do the decoding for
> you, until then, this is it I'm afraid.
>
> --
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klassen
> Sent: Tuesday, February 21, 2006 5:11 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Too bad Joe picked today to be MIA.
>
> Scott Klassen
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> Sent: Tuesday, February 21, 2006 7:59 AM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
> The GUIDs returned in this scenario are not used by the directory in the
> traditional manner and, as such, using a GUID-based binding string won't
> locate the owning object. The invocation IDs (which are indeed GUIDs but
> not objectGUIDs) are maintained on the DC's NTDSDSA instance (its NTDS
> Settings object) by the "invocationId" property ... retired invocation IDs
> are maintained by retiredReplDSASignatures.
>
> ADfind can likely hit these ... but the GUIDS needs to be expressed as
part
> of the query filter, not the base. I'll leave joe (why does he insist on
> using a little "j"?) to provide the ADfind syntax (it seems that no matter
> how hard I try, joe will always have a better switch ... and if he doesn't
> have one, I'm fairly certain he quickly adds it, quietly releases the new
> binary with the same version number, posts the reply, ridicules my
> uneducated attempt at using a "real tool" (joe's words, not mine) and
> professes his innocence :0).
>
>
> --
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Thommes, Michael
M.
> Sent: Tuesday, February 21, 2006 7:44 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to the rescue!
> I recently had to do this and got it accomplished with the following
syntax
> (with a little help from joe :) ):
>
> adfind -default -binenc -f
> objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
>
> ("adfind /???" For lots of good info!)
>
> Mike Thommes
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
> Sent: Monday, February 20, 2006 8:56 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: [ActiveDir] repadmin info oddity
>
> I try to keep up on new or updated MS KB articles and often check to see
how
> they correlate with my environment. I noticed that 875495, dealing with
USN
> rollbacks, was updated earlier this month. As I've experienced two AD
> issues, both of which needed PSS involvement (one dealing with sysvol
> inconsistency and the other which wound up being the RID master going on
>
> temporary strike) I figured that I'd do a quick check as described in the
> article. On the good side, the USN's are consistent between controllers.
> On the disconcerting side, I got a little more information than I was
> expecting. Besides my DC's, I also got USN listings for several GUIDs.
> I
> assume these are leftovers from DC demotions and only remain in the form
of
> historical data. Do I need to worry about these (especially the DC1
> (retired) listing) and is there a way I can resolve the GUIDs to names,
find
> where this info is hiding, and clear them out?
>
> Thanks,
>
> Scott Klassen
>
> >repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
> ..
> Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
> 20:08:20
> 2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
> 00:02:34
> 6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
> 11:53:16
> Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
> 20:10:50
> Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
> 06:36:16
> e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
> 20:52:04
> ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
> 14:29:20
>
>
> 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/ | | | |
| klas9574
Posts:1
| | 02/22/2006 2:56 AM |
| Very handy and helpful. Thank you so much for the time you've put into this
Dean. If I ever get to meet you, it's worth a few at the bar. If you
didn't see a couple of days ago, MS announced that it was changing the names
for parts of AD. I think they need to rethink the choices they've made and
just call it The Dean and Joe Show. Has a bit of a ring to it. :)
Scott Klassen
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: Wednesday, February 22, 2006 8:17 AM
To: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
As I'd hoped, joe does indeed have another way ... one that does the
encoding for you. There's a prefix that can be supplied within the filter
that extends to any attribute of your choosing (this instructs ADfind to
manipulate the byte ordering and related structure); {{GUID=}}. The query below exploits that feature permitting repadmin's GUID
format to be supplied directly.
C:\>adfind -config -binenc -f
(retiredReplDSASignatures=*{{GUID:6cc4a8e0-2019-4e4f-81cd-f35926de38a3}}*)"
-dn
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: Tuesday, February 21, 2006 7:09 PM
To: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
Hmmm, I would guess he's probably adding a new switch to deal with this
particular thread.
Anyway, since he's not responded, I'll take a stab at what ADfind can or
cannot do here (not really ADfind's problem if my lazy research is
accurate). The attribute in question's syntax is a single-valued "octet
string" which can typically be filtered against assuming the correct
notation is supplied. This particular attribute, however, will often
contain multiple GUIDs within the flat value (a pack of them) making it
difficult to successfully construct a reliable and/or optimal filter
(remember, medial queries are painful without the necessary index).
To further complicate the issue, the byte ordering is maintained differently
internally to the way it's displayed. Since ADfind AFAIK cannot yet decode
"retiredReplDSASignatures", in order to query against it we have to reorder
it ourselves. Here's an example of how to convert repadmin's display format
to the internally maintained byte ordering (this is a little painful) -
repadmin's output = 6cc4a8e0-2019-4e4f-81cd-f35926de38a3
internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38 A3
... now trim the hyphens and pad repadmin's output to pair up the bytes -
repadmin's output = 6c c4 a8 e0 20 19 4e 4f-81 cd f3 59 26 de 38 a3 (padded
& trimmed) internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38
A3
... now, re-order the 1st 4 octets, then the next 2 octets and again the
next 2 octets. I've added extra spaces for legibility (essentially, you're
re-ordering the first double-word, the next word, the next word and the rest
remains as is ... this is known as "network" or "pretty" byte ordering) -
repadmin's output = e0 a8 c4 6c 19 20 4f 4e 81 cd f3 59 26 de 38
a3 (re-ordered)
internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38
A3
OK, having done all of that, you now have two possible options:
option 1) use a fairly concise query and parse the output as follows ...
... create a string of 8 words (or 8 octet pairs if you prefer) to match
ADfind's output format -
resulting structure = E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3
... then use the following syntax -
C:\>adfind -config -f
"&(objectcategory=ntdsdsa)(retiredReplDSASignatures=*)" -csv -nocsvheader
retiredReplDSASignatures | findstr "E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3"
... this returns the DN of the "NTDS Settings" object of the DC that owns
the retired invocation ID. If no results are returned, one of two things
occurred; 1) you fat-fingered it or 2) the DC no longer exists.
option 2) submit the following v. expensive query (note, it's a medial
query) -
C:\>adfind -config -f
"retiredReplDSASignatures=*\E0\A8\C4\6C\19\20\4F\4E\81\CD\F3\59\26\DE\38\A3*
" retiredReplDSASignatures
Fingers crossed that Joe will have a hidden switch to do the decoding for
you, until then, this is it I'm afraid.
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klassen
Sent: Tuesday, February 21, 2006 5:11 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Too bad Joe picked today to be MIA.
Scott Klassen
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: Tuesday, February 21, 2006 7:59 AM
To: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
The GUIDs returned in this scenario are not used by the directory in the
traditional manner and, as such, using a GUID-based binding string won't
locate the owning object. The invocation IDs (which are indeed GUIDs but
not objectGUIDs) are maintained on the DC's NTDSDSA instance (its NTDS
Settings object) by the "invocationId" property ... retired invocation IDs
are maintained by retiredReplDSASignatures.
ADfind can likely hit these ... but the GUIDS needs to be expressed as part
of the query filter, not the base. I'll leave joe (why does he insist on
using a little "j"?) to provide the ADfind syntax (it seems that no matter
how hard I try, joe will always have a better switch ... and if he doesn't
have one, I'm fairly certain he quickly adds it, quietly releases the new
binary with the same version number, posts the reply, ridicules my
uneducated attempt at using a "real tool" (joe's words, not mine) and
professes his innocence :0).
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Thommes, Michael M.
Sent: Tuesday, February 21, 2006 7:44 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to the rescue!
I recently had to do this and got it accomplished with the following syntax
(with a little help from joe :) ):
adfind -default -binenc -f
objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
("adfind /???" For lots of good info!)
Mike Thommes
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
Sent: Monday, February 20, 2006 8:56 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] repadmin info oddity
I try to keep up on new or updated MS KB articles and often check to see how
they correlate with my environment. I noticed that 875495, dealing with USN
rollbacks, was updated earlier this month. As I've experienced two AD
issues, both of which needed PSS involvement (one dealing with sysvol
inconsistency and the other which wound up being the RID master going on
temporary strike) I figured that I'd do a quick check as described in the
article. On the good side, the USN's are consistent between controllers.
On the disconcerting side, I got a little more information than I was
expecting. Besides my DC's, I also got USN listings for several GUIDs.
I
assume these are leftovers from DC demotions and only remain in the form of
historical data. Do I need to worry about these (especially the DC1
(retired) listing) and is there a way I can resolve the GUIDs to names, find
where this info is hiding, and clear them out?
Thanks,
Scott Klassen
>repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
..
Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
20:08:20
2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
00:02:34
6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
11:53:16
Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
20:10:50
Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
06:36:16
e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
20:52:04
ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
14:29:20
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/ | | | |
| AD000001290
Posts:0
| | 02/22/2006 3:04 AM |
| You mean 'The Dean and joe Show' with as small 'j' surely :)
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klassen
Sent: 22 February 2006 14:55
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Very handy and helpful. Thank you so much for the time you've put into
this Dean. If I ever get to meet you, it's worth a few at the bar. If
you didn't see a couple of days ago, MS announced that it was changing
the names for parts of AD. I think they need to rethink the choices
they've made and just call it The Dean and Joe Show. Has a bit of a
ring to it. :)
Scott Klassen
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: Wednesday, February 22, 2006 8:17 AM
To: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
As I'd hoped, joe does indeed have another way ... one that does the
encoding for you. There's a prefix that can be supplied within the
filter that extends to any attribute of your choosing (this instructs
ADfind to manipulate the byte ordering and related structure);
{{GUID=}}. The query below exploits that feature permitting repadmin's
string>GUID
format to be supplied directly.
C:\>adfind -config -binenc -f
(retiredReplDSASignatures=*{{GUID:6cc4a8e0-2019-4e4f-81cd-f35926de38a3}}
*)"
-dn
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: Tuesday, February 21, 2006 7:09 PM
To: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
Hmmm, I would guess he's probably adding a new switch to deal with this
particular thread.
Anyway, since he's not responded, I'll take a stab at what ADfind can or
cannot do here (not really ADfind's problem if my lazy research is
accurate). The attribute in question's syntax is a single-valued "octet
string" which can typically be filtered against assuming the correct
notation is supplied. This particular attribute, however, will often
contain multiple GUIDs within the flat value (a pack of them) making it
difficult to successfully construct a reliable and/or optimal filter
(remember, medial queries are painful without the necessary index).
To further complicate the issue, the byte ordering is maintained
differently internally to the way it's displayed. Since ADfind AFAIK
cannot yet decode "retiredReplDSASignatures", in order to query against
it we have to reorder it ourselves. Here's an example of how to convert
repadmin's display format to the internally maintained byte ordering
(this is a little painful) -
repadmin's output = 6cc4a8e0-2019-4e4f-81cd-f35926de38a3
internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38 A3
... now trim the hyphens and pad repadmin's output to pair up the bytes
-
repadmin's output = 6c c4 a8 e0 20 19 4e 4f-81 cd f3 59 26 de 38 a3
(padded & trimmed) internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3
59 26 DE 38
A3
... now, re-order the 1st 4 octets, then the next 2 octets and again the
next 2 octets. I've added extra spaces for legibility (essentially,
you're re-ordering the first double-word, the next word, the next word
and the rest remains as is ... this is known as "network" or "pretty"
byte ordering) -
repadmin's output = e0 a8 c4 6c 19 20 4f 4e 81 cd f3 59 26 de
38
a3 (re-ordered)
internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE
38
A3
OK, having done all of that, you now have two possible options:
option 1) use a fairly concise query and parse the output as follows ...
... create a string of 8 words (or 8 octet pairs if you prefer) to match
ADfind's output format -
resulting structure = E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3
... then use the following syntax -
C:\>adfind -config -f
"&(objectcategory=ntdsdsa)(retiredReplDSASignatures=*)" -csv
-nocsvheader retiredReplDSASignatures | findstr "E0A8 C46C 1920 4F4E
81CD F359 26DE 38A3"
... this returns the DN of the "NTDS Settings" object of the DC that
owns the retired invocation ID. If no results are returned, one of two
things occurred; 1) you fat-fingered it or 2) the DC no longer exists.
option 2) submit the following v. expensive query (note, it's a medial
query) -
C:\>adfind -config -f
"retiredReplDSASignatures=*\E0\A8\C4\6C\19\20\4F\4E\81\CD\F3\59\26\DE\38
\A3*
" retiredReplDSASignatures
Fingers crossed that Joe will have a hidden switch to do the decoding
for you, until then, this is it I'm afraid.
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klassen
Sent: Tuesday, February 21, 2006 5:11 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Too bad Joe picked today to be MIA.
Scott Klassen
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: Tuesday, February 21, 2006 7:59 AM
To: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
The GUIDs returned in this scenario are not used by the directory in the
traditional manner and, as such, using a GUID-based binding string won't
locate the owning object. The invocation IDs (which are indeed GUIDs
but not objectGUIDs) are maintained on the DC's NTDSDSA instance (its
NTDS Settings object) by the "invocationId" property ... retired
invocation IDs are maintained by retiredReplDSASignatures.
ADfind can likely hit these ... but the GUIDS needs to be expressed as
part of the query filter, not the base. I'll leave joe (why does he
insist on using a little "j"?) to provide the ADfind syntax (it seems
that no matter how hard I try, joe will always have a better switch ...
and if he doesn't have one, I'm fairly certain he quickly adds it,
quietly releases the new binary with the same version number, posts the
reply, ridicules my uneducated attempt at using a "real tool" (joe's
words, not mine) and professes his innocence :0).
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Thommes,
Michael M.
Sent: Tuesday, February 21, 2006 7:44 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to the rescue!
I recently had to do this and got it accomplished with the following
syntax (with a little help from joe :) ):
adfind -default -binenc -f
objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
("adfind /???" For lots of good info!)
Mike Thommes
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
Sent: Monday, February 20, 2006 8:56 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] repadmin info oddity
I try to keep up on new or updated MS KB articles and often check to see
how they correlate with my environment. I noticed that 875495, dealing
with USN rollbacks, was updated earlier this month. As I've experienced
two AD issues, both of which needed PSS involvement (one dealing with
sysvol inconsistency and the other which wound up being the RID master
going on
temporary strike) I figured that I'd do a quick check as described in
the article. On the good side, the USN's are consistent between
controllers.
On the disconcerting side, I got a little more information than I was
expecting. Besides my DC's, I also got USN listings for several GUIDs.
I
assume these are leftovers from DC demotions and only remain in the form
of historical data. Do I need to worry about these (especially the DC1
(retired) listing) and is there a way I can resolve the GUIDs to names,
find where this info is hiding, and clear them out?
Thanks,
Scott Klassen
>repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
..
Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
20:08:20
2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
00:02:34
6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
11:53:16
Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
20:10:50
Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
06:36:16
e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
20:52:04
ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
14:29:20
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/
PLEASE READ: The information contained in this email is confidential and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and delete your
copy from your system. You must not copy, distribute or take any further
action in reliance on it. Email is not a secure method of communication and
Nomura International plc ('NIplc') will not, to the extent permitted by law,
accept responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence of any virus, worm or similar malicious or disabling
code in, this message or any attachment(s) to it. If verification of this
email is sought then please request a hard copy. Unless otherwise stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely those of
the author and do not necessarily represent those of NIplc; (3) is intended
for informational purposes only and is not a recommendation, solicitation or
offer to buy or sell securities or related financial instruments. NIplc
does not provide investment services to private customers. Authorised and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies.
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/ | | | |
| dwells
Posts:53
| | 02/22/2006 3:15 AM |
| Glad it helped. As I meant to mention in my last post, that syntax was the
result of a chat with joe late last night ... no effort on my part short of
testing it ... so the thanks there should go to ADfind's author :o)
The "Dean and Joe Show" ... hmmm, I like that -- LOL! :o) Combo'ing that
with your willingness to buy me a beer (or a scotch if you'd prefer ;o) ...
you'll be able to do/see both if you're attending NetPro's DEC in Vegas;
along with a number of truly valuable presentations, Joe and I will be
presenting together on some of the more elusive behaviors of AD.
Hope to see you there.
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klassen
> Sent: Wednesday, February 22, 2006 9:55 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Very handy and helpful. Thank you so much for the time
> you've put into this Dean. If I ever get to meet you, it's
> worth a few at the bar. If you didn't see a couple of days
> ago, MS announced that it was changing the names for parts of
> AD. I think they need to rethink the choices they've made
> and just call it The Dean and Joe Show. Has a bit of a ring
> to it. :)
>
> Scott Klassen
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> Sent: Wednesday, February 22, 2006 8:17 AM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
> As I'd hoped, joe does indeed have another way ... one that
> does the encoding for you. There's a prefix that can be
> supplied within the filter that extends to any attribute of
> your choosing (this instructs ADfind to manipulate the byte
> ordering and related structure); {{GUID= string>}}. The query below exploits that feature permitting
> repadmin's
> string>GUID
> format to be supplied directly.
>
> C:\>adfind -config -binenc -f
> (retiredReplDSASignatures=*{{GUID:6cc4a8e0-2019-4e4f-81cd-f359
26de38a3}}*)"
> -dn
>
> --
>
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> Sent: Tuesday, February 21, 2006 7:09 PM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Hmmm, I would guess he's probably adding a new switch to deal
> with this particular thread.
>
> Anyway, since he's not responded, I'll take a stab at what
> ADfind can or cannot do here (not really ADfind's problem if
> my lazy research is accurate). The attribute in question's
> syntax is a single-valued "octet string" which can typically
> be filtered against assuming the correct notation is
> supplied. This particular attribute, however, will often
> contain multiple GUIDs within the flat value (a pack of them)
> making it difficult to successfully construct a reliable
> and/or optimal filter (remember, medial queries are painful
> without the necessary index).
>
> To further complicate the issue, the byte ordering is
> maintained differently internally to the way it's displayed.
> Since ADfind AFAIK cannot yet decode
> "retiredReplDSASignatures", in order to query against it we
> have to reorder it ourselves. Here's an example of how to
> convert repadmin's display format to the internally
> maintained byte ordering (this is a little painful) -
>
> repadmin's output = 6cc4a8e0-2019-4e4f-81cd-f35926de38a3
> internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38 A3
>
> ... now trim the hyphens and pad repadmin's output to pair up
> the bytes -
>
> repadmin's output = 6c c4 a8 e0 20 19 4e 4f-81 cd f3 59 26
> de 38 a3 (padded & trimmed) internal structure = E0 A8 C4 6C
> 19 20 4F 4E 81 CD F3 59 26 DE 38
> A3
>
> ... now, re-order the 1st 4 octets, then the next 2 octets
> and again the next 2 octets. I've added extra spaces for
> legibility (essentially, you're re-ordering the first
> double-word, the next word, the next word and the rest
> remains as is ... this is known as "network" or "pretty" byte
> ordering) -
>
> repadmin's output = e0 a8 c4 6c 19 20 4f 4e 81 cd
> f3 59 26 de 38
> a3 (re-ordered)
> internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD
> F3 59 26 DE 38
> A3
>
> OK, having done all of that, you now have two possible options:
>
> option 1) use a fairly concise query and parse the output as
> follows ...
>
> ... create a string of 8 words (or 8 octet pairs if you
> prefer) to match ADfind's output format -
>
> resulting structure = E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3
>
> ... then use the following syntax -
>
> C:\>adfind -config -f
> "&(objectcategory=ntdsdsa)(retiredReplDSASignatures=*)" -csv
> -nocsvheader retiredReplDSASignatures | findstr "E0A8 C46C
> 1920 4F4E 81CD F359 26DE 38A3"
>
> ... this returns the DN of the "NTDS Settings" object of the
> DC that owns the retired invocation ID. If no results are
> returned, one of two things occurred; 1) you fat-fingered it
> or 2) the DC no longer exists.
>
> option 2) submit the following v. expensive query (note, it's a medial
> query) -
>
> C:\>adfind -config -f
> "retiredReplDSASignatures=*\E0\A8\C4\6C\19\20\4F\4E\81\CD\F3\5
9\26\DE\38\A3*
> " retiredReplDSASignatures
>
> Fingers crossed that Joe will have a hidden switch to do the
> decoding for you, until then, this is it I'm afraid.
>
> --
>
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klassen
> Sent: Tuesday, February 21, 2006 5:11 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Too bad Joe picked today to be MIA.
>
> Scott Klassen
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> Sent: Tuesday, February 21, 2006 7:59 AM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
> The GUIDs returned in this scenario are not used by the
> directory in the traditional manner and, as such, using a
> GUID-based binding string won't locate the owning object.
> The invocation IDs (which are indeed GUIDs but not
> objectGUIDs) are maintained on the DC's NTDSDSA instance (its
> NTDS Settings object) by the "invocationId" property ...
> retired invocation IDs are maintained by retiredReplDSASignatures.
>
> ADfind can likely hit these ... but the GUIDS needs to be
> expressed as part of the query filter, not the base. I'll
> leave joe (why does he insist on using a little "j"?) to
> provide the ADfind syntax (it seems that no matter how hard I
> try, joe will always have a better switch ... and if he
> doesn't have one, I'm fairly certain he quickly adds it,
> quietly releases the new binary with the same version number,
> posts the reply, ridicules my uneducated attempt at using a
> "real tool" (joe's words, not mine) and professes his innocence :0).
>
>
> --
>
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
> Thommes, Michael M.
> Sent: Tuesday, February 21, 2006 7:44 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to
> the rescue!
> I recently had to do this and got it accomplished with the
> following syntax (with a little help from joe :) ):
>
> adfind -default -binenc -f
> objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
>
> ("adfind /???" For lots of good info!)
>
> Mike Thommes
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
> Sent: Monday, February 20, 2006 8:56 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: [ActiveDir] repadmin info oddity
>
> I try to keep up on new or updated MS KB articles and often
> check to see how they correlate with my environment. I
> noticed that 875495, dealing with USN rollbacks, was updated
> earlier this month. As I've experienced two AD issues, both
> of which needed PSS involvement (one dealing with sysvol
> inconsistency and the other which wound up being the RID
> master going on
>
> temporary strike) I figured that I'd do a quick check as
> described in the article. On the good side, the USN's are
> consistent between controllers.
> On the disconcerting side, I got a little more information
> than I was expecting. Besides my DC's, I also got USN
> listings for several GUIDs.
> I
> assume these are leftovers from DC demotions and only remain
> in the form of historical data. Do I need to worry about
> these (especially the DC1
> (retired) listing) and is there a way I can resolve the GUIDs
> to names, find where this info is hiding, and clear them out?
>
> Thanks,
>
> Scott Klassen
>
> >repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
> ..
> Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
> 20:08:20
> 2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time
> 2005-08-04
> 00:02:34
> 6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time
> 2004-07-24
> 11:53:16
> Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
> 20:10:50
> Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time
> 2005-08-05
> 06:36:16
> e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time
> 2004-12-28
> 20:52:04
> ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time
> 2005-06-08
> 14:29:20
>
>
> 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/ | | | |
| klas9574
Posts:1
| | 02/22/2006 3:55 AM |
| Not this year, but next is a definite possibility.
FYI if anyone but me cares, joe is working on getting the updated scripts
from AD3ed put up on joeware.net. He just had to wait for permission from
OReilly to do so. Now nobody else has to bug him about it.
Scott Klassen
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: Wednesday, February 22, 2006 9:13 AM
To: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
Glad it helped. As I meant to mention in my last post, that syntax was the
result of a chat with joe late last night ... no effort on my part short of
testing it ... so the thanks there should go to ADfind's author :o)
The "Dean and Joe Show" ... hmmm, I like that -- LOL! :o) Combo'ing that
with your willingness to buy me a beer (or a scotch if you'd prefer ;o) ...
you'll be able to do/see both if you're attending NetPro's DEC in Vegas;
along with a number of truly valuable presentations, Joe and I will be
presenting together on some of the more elusive behaviors of AD.
Hope to see you there.
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klassen
> Sent: Wednesday, February 22, 2006 9:55 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Very handy and helpful. Thank you so much for the time
> you've put into this Dean. If I ever get to meet you, it's
> worth a few at the bar. If you didn't see a couple of days
> ago, MS announced that it was changing the names for parts of
> AD. I think they need to rethink the choices they've made
> and just call it The Dean and Joe Show. Has a bit of a ring
> to it. :)
>
> Scott Klassen
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> Sent: Wednesday, February 22, 2006 8:17 AM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
> As I'd hoped, joe does indeed have another way ... one that
> does the encoding for you. There's a prefix that can be
> supplied within the filter that extends to any attribute of
> your choosing (this instructs ADfind to manipulate the byte
> ordering and related structure); {{GUID= string>}}. The query below exploits that feature permitting
> repadmin's
> string>GUID
> format to be supplied directly.
>
> C:\>adfind -config -binenc -f
> (retiredReplDSASignatures=*{{GUID:6cc4a8e0-2019-4e4f-81cd-f359
26de38a3}}*)"
> -dn
>
> --
>
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> Sent: Tuesday, February 21, 2006 7:09 PM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Hmmm, I would guess he's probably adding a new switch to deal
> with this particular thread.
>
> Anyway, since he's not responded, I'll take a stab at what
> ADfind can or cannot do here (not really ADfind's problem if
> my lazy research is accurate). The attribute in question's
> syntax is a single-valued "octet string" which can typically
> be filtered against assuming the correct notation is
> supplied. This particular attribute, however, will often
> contain multiple GUIDs within the flat value (a pack of them)
> making it difficult to successfully construct a reliable
> and/or optimal filter (remember, medial queries are painful
> without the necessary index).
>
> To further complicate the issue, the byte ordering is
> maintained differently internally to the way it's displayed.
> Since ADfind AFAIK cannot yet decode
> "retiredReplDSASignatures", in order to query against it we
> have to reorder it ourselves. Here's an example of how to
> convert repadmin's display format to the internally
> maintained byte ordering (this is a little painful) -
>
> repadmin's output = 6cc4a8e0-2019-4e4f-81cd-f35926de38a3
> internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38 A3
>
> ... now trim the hyphens and pad repadmin's output to pair up
> the bytes -
>
> repadmin's output = 6c c4 a8 e0 20 19 4e 4f-81 cd f3 59 26
> de 38 a3 (padded & trimmed) internal structure = E0 A8 C4 6C
> 19 20 4F 4E 81 CD F3 59 26 DE 38
> A3
>
> ... now, re-order the 1st 4 octets, then the next 2 octets
> and again the next 2 octets. I've added extra spaces for
> legibility (essentially, you're re-ordering the first
> double-word, the next word, the next word and the rest
> remains as is ... this is known as "network" or "pretty" byte
> ordering) -
>
> repadmin's output = e0 a8 c4 6c 19 20 4f 4e 81 cd
> f3 59 26 de 38
> a3 (re-ordered)
> internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD
> F3 59 26 DE 38
> A3
>
> OK, having done all of that, you now have two possible options:
>
> option 1) use a fairly concise query and parse the output as
> follows ...
>
> ... create a string of 8 words (or 8 octet pairs if you
> prefer) to match ADfind's output format -
>
> resulting structure = E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3
>
> ... then use the following syntax -
>
> C:\>adfind -config -f
> "&(objectcategory=ntdsdsa)(retiredReplDSASignatures=*)" -csv
> -nocsvheader retiredReplDSASignatures | findstr "E0A8 C46C
> 1920 4F4E 81CD F359 26DE 38A3"
>
> ... this returns the DN of the "NTDS Settings" object of the
> DC that owns the retired invocation ID. If no results are
> returned, one of two things occurred; 1) you fat-fingered it
> or 2) the DC no longer exists.
>
> option 2) submit the following v. expensive query (note, it's a medial
> query) -
>
> C:\>adfind -config -f
> "retiredReplDSASignatures=*\E0\A8\C4\6C\19\20\4F\4E\81\CD\F3\5
9\26\DE\38\A3*
> " retiredReplDSASignatures
>
> Fingers crossed that Joe will have a hidden switch to do the
> decoding for you, until then, this is it I'm afraid.
>
> --
>
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klassen
> Sent: Tuesday, February 21, 2006 5:11 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Too bad Joe picked today to be MIA.
>
> Scott Klassen
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> Sent: Tuesday, February 21, 2006 7:59 AM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
> The GUIDs returned in this scenario are not used by the
> directory in the traditional manner and, as such, using a
> GUID-based binding string won't locate the owning object.
> The invocation IDs (which are indeed GUIDs but not
> objectGUIDs) are maintained on the DC's NTDSDSA instance (its
> NTDS Settings object) by the "invocationId" property ...
> retired invocation IDs are maintained by retiredReplDSASignatures.
>
> ADfind can likely hit these ... but the GUIDS needs to be
> expressed as part of the query filter, not the base. I'll
> leave joe (why does he insist on using a little "j"?) to
> provide the ADfind syntax (it seems that no matter how hard I
> try, joe will always have a better switch ... and if he
> doesn't have one, I'm fairly certain he quickly adds it,
> quietly releases the new binary with the same version number,
> posts the reply, ridicules my uneducated attempt at using a
> "real tool" (joe's words, not mine) and professes his innocence :0).
>
>
> --
>
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
> Thommes, Michael M.
> Sent: Tuesday, February 21, 2006 7:44 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to
> the rescue!
> I recently had to do this and got it accomplished with the
> following syntax (with a little help from joe :) ):
>
> adfind -default -binenc -f
> objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
>
> ("adfind /???" For lots of good info!)
>
> Mike Thommes
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
> Sent: Monday, February 20, 2006 8:56 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: [ActiveDir] repadmin info oddity
>
> I try to keep up on new or updated MS KB articles and often
> check to see how they correlate with my environment. I
> noticed that 875495, dealing with USN rollbacks, was updated
> earlier this month. As I've experienced two AD issues, both
> of which needed PSS involvement (one dealing with sysvol
> inconsistency and the other which wound up being the RID
> master going on
>
> temporary strike) I figured that I'd do a quick check as
> described in the article. On the good side, the USN's are
> consistent between controllers.
> On the disconcerting side, I got a little more information
> than I was expecting. Besides my DC's, I also got USN
> listings for several GUIDs.
> I
> assume these are leftovers from DC demotions and only remain
> in the form of historical data. Do I need to worry about
> these (especially the DC1
> (retired) listing) and is there a way I can resolve the GUIDs
> to names, find where this info is hiding, and clear them out?
>
> Thanks,
>
> Scott Klassen
>
> >repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
> ..
> Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
> 20:08:20
> 2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time
> 2005-08-04
> 00:02:34
> 6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time
> 2004-07-24
> 11:53:16
> Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
> 20:10:50
> Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time
> 2005-08-05
> 06:36:16
> e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time
> 2004-12-28
> 20:52:04
> ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time
> 2005-06-08
> 14:29:20
>
>
> 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/ | | | |
| dwells
Posts:53
| | 02/22/2006 7:02 AM |
| Inline ...
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brett Shirley
> Sent: Wednesday, February 22, 2006 2:35 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Cc: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
>
> I wouldn't make a "hard feature" on such parsing, b/c it is
> not documented and could change at Brett or (lets call him)
> Greg's willy nilly.
... then don't! ;o)
On a more serious note, and this is more a policy thing than technical;
what makes it OK to simply change things that many or most customer's
are obviously using? I realize some are classified as a "support tool" and
not officially supported (there's irony in that word play) but they're
nonetheless valuable and are also supplied on the base media. This value
(and the complexity of such tools) makes them ideal candidates for wrappers,
i.e. scripts that simplify their usage or exploit their capabilities for
a larger purpose ......... anyways, soapbox over.
> Oh and I just rememberd ... I should also note, isn't a 100%
> accurate to use retired DSA signatures, we punted a bug in
> repadmin relating around this, IIRC ... IFM maintains the
> same retired DSAs list as the original source DC, meaning it
> is tricky to figure who is the real slim shady when deal with
> retired IIDs.
Hmmm, I'd not seen that before but can confirm that as of SP1/R2 the bug
persists. It's probably worth cleaning that up following the promotion
rather than just leaving it there to irritate and confuse at a later point
in time (that takes some additional effort and a little experience though).
> It may be probabalistically or even deterministically
> possible by looking at when the IID was retired, and matching
> against active IIDs, and matching retired IIDs, to figure out
> who originally owned the IID. That's what joe should work on...
Hmmm, not sure that's going to be feasible for the long-term since the
retired invocation IDs are maintained by a single-valued pack of
octet-strings, i.e. the metadata would reflect only the last update so
anything else that touched it such as restore or app. NC
addition-removal-readdition would eliminate the ability to derive anything
useful ... not everyday circumstances I'll grant you but certainly possible.
By IID, you're abbreviating invocation ID, not interface ID ... right (if
the latter, I'm confused)?
> We've also debated when we delete a DSA or stamping all
> related IIDs, into a never cleared place in the DS, so that
> repadmin /showutdvec could always resolve DSAs even after
> they've been deleted for 10 years.
I like the idea ... assuming the "never cleared" aspect only refers to the
automagic behaviors of the directory and not an enforced mechanism that
would prevent a sufficiently perm'd admin. from manually removing them. I'm
not saying I'm able to provide a credible reason for wanting to remove them
but suffice it to say that, for components such as this that do not
negatively impact the consistency or day-today proper-functioning of the
directory, they should not be forcibly blocked since it's ~impossible to
fully anticipate a customer's needs.
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/ | | | |
| activedirsmaporg
Posts:0
| | 02/22/2006 7:21 AM |
| Dean on another fork identified where repadmin gets the GUIDs it can
resolve. It does a search in CN=Sites (maybe CN=Configuration) for all
DSA objects (aka "nTDSDSA" or "NTDS Settings objects", retrieving the two
attributes Dean mentioned, and makes a table/cache to translate the names
to GUIDs. If you want, you can use "/nocache" to not build the cache (and
consequently possibly speed up the operation) and then you will see all
GUIDs in your UTDVec.
Cheers,
BrettSh
On Tue, 21 Feb 2006, Scott Klassen wrote:
> Thanks Michael and Dean. Very good information. ADFind came up empty on
> the GUIDs, so wherever Repadmin is getting this info from, it is well
> buried. I'm not going to lose any sleep over it. The more I learn on this
> list, the more things I don't want to mess with. :)
>
> Scott Klassen
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Thommes, Michael M.
> Sent: Tuesday, February 21, 2006 6:44 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to the rescue!
> I recently had to do this and got it accomplished with the following
> syntax (with a little help from joe :) ):
>
> adfind -default -binenc -f
> objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
>
> ("adfind /???" For lots of good info!)
>
> Mike Thommes
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
> Sent: Monday, February 20, 2006 8:56 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: [ActiveDir] repadmin info oddity
>
> I try to keep up on new or updated MS KB articles and often check to see
> how
> they correlate with my environment. I noticed that 875495, dealing with
> USN
> rollbacks, was updated earlier this month. As I've experienced two AD
> issues, both of which needed PSS involvement (one dealing with sysvol
> inconsistency and the other which wound up being the RID master going on
>
> temporary strike) I figured that I'd do a quick check as described in
> the
> article. On the good side, the USN's are consistent between
> controllers.
> On the disconcerting side, I got a little more information than I was
> expecting. Besides my DC's, I also got USN listings for several GUIDs.
> I
> assume these are leftovers from DC demotions and only remain in the form
> of
> historical data. Do I need to worry about these (especially the DC1
> (retired) listing) and is there a way I can resolve the GUIDs to names,
> find
> where this info is hiding, and clear them out?
>
> Thanks,
>
> Scott Klassen
>
> >repadmin /showutdvec dc1 dc=domain,dc=com
> Caching GUIDs.
> ..
> Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
> 20:08:20
> 2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
> 00:02:34
> 6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
> 11:53:16
> Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
> 20:10:50
> Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
> 06:36:16
> e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
> 20:52:04
> ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
> 14:29:20
>
>
> 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/ | | | |
| activedirsmaporg
Posts:0
| | 02/22/2006 7:36 AM |
| I wouldn't make a "hard feature" on such parsing, b/c it is not documented
and could change at Brett or (lets call him) Greg's willy nilly.
Oh and I just rememberd ... I should also note, isn't a 100% accurate to
use retired DSA signatures, we punted a bug in repadmin relating around
this, IIRC ... IFM maintains the same retired DSAs list as the original
source DC, meaning it is tricky to figure who is the real slim shady when
deal with retired IIDs.
It may be probabalistically or even deterministically possible by looking
at when the IID was retired, and matching against active IIDs, and
matching retired IIDs, to figure out who originally owned the IID. That's
what joe should work on...
We've also debated when we delete a DSA or stamping all related IIDs, into
a never cleared place in the DS, so that repadmin /showutdvec could always
resolve DSAs even after they've been deleted for 10 years.
On Tue, 21 Feb 2006, Dean Wells wrote:
> Hmmm, I would guess he's probably adding a new switch to deal with this
> particular thread.
>
> Anyway, since he's not responded, I'll take a stab at what ADfind can or
> cannot do here (not really ADfind's problem if my lazy research is
> accurate). The attribute in question's syntax is a single-valued "octet
> string" which can typically be filtered against assuming the correct
> notation is supplied. This particular attribute, however, will often
> contain multiple GUIDs within the flat value (a pack of them) making it
> difficult to successfully construct a reliable and/or optimal filter
> (remember, medial queries are painful without the necessary index).
>
> To further complicate the issue, the byte ordering is maintained differently
> internally to the way it's displayed. Since ADfind AFAIK cannot yet decode
> "retiredReplDSASignatures", in order to query against it we have to reorder
> it ourselves. Here's an example of how to convert repadmin's display format
> to the internally maintained byte ordering (this is a little painful) -
>
> repadmin's output = 6cc4a8e0-2019-4e4f-81cd-f35926de38a3
> internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38 A3
>
> ... now trim the hyphens and pad repadmin's output to pair up the bytes -
>
> repadmin's output = 6c c4 a8 e0 20 19 4e 4f-81 cd f3 59 26 de 38 a3 (padded
> & trimmed)
> internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38 A3
>
> ... now, re-order the 1st 4 octets, then the next 2 octets and again the
> next 2 octets. I've added extra spaces for legibility (essentially, you're
> re-ordering the first double-word, the next word, the next word and the rest
> remains as is ... this is known as "network" or "pretty" byte ordering) -
>
> repadmin's output = e0 a8 c4 6c 19 20 4f 4e 81 cd f3 59 26 de 38
> a3 (re-ordered)
> internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38
> A3
>
> OK, having done all of that, you now have two possible options:
>
> option 1) use a fairly concise query and parse the output as follows ...
>
> ... create a string of 8 words (or 8 octet pairs if you prefer) to match
> ADfind's output format -
>
> resulting structure = E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3
>
> ... then use the following syntax -
>
> C:\>adfind -config -f
> "&(objectcategory=ntdsdsa)(retiredReplDSASignatures=*)" -csv -nocsvheader
> retiredReplDSASignatures | findstr "E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3"
>
> ... this returns the DN of the "NTDS Settings" object of the DC that owns
> the retired invocation ID. If no results are returned, one of two things
> occurred; 1) you fat-fingered it or 2) the DC no longer exists.
>
> option 2) submit the following v. expensive query (note, it's a medial
> query) -
>
> C:\>adfind -config -f
> "retiredReplDSASignatures=*\E0\A8\C4\6C\19\20\4F\4E\81\CD\F3\59\26\DE\38\A3*
> " retiredReplDSASignatures
>
> Fingers crossed that Joe will have a hidden switch to do the decoding for
> you, until then, this is it I'm afraid.
>
> --
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klassen
> Sent: Tuesday, February 21, 2006 5:11 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Too bad Joe picked today to be MIA.
>
> Scott Klassen
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
> Sent: Tuesday, February 21, 2006 7:59 AM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] repadmin info oddity
>
> The GUIDs returned in this scenario are not used by the directory in the
> traditional manner and, as such, using a GUID-based binding string won't
> locate the owning object. The invocation IDs (which are indeed GUIDs but
> not objectGUIDs) are maintained on the DC's NTDSDSA instance (its NTDS
> Settings object) by the "invocationId" property ... retired invocation IDs
> are maintained by retiredReplDSASignatures.
>
> ADfind can likely hit these ... but the GUIDS needs to be expressed as part
> of the query filter, not the base. I'll leave joe (why does he insist on
> using a little "j"?) to provide the ADfind syntax (it seems that no matter
> how hard I try, joe will always have a better switch ... and if he doesn't
> have one, I'm fairly certain he quickly adds it, quietly releases the new
> binary with the same version number, posts the reply, ridicules my
> uneducated attempt at using a "real tool" (joe's words, not mine) and
> professes his innocence :0).
>
>
> --
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Thommes, Michael M.
> Sent: Tuesday, February 21, 2006 7:44 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] repadmin info oddity
>
> Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to the rescue!
> I recently had to do this and got it accomplished with the following syntax
> (with a little help from joe :) ):
>
> adfind -default -binenc -f
> objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
>
> ("adfind /???" For lots of good info!)
>
> Mike Thommes
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
> Sent: Monday, February 20, 2006 8:56 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: [ActiveDir] repadmin info oddity
>
> I try to keep up on new or updated MS KB articles and often check to see how
> they correlate with my environment. I noticed that 875495, dealing with USN
> rollbacks, was updated earlier this month. As I've experienced two AD
> issues, both of which needed PSS involvement (one dealing with sysvol
> inconsistency and the other which wound up being the RID master going on
>
> temporary strike) I figured that I'd do a quick check as described in the
> article. On the good side, the USN's are consistent between controllers.
> On the disconcerting side, I got a little more information than I was
> expecting. Besides my DC's, I also got USN listings for several GUIDs.
> I
> assume these are leftovers from DC demotions and only remain in the form of
> historical data. Do I need to worry about these (especially the DC1
> (retired) listing) and is there a way I can resolve the GUIDs to names, find
> where this info is hiding, and clear them out?
>
> Thanks,
>
> Scott Klassen
>
> >repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
> ..
> Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
> 20:08:20
> 2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
> 00:02:34
> 6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
> 11:53:16
> Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
> 20:10:50
> Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
> 06:36:16
> e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
> 20:52:04
> ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
> 14:29:20
>
>
> 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/ | | | |
| dwells
Posts:53
| | 02/22/2006 12:17 PM |
| Hmmm, I would guess he's probably adding a new switch to deal with this
particular thread.
Anyway, since he's not responded, I'll take a stab at what ADfind can or
cannot do here (not really ADfind's problem if my lazy research is
accurate). The attribute in question's syntax is a single-valued "octet
string" which can typically be filtered against assuming the correct
notation is supplied. This particular attribute, however, will often
contain multiple GUIDs within the flat value (a pack of them) making it
difficult to successfully construct a reliable and/or optimal filter
(remember, medial queries are painful without the necessary index).
To further complicate the issue, the byte ordering is maintained differently
internally to the way it's displayed. Since ADfind AFAIK cannot yet decode
"retiredReplDSASignatures", in order to query against it we have to reorder
it ourselves. Here's an example of how to convert repadmin's display format
to the internally maintained byte ordering (this is a little painful) -
repadmin's output = 6cc4a8e0-2019-4e4f-81cd-f35926de38a3
internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38 A3
... now trim the hyphens and pad repadmin's output to pair up the bytes -
repadmin's output = 6c c4 a8 e0 20 19 4e 4f-81 cd f3 59 26 de 38 a3 (padded
& trimmed)
internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38 A3
... now, re-order the 1st 4 octets, then the next 2 octets and again the
next 2 octets. I've added extra spaces for legibility (essentially, you're
re-ordering the first double-word, the next word, the next word and the rest
remains as is ... this is known as "network" or "pretty" byte ordering) -
repadmin's output = e0 a8 c4 6c 19 20 4f 4e 81 cd f3 59 26 de 38
a3 (re-ordered)
internal structure = E0 A8 C4 6C 19 20 4F 4E 81 CD F3 59 26 DE 38
A3
OK, having done all of that, you now have two possible options:
option 1) use a fairly concise query and parse the output as follows ...
... create a string of 8 words (or 8 octet pairs if you prefer) to match
ADfind's output format -
resulting structure = E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3
... then use the following syntax -
C:\>adfind -config -f
"&(objectcategory=ntdsdsa)(retiredReplDSASignatures=*)" -csv -nocsvheader
retiredReplDSASignatures | findstr "E0A8 C46C 1920 4F4E 81CD F359 26DE 38A3"
... this returns the DN of the "NTDS Settings" object of the DC that owns
the retired invocation ID. If no results are returned, one of two things
occurred; 1) you fat-fingered it or 2) the DC no longer exists.
option 2) submit the following v. expensive query (note, it's a medial
query) -
C:\>adfind -config -f
"retiredReplDSASignatures=*\E0\A8\C4\6C\19\20\4F\4E\81\CD\F3\59\26\DE\38\A3*
" retiredReplDSASignatures
Fingers crossed that Joe will have a hidden switch to do the decoding for
you, until then, this is it I'm afraid.
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klassen
Sent: Tuesday, February 21, 2006 5:11 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Too bad Joe picked today to be MIA.
Scott Klassen
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: Tuesday, February 21, 2006 7:59 AM
To: Send - AD mailing list
Subject: RE: [ActiveDir] repadmin info oddity
The GUIDs returned in this scenario are not used by the directory in the
traditional manner and, as such, using a GUID-based binding string won't
locate the owning object. The invocation IDs (which are indeed GUIDs but
not objectGUIDs) are maintained on the DC's NTDSDSA instance (its NTDS
Settings object) by the "invocationId" property ... retired invocation IDs
are maintained by retiredReplDSASignatures.
ADfind can likely hit these ... but the GUIDS needs to be expressed as part
of the query filter, not the base. I'll leave joe (why does he insist on
using a little "j"?) to provide the ADfind syntax (it seems that no matter
how hard I try, joe will always have a better switch ... and if he doesn't
have one, I'm fairly certain he quickly adds it, quietly releases the new
binary with the same version number, posts the reply, ridicules my
uneducated attempt at using a "real tool" (joe's words, not mine) and
professes his innocence :0).
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Thommes, Michael M.
Sent: Tuesday, February 21, 2006 7:44 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] repadmin info oddity
Adfind (http://www.joeware.net/win/free/tools/adfind.htm) to the rescue!
I recently had to do this and got it accomplished with the following syntax
(with a little help from joe :) ):
adfind -default -binenc -f
objectGUID={{GUID:0B3F5BC4-5713-4611-8F6A-752A3B0DE664}} dn
("adfind /???" For lots of good info!)
Mike Thommes
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of SCOTT KLASSEN
Sent: Monday, February 20, 2006 8:56 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] repadmin info oddity
I try to keep up on new or updated MS KB articles and often check to see how
they correlate with my environment. I noticed that 875495, dealing with USN
rollbacks, was updated earlier this month. As I've experienced two AD
issues, both of which needed PSS involvement (one dealing with sysvol
inconsistency and the other which wound up being the RID master going on
temporary strike) I figured that I'd do a quick check as described in the
article. On the good side, the USN's are consistent between controllers.
On the disconcerting side, I got a little more information than I was
expecting. Besides my DC's, I also got USN listings for several GUIDs.
I
assume these are leftovers from DC demotions and only remain in the form of
historical data. Do I need to worry about these (especially the DC1
(retired) listing) and is there a way I can resolve the GUIDs to names, find
where this info is hiding, and clear them out?
Thanks,
Scott Klassen
>repadmin /showutdvec dc1 dc=domain,dc=com Caching GUIDs.
..
Default-First-Site-Name\DC2 @ USN 455091 @ Time 2006-02-20
20:08:20
2c92760e-e8fc-4418-947e-3b1016ab8514 @ USN 1012381 @ Time 2005-08-04
00:02:34
6e129965-56c3-469e-b70a-f1fdfb8bb2cc @ USN 969931 @ Time 2004-07-24
11:53:16
Default-First-Site-Name\DC1 @ USN 1717571 @ Time 2006-02-20
20:10:50
Default-First-Site-Name\DC1 (retired) @ USN 1298674 @ Time 2005-08-05
06:36:16
e2199f22-f1dd-4d1c-90a6-0e8bb874f355 @ USN 744173 @ Time 2004-12-28
20:52:04
ff0d7d50-214f-4bc1-96b6-55ac6ef317f0 @ USN 852323 @ Time 2005-06-08
14:29:20
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/ | | | |
|
|