Reading out the maxPwdAge attribute is a trivial task  in PowerShell (I am re-using the function AdsLargeIntegerToInt64):

In my case this returns the value -78624000000000 but how do we interpret this?

The value is expressed in 100 nanosecond units which is the same unit as a windows FILETIME structure uses.

Knowing that we can use the FromTicks method from the .NET TimeSpan structure to convert it to the number of days:

And $maxPwdDays is 91 in my case.

Note that I am using ABS to make the value positive since maxPwdAge is always negative.

Because the IADsLargeInteger object doesn’t provide type information PowerShell cannot read the HighPart and LowPart properties.

So I wrote the function below to get the Int64 value of an IADsLargeInteger:

In such a script you can easily get failures because of Active Directory replication.

Image that you create a new user account and later on you need set an additional attribute. What happens if the user was created while connected to Domain Controller A and you try to set an additional attribute while connected to Domain Controller B before replication has completed?

We can prevent this easily by performing all actions on the same domain controller. In my script I query for any Domain Controller that has the Global Catalog role:

Insert the $DC variable in your ldap binding eg:

Next problem is when you perform non ADSI operations such as setting NTFS permissions on a fileserver (eg homedirectory).

This server may not yet be able to resolve the username to it’s SID and thus the operation may fail!

We can solve this easily by giving permissions to the SID directory instead to the username. Example:

But how do we get more insight into these RID Allocation pools?

The DCDIAG tool can display this information per domain controleler using the following syntax

Example output:

But where in Active Directory is this information stored and can we display it for all Domain Controllers at once for larger environments?

Let’s start with the Active Directory part, the System container has an object named RID Manager$:

The fSMORoleOwner attribute holds the RID Master FSMO role owner.

rIDAvailablePool is a Large Integer (an 8 byte value) where the lower 4 bytes  are the From (Beginning of next RID pool to be allocated) and the higher 4 bytes are the To (Total number of RIDS that can be created in a domain) as displayed by dcdiag.

The Allocation Pools and the Next RID are kept by each server in a child object called RID Set. We can find the RID Set by querying the rIDSetReferences attribute which contains the LDAP path to the RID Set:

The RID Set contains the other values we are looking for where rIDAllocationpool (the pool currently in use) and rIDPreviousAllocationpool (the pool that will be used next when the current pool is exhausted) are again Large Integers with a Low and a High part:

Now that we know where the values are stored we can write a script, I have chosen PowerShell.

First we connect to the (Default) domain and obtain the distinguishedName of the domain (DC=MyDomain, DC=local).

Now we can open RID Manager Object:

And query for the FSMO Role Owner:

From the RID Master we read the rIDAvailablePool attribute:

GetInteger8 is a helper function to read Integer8 (Large Integer) values from Active Directory:

We are going to store all RID Data in an array so we can use the Format options from PowerShell:

I wrote a function to gather and return the RID Data for a Domain Controller object:

Now we can Bind to the Domain Controllers OU, enumerate all children and gather the RID Data for them:

Last step is outputting the Data:

This is the data for my environment:

The complete script can be downloaded below.

I encountered another interesting error during Exchange 2010 installation today. During the Organization Preparation I got the following error:

The setup.log doesn’t give us much more detailed info:

I remembered from a Tweet by Helge Klein recently that the Active Directory schema has no mechanism for enforcing uniqueness of an attribute.

My first assumption was a duplicate sAMAccountName but I couldn’t find any evidence for that.

Then I checked for duplicate SID‘s, you can do this via NTDSUtil:

NTDSUtil creates a log file in the current directory (dupsid.log) and indeed I was having duplicate SID’s:

What made this very interesting is that the names listed here like Public Folder Management and Recipient Management are all created during Exchange 2010 installation.

This behaviour is described in Prepare Active Directory and Domains in a little note:

So what happened?

I did a P2V of 2 existing domain controller to test an AD upgrade in a Sandbox. After the AD upgrade I kept the sandbox and decided to test Exchange installation as well.

I first created a P2V of DC002, the least important domain controller, and put in online in the sandbox to test the P2V process.

Because the DC002 had the RID Master FSMO role it was possible to allocate a block (the same block) of relative ID’s in both the sandbox and the production environment.

A couple of days later I did the P2V of the other domain controller and placed it online as well. And this is where the duplicate block became a problem.

Because I am in a sandbox I could take the easy solution which is use the cleanup duplicate sid command in NTDSUtil:

Warning: the cleanup duplicate sid command will delete BOTH objects having the same sid!

Sidenote: It seems that the problem with the otherWellKnownObjects attribute I described earlier was actually caused by the Exchange Setup as well!

My recommendations  for P2V of Domain Controllers:

• P2V all Domain Controllers at the same time.
• If you cannot p2v all Domain Controllers at the same time, do not bring a copy online before you finished all P2V’s.
• Make sure the RID Master is brought online LAST

We used a P2V to get real copies of the Active Directory and the AD upgrade to 2008 R2 was already tested.

But during the Exchange installation in the sandbox I got the following error:

The setup log (located in C:\ExchangeSetupLogs) shows a little more detail:

The strange thing is that it’s referring to a deleted object (since it’s in the deleted objects container). So what’s going on?

I used the ldp.exe tool to connect to the deleted objects container and inspect the Organization Management object but I couldn’t find any invalid data in it. So I was looking at the wrong place

But if you break down the error message then it’s actually very clear where you need to look:

The attribute otherWellKnownObjects of the object CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=zorg,DC=local (which is a multivalued object) has a value that refers to a deleted item (B:32:C262A929D691B74A9E068728F8F842EA:CN=Organization Management\0ADEL:c1b94668-b67b-4231-8e5a-b11ecf5b7838,CN=Deleted Objects,DC=zorg,DC=local).

So I opened ADSI Edit and navigated to the Microsoft Exchange container:

Then I looked at the properties of CN=Microsoft Exchange we can see the otherWellKnownObjects attribute:

But unfortunately ADSI Edit cannot view or modify  this attribute:

My next attempt was ADExplorer from SysInternals (version 1.42). Once again I navigated to the Microsoft Exchange container:

AD Explorer has no problems showing the values:

I thought I was almost there: I right clicked the wellKnownObjects Attribute then Modify and after selecting the Deleted value I clicked Remove followed by OK:

And this made AD Explorer hang itsself:

Followed by Crash:

So I had to solve it myself with the help of a PowerShell script.

First I read the the otherWellKnownObjects attribute with PowerShell (I wrote about that earlier).

This returns a Collection that I walk backwards with a for loop, this is important when removing items in a collection during a loop (don’t shoot yourself in the foot).

For each item in the Collection I get the distinguishedName from the DNString property and if it contains “0ADEL” then I assume the object it refers to has been deleted so I remove this item from the Collection.

Finally I check if we have deleted at least one item and if so I call SetInfo() to commit the changes to Active Directory.

If you want to test the script, be sure to comment the SetInfo() call to prevent the actual deletion in your Active Directory!

In my case this was the Microsoft Exchange container in the Configuration partition:

The otherWellKnownObjects attribute is of type ADSTYPE_DN_WITH_BINARY which unfortunately cannot be viewed or edited with ADSI Edit:

So I wrote a script to read the values with PowerShell but it’s not very straightforward how to do this.

Reading the otherWellKnownObjects property returns a collection of IADsDNWithBinary interfaces but this interface is unknown in PowerShell.

Using reflection we can read the values:

But after you have hidden a Mailbox you cannot create an Outlook profile for it (or add it as an extra mailbox).

When you click Check Name in the wizard you’ll get an error:

The common workaround is to remove the “Hide from Exchange address lists” setting, create the profile (or add the Mailbox) and afterwards set it again.

Once the profile is created it all keeps working.

There is an easier solution though!

If you add the mailbox using the legacyExchangeDN attribute then Outlook happily accepts.

This works because Outlook really uses this value and not the user’s accountname to connect to a Mailbox.

 The Error above occurs because Outlook cannot resolve the username to the legacyExchangeDN name using the Address List.

So how do we get the user’s legacyExchangeDN?

It can be read using ADSI Edit:

But I prefer to read it with a script since it means less clicking.

Using PowerShell it’s also a very simple script:

Now we take the result, in my case:

Now we copy & paste this into the User Name Edit:

And Outlook will resolve it to the username

The same procedure can be used if you want to Add a Hidden Mailbox as Additional Mailbox:

Commenter Michel thought that the script only tested one level deep but it doesn’t.

But let’s prove that!

Create 3 Global Groups in your Active Directory and name them Level1, 2 and 3:

Make Level3 a Member of Level 2 and make Level a member of Level 1 and finally add an account to the Level 3 group:

Now run the script and the output should include all 3 groups:

And the Output: