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 iInstance 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.ditLog folder: C:\Program Files\Microsoft ADAM\FE-App1\data
Service state: RunningInstance 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.ditLog folder: C:\Program Files\Microsoft ADAM\FE-App2\data
Service state: RunningInstance 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.ditLog folder: C:\Program Files\Microsoft ADAM\FE-App3\data
Service state: Runningdsdbutil: 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.
If machine on which ADAM (or AD LDS) is running is domain joined this information should be published in AD with serviceConnectionPoint object created under this machine account object. This is well described in this article:
http://technet.microsoft.com/en-us/library/cc758577(WS.10).aspx
Hi Tomek
Yes, good point about the serviceConnectionPoint objects. The keywords and serviceBindingInformation attributes provide the required information. I think this is useful for applications coding against AD LDS to find the correct instance, ports, site, etc., but maybe not so intuitive for most admins to work with.
As you point out, one limitation with serviceConnectionPoint objects is that they are only created automatically if the AD LDS server is a member of the AD domain. For them to be created it also requires that the service account has permissions to create serviceConnectionPoint objects as child objects of the AD LDS computer object. The Network Service built-in account has this permission, but if you are using a domain-based user account you need to assign this permission separately. If you don’t the serviceConnectionPoint object will not be created.
Tony
this was huge for me, thanks a bunch
this was huge for me, thanks a bunch