Zoho Banner September 2011

Archive for December, 2014

Another quick one to finish the year off.  Here’s a script that runs an LDAP query against all of the DCs in the forest and reports back the time it has taken for each.  The intention is to identify any DCs that are responding slowly for some reason.  In the example below, I’ve chosen to run my query against the schema partition as this will be consistent across all DCs in the forest, regardless of domain.  If you have a single domain forest, you might want to change this for a really inefficient query against something in the domain partition.

The script uses WinRM to query each DC directly.  I did it that way to remove network latency as an influence on the response timings.  If you don’t have all Windows Server 2012 (or later) DCs then you will need to explicitly enable WinRM to allow the script to talk to the DCs.

 

#########################################################
#
# Name: Get-LDAPSearchTimings.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 29/11/2014
# Comment: PowerShell script to
# obtain LDAP search times from all DCs in the forest
#
#########################################################

Import-Module ActiveDirectory # Imports the AD module (if required)

$domains = (Get-ADForest).domains
$dcs = @()
foreach ($domain in $domains){
    [string]$ddc = (Get-ADDomainController -DomainName $domain -Discover).hostname
    $ddcs = Get-ADDomainController -Filter * -Server $ddc
    foreach ($srv in $ddcs) {
       $name = $srv.hostname
       $dcs += $name
    } # end foreach
} # end foreach

foreach ($DC in $DCs) {
    $sc = {
        ipmo ActiveDirectory
        $sb = (Get-ADRootDSE).schemaNamingContext
        #$sb = (Get-ADRootDSE).DefaultNamingContext
        $fl = "(adminDescription=*name*)"
        #$fl = "(title=*manager*)"
        $ex = {Get-ADObject -LDAPFilter $fl -searchbase $sb -server localhost}
        (Measure-Command -Ex $ex).TotalSeconds
    } # end script block
    $mc = Invoke-Command -ComputerName $DC -ScriptBlock $sc
    write-host "Search took $mc seconds on $DC in AD Site $((get-addomaincontroller $dc -server $dc).site)"
} # end foreach

 

The output should look something like this:

get-ldapsearchtimings

I came across a weird error the other day while running Exchange Server 2013 CU6 setup with the /PrepareAD switch.  The error (from the Exchange setup logs) was this:

[12/02/2014 01:14:16.0727] [2] [ERROR] Could not find the Exchange Mailbox Administrators Universal Security Group through its well-known GUID 29a962c2-91d6-4ab7-9e06-8728f8f842ea.  Please make sure that Setup /prepareAD has been run.

I sat there scratching my head for a while because what (wtf?) is the Exchange Mailbox Administrators group and what does it have to do with Exchange 2013.  Anyway, after a journey of discovery, here’s what I found out.

For some time, Exchange has used an attribute named otherWellKnownObjects on the Exchange container in the Configuration partition of AD to store information about the location of certain Exchange objects, including the default groups.  One of these entries corresponds to the Organization Management group (as shown below).

attribute values

The strange-looking string next to the DN for the Organization Management group (C262A929D691B74A9E068728F8F842EA) is a Hex representation of a GUID.  To get to the string representation I found a handy function called Convert-OctetStringToGuid.  The result was as follows:

convert hex

The resulting GUID string (29a962c2-91d6-4ab7-9e06-8728f8f842ea) matches that shown in the original error.  So, basically the setup error was saying that it couldn’t find the Organization Management group.  The guff about the Exchange Mailbox Administrators group must be a legacy piece of code referencing an earlier version.  Once I had the new information I had a look to see if the group actually existed (it did).  I then concluded that maybe AD replication hadn’t finished by the time setup got to looking for the group.  I then made the executive decision to run setup with the /PrepareAD switch again.  Lo and behold it finished successfully.

I thought this write-up might help if you find yourself in the same boat.