Skype for Business - Hey, Where Did my Response Groups Go?!?

Now, for its next trick, Skype for Business will make Response Groups in the Control Panel magically disappear!

Seriously? You have a lot of nerve, Skype For Business. 😉

A client opened a ticket recently for help recovering his Skype for Business Response Groups. He shared a picture of the empty Control Panel:

Bye, Felicia.

I had the client run several commands to verify the Response Groups were still seen via PowerShell. 'Get-CsRGSWorkflow' and 'Get-CsRGSQueue' both returned all workflows and queues that had been created. At this point, the only other thing I could think of that may prevent him from seeing the Response Groups was his permissions.

I asked to see which RBAC groups he was in and I noticed he was in both the 'CsReponseGroupAdministrator' and 'CsResponseGroupManager' groups. The 'admin' group manages all the Response Groups for a site, while the 'manager' groups allows for management of specific response groups (Technet Article).

Was it possible that somehow the 'manager' group was overwriting the permissions for the 'admin' group? As it turns out, yes, that appears to have been what happened. A search via Google produced a  blog post outlining the exact same problem in Lync 2013. I had the user remove his account from the 'manager' group and leave himself in the 'admin' group. A quick sign out/sign in forced the group change and he was able to see his Response Groups in the Control Panel again.

Polycom CX/VVX Phones - Why did my Transfer Fail?

I received an email from a client this week that users at his site could not complete transfers from their Polycom CX or VVX desk phones. Tranfers using the Skype for Business client worked perfectly, but any transfer via the desk phone failed. The client said when they initiated a transfer from a desk phone, it would either transfer to dead air or reply with a busy signal. This happened when the phone tried to transfer to an extension or the full 10 digit DID.

I broke this problem down into several things I wanted to examine. First off, was there something on the phone that wasn't allowing the transfer? I've found Polycom phone configuration files to be a blessing and a curse. You can edit the configuration files to do almost anything, however, searching thru 60-70 pages of a configuration guide to find the one setting you need can be... challenging?

Yes, challenging. We'll go with that. 😏

As it turns out, there is a field that needs to be enabled for transferring. Feel free to copy and paste the line below into a config file (.cfg) and then upload it to a phone to test:

<CONFIG_FILES
call.BlindTransferSpecialInterop="1"
/>

The other side of this issue is in Skype for Business. The cleint's user dial plan allowed for international calling and I specifically configured normalization rules for multiple internal number ranges at his site. I assumed that the phone would use the same dial plan as the user. Dialing out through the phone worked, but when a user tried to transfer a call it would fail. Are the phones using a different dial plan for transfers, somehow? Spoiler Alert: Yes.

To get transferring to work (along with the configuration change above), I had to add the same normalization rules in the user dial plan to the global dial plan. Once the normalization rules were in the global dial plan in Skype for Business, transferring worked like a charm.

I have a small request for this article - if you are someone who is better than me at Polycom phones, please explain if this is normal. Most phones I've worked with have transferring enabled by default. As for using one dial plan for making calls and another one for transferring - why is this a thing?

Comments and questions are always welcome.