Deleted objects and the Recycle Bin

Check whether the feature was enabled

Get-ADOptionalFeature -Identity 'Recycle Bin Feature' |
    Select-Object Name,EnabledScopes

An empty EnabledScopes means it is not enabled in the queried scope. The AD DS Recycle Bin is forest-wide, requires the appropriate forest functional level, and cannot be disabled after enabling it. It recovers objects deleted after activation, once the feature has replicated. Microsoft’s Recycle Bin guide covers enablement and recovery.

Plan enablement as a forest change. It won’t help an object that was already deleted, and the query above doesn’t enable it.

Match the recovery method to the remaining state

Tombstone reanimation is not equivalent to full Recycle Bin restoration: values that were stripped are not recovered just by making the object live. A recreated account with the same name also has a different identity. These differences determine whether old ACLs and application references continue to work.

Deletion has a lifecycle

Without Recycle Bin, deletion leaves a tombstone with much of the original object’s data stripped. With Recycle Bin enabled, a deleted object retains the data needed for restoration during its deleted object lifetime. It later becomes recycled and is eventually garbage-collected. A recycled object is not a normal Recycle Bin restore candidate.

$dc = 'dc1.contoso.com'
$config = (Get-ADRootDSE -Server $dc).configurationNamingContext
Get-ADObject -Server $dc `
    -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$config" `
    -Properties tombstoneLifetime,'msDS-DeletedObjectLifetime' |
    Select-Object tombstoneLifetime,'msDS-DeletedObjectLifetime'

Do not infer retention from today’s DC OS or assume every forest uses 180 days. An old forest can retain its earlier setting, and an unset deleted-object lifetime falls back to the applicable tombstone lifetime. These intervals also constrain safe backup and disconnected-DC decisions. See lingering objects.

Find and identify the exact object

$base = (Get-ADRootDSE -Server $dc).defaultNamingContext
Get-ADObject -Server $dc -SearchBase $base -IncludeDeletedObjects `
    -LDAPFilter '(&(isDeleted=TRUE)(msDS-LastKnownRDN=Alice Example))' `
    -Properties lastKnownParent,'msDS-LastKnownRDN',isRecycled,whenChanged |
    Select-Object ObjectGUID,DistinguishedName,lastKnownParent,
        'msDS-LastKnownRDN',isRecycled,whenChanged

The sample value is literal; escape values when building filters from user input. Several deleted objects can share a former name, so compare the GUID, former parent and deletion context before restoring anything. Don’t pipe a broad name search straight into restore.

Restore the parent before its descendants

If an OU hierarchy was deleted, restore its parents first, then the children. Creating another OU with the same DN does not recreate the old OU’s identity. AD Administrative Center is often the clearest way to inspect a small restoration; use PowerShell when the scope and order need to be explicit.

After selecting and validating a restorable GUID, the following is a directory change:

# Replace with the exact deleted object's GUID from the inspected result.
$deletedGuid = '11111111-2222-3333-4444-555555555555'
Get-ADObject -Server $dc -Identity $deletedGuid -IncludeDeletedObjects |
    Restore-ADObject -Server $dc -WhatIf

Review the preview, then remove -WhatIf to perform the approved recovery. If the original parent is unavailable, check where -TargetPath will put the object and whether its name will collide there. After replication, test its links, group membership, permissions and application behavior. Advanced AD Administrative Center guidance explains subtree restoration and ordering.

For a deliberately chosen alternative parent, inspect that container and preview one exact object:

$targetPath = 'OU=Recovered,DC=contoso,DC=com'
Get-ADObject -Server $dc -Identity $targetPath -ErrorAction Stop
Restore-ADObject -Server $dc -Identity $deletedGuid `
    -TargetPath $targetPath -WhatIf

-NewName can resolve an intentional naming collision while preserving the recovered object’s GUID. Neither option repairs the application’s expectations about its location or name. Restore-ADObject’s parameter definitions distinguish restoring identity from choosing the new DN.

Recover links where they are stored

Group member values are forward links on the group; a user’s memberOf is a backlink. Restoring a user and restoring the necessary group links are related operations, but they do not mean writing memberOf on the user.

When an authoritative backup-based restore is required, account for the domain holding each forward link. A GC does not contain every domain-local membership from every resource domain. Generated link-recovery files and the order in which members and groups become available matter. Microsoft’s account/group recovery procedure explains the cross-domain link case and the different consequences of restoring a whole subtree.

Check those dependencies within the scope of the restore you need. They don’t automatically call for a whole-domain rollback. A subtree restore can overwrite legitimate post-backup edits to passwords, permissions and attributes within that subtree.

Recycle Bin does not undo an edit

If an application overwrites an attribute on an existing user, the object was never deleted. Recycle Bin cannot roll the edit back. A mounted snapshot may help find the former value; a supported backup/restore plan may be needed for a wider failure. Passwords, links and security descriptors require more care than exporting and importing a few text properties. Use the recovery-scope checks to distinguish selected-value repair from restoring a replica, domain or forest.

Verify identity, access and persistence

After restoration, query the same GUID on the recovery DC and another required replica. Check the intended parent/name and attributes, then test group-based access from a new appropriate logon/ticket context. An old session can retain old authorization data, making a good directory restore look ineffective.

Check what provisioning or synchronization software will do to the recovered object. Keep the original deletion logs and find the system of record; otherwise the next sync can delete or overwrite it again.

Accidental deletion protection is an ACL

Get-ADOrganizationalUnit -Server $dc -Filter * `
    -Properties ProtectedFromAccidentalDeletion |
    Where-Object { -not $_.ProtectedFromAccidentalDeletion } |
    Select-Object DistinguishedName

Review the OUs this returns. Protection is a useful barrier, but you still need a backup and recovery path. Tree-delete behavior and rights on the parent/container matter too: protecting a descendant doesn’t make every operation against a parent harmless. Test the delegated workflow before relying on the check box.