S4B Room System on Surface Pro 3

Recently MS have released the Skype for Business Room system app on the windows store. Seeing that it has been made to work on a surface pro in a dock, I dusted off an old SP3 found a dock and though, lets give this a crack. After much dicking around and installing windows 10 I installed the app from the store (https://www.microsoft.com/en-us/store/p/skype-room-system/9nblggh5799l)

The app shows 4 steps to config, I put in all the required details (After setting up a new Room System account in AD/Exch/S4B) and everything was going smoothly until I got to the last page. Please connect to a dock. WHAT?! The tablet is in the dock, whats the problem. The dock was working fine, with all peripherals attached through it.

Lesson here, vendors can mislead through not enough information. After much researching the app will only work with:

• A Surface Pro 4 i5 (SP4’s with other processors aren’t supported)
• A ‘Skype for Business’ dock, i.e:
  • Crestron RL2
  • Logitech Smart Dock
  • Polycom MSR

Its worth noting that most distributors and vendors provide these as a package

Its such a shame that MS have locked down the apps functionality, if you agree, please vote here: Skype for Business Feedback

Engaged tone when calling extension

A client was experiencing a weird issue where an extension could call outbound, but didn’t receive any incoming calls. Callers would hear the busy tone, and if exchange um hadn’t been configured, disconnected.

Comparing the CS-User to a known working extension showed no differences and there were no extension conflicts.

If you are having this issue, I’d recommend the following:

1. Open the report server
2. Click the user activity report
3. Search for the user you completed the testing from
4. Find the call
5. Open the details of the call, then open the details for the diagnostics of the call
   In my instance, I had the error message

   The routing rules did not result in a final response and callee is not enabled for Unified Messaging

   

Greig from greiginsydney has seen this before and reports that it is caused by bad firmware adding an incorrect call forward rule (Also, his blog is beyond wizardry and you should definitely check it out).

Following Greig’s steps and re-creating the AD account and Lync account resolved the issue.

Polycom VVX Phone Manager Script

James Cussen has wrote an excellent script for managing Polycom VVX phones.

Its really intuitive and assist with management migrations from phone systems where endpoints and their IP addresses were easy to see (Think asterisk sip show peers). You can easily see all VVX phones that are in the monitoring DB as well as search subnets

This tool is absolutely legendary and can be downloaded from technet Here.

James also has a really good write up here outlining all the features and usage.

PIN Authentication Error

I was having issues with a desk phone (Specifically a Polycom VVX310 running 5.4.0.10182) signing in to Lync 2013 with Ext/Pin. When attempting auth the phone would simply return “Lync Sign in Failed”. Pin Auth had been previously working and no changes to DNS or DHCP had been made and all certificates were valid.

I cranked up the logs on the device and still couldn’t see any issues. It was grabbing the CA on boot and would contact Lync and get a webticket, however the following in the log raised an eyebrow.

0202115811|tickt|*|00|m_validUntil [0]
0202115811|tickt|*|00|m_validityDuration [0]
0202115811|tickt|*|00|m_bCertExists [0]
0202115811|tickt|*|00|m_bCertExpired [1]
0202115811|tickt|*|00|m_eErrorCode [9]

Doubting the HTTPS certificate on the certificate service, I opened and confirmed that it was still valid and trusted.

The next step was to test an alternate phone and an alternate site. Same issue. This points us back to the issue being lync wide.

Luckily there are a few powershell cmdlets that we can use to test the web ticket service.

Test-CSClientAuth will allow us to test NTLM authentication against the web ticket service. TechNet article here

Test-CSPhoneBootsrap will allow us to test PIN/EXT auth against the web ticket service. TechNet article here

When testing these directly from your lync server you will need to fill out -TargetFqdn and -TargetURI to avoid DHCP lookups/failure. You can alternatively install the module on a PC that has DHCP and test from there.

Typical usage and responses for these cmdlets:

PS> Test-CsClientAuth -UserSipAddress USER@SIPDOMAIN -TargetFqdn LYNCSERVER.DOMAIN
cmdlet Test-CsClientAuthentication at command pipeline position 1
Supply values for the following parameters:
UserCredential


Target Fqdn : LYNCSERVER.DOMAIN
Target Uri : https://LYNCSERVER.DOMAIN:443/CertProv/CertProvisioningService.svc
Result : Success
Latency : 00:00:00.6313045
Error Message :
Diagnosis :


PS> Test-CsPhoneBootstrap -UserSipAddress USER@DOMAIN -PhoneOrExt "EXT" -PIN "PIN" -TargetFqdn LYNCSERVER.DOMAIN -TargetUri "https://LYNCSERVER.DOMAIN:443/CertProv/CertProvisioningService.svc"

Target Fqdn : LYNCSERVER.DOMAIN
Target Uri : https://LYNCSERVER.DOMAIN:443/CertProv/CertProvisioningService.svc
Result : Failure
Latency : 00:00:00.0973450
Error Message : No response received for Web-Ticket service.
 Inner Exception:The HTTP request is unauthorized with client authentication scheme 'Basic'. The authentication header received from the
 server was 'Basic realm ="LYNC"'.
 Inner Exception:The remote server returned an error: (401) Unauthorized.

Diagnosis :
 Inner Diagnosis:Warning : 120 LYNCSERVER.DOMAIN "InvalidPin"
 X-Ms-diagnostics : 28003;source="LYNCSERVER.DOMAIN";reason="The pin is invalid.";faultcode="wsse:FailedAuthentication"
 X-MS-Server-Fqdn : LYNCSERVER.DOMAIN
 Strict-Transport-Security : max-age=31536000; includeSubDomains
 X-Content-Type-Options : nosniff
 Content-Length : 4897
 Cache-Control : private
 Content-Type : text/html; charset=utf-8
 Date : Thu, 02 Feb 2017 01:20:52 GMT
 Server : Microsoft-IIS/8.0
 WWW-Authenticate : Basic realm ="LYNC"
 X-Powered-By : ASP.NET

As you can see above, the reason reported back was invalid pin. In my case I wasn’t getting a response from the web-ticket at all (Above shown as demonstration)

So the issue was with the web service not responding. I restarted the internal web service within IIS and tested again. This resolved the issue and users were able to use ext/pin sign in again.