P.S. - You can't really insult me ... P.P.S - and if we were smart, we would've compressed the metadata from the get go ;) and we'd be trying to figure out how to stuff the SID in the metadata w/o bloating the DIT by 10% ... and instead we'd have to be really cunning (cunning is smarter than smart) to make it all work out,
P.P.P.S. - or do survey's to see if the increase in DIT size is worth the feature to you guys (which is an interesting question in itself, just to see what people are willing to "pay". ;) P.P.P.P.S. - Instead we're lucky. The line between lucky and cunning is very narrow. OK, I'm done. On Fri, 14 Oct 2005, Brett Shirley wrote: > Well, first you should _never_ ever view anything _I_ am musing as a > possible feature from the product group, I muse ALOT of stuff. PMs will > be feature groups spokespeople, I am a dev. This feature (in various > forms) has been under consideration before, specicfically Win2k, Win2k3, > and Longhorn timeframes. > > Secondarily, features for any company, is always an optimization question > of profit opportunity of feature A vs. feature B vs. cost vs. available > resources ... would you give up the planned Longhorn RODC features for > something like this? > > And finally ... you've dealt with the product group before ... they tell > us (devs) the first time we goto a conference never promise the customer > anything, as we are only supposed to set expectations in customers that > will be delievered on ... > > IF you really want a commitment on adding it... how about this, I > can commit to delivering my first blog post before giving you user > modification tracking in metadata. > > ... have I now doomed the feature to never show up? > > So you asked was that a yes or no in that previous post ... I'd view this > as nothing less than and nothing more than ... msft has smart people who > think about this stuff ... and in that spirit, if it were done, you > probably don't need to worry about DIT bloat (I'm much too smart to let > that happen, frankly you insult me ;). > > Cheers, > BrettSh [msft] > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > On Fri, 14 Oct 2005, Al Mulnick wrote: > > > Is that a "yes" you'll add it? Or no, "..and no bananas for you." answer? > > > > Al > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley > > Sent: Friday, October 14, 2005 11:50 AM > > To: [email protected] > > Subject: RE: [ActiveDir] Knowing when users were deleted. > > > > > > > > Ignoring the 16 bytes at the beginning of the metadata for version and attr > > count info, and garbage wasted space ... the metadata for a single attribute > > is 48 bytes, adding the SID (28 bytes) would be an expansion of 57% on the > > _raw_ per attribute metadata size. > > > > A sampling of a corporate DB showed the raw metadata size to be 15% of the > > DIT size, which would lead me to believe the DIT would expand by ~10% for a > > trivial implementation against this paticular corporate DIT.[1] > > > > However, if you look at the /showobjmeta for _any_ object, you will realize > > that is a data structure that is over ripe (like banannas you wouldn't even > > use for a bananna cake) for being compressed. I think I could add a SID, > > (custom) compress it, and shrink the DIT in size. > > > > While you might think a GUID is better, because If you add a GUID, it is > > only 16 bytes, but that's a very uncompressible 16 bytes, "effectively a > > random hash". The SID is more likely to compress properly. > > > > [1] I expect that corporate DITs vary what % is meta-data by how many certs > > and big blobs they stick in thier AD. I imagine most corporate DITs are > > worse (as in higher % is metadata) than the one I checked out. > > > > Not that I've been thought of it ... > > > > Cheers, > > -BrettSh [msft] > > > > This posting is provided "AS IS" with no warranties, and confers no rights. > > > > > > On Fri, 14 Oct 2005, Al Mulnick wrote: > > > > > <raises hand> > > > GUID or SID of the user account that made the delete request. Last > > > mod my not be enough in case some process gets hold of that data in > > > the deleted items, even if unlikely. I want the id of the identity > > > that put caused the object to be there in the first place. > > > > > > Having the data for a full undelete option wouldn't seem too terrible > > > either, although that might significantly increase the storage in the > > > DIT. In the past I've had to write apps to keep that information out > > > of band in order to put back items mistakenly removed. But I can't see > > > why I should have to trip through all the DC's Audit logs to find the > > > information about who deleted something given how common this type of > > > question is. It should be recorded same as the audit log (we have the > > > information, why not stamp it on the object at time of deletion?) > > > > > > Al > > > > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of joe > > > Sent: Friday, October 14, 2005 11:03 AM > > > To: [email protected] > > > Subject: RE: [ActiveDir] Knowing when users were deleted. > > > > > > > > > Correct, you can currenlty only get the when and the where (DC Where > > > not Client Where). > > > > > > Which raises the question. How many people would like a metadata stamp > > > with the GUID or SID of the userid that made the modification for a > > > given attribute (or value if appropriate)? Or would it be ok to just > > > have who made the last change to the object? Either way, none of the > > > "administrators group" nonsense, it points to a specific security > > > principal. > > > > > > > > > > > > _____ > > > > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Freddy > > > HARTONO > > > Sent: Friday, October 14, 2005 3:18 AM > > > To: [email protected] > > > Subject: RE: [ActiveDir] Knowing when users were deleted. > > > > > > > > > Hi Yann, > > > > > > You can find at the deletedobject folder via adfind -showdel and see > > > the Last modified date - that would be when the object is deleted. > > > > > > But as for who deleted - I dont think you can find it without the > > > auditing. > > > > > > > > > > > > Thank you and have a splendid day! > > > > > > Kind Regards, > > > > > > Freddy Hartono > > > Group Support Engineer > > > InternationalSOS Pte Ltd > > > mail: [EMAIL PROTECTED] > > > phone: (+65) 6330-9740 - temp > > > > > > > > > > > > _____ > > > > > > From: Yann [mailto:[EMAIL PROTECTED] > > > Sent: Friday, October 14, 2005 2:57 PM > > > To: [email protected] > > > Subject: [ActiveDir] Knowing when users were deleted. > > > > > > > > > Hi there, > > > > > > I wonder if there is a way to know when a user has been deleted from > > > AD other than using security audt, because at the time of the > > > deletion, i forgot to activate the audit :( > > > > > > So my boss urge me to find the guilty user AND the time of deletion. I > > > looked for attributes in adsi and found that there is the whencreated, > > > whenmodified attribute but not whendeletedtimestamp one. > > > > > > Any idea ? > > > > > > > > > > > > _____ > > > > > > Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! > > > Messenger T?l?chargez > > > <http://us.rd.yahoo.com/messenger/mail_taglines/default/*http://fr.mes > > > senger > > > yahoo.com> le ici ! > > > > > > > > > > > > > > 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/
