Archive | ActiveDirectory RSS for this section

Recovering Deleted AD Users (and other objects) with PowerShell

If you have to recover deleted users in AD, and don’t have the AD Recycle Bin available, PowerShell is perfect for the task.

There’s an article on TechNet http://technet.microsoft.com/en-us/library/dd379509(v=ws.10).aspx  which describes using LDP or PowerShell with the Recycle Bin, but if you don’t have that enabled, there are a few things it leaves out.

If you don’t specify the “-NewName” property when using Restore-ADObject, you get the following error.

Restore-ADObject : Illegal modify operation. Some aspect of the modification is not permitted

This can be for other reasons, such as the parent/former OU being invalid (having been deleted itself), but in this case, deleted items don’t have a displayname, soooo.  Also, in the article, they filter Objects by displayname, but again, deleted objects don’t have one.  Womp Womp.

So you can try something like these commands instead.

Get-ADObject -IncludeDeletedObjects -filter {cn -like "*name*"} | Restore-ADObject -NewName "<newname>"
or
Get-ADObject -IncludeDeletedObjects -filter {objectguid -eq "someguid"} | Restore-ADObject -NewName "<newname>"
Advertisements

Recovering from accidental deletion of DFS Namespace

DFS Namespaces have really poor options in terms of permissions delegation.  Either someone can edit everything about a namespace or they can’t.  This led in my case to someone deleting the entire namespace while making other edits.  Other than the “Are You Sure?” dialog it didn’t require for any other sort of confirmation before removing the object from Active Directory, removing the shares from the hosting servers, and generally putting File Sharing back to the stone age. Recovering from this was a multi-step process, involving recovering the CN=<name of your dfs namespace>,CN=Dfs-Configuration,CN=System,DC=<domain DN>  object (The pkT attribute of that object appears to contain a binary representation of the links and targets in that namespace.), restoring the root share on the root server(s) and restoring registry settings related to those DFS shares.

  1. Restore the CN=<name of your dfs namespace>,CN=Dfs-Configuration,CN=System,DC=<domain DN>  object from backup.
    •  In this case the individual object was available from a brick level backup, much easier than doing an Authoritative Restore.
  2. Re-share the folder on the root server(s), giving whatever permissions were appropriate.
    • As a rule of thumb, I would not put files in the root of a DFS share, mostly for cleanliness, but it also helps in this case.  No files in the actual root means the share can be added with basic permissions (Admin Full, User Read).
  3. Re-create or restore the registry settings
    • In this case it is a 2000 style DFS Namespace, so the registry entries which needed to be restored are under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain
    • 3 entries need to be recreated for each deleted Namespace
      1. A Key with the name of the Namespace, and the next two entries underneath
      2. A String with the name LogicalShare and the value  <sharename>
      3. A String with the name RootShare and the value <sharename>
  4. Restart the DFS Namespace service on the hosting servers.

And now, \\DOMAIN\<namespace> should be restored, all of the links/targets in place as they were.