Learning about Docker, Kubernetes and other technologies the hard way… so you don't have to.

Menu

Is that Skype for Business (Lync) Number Free?

Get-CsAdPrincipal is a tragically underused cmdlet. Absent a fully generic Get-CsEndpointObject, it’s the next best thing to Get-ADObject, and is killer when you have no idea what you’re looking for – a User, a Common Area Phone, Conference Dialin Number, Response Group or some crazy custom endpoint used in a Skype-enabled application, especially if all you care about is seeing if a number is available. If you see “485 Ambiguous” in a SIP trace, this will help you figure out who (and/or what) all has this number, and why Skype isn’t quite sure which one the caller wanted to reach.

There are several scripts for testing each of the Skype for Business object types one by one, and I give some of my favorites at the end of the post; the Get-CsAdPrincipal approach is faster in automation if you’re mostly interested in whether a number is consumed at all, and aren’t concerned with *what* exactly is consuming it.

The LDAP query is checking both the MsRTCSIP-Line and MsRTCSIP-PrivateLine attributes, and there is an asterisk at the end in case the extension was specified separately: tel:+499112224000 and tel:+499112224000;ext=4000 are functionally the same number, but do not look the same to Skype for Business! This is common in places where each line can be directly dialed from outside – that is, much of Europe. I used the attribute names in all lowercase because the mixed-case versions did not work.

If all you wanted was a quick way to check if a number is free or not, you can quit reading now and get back to writing your provisioning script 🙂 If you want to know a bit more about Skype for Business objects, as well as see some really nice stuff for viewing your number pool, stay with me…

From there, if you do want to make changes to the object consuming the number, it takes a little knowledge to interpret the result and get the Cs* object to change the phone number. WARNING: Do NOT write MsRTCSIP-Line directly in AD – it might appear to work, but is completely unsupported.

First, just seeing the DisplayName and SipAddress might make it clear enough to you, especially if you’ve been careful about your naming schemes.

Next, look at the ObjectClass: {top, person, organizationalPerson, user} is an AD User object. As far as I know, Skype for Business uses that only for CsUser and endpoints for third-party applications that have chosen to authenticate as AD Users (AudioCodes’ IVR running as a VM in their SBA, for example). Just about everything else will be {top, person, organizationalPerson, contact}: Common Area Phones, Response Groups, Conference Dialin Numbers, Analog Devices, weird custom endpoints.

Finally, look at where it lives: DistinguishedName/Identity (they’re identical).

If it’s in your regular AD structure and is a Contact object, it’s most likely a Common Area Phone (Get-CsCommonAreaPhone) or Analog Device (Get-CsAnalogDevice – reference to a fax or other device that can’t play directly with Skype), perhaps Exchange Unified Messaging (Get-CsExUmContact).

If it’s in CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration,DC=yourawesomedomain,DC=com, then it is a Dialin Conference Number or Response Group, which can be found by piping into Get-CsApplicationEndpoint like so:

Note: I had to run the Get-AdObject twice to check both our regular user domain and the root domain, where for reasons I wasn’t around for, all of the Response Groups and Dialin Conferencing numbers ended up.

Will try to optimize yours a bit, because I agree, it *should* be faster. But maybe Skype for Business is doing a super-good job in searching AD.