I have seen a number of posts where the contents of AD (accounts, groups, and OUs) are dumped and stored in a database for one reason or another. I myself do this to provide access to this data for reporting purposes as well as some other applications where we automatically enable and disable accounts via an Oracle based security application which moves disabled accounts to and from a secure OU.
When storing records about the previous state of an account that made be needed in the future for further processing, I only store the GUID of the account, the GUID of the parent OU from which the account was moved, the userAccountControl value, and any other point in time data that is pertinent. Not only is this data more compact than store the distinguished of the account and OU, it provide the only truly safe way of finding the same object at a future date. If your OU tree get modified through renaming an OU or pruning and grafting your stored DNs are worthless. If accounts get renamed then even relying on the TranslateNAme UDF is not much help.
But if you stored the GUID you are just fine. You can bind directly to the GUID of an object using the LDAP provider.
The guid of an object can be obtained via $object.Guid when you first dumped or had the object originally. You can use the following code to bind directly to the specific object you desire regardless of where it now exists in the hierarchy or by whatever name it is now known.
Code:
$Guid = 'a1ab60d1c2724e409005db95ac64048e'
$oUser = GetObject("LDAP://DomainName/<GUID=$Guid>")
$NewDN = $oUser.distinguishedName
