Zoho Banner September 2011

Archive for the ‘AD LDS / ADAM’ Category

For those of you planning to extend your AD DS or AD LDS schema, you will need to find a unique object identifier (OID) for each new schema class and attribute.  The process by which you can acquire the OIDs is described by Microsoft here:


In summary, Microsoft suggests two methods for obtaining an OID:

1. Contact the International Standards Organisation (ISO) Name Registration Authority specific to your country; or

2. Use the oidgen.vbs script provided by Microsoft.  This method generates a random GUID and hangs it off an existing OID owned by Microsoft.

Another option not referred to by Microsoft is to contact the Internet Assigned Numbers Authority (IANA) and request a Private Enterprise Number (PEN).  The process is free an you will be able to acquire your very own root OID within 30 days of submitting a request.

Obviously, the scripted method is the quickest and simplest.  I guess the only downside is that there is a (very) remote possibility that the same OID can be generated twice.  Hidden away on the Q&A page of the oidgen.vbs script is a really nice little Powershell script that does the equivalent.  The script is written by Jiri Formacek of Microsoft and I take absolutely no credit for it. :-)

 I’ve seen a number of instances where people advise only to use the script in lab environments.  Personally, I can’t help thinking that this is being overly cautious.  Here are two examples of the OID generated by the script:



Microsoft’s root OID is shown in bold.  As you can see the remaining portion is fairly long.  I’m no mathematician, but what are the chances of the same OID being generated twice?  I guess it depends a little on the algorithm used to generated the new GUID.  Even if that scenario were to occur, what are the chances of the same schema extensions using the identical OID being used in more than one organisation? 

Your approach will depend on your attitude to risk, but if you are not a software vendor then I would think it fairly safe to use the scripted approach for your custom extensions.

Quest Software make it hard to love them sometimes.  When they made Quest Quick Connect Express for Active Directory available at no cost it was a real boon for anyone wanting to synchronise objects from AD to AD (or AD LDS instances).  In particular it offered a great free method of achieving GAL Sync between two Exchange Organisations, the likes of which have not been seen since the days of Microsoft’s Identity Integration Feature Pack (IIFP – a cut down version of MIIS/ILM/FIM). I thought was smart, strategic thinking on Quest’s part: make the sync engine available with basic functionality to get everyone used to the product and then generate revenue through add-on licences for other data sources (generic LDAP, SQL, Oracle, etc.).  Sadly, the strategic approach seems to have been thrown out in the (mistaken) belief that charging for the AD connector will bring in more revenue.  Hopefully Dell (Quest’s new owner) will hear the howls of derision and bring back the free version.

Now that I’ve got that off my chest, what are the options left for (free) GAL Sync?  Well, if you have a copy of the Quest One Quick Connect Sync Engine version 4.7 or 5.0 you can still use these to achieve GAL Sync free of charge.  The current version of the Sync Engine (5.1) has had the AD DS/AD LDS connectors disabled so if you download that you will need to purchase a Quest One Quick Connect Express for Active Directory licence to get the old functionality back.

It doesn’t look like version 5.0 of the Sync Engine is available on the Quest web site, but you can still download version 4.7.  To get there you need to register for the Quest One Quick Connect Express for AD trial version and you will then see the download options for the Sync Engine.  The Step-by-Step Guide that I originally wrote was for version 4.7 and is still available:


If you have version 5.0 downloaded somewhere, consider yourself lucky – and hold on to it!


Here’s a quick tip on how to find out what ports your AD LDS instances are listening on. 

On the machine running the instance(s), open a command prompt with Administrator privileges and type the following:

dsdbutil “li i” q

The syntax used above runs the dsdbutil.exe utility with the “List Instances” option.  The output should show details of your AD LDS instances, including the LDAP and LDAPS port numbers as shown in the example below.

C:\>dsdbutil “li i” q
dsdbutil: li i

Instance Name:         FE-App1
Long Name:             FE-App1
LDAP Port:             50000
SSL Port:              50001
Install folder:        C:\Windows\
Database file:         C:\Program Files\Microsoft ADAM\FE-App1\data\adamntds.dit

Log folder:            C:\Program Files\Microsoft ADAM\FE-App1\data
Service state:         Running

Instance Name:         FE-App2
Long Name:             FE-App2
LDAP Port:             50002
SSL Port:              50003
Install folder:        C:\Windows\
Database file:         C:\Program Files\Microsoft ADAM\FE-App2\data\adamntds.dit

Log folder:            C:\Program Files\Microsoft ADAM\FE-App2\data
Service state:         Running

Instance Name:         FE-App3
Long Name:             FE-App3
LDAP Port:             50004
SSL Port:              50005
Install folder:        C:\Windows\
Database file:         C:\Program Files\Microsoft ADAM\FE-App3\data\adamntds.dit

Log folder:            C:\Program Files\Microsoft ADAM\FE-App3\data
Service state:         Running

dsdbutil: q

Given that wanting to know the port numbers used by AD LDS is a fairly common requirement, I think it would be helpful if Microsoft made this information available through the Roles view in the Server Manager console.  This would be the logical place for it as Server Manager already shows related information such as Services and Events.


Let me know if you agree and I’ll submit a request to Microsoft to make a change.

In my last post, I provided a small batch file to support scheduled IFM dumps of an AD LDS instance.  Afterwards, I realised that batch files are sooo last century and decided to have a crack at the Powershell version.  I’m no Bwandon, but the script below seems to do the trick.

# Name: Create_IFM_Dump.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 20/04/2009
# Comment: PowerShell script to create AD LDS IFM
# backup.  To be run nightly as a scheduled task.

# Declare variables$IFMDir = “c:\backup\adlds\Instance1″
$IFMName = “adamntds.dit”
$cmd = $env:SystemRoot + “\system32\dsdbutil.exe”
$flags = “`”ac i Instance1`” ifm `”create full c:\backup\adlds\Instance1`” q q”
$date = get-Date -f “yyyymmdd”
$backupfile = $date + “_adamntds.bak”
$DumpIFM = “{0} {1}” -f $cmd,$Flags

# Main

# Create the folder if it doesn’t exist if(test-path -path $IFMDir)
{write-host “The folder” $IFMDir “already exists”}
{New-Item $IFMDir -type directory}
# Clear the IFM folder (Dsdbutil needs folder to be empty before writing to it) Remove-Item $IFMDir\*

# Run Dsdbutil.exe to create the IFM dump file Invoke-expression $DumpIFM# Rename the dump file to give the backup a unique name

rename-item $IFMDir”\”$IFMName -newname $backupfile

# End Main


Microsoft Technet describes how to back up an AD LDS instance using either Windows Server Backup or Dsdbutil.exe.  Interestingly, the Dsdbutil method leverages the Install From Media (IFM) feature to perform the backup.  Here’s a small batch file that you can use to schedule the backup using the Task Scheduler.

@echo off
rd /s c:\backup\adlds\Instance1\ /q
%windir%\system32\dsdbutil.exe “ac i Instance1″ ifm “create full c:\backup\adlds\Instance1″ q q


I really like the snapshot feature of Windows Server 2008 AD and have been using it quite a bit recently.  This week I had my first foray into snapshotting with AD LDS.  Everything is pretty much the same as for AD, the only obvious difference being that you can create the snapshots using either dsdbutil or ntdsutil with AD LDS.  I was somewhat surprised then to see a nasty looking error (see below) when I fired up Dsamain.exe to expose my freshly taken AD LDS snapshot.

C:\>dsamain -dbpath “C:\$SNAP_200904031033_VOLUMEC$\Program Files
\Microsoft ADAM\INSTANCE1\data\adamntds.dit” -ldapport 15005
EVENTLOG (Error): NTDS Database / Internal Processing : 1168
Internal error: An Active Directory Domain Services error has occurred.
Additional DataError value (decimal):
Error value (hex):

Internal ID:

EVENTLOG (Error): NTDS General / Internal Processing : 1003
Active Directory Domain Services could not be initialized.

The directory service cannot recover from this error.

User Action

Restore the local directory service from backup media.

Additional Data

Error value:
-1507 JET_errColumnNotFound, No such column

EVENTLOG (Informational): NTDS General / Service Control : 1004
Active Directory Domain Services was shut down successfully.

After a few minutes bafflement, I had another look through the Dsamain.exe command line options and saw this:

 -adlds       (optional) open AD/LDS DIT

It turns out the -adlds parameter is optional only in the sense that you don’t (and in fact must not) include it when using Dsamain.exe with AD.  It is mandatory when using AD LDS.

Once I included the -adlds parameter everything fired up normally.   Another case of RTFM for me. :-)