Conferencing Modalities No Longer Function - MS16-065

Microsoft recently published a KB article related to a security bulletin MS16-065:

Symptoms

After you install the Microsoft .NET Framework Security Update MS16-065 on a Front End or Standard Edition server for Lync Server 2010, Lync Server 2013, or Skype for Business Server 2015, several conferencing modalities no longer function for internal users.

For a complete list of the .NET Framework updates that can cause this problem, see the Microsoft Security Bulletin MS16-065 - Important topic on the Microsoft TechNet website.

The following are known modalities affected by this issue:

·         Whiteboards

·         Uploading PowerPoint Presentations

·         Sharing Notes

·         Polls

·         Q&A

The error messages that users may receive when this problem occurs include the following:

·         We can’t connect to the server for presenting right now.

·         Network issues are keeping you from sharing notes and presenting whiteboards, polls and uploaded Pow…

·         An error occurred during the Skype Meeting.

I ran into this but it was not immediately apparent to which KB's this correlates to so I thought I would list out the ones that will cause this behavior and save someone else some time hunting:

Server 2008 R2:
KB3142024
KB3142033
KB3142037

Server 2012:
KB3142025
KB3142032
KB3142035

Server 2012 R2:
KB3142026
KB3142030
KB3142036

Update:

This also breaks the Lync Web App in Lync Server 2010 which is not documented in the KB at the time of this post. You will also need to add the following reg keys in [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\System.Net.ServicePointManager.SchSendAuxRecord]:

DWORD Name: C:\Program Files\Microsoft Lync Server 2010\OCSMCU\Web Meeting Conferencing\MeetingMCUSvc.exe
DWORD Value: 0

DWORD Name: C:\Windows\System32\inetsrv\w3wp.exe
DWORD Value: 0

Then restart the RTCMEETINGMCU service as well as perform an IISReset.

How to Disable Interfaces on AudioCodes Mediant 1000

One of our clients recently rolled out AudioCodes Element Management System (EMS) and noticed that they were receiving a lot of alarms about interfaces being down. You might also see these alarms show up on the gateway management page:

I wasn't able to find much online in the way of how to administratively down or disable the alarms on each gateway so I opened a support ticket figured it out and thought I should post this in the event that anyone else out there also needs to do this. 

First login to your gateway and determine which interface you want to turn disable the alarm on. The interfaces are read on the top row beginning as GB_0_1 on the left and then going two, three, four, etc, if you have another row of interfaces then it would be GB_X_1 with X being 1-9

Once you have written down which interface you want to remove, expand VoIP -> Network -> and select Ethernet Groups Table:

Select Index 0 (or whichever index has the interface under the member column) and then click edit:

In the edit record window click the drop down of the member you want to remove, and change it to none:

Click submit, and your changes should show the Index as no longer having that interface listed:

You will then need to restart the gateway for the changes to take effect 

Lync Server 2013 Services by Server Type

The following is a list of each server role and the associated Lync server services for Lync 2013:

Enterprise Edition Front End:

Lync Server Application Sharing

Lync Server Audio Test Service

Lync Server Audio/Video Conferencing

Lync Server Bandwidth Policy Service (Authentication)

Lync Server Bandwidth Policy Service (Core)

Lync Server Call park

Lync Server Conferencing Announcement

Lync Server Conferencing Attendant

Lync Server File Transfer Agent

Lync Server Front-End

Lync Server IM Conferencing

Lync Server Master Replicator Agent

Lync Server Mediation

Lync Server Replica Replicator Agent

Lync Server Response group

Lync Server Web Conferencing

Lync Server Web Conferencing Compatibility

Standard Edition Front End:

Lync Server Application Sharing

Lync Server Audio Test Service

Lync Server Audio/Video Conferencing

Lync Server Bandwidth Policy Service (Authentication)

Lync Server Bandwidth Policy Service (Core)

Lync Server Call park

Lync Server Conferencing Announcement

Lync Server Conferencing Attendant

Lync Server Front-End

Lync Server IM Conferencing

Lync Server Mediation

Lync Server Replica Replicator Agent

Lync Server Response group

Lync Server Web Conferencing

Lync Server Web Conferencing Compatibility

Mediation:

Lync Server Front-End

Lync Server Mediation

Lync Server Replica Replicator Agent

SBA:

Lync Server Front-End

Lync Server Mediation

Lync Server Replica Replicator Agent

Edge:

Lync Server Access Edge

Lync Server Audio/Video Authentication

Lync Server Audio/Video Edge

Lync Server Replica Replicator Agent 

Limitations on Transferring Conference Calls

A client recently reported that they were no longer able to transfer conference calls to their mobile phone. I invited them to a conference to test and I was able to, however upon performing a screen share session with them I confirmed that they were not able to. Upon logging into their environment with a test account I confirmed that the test account was also unable to transfer conference calls:

We then tested and we were able to transfer a call when it was a peer to peer session. This made me think that this has to be due to a conferencing or voice policy. I checked and found that there was no difference in the configuration between my configuration and the clients. I spent some time reproducing and looking at each of the client’s .UCCAPI logs thinking it was something that was being denied in the in-band-provisioning however nothing jumped out. 

I finally noticed that it was only allowing me to transfer the conference call to a mobile phone and not to any other user like it would in the peer-to-peer session. I immediately checked the Phones list on the client that was not working and all the fields were blank:

Upon configuring the client with a Mobile phone:

I was then able to transfer the conference call to my mobile:

Solution:

In order to transfer conference calls to another phone, the phone number must be associated with the user’s account either by one of the telephone fields in AD, or by configuring the number within the client itself. 

The Never Ending Call Forward

Recently I had a client that reported they had a user who went on vacation and had configured their call forwarding settings to forward all their calls to the office receptionist while they were out. When they returned they disabled call forwarding however all of their calls were still being forwarded to the receptionist. Now this is not the first time I have heard of this issue, so I began by first taking a look at their call forwarding settings using SEFAUtil as sometimes the client and the pool won't sync and it takes forcibly changing it via SEFAUtil to change the setting. I pulled the user's config however there was nothing set:

I then tried using Anthony Caragol's Call Forwarding Script just to double check and see if maybe SEFAUtil wasn't reporting something correctly but it reported the same thing:

I thought that this was odd, so I decided to reproduce the issue and pull a trace from the FE pool. Doing so I saw that the call rang the user, then was responded with a PRAC and the forwarding user's identity:

Looking at the closest traces yielded nothing so I decided to also trace from the SBA that the user was registered to. This showed that a Added P-Asserted-Identity from EPID ashirey@clientdomain.com was being sent. Meaning that an endpoint was causing the call forwarding. Now this also was not unheard of however I found it strange that her client was showing no call forwarding and it was and endpoint. So I asked the user to log off of her client and then wait 1 minute then sign back in an re-test. This also yielded the same behavior and same message in the trace. 

SOLUTION:

I was starting to run out of ideas and so I had one last thought, why not have the user that was receiving the forwarded calls also sign out. After having both users sign out and remain signed out for 5 minutes, then signing back in, the call forwarding was finally disabled. 

So when in doubt while troubleshooting call forwarding have all the users sign out that are involved.

Script: Pool Objects

After my issue this week with attempting to decommission a Lync 2013 pool due to a lingering object, I decided to write a simple script that takes the pool name that you are attempting to remove, and runs though all possible objects and outputs any missed that are still attached to the pool.

Download OrphanedObjects.ps1

I have tested and confirmed that this works on Lync 2013 and S4B. It does NOT work on Lync 2010, but if I get enough interest in a 2010 version I could modify it to work.

Searching for Orphaned Objects

Recently when decommissioning a Lync 2013 pool, I ran into an issue where it said that by publishing the topology and removing the pool I would orphan existing users, endpoints, or devices:

Consult your Skype for Business Server documentation to learn how to move or disable objects still homed on the pool. To find those objects, execute the following cmdLets: Get-CsUser, Get-CsExUmContact, Get-CsCommonAreaPhone, Get-CsAnalogDevice, Get-CsRgsWorkflow, Get-CsDialInConferencingAccessNumber, Get-CsAudioTestServiceApplication, Get-CsTrustedApplicationEndpoint, Get-CsPersistentChatEndpoint.

Now I knew there were more objects that could trigger the orphaned objects failure, so I also ran Get-CsConferenceDirectory, Get-CsTrustedApplication, Get-CsTrustedApplicationComputer, Get-CsTrustedApplicationEndpoint, Get-CsTrustedApplicationPool. The only result I got was aCsAudioTestServiceApplication: 

I attempted to remove this however there is no remove cmdlet, and there is no option to set it's registrar pool with Set-CsAudioTestServiceApplication. 

I confirmed with one of my co-workers that it was not possible to remove this, however it should not be an object that prevents the removal of a pool. So what was causing the hold? 

Solution:
I decided to go into the weeds and dumped all user objects from AD to a CSV via CDSVE ( csvde -f test.csv -r objectClass=user ), and then searched for all users who had the msRTCSIP-PrimaryHomeServer value that matched the Lync 2013 server. Low and behold there was a Lync Room System object that was still homed to the Lync 2013 pool. After moving this object to the new S4B pool, I was then able to publish the topology.

Lync 2013 to S4B CMS Migration Replication Issues

I recently moved the CMS from Lync 2013 to a new S4B pool for a project I was working on. I followed the normal procedure and re-ran bootstapper on all the nodes that make up the new pool hosting the CMS, as well as the old Lync 2013 pool to remove the CMS role. I verified that the S4B Master Replicator Agent and File Transfer Agent services were running on all four of the new S4B nodes. I rebooted all four of the new S4B servers individually and once complete I attempted to view the CMS replication status however it reported nothing was updating. All entries show UpToDate False, and all of them except the node I ran the Move-csManagmentServer cmdlet from and the edge servers show laststatusreport from around the time I performed the move:

I verified that I was able to download the Topology; I could see that FE01 was the ActiveMaster of the CMS:

I ran a trace using ManagmentCore scenario and saw a couple errors regarding the XDS-Replica folder:

This line stuck out particularly:

Query changes operation failed. Exception [System.UnauthorizedAccessException: Access to the path '\\S4BFENJ01.spscom.com\xds-replica\xds-master\xds-master\working\replication\tmp\0c112834-9f3e-49bc-ba01-fb0e4227e56e' is denied.

At this point I attempted to recreate the XDS-Replica folder by following Ken’s blog ( http://ucken.blogspot.com/2012/04/resetting-lync-cms-replication.htm ) however this didn’t seem to solve it. At this point I knew it had to be something to do with permissions/authentication. I checked and verified that all the servers in the new S4B pool were members of the RTCUniversalConfigReplicator group. 

Solution:
I finally enabled CAPI2 logs and saw that there was an expired certificate being passed. So I re-ran the deployment wizard, checked and sure enough the OAuth certificate had expired. Renewing the certificate and restarting each server propagated the OAuth certificate and replication began to work.