Inline ... -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley > Sent: Wednesday, February 22, 2006 2:35 AM > To: [email protected] > 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/
