Changing the primary SIP domain

Recently I came across a situation where it was necessary to change the primary SIP domain for a Lync 2013 customer (although this will work for any Lync or Skype for Business deployment). This is not a very difficult process but there are a few gotchas which I would like to share...

1. Make sure that you change the SIP address for all your users after making the change to the new SIP domain
2. Make sure you run the bootstrap after you have made the change on all servers
3. Make sure you modify all your RGS workflows to use the new SIP domain
4. Finally, and the hardest one (because its not documented anywhere); you will need to manually edit the application contacts using ADSIEdit.exe to use the new SIP domain

 Changing the Application Contacts

First open ADSIEdit and go to the configuration node, and navigate to the Application Contacts folder:

 Once there, open each entry and modify the msRTCSIP-PrimaryUserAddress and Proxy address to use the new SIP domain:

 

Don't forget to restart the services that you have changed !!

Lync/SfB Disabled your AD Disabled Users

I have noticed this with many customers I have visited. Their off-boarding process usually misses disabling the user from Lync/SfB.

The end result is that users being disabled in AD are still active and visible in Lync/SfB; this also has licensing implications, especially with today's O365 licensing and auditing. Add to that, the DID number assigned to the user will still be in use and will not be freed up.

I came up with this script that will quickly go through the AD/SfB environment and spit-out (or also disable) all users that are already disabled in AD.

Download
v.0.01 - 2015-09-06 - Get-CsDisabledUsers.v.0.01.zip
v.0.02 - 2016-05-17 - Get-CsDisabledUsers.v.0.02.zip

Lync QoS Script

QoS has always been a hot discussion on the table when implementing Lync/SfB ... especially when you have voice traffic to deal with.

There are many great blogs out there that discuss the QoS settings and ports to use, and how to set them up; my favourite is this post by Jeff Schertz which inspired me to write this script.

This is a very simple scripts which I believe picks up where the above post left off; it will read the ports from the current environment, and create the GPO policies required for both servers and clients automatically (provided it has access to the AD environment).

Please run this script with administrative privileges, using a Domain Admin account.

Download
v.0.01 - 2015-03-16 - Create-QoS-Policy.v.0.01.zip
v.0.02 - 2017-01-31 - Create-QoS-Policy.v.0.02.zip

Lync Mirroring Status Disconnected

Ok, this is a very quick one that caught me by surprise. At one of our customers; changes to the Lync settings were not taking affect. Checking the replication status, I found that replication was down for over 10 days. Running "Get-CsManagementStoreReplicationStatus" I found ...

This immediately pointed me to the SQL servers. When I checked the servers, I found the primary server was completely down. The mirror server had taken over as the principle, but apparently, Lync wasn't talking to it :( ... Checking the mirroring status "Get-CsDatabaseMirrorState" confirmed this limbo state ...

Looking at the SQL Managment Studio on both servers; I found that both servers were showing the databases as "Principle"; while the failed server was showing "Principle, Disconnected / In Recovery"; the mirror server was showing "Principle, Disconnceted"

Solution

After a bit of research and asking around; I came to this article, which helped resolve the issue. I have summarized the steps below, so that it is easier for anyone searching for this in the future...

1. Connect to Mirror DB server
2. Click on "New Query..."
3. type the command "alter endpoint mirroring_endpoint state=stopped"
4. Press the button "Execute"
5. Wait until the command completes, at this point you have disabled the replication between the servers.
6. Execute the command "alter endpoint mirroring_endpoint state=started"
7. This will re-start the mirroring process, and this time, the database server will see the primary server as up, and will start replicating back to it the information that it lost.

At this point you have two options, of either leaving the second SQL server as the principle, and the original one as the Mirror, or you can failover the Databses back to the original state. In both cases, Lync doesn't mind, and doesn't care.

Sonus SBC AD Lookup Gotchas

I have recently been troubleshooting issues with a Sonus SBC 1000 doing call routing using AD lookups.

There are many blogs out there about how to do this, including the guide from Sonus themselves which is pretty descent.

Let me however, go into some of the gotchas that caught me by surprise, and are not well documented on the Sonus site...

AD Cache Lookup

There is a very clear note saying that it is "recommended" to have a USB stick attached to the SBC if you are going to use the AD Lookup in cached mode.

What there is no mention of, is the way the Sonus SBC uses the cache, and how it gets updated. This information was provided to me from Sonus TAC/Engineering, and is current as of the date of publishing this blog post; this applies to having the AD Configuration in "Updates" mode...

1. All domain controllers configured are treated equally; i.e. if any one of them responds back with a successful query, than the cache is valid, even if all the other queries fail.
2. The cache is dropped before the new cache is read; thus if the AD query fails, the system is left with "NO CACHE" unless you have a USB stick with a backup cache to be used.
3. if "ALL" domain controllers fail to respond, the SBC switches to online mode, and tries to query the domain controllers in order for the user in question.
4. The system will not try any failed domain controllers again until the next update cycle as configured in the "Cache Settings"

they have said that they are working on improving the process...

Case Sensitive Lookup

Apparently the lookup is case-sensitive; while simply testing for "=msRTCSIP-Line=" in your transformation table may work most of the time, if a Lync administrator decides to type "Tel:+xxxxx" instead of "tel:+xxxx" the query will fail to return a positive match.

To overcome this issue the recommendation is to use "(?i)=msRTCSIP-Line=" which would make the lookup case-insensitive.

Of course you can use the same "(?i)" in other locations too for matching without case.

 Lookup Limits

Transformation table lookups on the SBC have a hard limit of 256 characters for the string being manipulated. This is a hard limit and as per the Engineering team, the registers were never meant to hold large strings of data (such as memberof fields.

This is a major draw-back if you do routing based on group memberships or on other fields which may exceed this hard limit.