Open a Socket!

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”}
else
{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

 Tony

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

Enjoy!

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):
-1507Error value (hex):
fffffa1d

Internal ID:
20208a9

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.