Active Directory Powershell cmdlets failing…what is port 9389?

I was working on a Project With a customer where they are running a Lync pilot for about 150 out of 10,000 employees. Considering the size of the customer, along With the fact that they are very Security-minded, the infrastructure is quite complex. For instance, all the Lync related servers are placed in a separate VLAN/subnet With strict firewall Access lists governing traffic. I am no stranger to the comprehensive requirements for ports in a Lync topology, and thought I had it all covered.

The pilot users normally reside in different SMTP domains, but for simplicity during the pilot phase they were all assigned URI’s within the same SIP domain. The Project manager wanted a list of all the users’ email addresses, to send Project updates and so on. To avoid the manual process of achieving this, I put together some Powershell code to achieve this:

Get-CsUser -Filter {Enabled -eq $true} | Select-Object sAMAccountName | foreach-Object ($_.sAMAccountName) { Get-AdUser -Identity $_.sAMAccountName -Properties EmailAddress | Select-Object Name, EmailAddress } | Export-Csv -Path C:\temp\UserEmailAddresses.csv

Powershell would pause for half a minute, then Return an error stating that the Domain Controller could not be contacted or that the Web Services might not be running. This puzzled me, since Active Directory preparations had gone smoothly. DNS lookup for LDAP (_ldap._tcp.domain.com) and GC (_gc._tcp.domain.com) gave a full list, and telnet to LDAP (port 389) and GC (port 3268) on selected DC’s were successful. What’s there to complain about?

Luckily the customer has Splunk running, monitoring all of the network. A quick look on the designated VLAN where the Lync server resides gave results. It stood out quite clearly that the Lync server was trying to Reach the DC on port 9389 – something I have never heard of before, neither is it described in the documentation as a requirement (http://technet.microsoft.com/en-us/library/gg398833.aspx).

Some Research soon bore fruit, as I discovered the “Active Directory Web Services” running via TCP/9389. Seems like both Active Directory Powershell module as well as Active Directory Administrative Center both depend on the latter service. Normally Access to DC’s from servers are relatively unconstrained, but clearly comething to be aware of in more locked Down infrastructure – at least for the full advantage of AD cmdlets from the Lync server.