RE: [ActiveDir] Tombstone.

[joe]

Difficult to replicate a deleted object... If you send a null to your
replication partner, it doesn't know what to remove. :)
 
You can get around the whole tombstone thing though if you use dynamic
objects. Those really and truly do delete with no chance of reanimation.
However, the time to die info is (well usually) on the object from the very
beginning so you don't need to replicate around a notification of a
tombstone, each DC will know when it needs to remove the object. This is
actually a fun way to build lingering objects in your directory. There are a
couple of ways it can be leveraged to do so if you really want to work at
dorking your forest up.
 
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 
 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Monday, December 04, 2006 4:00 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Tombstone.


Brett, because of the way the question was asked it might be a good idea to
mention why that's important vs. just deleting an object and replicating
that. 

My $0.04 for the day. 

Al


On 12/4/06, Brett Shirley <[EMAIL PROTECTED]> wrote: 

By default it is not possible to recover an AD object from an AD
tombstone.

The AD tombstone mechanism is used to support AD replication.

The way AD replications works, is that in a sense a delete is really like 
a modify by "setting the isDeleted" attribute (really the metadata, maybe
the attr too, don't remember OTOH).  By setting this attribute the AD
object turns into an AD tombstone, a change that can replicate normally 
around to make the delete global.

Cheers,
Brett Shirley


On Tue, 5 Dec 2006, Ajay Kumar wrote:

> Hi all,
>
> I have a query
> Is that possible to recover network object from AD tombstone. 
> If not then wht is use of it.
>
> Regards,
> Ajay pardeshi
>

List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir@mail.activedir.org/

RE: [ActiveDir] Tombstone.

[joe]

Note that not all objects can be reanimated, there is a little bug I found
that impacts objects (mostly config objects if I recall properly) created
with specific settings that will not allow you to move them out of the
deleted objects container once they have been "deleted/tombstoned". I
believe I ran into that while doing mass testing of AdMod which will also
reanimate tombstones. The bug is officially bugged and should be corrected
eventually.

  joe 


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray
Sent: Monday, December 04, 2006 2:51 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Tombstone.

Hi Ajay

Not sure what network objects you are interested in, but you do have the
ability to reanimate tombstoned objects.  The main issue with this is that
not all of the attributes are preserved when the object is tombstoned, which
means you won't get back everything that was lost using this method.

For some tools leveraging the reanimation API, have a look at:

http://www.microsoft.com/technet/sysinternals/utilities/AdRestore.mspx

http://www.quest.com/object_restore_for_active_directory/

Also have a look at the discussion thread below.  Dean Wells shows how to
modify the schema to include additional attributes in tombstone reanimation.

http://www.mail-archive.com/activedir@mail.activedir.org/msg30802.html

Tony
-- Original Message --
From: "Ajay Kumar" <[EMAIL PROTECTED]>
Reply-To: ActiveDir@mail.activedir.org
Date:  Tue, 5 Dec 2006 00:33:21 +0530

Hi all,

I have a query
Is that possible to recover network object from AD tombstone.
If not then wht is use of it.

Regards,
Ajay pardeshi


 





Sent via the WebMail system at mail.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@mail.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@mail.activedir.org/

Re: [ActiveDir] Tombstone.

[Al Mulnick]

Brett, because of the way the question was asked it might be a good idea to
mention why that's important vs. just deleting an object and replicating
that.

My $0.04 for the day.

Al

On 12/4/06, Brett Shirley <[EMAIL PROTECTED]> wrote:


By default it is not possible to recover an AD object from an AD
tombstone.

The AD tombstone mechanism is used to support AD replication.

The way AD replications works, is that in a sense a delete is really like
a modify by "setting the isDeleted" attribute (really the metadata, maybe
the attr too, don't remember OTOH).  By setting this attribute the AD
object turns into an AD tombstone, a change that can replicate normally
around to make the delete global.

Cheers,
Brett Shirley


On Tue, 5 Dec 2006, Ajay Kumar wrote:

> Hi all,
>
> I have a query
> Is that possible to recover network object from AD tombstone.
> If not then wht is use of it.
>
> Regards,
> Ajay pardeshi
>

List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir@mail.activedir.org/

RE: [ActiveDir] Tombstone.

[Almeida Pinto, Jorge de]

are you asking if it is possible to undelete a tombstone which was created when 
an object was deleted?
Well, yes it is possible.
 
When an object is deleted almost all of its attributes are lost except several 
important attributes. Undeleting the object will not return the values of those 
attributes. Only doing an authoritative restore or an undelete followed by a 
write back of attributes (from some repository) will fully restore the object
 
also see:
MS-KBQ840001_How to restore deleted user accounts and their group memberships 
in Active Directory
 
Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services
 
LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 



From: [EMAIL PROTECTED] on behalf of Ajay Kumar
Sent: Mon 2006-12-04 20:03
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Tombstone.


? 
Hi all,
 
I have a query
Is that possible to recover network object from AD tombstone.
If not then wht is use of it.
 
Regards,
Ajay pardeshi


This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.
<>

Re: [ActiveDir] Tombstone.

[Brett Shirley]

By default it is not possible to recover an AD object from an AD
tombstone.

The AD tombstone mechanism is used to support AD replication.

The way AD replications works, is that in a sense a delete is really like
a modify by "setting the isDeleted" attribute (really the metadata, maybe
the attr too, don't remember OTOH).  By setting this attribute the AD
object turns into an AD tombstone, a change that can replicate normally
around to make the delete global.

Cheers,
Brett Shirley


On Tue, 5 Dec 2006, Ajay Kumar wrote:

> Hi all,
> 
> I have a query
> Is that possible to recover network object from AD tombstone.
> If not then wht is use of it.
> 
> Regards,
> Ajay pardeshi
> 

List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir@mail.activedir.org/

Re: [ActiveDir] Tombstone.

[Tony Murray]

Hi Ajay

Not sure what network objects you are interested in, but you do have the 
ability to reanimate tombstoned objects.  The main issue with this is that not 
all of the attributes are preserved when the object is tombstoned, which means 
you won't get back everything that was lost using this method.

For some tools leveraging the reanimation API, have a look at:

http://www.microsoft.com/technet/sysinternals/utilities/AdRestore.mspx

http://www.quest.com/object_restore_for_active_directory/

Also have a look at the discussion thread below.  Dean Wells shows how to 
modify the schema to include additional attributes in tombstone reanimation.

http://www.mail-archive.com/activedir@mail.activedir.org/msg30802.html

Tony
-- Original Message --
From: "Ajay Kumar" <[EMAIL PROTECTED]>
Reply-To: ActiveDir@mail.activedir.org
Date:  Tue, 5 Dec 2006 00:33:21 +0530

Hi all,

I have a query
Is that possible to recover network object from AD tombstone.
If not then wht is use of it.

Regards,
Ajay pardeshi


 





Sent via the WebMail system at mail.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@mail.activedir.org/

[ActiveDir] Tombstone.

[Ajay Kumar]

Hi all,

I have a query
Is that possible to recover network object from AD tombstone.
If not then wht is use of it.

Regards,
Ajay pardeshi

RE: [ActiveDir] Tombstone attributes

[joe]

> I don't consider storing the PW in a tombstone a particularily high risk

I agree with Guido here. I expect I wouldn't think twice about doing this if
it came up. When you reanimate even if you set pwdLastSet to be recovered it
won't be. It won't be stripped on the tombstoning process, it will be
stripped when the object is reanimated. Also the object will be disabled on
reanimate. So the user/computer has to be reenabled and unexpired (Set the
pwdlastset to -1) to be used, it isn't like you would accidently reanimate
and have a fully functioning account. Could be handy to have that old
password there for the cases like Ulf said for old computers or Service IDs
that you don't want to go change the password in 1000 different places for
(not that I like that excuse).

  joe

--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido
Sent: Wednesday, April 19, 2006 4:51 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone attributes

it all comes down to: 
- what are you trying to protect yourself from? 
- what are your procedures or tools for restoring the objects?
- what are the risks involved and potential costs for recovery?

protecting from accidental deletion of a single object is different from
trying to protect yourself from accidental mass deletions (such as a whole
OU containing many hundred or thousand objects). Planning recovery in a
single-domain forest is different from planning recovery in multi-domain
forests. Planning to use online recovery tools (tombstone
reanimation) is different from planning to recover objects using the native
recovery options (systemstate restore + NTDSUTIL authoritative restore).

A combination of both approaches (online recovery + native tools) could be
the right answer => no matter what tools you use, you'll always want to
perform system state backups of at least 2 DCs in every domain anyways to be
on the safe side and be prepared for a true forest recovery. 

But you couldn't care less to reboot a DC just to recover a single or very
few objects (depends on size of your environment and if you have
deliberately planned a "recovery" DC that's not used by users or apps).
Online recovery tools do a perfect job of recovering these objects - and if
it's only a few, then you're fine with setting the PW at recovery time.
Logistics is the main pain here: you'll have to tell the recovered user the
new PW so that he can logon again - and as Ulf mentioned, you'll have to
rejoin computer accounts to the domain if you plan to recover them online as
well, but for a few objects, this could be acceptable (yet painful).

When planning recovery of accidental mass deletions, you could argue to do
this via the "native" way, restoring a DC from a sys-state backup and
performing an auth. restore. And since the PW is obviously stored in the
sys-state backup you'll get (almost) everything back (ofcourse, you'll have
the same trouble with passwords that just expired or that a user had just
changed after doing your backup...). But in general, users'
passwords will be recovered just fine and computers actually leverage the
last two passwords during authentication so in general there's no issue with
expired computer passwords either. You're main challenge with using the
native tools now lies in correct recovery of the links between the various
objects you've just restored - this is particularly painful for multi-domain
environemnts.  On the other side, if you plan to use the online recovery
tools for mass recovery, you'd certainly wish to have the password in the
tombstone since otherwise this would be a logistical nightmare - yet the
tools to handle link recovery in multi-domain environments just fine, which
is a big painpoint when recovering natively.

So it's up to you to weight the risk of storing passwords in tombstones to
allow easier recovery - or to choose native recovery when recovering from
mass deletion. I don't consider storing the PW in a tombstone a
particularily high risk - especially if you weight it against the cost you
have to recover things correctly the native way. Realize, that you don't
need to store all the PW related attributes, only Unicode-Pwd is required to
successfully restore the PW (and using most online recovery tools you could
still choose to have the user reset his PW at next logon).

Some of this is discussed in more detail in the following guide:
http://www.netpro.com/media/pdf/NetPro_ADDR_Guide.pdf


/Guido

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Onyszko
Sent: Mittwoch, 19. April 2006 00:43
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Tombstone attributes

Ulf B. Simon-Weidner wrote:
> 

RE: [ActiveDir] Tombstone attributes

[Grillenmeier, Guido]

it all comes down to: 
- what are you trying to protect yourself from? 
- what are your procedures or tools for restoring the objects?
- what are the risks involved and potential costs for recovery?

protecting from accidental deletion of a single object is different from
trying to protect yourself from accidental mass deletions (such as a
whole OU containing many hundred or thousand objects). Planning recovery
in a single-domain forest is different from planning recovery in
multi-domain forests. Planning to use online recovery tools (tombstone
reanimation) is different from planning to recover objects using the
native recovery options (systemstate restore + NTDSUTIL authoritative
restore).

A combination of both approaches (online recovery + native tools) could
be the right answer => no matter what tools you use, you'll always want
to perform system state backups of at least 2 DCs in every domain
anyways to be on the safe side and be prepared for a true forest
recovery. 

But you couldn't care less to reboot a DC just to recover a single or
very few objects (depends on size of your environment and if you have
deliberately planned a "recovery" DC that's not used by users or apps).
Online recovery tools do a perfect job of recovering these objects - and
if it's only a few, then you're fine with setting the PW at recovery
time. Logistics is the main pain here: you'll have to tell the recovered
user the new PW so that he can logon again - and as Ulf mentioned,
you'll have to rejoin computer accounts to the domain if you plan to
recover them online as well, but for a few objects, this could be
acceptable (yet painful).

When planning recovery of accidental mass deletions, you could argue to
do this via the "native" way, restoring a DC from a sys-state backup and
performing an auth. restore. And since the PW is obviously stored in the
sys-state backup you'll get (almost) everything back (ofcourse, you'll
have the same trouble with passwords that just expired or that a user
had just changed after doing your backup...). But in general, users'
passwords will be recovered just fine and computers actually leverage
the last two passwords during authentication so in general there's no
issue with expired computer passwords either. You're main challenge with
using the native tools now lies in correct recovery of the links between
the various objects you've just restored - this is particularly painful
for multi-domain environemnts.  On the other side, if you plan to use
the online recovery tools for mass recovery, you'd certainly wish to
have the password in the tombstone since otherwise this would be a
logistical nightmare - yet the tools to handle link recovery in
multi-domain environments just fine, which is a big painpoint when
recovering natively.

So it's up to you to weight the risk of storing passwords in tombstones
to allow easier recovery - or to choose native recovery when recovering
from mass deletion. I don't consider storing the PW in a tombstone a
particularily high risk - especially if you weight it against the cost
you have to recover things correctly the native way. Realize, that you
don't need to store all the PW related attributes, only Unicode-Pwd is
required to successfully restore the PW (and using most online recovery
tools you could still choose to have the user reset his PW at next
logon).

Some of this is discussed in more detail in the following guide:
http://www.netpro.com/media/pdf/NetPro_ADDR_Guide.pdf


/Guido

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Onyszko
Sent: Mittwoch, 19. April 2006 00:43
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Tombstone attributes

Ulf B. Simon-Weidner wrote:
> Unfortunately the passwords is the same attribute for users and
computers. I
> thought recently to put the password in the tombstone to ease computer
> account reanimation - after the account is deleted the computer is not
able
> to change it's password, and if it was deleted accidentally it's easy
to
> reanimate the account and the computer will still be happy.
> 
> I know that it'll be easy to put the computers in the domain again,
however
> I've had a customer with hundreds of sites which lost a couple hundred
> computer accounts across those sites, and bandwidth didn't allow to
remotly
> script the addition of the computer accounts to the domain via netdom.
We
> were able to perform an authoritative restore, and were lucky that we
lost
> almost no computer accounts due to changed password, however this was
a
> unlikely event with the computers recently joined the newly created
domain.
> In running domains we'd have to calculate an average of 1/15th of
computers
> per day of the age of the backup to join manually.
> 
> I agree on user objects 

RE: [ActiveDir] Tombstone attributes

[Ulf B. Simon-Weidner]

Agreed - as I said I'd put procedures in place to protect user account
passwords, but would use tombstones to ease computer account restores.

Ulf

 

|-Original Message-
|From: [EMAIL PROTECTED] 
|[mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Onyszko
|Sent: Wednesday, April 19, 2006 12:43 AM
|To: ActiveDir@mail.activedir.org
|Subject: Re: [ActiveDir] Tombstone attributes
|
|Ulf B. Simon-Weidner wrote:
|> Unfortunately the passwords is the same attribute for users and 
|> computers. I thought recently to put the password in the 
|tombstone to 
|> ease computer account reanimation - after the account is deleted the 
|> computer is not able to change it's password, and if it was deleted 
|> accidentally it's easy to reanimate the account and the 
|computer will still be happy.
|> 
|> I know that it'll be easy to put the computers in the domain again, 
|> however I've had a customer with hundreds of sites which 
|lost a couple 
|> hundred computer accounts across those sites, and bandwidth didn't 
|> allow to remotly script the addition of the computer accounts to the 
|> domain via netdom. We were able to perform an authoritative restore, 
|> and were lucky that we lost almost no computer accounts due 
|to changed 
|> password, however this was a unlikely event with the 
|computers recently joined the newly created domain.
|> In running domains we'd have to calculate an average of 1/15th of 
|> computers per day of the age of the backup to join manually.
|> 
|> I agree on user objects - and if I'd decide to keep the password for 
|> computer account in the tombstone I'd would prefer to put a 
|procedure 
|> in place to change a users password before deleting it.
|> 
|
|Jup, I can agree with it - but still I don't like idea of 
|restoring the user with old password. What about password age 
|and complying with security policy - I can imagine situation 
|in which user's password was
|89 day's old (wit 90 days maximum password age), then was 
|deleted an restored - password will be valid for another 90 
|days. What about complexity requirements ?
|
|
|
|--
|Tomasz Onyszko
|http://www.w2k.pl/blog/ - (PL)
|http://blogs.dirteam.com/blogs/tomek/ - (EN)
|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/

Re: [ActiveDir] Tombstone attributes

[Tomasz Onyszko]

Ulf B. Simon-Weidner wrote:

Unfortunately the passwords is the same attribute for users and computers. I
thought recently to put the password in the tombstone to ease computer
account reanimation - after the account is deleted the computer is not able
to change it's password, and if it was deleted accidentally it's easy to
reanimate the account and the computer will still be happy.

I know that it'll be easy to put the computers in the domain again, however
I've had a customer with hundreds of sites which lost a couple hundred
computer accounts across those sites, and bandwidth didn't allow to remotly
script the addition of the computer accounts to the domain via netdom. We
were able to perform an authoritative restore, and were lucky that we lost
almost no computer accounts due to changed password, however this was a
unlikely event with the computers recently joined the newly created domain.
In running domains we'd have to calculate an average of 1/15th of computers
per day of the age of the backup to join manually.

I agree on user objects - and if I'd decide to keep the password for
computer account in the tombstone I'd would prefer to put a procedure in
place to change a users password before deleting it.



Jup, I can agree with it - but still I don't like idea of restoring the 
user with old password. What about password age and complying with 
security policy - I can imagine situation in which user's password was 
89 day's old (wit 90 days maximum password age), then was deleted an 
restored - password will be valid for another 90 days. What about 
complexity requirements ?




--
Tomasz Onyszko
http://www.w2k.pl/blog/ - (PL)
http://blogs.dirteam.com/blogs/tomek/ - (EN)
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/

RE: [ActiveDir] Tombstone attributes

[Ulf B. Simon-Weidner]

Unfortunately the passwords is the same attribute for users and computers. I
thought recently to put the password in the tombstone to ease computer
account reanimation - after the account is deleted the computer is not able
to change it's password, and if it was deleted accidentally it's easy to
reanimate the account and the computer will still be happy.

I know that it'll be easy to put the computers in the domain again, however
I've had a customer with hundreds of sites which lost a couple hundred
computer accounts across those sites, and bandwidth didn't allow to remotly
script the addition of the computer accounts to the domain via netdom. We
were able to perform an authoritative restore, and were lucky that we lost
almost no computer accounts due to changed password, however this was a
unlikely event with the computers recently joined the newly created domain.
In running domains we'd have to calculate an average of 1/15th of computers
per day of the age of the backup to join manually.

I agree on user objects - and if I'd decide to keep the password for
computer account in the tombstone I'd would prefer to put a procedure in
place to change a users password before deleting it.

Gruesse - Sincerely, 

Ulf B. Simon-Weidner 

  MVP-Book "Windows XP - Die Expertentipps": http://tinyurl.com/44zcz
  Weblog: http://msmvps.org/UlfBSimonWeidner
  Website: http://www.windowsserverfaq.org
  Profile:
http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1214C811
D   

 

|-Original Message-
|From: [EMAIL PROTECTED] 
|[mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Onyszko
|Sent: Tuesday, April 18, 2006 11:19 PM
|To: ActiveDir@mail.activedir.org
|Subject: Re: [ActiveDir] Tombstone attributes
|
|Steele, Aaron [BSD] - ADM wrote:
|> Hi there all,
|>  
|> Does anyone here know why Microsoft chose not to include the 
|> attributes related to user password and sidHistory in the 
|tombstone of 
|> an object upon deletion?
|> Was it a security decision?
|> I would like to get some input from people here before I go 
|and update 
|> my schema to enable the restoration of these properties from the 
|> tombstone'd object.
|
|Personally I would not like to preserve password attribute on tombstone
|- I don't see a reason for that, and yes, IMO it can be seen 
|as possible 
|   security threat. If user is deleted and restoring it 
|requires admin action it is just another logical step to reset 
|it's password.
|
|SID History attribute is preserved as with SP1 on Windows 2003 
|DC. ~Eric wrote about it some time ago:
|http://blogs.technet.com/efleis/archive/2005/07/12/407648.aspx
|
|and this is OK - when you want to restore object and probably 
|it's group membership etc. preserving SID History is good solution.
|
|--
|Tomasz Onyszko
|http://www.w2k.pl/blog/ - (PL)
|http://blogs.dirteam.com/blogs/tomek/ - (EN)
|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/

RE: [ActiveDir] Tombstone attributes

[Almeida Pinto, Jorge de]

In addition to what Tomasz said...
 
How objects are deleted / tombstoned (simplified!)
* The "isDeleted" attribute is set to TRUE (which marks the object as a 
tombstone - an object that has been deleted but not fully removed from the 
directory).
* The relative distinguished name (RDN) of the object is set to a value that 
cannot be set by an LDAP application (a value that is impossible).
* Strips ALL attributes not needed by AD, except for the important attributes 
like "objectGUID", "objectSid", "distinguishedName", "nTSecurityDescriptor" and 
"uSNChanged" which are preserved on the tombstone.
  * On W2K3 SP1 DCs, the "sIDHistory" attribute is also preserved
* Move the tombstone to the "Deleted Objects" container of the partition where 
the object resides (If the object systemFlags property contains the 0x0200 
flag, the object is not moved to the Deleted Objects container) (e.g. NTDS 
Settings object of a DC)
 
Config. which attr. are retained when object is tombstoned
* Besides the mandatory retained attributes, additional attributes can be 
configured in the schema to be retained when an object is tombstoned
* Using ADSIEDIT.MSC and connecting to the schema partition
* Each attribute has a "searchFlags" property which consists of bits, each with 
a certain meaning
* Enabling the FOURTH bit (bit 3) on the property preserves the attribute in 
the tombstone of the deleted objects
1st bit (bit 0): 2^0=1, 2nd bit (bit 1): 2^1=2, 3rd bit (bit 2): 2^2=4, 4th bit 
(bit 3): 2^3=8
 
More info
How the Data Store Works
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/54094485-71f6-4be8-8ebf-faa45bc5db4c.mspx
 
Creating and Deleting Active Directory Objects
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/creating_and_deleting_active_directory_objects.asp
 
 
 
Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services
 
LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 



From: [EMAIL PROTECTED] on behalf of Steele, Aaron [BSD] - ADM
Sent: Tue 2006-04-18 23:05
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Tombstone attributes


Hi there all,
 
Does anyone here know why Microsoft chose not to include the attributes related 
to user password and sidHistory in the tombstone of an object upon deletion?
Was it a security decision?
I would like to get some input from people here before I go and update my 
schema to enable the restoration of these properties from the tombstone'd 
object.
 
Thanks for your input.
/aaron

Aaron Steele
University of Chicago
Enterprise Systems Administrator
P: 773.834.9099
E: [EMAIL PROTECTED]

 
This email is intended only for the use of the individual or entity to which it 
is addressed and may contain information that is privileged and confidential. 
If the reader of this email message is not the intended recipient, you are 
hereby notified that any dissemination, distribution, or copying of this 
communication is prohibited. If you have received this email in error, please 
notify the sender and destroy/delete all copies of the transmittal. Thank you.


This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.
<>

Re: [ActiveDir] Tombstone attributes

[Tomasz Onyszko]

Steele, Aaron [BSD] - ADM wrote:

Hi there all,
 
Does anyone here know why Microsoft chose not to include the attributes 
related to user password and sidHistory in the tombstone of an object 
upon deletion?

Was it a security decision?
I would like to get some input from people here before I go and update 
my schema to enable the restoration of these properties from the 
tombstone'd object.


Personally I would not like to preserve password attribute on tombstone 
- I don't see a reason for that, and yes, IMO it can be seen as possible 
  security threat. If user is deleted and restoring it requires admin 
action it is just another logical step to reset it's password.


SID History attribute is preserved as with SP1 on Windows 2003 DC. ~Eric 
wrote about it some time ago:

http://blogs.technet.com/efleis/archive/2005/07/12/407648.aspx

and this is OK - when you want to restore object and probably it's group 
membership etc. preserving SID History is good solution.


--
Tomasz Onyszko
http://www.w2k.pl/blog/ - (PL)
http://blogs.dirteam.com/blogs/tomek/ - (EN)
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/

[ActiveDir] Tombstone attributes

[Steele, Aaron [BSD] - ADM]

Hi there 
all,
 
Does anyone here 
know why Microsoft chose not to include the attributes related to user password 
and sidHistory in the tombstone of an object upon deletion?
Was it a security 
decision?
I would like to get 
some input from people here before I go and update my schema to enable the 
restoration of these properties from the tombstone'd object.
 
Thanks for your 
input.
/aaron

Aaron 
SteeleUniversity of ChicagoEnterprise Systems 
AdministratorP: 
773.834.9099E: 
[EMAIL PROTECTED]
 This email is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this email message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is prohibited. If you have received this email in error, please notify the sender and destroy/delete all copies of the transmittal. Thank you.

RE: [ActiveDir] Tombstone value

[Dean Wells]

Right back at ya :O)

--
Dean Wells
MSEtechnology
* Email: [EMAIL PROTECTED]
http://msetechnology.com


-Original Message-
From: joe [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 28, 2005 10:30 AM
To: [EMAIL PROTECTED]
Subject: FW: [ActiveDir] Tombstone value

You are alive!

Happy thanksgiving.

What an odd number to limit it at. I generally expect a binary type limit
value.
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
Sent: Monday, November 28, 2005 11:49 AM
To: Send - AD mailing list
Subject: RE: [ActiveDir] Tombstone value

Coincidental timing, second time I've answered this in as many days -

Max: 999,999,999 days or 2,739,726 years (not including leap years)
Min: 2 days

AFAIK, these thresholds have remained unchanged since 2K RTM.

--
Dean Wells
MSEtechnology
* Email: [EMAIL PROTECTED]
http://msetechnology.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Monday, November 28, 2005 6:10 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone value

I think it is a great idea to increase the TSL. Do you actually think it
would be easier to create a new user and re-ACL when all you have to do is
undelete and set a password instead? 

Not only would I increase the TSL, I would also look at all of the
attributes and figure out which ones I would add to the tombstone set to be
kept. Probably just about every attribute that can be kept. 

The biggest downside to increasing the TSL is how much space is taken up by
the tombstones. If you have the disk or the number of deletions is small
enough to manage, I would crank up the TSL. The max value is a good
question, I haven't seen that discussed previously. Possibly ~Eric will
swing through with an answer, I am sure he could find it in the source
before I could. Possibly if the question has been asked or answered
previously one of the PSS folks will be able to respond. 

The other option, which we have discussed here previously, is to manually
(with code) implement a new staged deletion process where nothing you care
about is actually ever really deleted. It goes into a special container of
YOUR choosing and you initially move the full object there (deleted), then
at some point you scrub some of the attribs, then at another point you scrub
all of the attribs except the mandatories and say sIDHistory and they stay
there "forever". Of course you hit the duplicate name possibilities but then
I am not one for duplicating SAM Names ever, I think they should stay
unique, they shouldn't just be unique for the moment. You wouldn't worry
about duplicate cns as you would rename the objects when they were deleted
to something similar to a deleted object with the GUID in the name. You
would want to lock the container down to some very small group to help
prevent apps from finding the IDs and displaying them. 




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
Simon-Weidner
Sent: Monday, November 28, 2005 1:17 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone value

Hi Susan,

I've seen issues with tombstones sitting around, such as bad written
software who still sees them. The main other reason for finally getting rid
of the tombstones is to free Active Directory space, but that shouldn't be
an issue in a SBS-Domain.
On the other hand I do not see the need in a small environment to even
increase the tombstone lifetime further than 60 days. Increasing it may help
in certain scenarios, such as DCs which are regulary offline for a while
(e.g. those who get to travel the ocean on ships) and in huge enterprises
with a lot of slow unreliable lines in countries where you can't make sure
that a broken line is replaced quickly.

I don't see the requirement to restore objects from backup which are more
than 60 days old. Users wouldn't remember their password anyways, computers
also. Groups may have been changed as well, ...
And the tombstone only helps you when performing a semi-authoritative
restore, such as the recovery manager from quest does. However I do not
believe many companies running SBS are running recovery manager. If you want
to manually restore tombstones you need to fill most of the attributes
manually as well, so it's quite a pain.

Wouldn't it be easier to just create a new account and use the sidwalk
migration suite / subinacl on those few boxes in your SBS domain after the
60 days have expired?

Just my 0,02?

Ulf

|-Original Message-
|From: [EMAIL PROTECTED] [mailto:ActiveDir- 
|[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - 
|SBS Rocks [MVP]
|Sent: Monday, November 28, 2005 3:42 AM
|To: ActiveDir@mail.activedir.org
|Subject: [ActiveDir] Tombstone value
|
|Stupid question from the SBS AD crowd.
|
|Default tombstone value is 60 days on Win2k3 Default tombstone f

RE: [ActiveDir] Tombstone value

[Almeida Pinto, Jorge de]

>>>Max: 999,999,999 days or 2,739,726 years (not including leap years)
 
the network latency must be very very high if even this is not enoughmaybe 
we can undelete some dinosaurs... ;-)
 
Jorge



From: [EMAIL PROTECTED] on behalf of Dean Wells
Sent: Mon 11/28/2005 5:48 PM
To: Send - AD mailing list
Subject: RE: [ActiveDir] Tombstone value



Coincidental timing, second time I've answered this in as many days -

Max: 999,999,999 days or 2,739,726 years (not including leap years)
Min: 2 days

AFAIK, these thresholds have remained unchanged since 2K RTM.

--
Dean Wells
MSEtechnology
* Email: [EMAIL PROTECTED]
http://msetechnology.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Monday, November 28, 2005 6:10 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone value

I think it is a great idea to increase the TSL. Do you actually think it
would be easier to create a new user and re-ACL when all you have to do is
undelete and set a password instead?

Not only would I increase the TSL, I would also look at all of the
attributes and figure out which ones I would add to the tombstone set to be
kept. Probably just about every attribute that can be kept.

The biggest downside to increasing the TSL is how much space is taken up by
the tombstones. If you have the disk or the number of deletions is small
enough to manage, I would crank up the TSL. The max value is a good
question, I haven't seen that discussed previously. Possibly ~Eric will
swing through with an answer, I am sure he could find it in the source
before I could. Possibly if the question has been asked or answered
previously one of the PSS folks will be able to respond.

The other option, which we have discussed here previously, is to manually
(with code) implement a new staged deletion process where nothing you care
about is actually ever really deleted. It goes into a special container of
YOUR choosing and you initially move the full object there (deleted), then
at some point you scrub some of the attribs, then at another point you scrub
all of the attribs except the mandatories and say sIDHistory and they stay
there "forever". Of course you hit the duplicate name possibilities but then
I am not one for duplicating SAM Names ever, I think they should stay
unique, they shouldn't just be unique for the moment. You wouldn't worry
about duplicate cns as you would rename the objects when they were deleted
to something similar to a deleted object with the GUID in the name. You
would want to lock the container down to some very small group to help
prevent apps from finding the IDs and displaying them.




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
Simon-Weidner
Sent: Monday, November 28, 2005 1:17 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone value

Hi Susan,

I've seen issues with tombstones sitting around, such as bad written
software who still sees them. The main other reason for finally getting rid
of the tombstones is to free Active Directory space, but that shouldn't be
an issue in a SBS-Domain.
On the other hand I do not see the need in a small environment to even
increase the tombstone lifetime further than 60 days. Increasing it may help
in certain scenarios, such as DCs which are regulary offline for a while
(e.g. those who get to travel the ocean on ships) and in huge enterprises
with a lot of slow unreliable lines in countries where you can't make sure
that a broken line is replaced quickly.

I don't see the requirement to restore objects from backup which are more
than 60 days old. Users wouldn't remember their password anyways, computers
also. Groups may have been changed as well, ...
And the tombstone only helps you when performing a semi-authoritative
restore, such as the recovery manager from quest does. However I do not
believe many companies running SBS are running recovery manager. If you want
to manually restore tombstones you need to fill most of the attributes
manually as well, so it's quite a pain.

Wouldn't it be easier to just create a new account and use the sidwalk
migration suite / subinacl on those few boxes in your SBS domain after the
60 days have expired?

Just my 0,02?

Ulf

|-Original Message-
|From: [EMAIL PROTECTED] [mailto:ActiveDir-
|[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz -
|SBS Rocks [MVP]
|Sent: Monday, November 28, 2005 3:42 AM
|To: ActiveDir@mail.activedir.org
|Subject: [ActiveDir] Tombstone value
|
|Stupid question from the SBS AD crowd.
|
|Default tombstone value is 60 days on Win2k3 Default tombstone for new
forests
|on 2k3 sp1 is 180
|
|Translation for us SBS boxes... unless we change it it's 60 days if we
|were
an
|RTM SBS box or 180 if we were a SP1 installed box.
|
|For our space down here is there any di

RE: [ActiveDir] Tombstone value

[Rich Milburn]

2,736,726 years, 11 months, and 13 days, given a start date of January
1, on a leap year.

---
Rich Milburn
MCSE, Microsoft MVP - Directory Services
Sr Network Analyst, Field Platform Development
Applebee's International, Inc.
4551 W. 107th St
Overland Park, KS 66207
913-967-2819
--
"I love the smell of red herrings in the morning" - anonymous
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
Sent: Monday, November 28, 2005 10:49 AM
To: Send - AD mailing list
Subject: RE: [ActiveDir] Tombstone value

Coincidental timing, second time I've answered this in as many days -

Max: 999,999,999 days or 2,739,726 years (not including leap years)
Min: 2 days

AFAIK, these thresholds have remained unchanged since 2K RTM.

--
Dean Wells
MSEtechnology
* Email: [EMAIL PROTECTED]
http://msetechnology.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Monday, November 28, 2005 6:10 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone value

I think it is a great idea to increase the TSL. Do you actually think it
would be easier to create a new user and re-ACL when all you have to do
is
undelete and set a password instead? 

Not only would I increase the TSL, I would also look at all of the
attributes and figure out which ones I would add to the tombstone set to
be
kept. Probably just about every attribute that can be kept. 

The biggest downside to increasing the TSL is how much space is taken up
by
the tombstones. If you have the disk or the number of deletions is small
enough to manage, I would crank up the TSL. The max value is a good
question, I haven't seen that discussed previously. Possibly ~Eric will
swing through with an answer, I am sure he could find it in the source
before I could. Possibly if the question has been asked or answered
previously one of the PSS folks will be able to respond. 

The other option, which we have discussed here previously, is to
manually
(with code) implement a new staged deletion process where nothing you
care
about is actually ever really deleted. It goes into a special container
of
YOUR choosing and you initially move the full object there (deleted),
then
at some point you scrub some of the attribs, then at another point you
scrub
all of the attribs except the mandatories and say sIDHistory and they
stay
there "forever". Of course you hit the duplicate name possibilities but
then
I am not one for duplicating SAM Names ever, I think they should stay
unique, they shouldn't just be unique for the moment. You wouldn't worry
about duplicate cns as you would rename the objects when they were
deleted
to something similar to a deleted object with the GUID in the name. You
would want to lock the container down to some very small group to help
prevent apps from finding the IDs and displaying them. 




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
Simon-Weidner
Sent: Monday, November 28, 2005 1:17 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone value

Hi Susan,

I've seen issues with tombstones sitting around, such as bad written
software who still sees them. The main other reason for finally getting
rid
of the tombstones is to free Active Directory space, but that shouldn't
be
an issue in a SBS-Domain.
On the other hand I do not see the need in a small environment to even
increase the tombstone lifetime further than 60 days. Increasing it may
help
in certain scenarios, such as DCs which are regulary offline for a while
(e.g. those who get to travel the ocean on ships) and in huge
enterprises
with a lot of slow unreliable lines in countries where you can't make
sure
that a broken line is replaced quickly.

I don't see the requirement to restore objects from backup which are
more
than 60 days old. Users wouldn't remember their password anyways,
computers
also. Groups may have been changed as well, ...
And the tombstone only helps you when performing a semi-authoritative
restore, such as the recovery manager from quest does. However I do not
believe many companies running SBS are running recovery manager. If you
want
to manually restore tombstones you need to fill most of the attributes
manually as well, so it's quite a pain.

Wouldn't it be easier to just create a new account and use the sidwalk
migration suite / subinacl on those few boxes in your SBS domain after
the
60 days have expired?

Just my 0,02?

Ulf

|-Original Message-
|From: [EMAIL PROTECTED] [mailto:ActiveDir- 
|[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - 
|SBS Rocks [MVP]
|Sent: Monday, November 28, 2005 3:42 AM
|To: ActiveDir@mail.activedir.org
|Subject: [ActiveDir] Tombstone value
|
|Stu

RE: [ActiveDir] Tombstone value

[Grillenmeier, Guido]

hmm, can that Max value be increased in any way? Not sure that's enough
;-)

/Guido 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
Sent: Montag, 28. November 2005 17:49
To: Send - AD mailing list
Subject: RE: [ActiveDir] Tombstone value

Coincidental timing, second time I've answered this in as many days -

Max: 999,999,999 days or 2,739,726 years (not including leap years)
Min: 2 days

AFAIK, these thresholds have remained unchanged since 2K RTM.

--
Dean Wells
MSEtechnology
* Email: [EMAIL PROTECTED]
http://msetechnology.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Monday, November 28, 2005 6:10 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone value

I think it is a great idea to increase the TSL. Do you actually think it
would be easier to create a new user and re-ACL when all you have to do
is
undelete and set a password instead? 

Not only would I increase the TSL, I would also look at all of the
attributes and figure out which ones I would add to the tombstone set to
be
kept. Probably just about every attribute that can be kept. 

The biggest downside to increasing the TSL is how much space is taken up
by
the tombstones. If you have the disk or the number of deletions is small
enough to manage, I would crank up the TSL. The max value is a good
question, I haven't seen that discussed previously. Possibly ~Eric will
swing through with an answer, I am sure he could find it in the source
before I could. Possibly if the question has been asked or answered
previously one of the PSS folks will be able to respond. 

The other option, which we have discussed here previously, is to
manually
(with code) implement a new staged deletion process where nothing you
care
about is actually ever really deleted. It goes into a special container
of
YOUR choosing and you initially move the full object there (deleted),
then
at some point you scrub some of the attribs, then at another point you
scrub
all of the attribs except the mandatories and say sIDHistory and they
stay
there "forever". Of course you hit the duplicate name possibilities but
then
I am not one for duplicating SAM Names ever, I think they should stay
unique, they shouldn't just be unique for the moment. You wouldn't worry
about duplicate cns as you would rename the objects when they were
deleted
to something similar to a deleted object with the GUID in the name. You
would want to lock the container down to some very small group to help
prevent apps from finding the IDs and displaying them. 




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
Simon-Weidner
Sent: Monday, November 28, 2005 1:17 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone value

Hi Susan,

I've seen issues with tombstones sitting around, such as bad written
software who still sees them. The main other reason for finally getting
rid
of the tombstones is to free Active Directory space, but that shouldn't
be
an issue in a SBS-Domain.
On the other hand I do not see the need in a small environment to even
increase the tombstone lifetime further than 60 days. Increasing it may
help
in certain scenarios, such as DCs which are regulary offline for a while
(e.g. those who get to travel the ocean on ships) and in huge
enterprises
with a lot of slow unreliable lines in countries where you can't make
sure
that a broken line is replaced quickly.

I don't see the requirement to restore objects from backup which are
more
than 60 days old. Users wouldn't remember their password anyways,
computers
also. Groups may have been changed as well, ...
And the tombstone only helps you when performing a semi-authoritative
restore, such as the recovery manager from quest does. However I do not
believe many companies running SBS are running recovery manager. If you
want
to manually restore tombstones you need to fill most of the attributes
manually as well, so it's quite a pain.

Wouldn't it be easier to just create a new account and use the sidwalk
migration suite / subinacl on those few boxes in your SBS domain after
the
60 days have expired?

Just my 0,02?

Ulf

|-Original Message-
|From: [EMAIL PROTECTED] [mailto:ActiveDir- 
|[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - 
|SBS Rocks [MVP]
|Sent: Monday, November 28, 2005 3:42 AM
|To: ActiveDir@mail.activedir.org
|Subject: [ActiveDir] Tombstone value
|
|Stupid question from the SBS AD crowd.
|
|Default tombstone value is 60 days on Win2k3 Default tombstone for new
forests
|on 2k3 sp1 is 180
|
|Translation for us SBS boxes... unless we change it it's 60 days if we 
|were
an
|RTM SBS box or 180 if we were a SP1 installed box.
|
|For our space down here is there any disadvantage to increasing 
|that
value
|to something even longer?  Is there a max value

RE: [ActiveDir] Tombstone value

[Grillenmeier, Guido]

to answer one of your main questions: yes, when you've installed the box
with RTM it's 60 days and if the box was installed using the SP1
version, you'll be at 180 days. 

The best way to find out what you have is just to check the
tombstoneLifetime value in CN=Directory Service, CN=Windows
NT,CN=Services,CN=Configuration,DC=
=> if this value is NOT SET, then it's 60 days (default from
Win2000/2003)

With new SP1 forests, this value is no longer "hidden", so that you'll
see the 180 days displayed.  If your forest is 2003 SP1 and the value
doesn't show, then it's 60 days as you'll have created the forest prior
to applying SP1.


Is there an advantage to increase it?  Only if you intend to recover
really old objects, which I wouldn't recommend anyways. Especially in
SBS world, you'll likely not come accross a necessity to recover objects
that have been deleted for longer than a week or two...  The value was
only increased for enterprises with highly distributed AD DCs where for
various reasons (bad network, turned off DC etc.), 60 days proved not to
be long enough to inform all DCs in the forest that a deletion occured.

/Guido

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley,
CPA aka Ebitz - SBS Rocks [MVP]
Sent: Montag, 28. November 2005 03:42
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Tombstone value

Stupid question from the SBS AD crowd.

Default tombstone value is 60 days on Win2k3
Default tombstone for new forests on 2k3 sp1 is 180

Translation for us SBS boxes... unless we change it it's 60 days if we 
were an RTM SBS box or 180 if we were a SP1 installed box.

For our space down here is there any disadvantage to increasing that

value to something even longer?  Is there a max value?

We only have one PDC and possibly an additional domain controller.  If 
we have a pretty static-y network is there a disadvantage to 
increasing this value to aid in disaster recovery of the system state 
backup?
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/

RE: [ActiveDir] Tombstone value

[Dean Wells]

Coincidental timing, second time I've answered this in as many days -

Max: 999,999,999 days or 2,739,726 years (not including leap years)
Min: 2 days

AFAIK, these thresholds have remained unchanged since 2K RTM.

--
Dean Wells
MSEtechnology
* Email: [EMAIL PROTECTED]
http://msetechnology.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Monday, November 28, 2005 6:10 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone value

I think it is a great idea to increase the TSL. Do you actually think it
would be easier to create a new user and re-ACL when all you have to do is
undelete and set a password instead? 

Not only would I increase the TSL, I would also look at all of the
attributes and figure out which ones I would add to the tombstone set to be
kept. Probably just about every attribute that can be kept. 

The biggest downside to increasing the TSL is how much space is taken up by
the tombstones. If you have the disk or the number of deletions is small
enough to manage, I would crank up the TSL. The max value is a good
question, I haven't seen that discussed previously. Possibly ~Eric will
swing through with an answer, I am sure he could find it in the source
before I could. Possibly if the question has been asked or answered
previously one of the PSS folks will be able to respond. 

The other option, which we have discussed here previously, is to manually
(with code) implement a new staged deletion process where nothing you care
about is actually ever really deleted. It goes into a special container of
YOUR choosing and you initially move the full object there (deleted), then
at some point you scrub some of the attribs, then at another point you scrub
all of the attribs except the mandatories and say sIDHistory and they stay
there "forever". Of course you hit the duplicate name possibilities but then
I am not one for duplicating SAM Names ever, I think they should stay
unique, they shouldn't just be unique for the moment. You wouldn't worry
about duplicate cns as you would rename the objects when they were deleted
to something similar to a deleted object with the GUID in the name. You
would want to lock the container down to some very small group to help
prevent apps from finding the IDs and displaying them. 




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
Simon-Weidner
Sent: Monday, November 28, 2005 1:17 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone value

Hi Susan,

I've seen issues with tombstones sitting around, such as bad written
software who still sees them. The main other reason for finally getting rid
of the tombstones is to free Active Directory space, but that shouldn't be
an issue in a SBS-Domain.
On the other hand I do not see the need in a small environment to even
increase the tombstone lifetime further than 60 days. Increasing it may help
in certain scenarios, such as DCs which are regulary offline for a while
(e.g. those who get to travel the ocean on ships) and in huge enterprises
with a lot of slow unreliable lines in countries where you can't make sure
that a broken line is replaced quickly.

I don't see the requirement to restore objects from backup which are more
than 60 days old. Users wouldn't remember their password anyways, computers
also. Groups may have been changed as well, ...
And the tombstone only helps you when performing a semi-authoritative
restore, such as the recovery manager from quest does. However I do not
believe many companies running SBS are running recovery manager. If you want
to manually restore tombstones you need to fill most of the attributes
manually as well, so it's quite a pain.

Wouldn't it be easier to just create a new account and use the sidwalk
migration suite / subinacl on those few boxes in your SBS domain after the
60 days have expired?

Just my 0,02?

Ulf

|-Original Message-
|From: [EMAIL PROTECTED] [mailto:ActiveDir- 
|[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - 
|SBS Rocks [MVP]
|Sent: Monday, November 28, 2005 3:42 AM
|To: ActiveDir@mail.activedir.org
|Subject: [ActiveDir] Tombstone value
|
|Stupid question from the SBS AD crowd.
|
|Default tombstone value is 60 days on Win2k3 Default tombstone for new
forests
|on 2k3 sp1 is 180
|
|Translation for us SBS boxes... unless we change it it's 60 days if we 
|were
an
|RTM SBS box or 180 if we were a SP1 installed box.
|
|For our space down here is there any disadvantage to increasing 
|that
value
|to something even longer?  Is there a max value?
|
|We only have one PDC and possibly an additional domain controller.  If 
|we
have
|a pretty static-y network is there a disadvantage to increasing 
|this
value
|to aid in disaster recovery of the system state backup?
|List info   : http://www.activedir.org/List.aspx
|List FAQ

RE: [ActiveDir] Tombstone value

[joe]

I think it is a great idea to increase the TSL. Do you actually think it
would be easier to create a new user and re-ACL when all you have to do is
undelete and set a password instead? 

Not only would I increase the TSL, I would also look at all of the
attributes and figure out which ones I would add to the tombstone set to be
kept. Probably just about every attribute that can be kept. 

The biggest downside to increasing the TSL is how much space is taken up by
the tombstones. If you have the disk or the number of deletions is small
enough to manage, I would crank up the TSL. The max value is a good
question, I haven't seen that discussed previously. Possibly ~Eric will
swing through with an answer, I am sure he could find it in the source
before I could. Possibly if the question has been asked or answered
previously one of the PSS folks will be able to respond. 

The other option, which we have discussed here previously, is to manually
(with code) implement a new staged deletion process where nothing you care
about is actually ever really deleted. It goes into a special container of
YOUR choosing and you initially move the full object there (deleted), then
at some point you scrub some of the attribs, then at another point you scrub
all of the attribs except the mandatories and say sIDHistory and they stay
there "forever". Of course you hit the duplicate name possibilities but then
I am not one for duplicating SAM Names ever, I think they should stay
unique, they shouldn't just be unique for the moment. You wouldn't worry
about duplicate cns as you would rename the objects when they were deleted
to something similar to a deleted object with the GUID in the name. You
would want to lock the container down to some very small group to help
prevent apps from finding the IDs and displaying them. 




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
Simon-Weidner
Sent: Monday, November 28, 2005 1:17 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone value

Hi Susan,

I've seen issues with tombstones sitting around, such as bad written
software who still sees them. The main other reason for finally getting rid
of the tombstones is to free Active Directory space, but that shouldn't be
an issue in a SBS-Domain.
On the other hand I do not see the need in a small environment to even
increase the tombstone lifetime further than 60 days. Increasing it may help
in certain scenarios, such as DCs which are regulary offline for a while
(e.g. those who get to travel the ocean on ships) and in huge enterprises
with a lot of slow unreliable lines in countries where you can't make sure
that a broken line is replaced quickly.

I don't see the requirement to restore objects from backup which are more
than 60 days old. Users wouldn't remember their password anyways, computers
also. Groups may have been changed as well, ...
And the tombstone only helps you when performing a semi-authoritative
restore, such as the recovery manager from quest does. However I do not
believe many companies running SBS are running recovery manager. If you want
to manually restore tombstones you need to fill most of the attributes
manually as well, so it's quite a pain.

Wouldn't it be easier to just create a new account and use the sidwalk
migration suite / subinacl on those few boxes in your SBS domain after the
60 days have expired?

Just my 0,02?

Ulf

|-Original Message-
|From: [EMAIL PROTECTED] [mailto:ActiveDir- 
|[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - 
|SBS Rocks [MVP]
|Sent: Monday, November 28, 2005 3:42 AM
|To: ActiveDir@mail.activedir.org
|Subject: [ActiveDir] Tombstone value
|
|Stupid question from the SBS AD crowd.
|
|Default tombstone value is 60 days on Win2k3 Default tombstone for new
forests
|on 2k3 sp1 is 180
|
|Translation for us SBS boxes... unless we change it it's 60 days if we 
|were
an
|RTM SBS box or 180 if we were a SP1 installed box.
|
|For our space down here is there any disadvantage to increasing 
|that
value
|to something even longer?  Is there a max value?
|
|We only have one PDC and possibly an additional domain controller.  If 
|we
have
|a pretty static-y network is there a disadvantage to increasing 
|this
value
|to aid in disaster recovery of the system state backup?
|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/ivedir.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/

RE: [ActiveDir] Tombstone value

[Ulf B. Simon-Weidner]

Hi Susan,

I've seen issues with tombstones sitting around, such as bad written
software who still sees them. The main other reason for finally getting rid
of the tombstones is to free Active Directory space, but that shouldn't be
an issue in a SBS-Domain.
On the other hand I do not see the need in a small environment to even
increase the tombstone lifetime further than 60 days. Increasing it may help
in certain scenarios, such as DCs which are regulary offline for a while
(e.g. those who get to travel the ocean on ships) and in huge enterprises
with a lot of slow unreliable lines in countries where you can't make sure
that a broken line is replaced quickly.

I don't see the requirement to restore objects from backup which are more
than 60 days old. Users wouldn't remember their password anyways, computers
also. Groups may have been changed as well, ...
And the tombstone only helps you when performing a semi-authoritative
restore, such as the recovery manager from quest does. However I do not
believe many companies running SBS are running recovery manager. If you want
to manually restore tombstones you need to fill most of the attributes
manually as well, so it's quite a pain.

Wouldn't it be easier to just create a new account and use the sidwalk
migration suite / subinacl on those few boxes in your SBS domain after the
60 days have expired?

Just my 0,02?

Ulf

|-Original Message-
|From: [EMAIL PROTECTED] [mailto:ActiveDir-
|[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS
|Rocks [MVP]
|Sent: Monday, November 28, 2005 3:42 AM
|To: ActiveDir@mail.activedir.org
|Subject: [ActiveDir] Tombstone value
|
|Stupid question from the SBS AD crowd.
|
|Default tombstone value is 60 days on Win2k3 Default tombstone for new
forests
|on 2k3 sp1 is 180
|
|Translation for us SBS boxes... unless we change it it's 60 days if we were
an
|RTM SBS box or 180 if we were a SP1 installed box.
|
|For our space down here is there any disadvantage to increasing that
value
|to something even longer?  Is there a max value?
|
|We only have one PDC and possibly an additional domain controller.  If we
have
|a pretty static-y network is there a disadvantage to increasing this
value
|to aid in disaster recovery of the system state backup?
|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/ivedir.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/

[ActiveDir] Tombstone value

[Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]]

Stupid question from the SBS AD crowd.

Default tombstone value is 60 days on Win2k3
Default tombstone for new forests on 2k3 sp1 is 180

Translation for us SBS boxes... unless we change it it's 60 days if we 
were an RTM SBS box or 180 if we were a SP1 installed box.


For our space down here is there any disadvantage to increasing that 
value to something even longer?  Is there a max value?


We only have one PDC and possibly an additional domain controller.  If 
we have a pretty static-y network is there a disadvantage to 
increasing this value to aid in disaster recovery of the system state 
backup?

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/

RE: [ActiveDir] Tombstone Interval

[David Adner]

Title: Tombstone Interval



Another tidbit... DNS servers run through an internal 
process every 2am to identify and delete "stale" dnsTombstone records.  
It's at that point they begin the traditional AD object deletion process.  
The 2am interval is not configurable.

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Dean 
  WellsSent: Wednesday, September 14, 2005 10:41 AMTo: 
  Send - AD mailing listSubject: RE: [ActiveDir] Tombstone 
  Interval
  
  Since it appears most of your questions have already been answered, 
  I'll fill in only those that I see remain; the default value is 604800 seconds 
  or 7 days (note that the default value provided by TechNet is inaccurate) 
  -
   
  dnscmd light.msetechnology.local /info 
  /dstombstoneinterval
   
  The 
  specifics of the behavior have already been provided but not the "why?"; when 
  DNS records are maintained within AD, they are frequently registered, 
  re-registered and de-registered.  Without DNS' "dstombstoneinterval" 
  mechanism, the de-registration of these records would have otherwise 
  triggered a run-of-the-mill AD tombstoning behavior thereby eating 
  through undesirably large quantities of DIT row space since re-registration 
  would have created a new record and not reanimated the existing tombstoned 
  record.  This is particularly true to say of Windows 2000 since the 
  records were maintained within the domain NC and, as a result, replicated as 
  empty shells to the GC whose row space (in the most extreme of circumstances) 
  could become dangerously low due to the net total of all DNS registrations 
  across all domains using integrated zones within the entire forest (unlikely I 
  agree ... but you can't develop a product on the premise of "n, that'll 
  never happen!" ... at least I live in hope).  As an aside, it's worth 
  noting that app. NCs do not under any circumstance replicate their 
  content through the partial replication mechanism to a GC and, as such, a 
  Windows 2003 directory (when configured accordingly) is less susceptible to 
  this anyway.
  --Dean 
  WellsMSEtechnology* Email: dwells@msetechnology.comhttp://msetechnology.com
   
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, 
  Jorge deSent: Wednesday, September 14, 2005 5:58 AMTo: 
  ActiveDir@mail.activedir.orgSubject: [ActiveDir] Tombstone 
  Interval
  
  Hi, 
  The first I 
  understand but I do not understand the second. Does anyone know what the 
  second does? 
  Thanks 
  Jorge 
  (1) configured per 
  forest in AD The tombstone lifetime 
  value in an Active Directory forest defines the default number of days that a 
  domain controller preserves knowledge of deleted objects. This value also 
  defines the useful life of a system state backup that is used for disaster 
  recovery or installation from backup media. Active Directory protects itself 
  from restoring data that is older than the tombstone lifetime by disallowing 
  the restore. 
  (2) configured per 
  DNS server in the registry manually or through DNSCMD /dstombstoneinterval[ 1-30] 
  Amount of time in seconds to keep 
  tombstoned records in Active Directory alive. 
  Met 
  vriendelijke groet / Kind regards, 
  Jorge de Almeida Pinto 
  Infrastructure Consultant __ 
   
  LogicaCMG Nederland B.V. (BU SD/AT) Division 
  Industry, Distribution and Transport (ID&T) Kennedyplein 
  248, 5611 ZT, Eindhoven .   Postbus 7089     5605 JB 
  Eindhoven (   Tel 
      : +31-(0)40-29.57.777 
  2   Fax : 
  +31-(0)40-29.57.709 (   Mobile  : 
  +31-(0)6-26.26.62.80 
  *   E-mail  : 
  [EMAIL PROTECTED]
  "   <http://www.logicacmg.com/> - 
  Solutions that matter - 
  This e-mail and any 
  attachment is for authorised use by the intended recipient(s) only. It may 
  contain proprietary material, confidential information and/or be subject to 
  legal privilege. It should not be copied, disclosed to, retained or used by, 
  any other party. If you are not an intended recipient then please promptly 
  delete this e-mail and any attachment and all copies and inform the sender. 
  Thank you.

RE: [ActiveDir] Tombstone Interval

[Dean Wells]

Title: Tombstone Interval



Since 
it appears most of your questions have already been answered, I'll fill in only 
those that I see remain; the default value is 604800 seconds or 7 days (note 
that the default value provided by TechNet is inaccurate) -
 
dnscmd 
light.msetechnology.local /info /dstombstoneinterval
 
The 
specifics of the behavior have already been provided but not the "why?"; when 
DNS records are maintained within AD, they are frequently registered, 
re-registered and de-registered.  Without DNS' "dstombstoneinterval" 
mechanism, the de-registration of these records would have otherwise 
triggered a run-of-the-mill AD tombstoning behavior thereby eating through 
undesirably large quantities of DIT row space since re-registration would have 
created a new record and not reanimated the existing tombstoned 
record.  This is particularly true to say of Windows 2000 since the 
records were maintained within the domain NC and, as a result, replicated as 
empty shells to the GC whose row space (in the most extreme of circumstances) 
could become dangerously low due to the net total of all DNS registrations 
across all domains using integrated zones within the entire forest (unlikely I 
agree ... but you can't develop a product on the premise of "n, that'll 
never happen!" ... at least I live in hope).  As an aside, it's worth 
noting that app. NCs do not under any circumstance replicate their content 
through the partial replication mechanism to a GC and, as such, a Windows 2003 
directory (when configured accordingly) is less susceptible to this 
anyway.
--Dean WellsMSEtechnology* Email: dwells@msetechnology.comhttp://msetechnology.com
 


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, 
Jorge deSent: Wednesday, September 14, 2005 5:58 AMTo: 
ActiveDir@mail.activedir.orgSubject: [ActiveDir] Tombstone 
Interval

Hi, 
The first I understand 
but I do not understand the second. Does anyone know what the second 
does? 
Thanks 
Jorge 
(1) configured per 
forest in AD The tombstone lifetime 
value in an Active Directory forest defines the default number of days that a 
domain controller preserves knowledge of deleted objects. This value also 
defines the useful life of a system state backup that is used for disaster 
recovery or installation from backup media. Active Directory protects itself 
from restoring data that is older than the tombstone lifetime by disallowing the 
restore. 
(2) configured per DNS 
server in the registry manually or through DNSCMD /dstombstoneinterval[ 1-30] 
Amount of time in seconds to keep 
tombstoned records in Active Directory alive. 
Met 
vriendelijke groet / Kind regards, 
Jorge de Almeida Pinto 
Infrastructure Consultant __ 
 
LogicaCMG Nederland B.V. (BU SD/AT) Division 
Industry, Distribution and Transport (ID&T) Kennedyplein 248, 
5611 ZT, Eindhoven .   Postbus 7089     5605 JB Eindhoven 
(   Tel 
    : +31-(0)40-29.57.777 
2   Fax : 
+31-(0)40-29.57.709 (   Mobile  : 
+31-(0)6-26.26.62.80 
*   E-mail  : 
[EMAIL PROTECTED]
"   <http://www.logicacmg.com/> - Solutions that matter 
- 
This e-mail and any 
attachment is for authorised use by the intended recipient(s) only. It may 
contain proprietary material, confidential information and/or be subject to 
legal privilege. It should not be copied, disclosed to, retained or used by, any 
other party. If you are not an intended recipient then please promptly delete 
this e-mail and any attachment and all copies and inform the sender. Thank 
you.

RE: [ActiveDir] Tombstone Interval

[Almeida Pinto, Jorge de]

Title: Tombstone Interval



That' s what I thought also... 
Looking at the Windows 2003 Branch Office Guide scenario, it is increased to 15 
days (=1296000 seconds)..
 
You can see this value as the 
max. timeframe a certain computer (especially DCs) will be offline. In the 
Windows 2003 Branch Office Guide scenario it is because the branch DCs are 
staged at the hub location and then shipped to the branch 
office
 
Cheers
Jorge


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
[EMAIL PROTECTED]Sent: Wednesday, September 14, 2005 
16:24To: ActiveDir@mail.activedir.orgSubject: RE: 
[ActiveDir] Tombstone Interval


I’m still 
confused.  What’s the point of dstombstoneinterval if you can only raise 
the value to 30 seconds?
 

:m:dsm:cci:mvp 




From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Almeida Pinto, Jorge 
deSent: Wednesday, September 
14, 2005 7:08 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Tombstone 
Interval
 
Scavenging 
and Aging are processes that age and cleanup (delete) unused DNS resource 
records. After a record is deleted it is tombstoned and kept in AD for the same 
time as the AD tombstone lifetime (60 days or 180 days in fresh AD SP1 
installs). However there is something else "in between" for DNS 
records.
 
I got 
the second from the Windows 2003 Branch Office Guide. 


Extending the 
DNS Tombstone 
Lifetime
You must extend the 
tombstone lifetime for DNS resource records stored in the directory. This 
prevents resource records from being removed from the directory while a new 
branch office domain controller is offline and being shipped to its new 
location.

 

First I 
did not understand it, but after testing it on a DC I found the following and it 
is clear now what it does

OK, 
here goes

 

A DNS 
object is just like any other AD object... There is a slight difference 
though

When a 
DNS object is deleted it is NOT AD tombstoned right away like other objects and 
it is also not "moved" to the Deleted Objects container of the naming context it 
resides it. Unlike any other objects it is invisible in the DNS GUI and it 
remains in the location for the DNS Tombstone Lifetime (don't know what the 
default is). When it is DNS tombstoned the attribute dNSTombstoned is set to 
TRUE. After the DNS Tombstone Lifetime it is AD tombstoned and "moved" to the 
Deleted Objects container of the naming context it resides 
it.

If the 
DNS object is "recreated" within the DNS Tombstone Lifetime the old DNS 
tombstoned object is revived (same GUID) as the attribute dNSTombstoned is set 
to FALSE .

 

If 
someone knows the default, please let me 
know.

 
Cheers,
Jorge



From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of 
[EMAIL PROTECTED]Sent: Wednesday, September 14, 2005 
12:08To: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Tombstone 
Interval

Would the latter refer 
to scavenged objects?

 

neil

 
 
--- 
Neil 
Ruston Nomura International 
Plc Tel: 020 7521 
3481 [EMAIL PROTECTED] 


   
  -Original 
  Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]On Behalf Of Almeida Pinto, Jorge 
  deSent: 14 September 2005 
  10:58To: 
  ActiveDir@mail.activedir.orgSubject: [ActiveDir] Tombstone 
  Interval
  Hi, 
  
  The 
  first I understand but I do not understand the second. Does anyone know what 
  the second does? 
  Thanks 
  
  Jorge 
  
  (1) 
  configured per forest in AD The tombstone lifetime value in 
  an Active Directory forest defines the default number of days that a domain 
  controller preserves knowledge of deleted objects. This value also defines the 
  useful life of a system state backup that is used for disaster recovery or 
  installation from backup media. Active Directory protects itself from 
  restoring data that is older than the tombstone lifetime by disallowing the 
  restore. 
  (2) 
  configured per DNS server in the registry manually or through 
  DNSCMD /dstombstoneinterval[ 1-30] Amount of time in seconds to 
  keep tombstoned records in Active Directory alive. 
   
  Met 
  vriendelijke groet / Kind regards, 
  
  Jorge 
  de Almeida Pinto Infrastructure 
  Consultant __ 
  
  LogicaCMG 
  Nederland B.V. (BU SD/AT) Division 
  Industry, Distribution and Transport (ID&T) Kennedyplein 
  248, 5611 ZT, Eindhoven .   Postbus 
  7089     5605 
  JB Eindhoven (   
  Tel 
      : +31-(0)40-29.57.777 
  2   
  Fax 
  : +31-(0)40-29.57.709 (   
  Mobile  
  : +31-(0)6-26.26.62.80 
  *   
  E-mail  
  : [EMAIL PROTECTED]
  "   
  <http://www.logicacmg.com/> 
  - 
  Solutions that matter - 
   
  This e-mail and any 
  attachment is for authorised use by the intended recipient(s) only. It may 
  contain proprietary material, confidential information and/or be subject to 
  legal privilege. I

RE: [ActiveDir] Tombstone Interval

[Marcus.Oh]

Title: Tombstone Interval








I’m still confused.  What’s
the point of dstombstoneinterval if you can only raise the value to 30 seconds?

 



:m:dsm:cci:mvp 











From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de
Sent: Wednesday, September 14,
2005 7:08 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone Interval



 

Scavenging
and Aging are processes that age and cleanup (delete) unused DNS resource
records. After a record is deleted it is tombstoned and kept in AD for the same
time as the AD tombstone lifetime (60 days or 180 days in fresh AD SP1 installs).
However there is something else "in between" for DNS records.

 

I got the
second from the Windows 2003 Branch Office Guide. 



Extending the DNS Tombstone Lifetime



You must extend the tombstone lifetime for DNS
resource records stored in the directory. This prevents resource records from
being removed from the directory while a new branch office domain controller is
offline and being shipped to its new location.



 





First I
did not understand it, but after testing it on a DC I found the following and
it is clear now what it does





OK, here
goes





 





A DNS
object is just like any other AD object... There is a slight difference though





When a
DNS object is deleted it is NOT AD tombstoned right away like other objects and
it is also not "moved" to the Deleted Objects container of the naming
context it resides it. Unlike any other objects it is invisible in the DNS GUI
and it remains in the location for the DNS Tombstone Lifetime (don't know what
the default is). When it is DNS tombstoned the attribute dNSTombstoned is set
to TRUE. After the DNS Tombstone Lifetime it is AD tombstoned and
"moved" to the Deleted Objects container of the naming context it
resides it.





If the
DNS object is "recreated" within the DNS Tombstone Lifetime the old
DNS tombstoned object is revived (same GUID) as the attribute dNSTombstoned is
set to FALSE .





 





If
someone knows the default, please let me know.





 




Cheers,

Jorge







From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, September 14,
2005 12:08
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Tombstone Interval



Would the latter refer to scavenged
objects?





 





neil





 



 

--- 
Neil Ruston 
Nomura International Plc 
Tel: 020 7521 3481 
[EMAIL PROTECTED] 



 

-Original Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Almeida Pinto, Jorge de
Sent: 14 September 2005 10:58
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Tombstone Interval

Hi,


The first I understand but
I do not understand the second. Does anyone know what the second does?


Thanks 

Jorge 

(1) configured per forest
in AD 
The tombstone lifetime value in an Active Directory forest defines the default
number of days that a domain controller preserves knowledge of deleted objects.
This value also defines the useful life of a system state backup that is used
for disaster recovery or installation from backup media. Active Directory
protects itself from restoring data that is older than the tombstone lifetime
by disallowing the restore. 

(2) configured per DNS
server in the registry manually or through DNSCMD 
/dstombstoneinterval[ 1-30] 
Amount of time in seconds to keep tombstoned records in Active Directory alive.


 

Met
vriendelijke groet / Kind regards, 

Jorge de Almeida Pinto 
Infrastructure Consultant 
__ 



LogicaCMG Nederland B.V. (BU SD/AT) 
Division Industry,
Distribution and Transport (ID&T) 
Kennedyplein
248, 5611 ZT, Eindhoven 
.  
Postbus
7089 
    5605 JB Eindhoven 
(  
Tel
    : +31-(0)40-29.57.777 
2  
Fax
: +31-(0)40-29.57.709 
(  
Mobile  : +31-(0)6-26.26.62.80


*  
E-mail  :
[EMAIL PROTECTED]

"  
<http://www.logicacmg.com/> - Solutions that matter -


 

This e-mail and any attachment is for
authorised use by the intended recipient(s) only. It may contain proprietary
material, confidential information and/or be subject to legal privilege. It
should not be copied, disclosed to, retained or used by, any other party. If
you are not an intended recipient then please promptly delete this e-mail and
any attachment and all copies and inform the sender. Thank you.





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

RE: [ActiveDir] Tombstone Interval

[Almeida Pinto, Jorge de]

Title: Tombstone Interval



Scavenging and Aging are 
processes that age and cleanup (delete) unused DNS resource records. After a 
record is deleted it is tombstoned and kept in AD for the same time as the AD 
tombstone lifetime (60 days or 180 days in fresh AD SP1 installs). However there 
is something else "in between" for DNS records.
 
I got the second from the 
Windows 2003 Branch Office Guide. 

Extending the DNS 
Tombstone 
Lifetime
You must extend the tombstone lifetime for DNS resource records stored in 
the directory. This prevents resource records from being removed from the 
directory while a new branch office domain controller is offline and being 
shipped to its new location.
 
First I 
did not understand it, but after testing 
it on a DC I found the following and it is clear 
now what it does
OK, here goes
 
A DNS object is just like any other AD object... There is a 
slight difference though
When a DNS object is deleted it is NOT AD tombstoned right 
away like other objects and it is also not "moved" to the Deleted Objects 
container of the naming context it resides it. Unlike any other objects it is 
invisible in the DNS GUI and it remains in the location for the DNS Tombstone 
Lifetime (don't know what the default is). When it is DNS tombstoned the 
attribute dNSTombstoned is set to TRUE. After the DNS Tombstone Lifetime it is 
AD tombstoned and "moved" to the Deleted Objects container of the naming context 
it resides it.
If the DNS object is "recreated" within the DNS Tombstone 
Lifetime the old DNS tombstoned object is revived (same GUID) as the attribute 
dNSTombstoned is set to FALSE .
 
If someone knows the default, please let me 
know.
 
Cheers,
Jorge


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
[EMAIL PROTECTED]Sent: Wednesday, September 14, 2005 
12:08To: ActiveDir@mail.activedir.orgSubject: RE: 
[ActiveDir] Tombstone Interval

Would 
the latter refer to scavenged objects?
 
neil
 
--- Neil Ruston Nomura International Plc Tel: 020 7521 3481 [EMAIL PROTECTED] 

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]On Behalf Of Almeida Pinto, 
  Jorge deSent: 14 September 2005 10:58To: 
  ActiveDir@mail.activedir.orgSubject: [ActiveDir] Tombstone 
  Interval
  Hi, 
  The first I 
  understand but I do not understand the second. Does anyone know what the 
  second does? 
  Thanks 
  Jorge 
  (1) configured per 
  forest in AD The tombstone lifetime 
  value in an Active Directory forest defines the default number of days that a 
  domain controller preserves knowledge of deleted objects. This value also 
  defines the useful life of a system state backup that is used for disaster 
  recovery or installation from backup media. Active Directory protects itself 
  from restoring data that is older than the tombstone lifetime by disallowing 
  the restore. 
  (2) configured per 
  DNS server in the registry manually or through DNSCMD /dstombstoneinterval[ 1-30] 
  Amount of time in seconds to keep 
  tombstoned records in Active Directory alive. 
  Met 
  vriendelijke groet / Kind regards, 
  Jorge de Almeida Pinto 
  Infrastructure Consultant __ 
   
  LogicaCMG Nederland B.V. (BU SD/AT) Division 
  Industry, Distribution and Transport (ID&T) Kennedyplein 
  248, 5611 ZT, Eindhoven .   Postbus 7089     5605 JB 
  Eindhoven (   Tel 
      : +31-(0)40-29.57.777 
  2   Fax : 
  +31-(0)40-29.57.709 (   Mobile  : 
  +31-(0)6-26.26.62.80 
  *   E-mail  : 
  [EMAIL PROTECTED]
  "   <http://www.logicacmg.com/> - 
  Solutions that matter - 
  This e-mail and any 
  attachment is for authorised use by the intended recipient(s) only. It may 
  contain proprietary material, confidential information and/or be subject to 
  legal privilege. It should not be copied, disclosed to, retained or used by, 
  any other party. If you are not an intended recipient then please promptly 
  delete this e-mail and any attachment and all copies and inform the sender. 
  Thank you.
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 t

RE: [ActiveDir] Tombstone Interval

[Katherine Coombs]

Title: Tombstone Interval



Hi Jorge,
 
It's to do with DNS (resource?) records, not AD tombstoned 
objects.  As per http://msdn.microsoft.com/library/default.asp?url="">:
 

DsTombstoneInterval 
Data type: uint32Lifetime of tombstoned records in Directory 
Service integrated zones, expressed in seconds.
 
HTH,
Katherine
 
PS.  Sorry - in a rush.  Hope this email doesn't seem 
abrupt!


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, 
Jorge deSent: 14 September 2005 17:58To: 
ActiveDir@mail.activedir.orgSubject: [ActiveDir] Tombstone 
Interval

Hi, 
The first I understand 
but I do not understand the second. Does anyone know what the second 
does? 
Thanks 
Jorge 
(1) configured per 
forest in AD The tombstone lifetime 
value in an Active Directory forest defines the default number of days that a 
domain controller preserves knowledge of deleted objects. This value also 
defines the useful life of a system state backup that is used for disaster 
recovery or installation from backup media. Active Directory protects itself 
from restoring data that is older than the tombstone lifetime by disallowing the 
restore. 
(2) configured per DNS 
server in the registry manually or through DNSCMD /dstombstoneinterval[ 1-30] 
Amount of time in seconds to keep 
tombstoned records in Active Directory alive. 
Met 
vriendelijke groet / Kind regards, 
Jorge de Almeida Pinto 
Infrastructure Consultant __ 
 
LogicaCMG Nederland B.V. (BU SD/AT) Division 
Industry, Distribution and Transport (ID&T) Kennedyplein 248, 
5611 ZT, Eindhoven .   Postbus 7089     5605 JB Eindhoven 
(   Tel 
    : +31-(0)40-29.57.777 
2   Fax : 
+31-(0)40-29.57.709 (   Mobile  : 
+31-(0)6-26.26.62.80 
*   E-mail  : 
[EMAIL PROTECTED]
"   <http://www.logicacmg.com/> - Solutions that matter 
- 
This e-mail and any 
attachment is for authorised use by the intended recipient(s) only. It may 
contain proprietary material, confidential information and/or be subject to 
legal privilege. It should not be copied, disclosed to, retained or used by, any 
other party. If you are not an intended recipient then please promptly delete 
this e-mail and any attachment and all copies and inform the sender. Thank 
you.

RE: [ActiveDir] Tombstone Interval

[neil.ruston]

Title: Tombstone Interval



Would 
the latter refer to scavenged objects?
 
neil
 
--- Neil Ruston Nomura International Plc Tel: 020 7521 3481 [EMAIL PROTECTED] 

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]On Behalf Of Almeida Pinto, 
  Jorge deSent: 14 September 2005 10:58To: 
  ActiveDir@mail.activedir.orgSubject: [ActiveDir] Tombstone 
  Interval
  Hi, 
  The first I 
  understand but I do not understand the second. Does anyone know what the 
  second does? 
  Thanks 
  Jorge 
  (1) configured per 
  forest in AD The tombstone lifetime 
  value in an Active Directory forest defines the default number of days that a 
  domain controller preserves knowledge of deleted objects. This value also 
  defines the useful life of a system state backup that is used for disaster 
  recovery or installation from backup media. Active Directory protects itself 
  from restoring data that is older than the tombstone lifetime by disallowing 
  the restore. 
  (2) configured per 
  DNS server in the registry manually or through DNSCMD /dstombstoneinterval[ 1-30] 
  Amount of time in seconds to keep 
  tombstoned records in Active Directory alive. 
  Met 
  vriendelijke groet / Kind regards, 
  Jorge de Almeida Pinto 
  Infrastructure Consultant __ 
   
  LogicaCMG Nederland B.V. (BU SD/AT) Division 
  Industry, Distribution and Transport (ID&T) Kennedyplein 
  248, 5611 ZT, Eindhoven .   Postbus 7089     5605 JB 
  Eindhoven (   Tel 
      : +31-(0)40-29.57.777 
  2   Fax : 
  +31-(0)40-29.57.709 (   Mobile  : 
  +31-(0)6-26.26.62.80 
  *   E-mail  : 
  [EMAIL PROTECTED]
  "   <http://www.logicacmg.com/> - 
  Solutions that matter - 
  This e-mail and any 
  attachment is for authorised use by the intended recipient(s) only. It may 
  contain proprietary material, confidential information and/or be subject to 
  legal privilege. It should not be copied, disclosed to, retained or used by, 
  any other party. If you are not an intended recipient then please promptly 
  delete this e-mail and any attachment and all copies and inform the sender. 
  Thank you.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.

[ActiveDir] Tombstone Interval

[Almeida Pinto, Jorge de]

Title: Tombstone Interval






Hi,


The first I understand but I do not understand the second. Does anyone know what the second does?


Thanks


Jorge


(1) configured per forest in AD

The tombstone lifetime value in an Active Directory forest defines the default number of days that a domain controller preserves knowledge of deleted objects. This value also defines the useful life of a system state backup that is used for disaster recovery or installation from backup media. Active Directory protects itself from restoring data that is older than the tombstone lifetime by disallowing the restore. 

(2) configured per DNS server in the registry manually or through DNSCMD

/dstombstoneinterval[ 1-30] 

Amount of time in seconds to keep tombstoned records in Active Directory alive. 



Met vriendelijke groet / Kind regards,


Jorge de Almeida Pinto

Infrastructure Consultant

__






LogicaCMG Nederland B.V. (BU SD/AT)

Division Industry, Distribution and Transport (ID&T)

Kennedyplein 248, 5611 ZT, Eindhoven

.   Postbus 7089

    5605 JB Eindhoven

(   Tel     : +31-(0)40-29.57.777

2   Fax : +31-(0)40-29.57.709

(   Mobile  : +31-(0)6-26.26.62.80

*   E-mail  : [EMAIL PROTECTED]

"    - Solutions that matter -



This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

RE: [ActiveDir] Tombstone Lifetime and DC Replication

[Eljin]

William,

The 1188 events that occur will give you full instructions to allow you to
see if you will have any lingering objects. Use the repadmin switch to check
beforehand

Eljin

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of William Lefkovics
Sent: Saturday, August 21, 2004 1:01 PM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Tombstone Lifetime and DC Replication

I think this normally comes up when an old backup is restored, but...

I have a pair of lab DCs on Windows 2003 that have been turned off for
longer than the tombstone lifetime of 60 days.

In firing them up, they will no longer speak to one another like each thinks
the other has cooties.
This is by design, of course.

I was going to force the removal of the one without the FSMO roles with
DCPromo and then rejoin.  Is that the simplest course of action?

Thanks in advance.

William



 

List info   : http://www.activedir.org/mail_list.htm
List FAQ: http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/


List info   : http://www.activedir.org/mail_list.htm
List FAQ: http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

RE: [ActiveDir] Tombstone Lifetime and DC Replication

[Rick Kingslan]

That's the course that I'd take, William.  One needs to be authoriatative,
and thinks that the other is grossly out of tune with reality.  In a sense,
both are right.  It just takes one of them to have a domain, and the other
can be whacked, clean up the residual elements and objects, and rebuild it.
Join it back as a new DC to the existing domain, and life should be just
fine again.

Rick Kingslan  MCSE, MCSA, MCT, CISSP
Microsoft MVP:
Windows Server / Directory Services
Windows Server / Rights Management
Windows Security (Affiliate)
Associate Expert
Expert Zone - www.microsoft.com/windowsxp/expertzone
WebLog - www.msmvps.com/willhack4food
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of William Lefkovics
Sent: Saturday, August 21, 2004 3:01 PM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Tombstone Lifetime and DC Replication

I think this normally comes up when an old backup is restored, but...

I have a pair of lab DCs on Windows 2003 that have been turned off for
longer than the tombstone lifetime of 60 days.

In firing them up, they will no longer speak to one another like each thinks
the other has cooties.
This is by design, of course.

I was going to force the removal of the one without the FSMO roles with
DCPromo and then rejoin.  Is that the simplest course of action?

Thanks in advance.

William



 

List info   : http://www.activedir.org/mail_list.htm
List FAQ: http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

List info   : http://www.activedir.org/mail_list.htm
List FAQ: http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

[ActiveDir] Tombstone Lifetime and DC Replication

[William Lefkovics]

I think this normally comes up when an old backup is restored, but...

I have a pair of lab DCs on Windows 2003 that have been turned off for
longer than the tombstone lifetime of 60 days.

In firing them up, they will no longer speak to one another like each thinks
the other has cooties.
This is by design, of course.

I was going to force the removal of the one without the FSMO roles with
DCPromo and then rejoin.  Is that the simplest course of action?

Thanks in advance.

William



 

List info   : http://www.activedir.org/mail_list.htm
List FAQ: http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/