How to Restore a Deleted Active Directory Object in 2026 (AD Recycle Bin & PowerShell)

Someone deletes a user, a group, or a whole OU in Active Directory, and the phone starts ringing. If the AD Recycle Bin is enabled, this is usually a five-minute fix. If it isn’t, you still have options, but the clock (tombstone lifetime) is working against you.

This covers checking whether the Recycle Bin is on, enabling it properly, and the actual PowerShell commands to bring back a deleted user, group, or OU (with its child objects) in 2026, without needing any third-party backup tool.

Step 1: check whether the Recycle Bin is already enabled

Run this from an elevated PowerShell session on a domain controller or a machine with RSAT’s Active Directory module:

Get-ADOptionalFeature -Filter 'Name -eq "Recycle Bin Feature"' | Select-Object Name, EnabledScopes

If EnabledScopes comes back empty, it’s off. If it lists your domain or forest’s distinguished name, it’s already on and you can skip to the restore commands below.

Step 2: enable the AD Recycle Bin

Check your forest functional level first, since this is the one hard requirement:

Get-ADForest | Select-Object ForestMode

Anything at Windows2008R2Forest or higher qualifies. If you’re still below that, this feature isn’t available until you raise the functional level, and that’s a separate change worth planning on its own.

To enable it, run:

Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' `
  -Scope ForestOrConfigurationSet `
  -Target 'yourdomain.com' -Confirm:$false

Replace yourdomain.com with your actual forest root domain. You’ll get a confirmation prompt (or skip it with -Confirm:$false as above). This is a one-time, forest-wide change and replicates to every domain controller, so give it a few minutes to land everywhere before you rely on it in a multi-DC environment.

Prefer a GUI? Open Active Directory Administrative Center (dsac.exe), select your domain in the left pane, and click Enable Recycle Bin in the Tasks pane on the right. Confirm the warning, then refresh (F5).

Step 3: restore a deleted object with PowerShell

The general pattern is: find the deleted object with Get-ADObject -IncludeDeletedObjects, then pipe it to Restore-ADObject. A deleted object’s normal attributes (like samAccountName) are still searchable, so you don’t need to know its GUID up front.

Restore a single deleted user

Get-ADObject -Filter 'samAccountName -eq "jbloggs"' -IncludeDeletedObjects | Restore-ADObject

This restores the object to its original OU with its original name and, crucially, its original group memberships intact. No -TargetPath or -NewName needed unless the original OU has since been deleted too.

Restore a deleted group

Get-ADObject -Filter 'msDS-lastKnownRDN -eq "Finance-Team"' -IncludeDeletedObjects | Restore-ADObject

msDS-lastKnownRDN is generally the more reliable filter for groups and OUs, since a deleted object’s display name gets a GUID suffix appended and plain name matches don’t always behave as expected.

Restore an OU and everything inside it

Deleting an OU deletes its contents too. When you restore, order matters: restore the OU itself first, then its child objects, otherwise the children have nowhere to land.

# 1. Restore the OU itself
Get-ADObject -Filter 'msDS-lastKnownRDN -eq "Sales"' -IncludeDeletedObjects | Restore-ADObject

# 2. Restore everything that was inside it, oldest deletion timestamp first
Get-ADObject -Filter 'isDeleted -eq $true -and lastKnownParent -like "*OU=Sales*"' `
  -IncludeDeletedObjects -Properties lastKnownParent |
  Sort-Object whenChanged |
  Restore-ADObject

For a large OU with nested sub-OUs, run that second command a couple of times. Restoring one level exposes the next level’s parent, so a single pass can miss deeply nested objects.

Restoring through the GUI instead

Active Directory Administrative Center has a dedicated Deleted Objects container once the Recycle Bin is enabled. Select your domain, open it, right-click the object, and choose Restore (or Restore To for a different OU). It’s slower for bulk restores but useful when you’re not sure exactly what was deleted and want to browse first.

If the Recycle Bin wasn’t enabled

Without it, a deleted object becomes a tombstone: most of its attributes are stripped and it’s purged permanently after the tombstone lifetime (again, 180 days by default on modern forests). Your options at that point are an authoritative restore from a System State backup, or a third-party AD recovery tool that keeps its own change history. Neither is as clean as the Recycle Bin, which is exactly why enabling it now, before you need it, is worth the five minutes.

Frequently asked questions

Does enabling the AD Recycle Bin have any downside?

It increases the size of the AD database slightly, since deleted objects are retained with all attributes for the full deleted object lifetime rather than being stripped down immediately. For the vast majority of environments this is negligible against the recovery benefit.

Can I restore an object to a different domain controller than the one it was deleted on?

Yes, once the deletion has replicated. Restore-ADObject works against whichever DC your session targets; it doesn’t need to be the same one the deletion happened on.

Why did the restored user lose their password?

They shouldn’t. Password hashes are preserved with the object. If a restored account won’t authenticate, check the account isn’t disabled (deletion doesn’t change the enabled flag, but a restore can occasionally leave it in a state worth double-checking) and that it replicated to the DC the user is authenticating against.

Can I change the deleted object lifetime from the 180-day default?

Yes, via the msDS-deletedObjectLifetime attribute on the directory service object, though most environments are better served leaving it at the default and pairing it with proper System State backups for anything older.