Move User from Online to Server Fails

Issue:

When trying to move a user from Skype for Business Online to Skype for Business Server, the following error was being output in the Skype for Business Server Control Panel – “Index was outside the bounds of the array” – not the most helpful issue to troubleshoot!

Troubleshooting:

A customer had recently requested support for the migration to SfB Online to SfB Server for a subset of users.

After initially understanding why this migration scenario was taking place, I began to look at the configuration in its entirety:

  • All Skype for Business Servers were running the latest CU
  • The SfB Server Topology was correctly and successfully published with no warnings or errors
  • All firewall ports had been opened correctly
  • Public DNS was pointing to the on-premise estate, for all required records
  • A Shared SIP Address space had been enabled
  • The Skype for Business control panel Hybrid wizard confirmed “all prerequisites had been met”

When testing a move of a user myself, I too encountered the error the customer had been reporting, which was;

“Index was outside the bounds of the array” – not the most helpful issue to troubleshoot!

The same occurred too when trying to move a user using PowerShell, with the appropriate switches.

As we had not implemented the solution, it was time to take a step back and look at all “moving components” within this scenario, including AAD Connect and ADFS.

Resolution:

When viewing the attributes that were being synchronised from the customers AD to Azure AD, I noticed that none of the MS-RTC* Attributes were included… hmmmm…..

After speaking with the customer, I then determined that Skype for Business Server had been install AFTER the installation of AAD Connect!

We decided to “Refresh the Directory Schema” using the AAD Connect Wizard, o ensure that our SfB attributes were being synced.

Following on from the refresh, we could then complete the procedure of moving a user from Online to Server, for those that needed to be migrated.

Persistent Chat – All Channel Servers are down

I was recently rebuilding my home lab, purely as a refresher when I ran into a (new for me) hurdle when deploying Persistent Chat.

I had deployed;

  • Single standard Edition Server
  • SQL Server with Reporting Services, hosting Monitoring and Archiving

I had then decided to update my deployment by adding Persistent Chat to my Standard Edition Server (Collocated)

  • My lab was running the most current windows updates and SfB Updates
  • I updated my topology to include pChat
    • FQDN – SE01.uccorey.local
    • SQL Store – SE01.uccorey.local\rtc
    • File Share – SE01.uccorey.local\UCShare (File Share)
    • Remaining options left at default
  • Successfully published my topology with no issues
  • Started the Skype for Business Persistent Chat Service

Issue:

When I then went to manage the service, via the Skype for Business Server Control Panel, I was presented with the following error;

CSCPError

Solution:

The first area I checked was the event viewer logs, initially the “Lync Server” logs were not showing any issues and were only capturing my starting and stopping of the service.

After reviewing the application log, the following error was being presented;

EventViewerError

After seeing this, I updated the permissions, on the MGC databases, under the RTC SQL instance located on my Standard Edition Server and then for good measure, restarted the server – which corrected the issue and allowed me to continue on with my pChat configuration.

Hope this helps you!

Skype for Business SEFA Util

For those wondering, Secondary Extension Feature Activation – SEFA 🙂

I am slow off the mark with this one, but for those Administrators that have been using Lync Server 2013 SEFA Util, you will be pleased to know what a Skype for Business iteration has now been released!

Download here

Continue reading

Centralised Logging Agent – Key does not exist

I hope everyone is well and enjoying their Skype for Business experiences, today’s post is more of a quick tip as opposed to in depth troubleshooting.

The fix will help you with you when troubleshooting at the component level though!

So a colleague of mine was having issues with Unified Messaging integration (which turned out to be a quick fix with OCSUMUTIL.exe), during the troubleshooting process I suggest he used the CLS logging tool.

Continue reading