Hi, Following a Microsoft article I deleted a 'folder' in ADSIedit, but it seems to have had an unexpected result, so I want to recover it. I do have a 24hour old backup, but have since made other changes to the server, so dont want to revert to this. I understand deleted items from AD are tombstoned for a length of time before being completely removed, but I am unsure as to how to access it. Server is SBS 2011.
When an AD item is erased most attributes other than GUID are stripped and it's sent to the recycler. It is then "tombstoned". It's essentially a GUID with very little (if any) other data. when the tombstone life is hit, it's erased permanently.
You can see if LDP.exe (support tool) can get at it, but it will only allow you to modify properties on the object (which you will need to know the GUID of, or be able to scour the AD trash for), and it will not restore the object. To restore it with whatever data is still there, you just need to set it's deleted flag to false (i think it's isDeleted, or something similar).
EDIT: By "folder", do you mean that you've erased a tree of items? If so, I personally wouldn't bother with trying to get them back, as each item would have been tombstoned individually more than likely and you'd need to know very specific details on each of them.
hmmm...specificicly, towards the end of the SBS2003->SBS2011 migration docs, it requests you delete the adsiedit:configuration->services->Exchange folder on the OLD server. I did that, and instantly lost the info store on the new server, did a restart of the new server and again the info store and some exchange services didnt start. Event viewer (on new server) says (summarised) exchange is missing config info. I checked adsiedit on the new server, and the exchange tree is missing from the same location in adsi edit. It is as if the delete was replicated to the new server from the old.
You won't be able to delete the Enterprise Recipient Update Service by using Exchange 2003 System Manager. Instead, perform the following steps to delete the Recipient Update Service by using Active Directory Service Interfaces Editor (ADSI Edit or AdsiEdit.msc). AdsiEdit.msc is included on the Windows Server 2003 CD in Support\Tools. For more information about ADSI Edit, see ADSI Edit (adsiedit.msc).
rah .. it would be nice if MS could come up with a better way to rid a domain of exchange 2003 installs. I dont know how many times now I've migrated from 03 to 07/10 to have to run adsiedit to delete random shit from the directory because the uninstall process for exchange 03 has failed, again.
ADSI Edit: How To Edit Active Directory Using ADSI Edit. Firstly, ADSI (Active Directory Service Interface Editor) Edit allows access and modifies the underlying and unexposed directory service data through ADUC (Active Directory Users and Computers). In this article, we discuss the usage of ADSI Edit, including how to access the tool, primary navigation, and everyday use cases for making changes to Active Directory objects and attributes. Whether we are seasoned system administrators or just starting, understanding how to use ADSI Edit helps to take Active Directory management skills to the next level.
Secondly, the ADSI (Active Directory Service Interface Editor) Edit Tool is an MMC snap-in. We use Active Directory Service Interfaces to connect to other Active Directory database partitions (NTDS.dit) or the LDAP server. The ADSI Edit tool also enables us to edit attributes, perform searches, and create, modify, and delete items in Active Directory.
Importantly, current Windows versions include ADSIEdit.msc in Remote Server Administration Tools (RSAT). The ADSI tool is a part of the ADDS Snap-ins and Command Line Tools package. Check out this article for instructions on installing RSAT and more information.
Note: The ADSI Edit snap-in in AD editing functionality resembles the Windows registry editor. As a result, we cannot alter some Windows settings using Group Policies or the graphical user interface. As a result, the administrator occasionally needs to make changes directly to the Windows registry to resolve a complicated issue.
Similarly, more tools are required to solve complex Active Directory issues than only the Users and Computers snap in or PowerShell cmdlets. For example, via ADSI Edit, we directly alter the AD database. But ADSI Edit, gets beyond all standard AD safety measures. In turn, this process means that by using adsiedit.msc to make erroneous AD modifications, we risk damaging or erasing our AD database. Hence, we advise backing up Active Directory before using this tool because of this.
To start, right click the ADSI tool and select Connect. We select a remote machine with an LDAP database or a Connection Point, Naming Context, from this menu. If we do not know the exact Connection Point Distinguished Name or Naming Contexts, we select one of the known Naming Contexts:
Additionally, please choose the default naming context to open the ADUC-like AD view and hit OK. The left pane now displays a brand new root partition that we can extend. As we see, the ADSI Edit terminal in this mode shows the hierarchical tree view of all containers and Active Directory OUs in AD.
Remember that after we click on the node, the Default Naming Context and the different levels of the hierarchy in ADSI Edit are only visible. Moreover, there are console based AD service containers that we conceal and that ADUC, by default, cannot show. In the AD hierarchy, for instance, we select, modify, move, remove, and rename any objects (computers, users, groups).
Please be aware that there are several data types among the characteristics of objects (Integer, String, MultiString, Time, etc.). For instance, AD shows the values of the time/date-related properties in the ADSI Object Attribute Editor console in their conventional form. We see that they are still stored in the Active Directory database in Timestamp format if we attempt to modify them.
Next, we configure AD settings with ADSI Edit that we cannot configure in any other method. For instance, any domain user adds up to 10 computer accounts to the domain (even without Domain Admin rights). The LDAP attribute ms-DS-MachineAccountQuota, which we may only modify using ADSI Edit, serves as our definition for this (in the domain properties).
For instance, we could use the ADUC snap-in to hide OU (one of the AD containers). Then, open the OU properties and alter the attribute from False (or Not Set) to True. To check the latest version of the AD schema using ADSI Edit:
We use ADSI adapter in PowerShell to establish a connection to an LDAP AD. Although there are better ways to administer AD (than the PowerShell Active Directory module), there are occasions when we must use it, such as via external tools or logon scripts. We must specify the LDAP path to an AD object to receive information about it using the ADSI interface:
In conclusion, ADSI Edit is a powerful tool that gives system administrators deeper access and control over Active Directory objects and attributes. While ADUC delivers a user friendly interface for managing Active Directory, it may only sometimes provide access to all necessary functionality. With ADSI Edit, administrators makes low level changes to objects and attributes that are generally invisible, allowing for advanced troubleshooting and fixing complex issues.
7fc3f7cf58