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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] http://msetechnology.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Scott Klassen > Sent: Wednesday, February 22, 2006 9:55 AM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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=<octet > 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: [EMAIL PROTECTED] > http://msetechnology.com > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > http://msetechnology.com > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Scott Klassen > Sent: Tuesday, February 21, 2006 5:11 PM > To: [email protected] > Subject: RE: [ActiveDir] repadmin info oddity > > Too bad Joe picked today to be MIA. > > Scott Klassen > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > http://msetechnology.com > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Thommes, Michael M. > Sent: Tuesday, February 21, 2006 7:44 AM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of SCOTT KLASSEN > Sent: Monday, February 20, 2006 8:56 PM > To: [email protected] > 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/
