All posts by Korbyn

Polycom Trio 5.5.2 firmware

Normally I’m not posting about specific firmware, but in the 5.5.2.11338 (5.5.2 Rev AC) release for Polycom Trio’s (yup, plural, there are two models now 8800 and 8500) the codec SILK has been made available.  Skype for Business SILK has only been added as an experimental feature so to make use of it, you need to modify the Codec Priorities on the device.  Rumors abound that we may see SILK in VVX500 and VVX600 series devices in the near future, but that lower end devices may not have the processing power needed.

SILK will only be capable of being used in peer-to-peer type calls as it’s not available in the Conferencing MCU, and a reminder that it is “Experimental” at this time.  There appears to be some typo’s currently if you want to modify a FTP Provisioning server cfg file for your Trio’s, the above exported config reports that SILK is in ksps instead of kbps.  Perhaps this is the change over to Kilo Samples Per Second, or a just a typo…  Either way, something to be mindful of when modifying config files.

voice.codecPref.SILK.24ksps=”4″
voice.codecPref.SILK.16ksps=”5″
voice.codecPref.SILK.12ksps=”6″
voice.codecPref.SILK.8ksps=”7″

This release for the RealPresence Trio 8800 system includes the following highlights:  (pdf release notes here)

• Screen Mirroring on RealPresence Trio Solution

• Software Update using Windows Server

• RealPresence Trio 8800 System Media Keepalive

• Toggle Content and People Video Streams

• Skype for Business User Experience Enhancements

• Viewing a Different Calendar in Skype for Business Mode

• Dynamic Port Ranges for Video and Content

• Adding a PSTN Participant to a Call

• Displaying Multiple Calendar Meetings on Connected Monitor

• Web Sign in for Skype for Business Online

• Secure Single Sign-On (SSO) with Third-Party Supporting Solutions

• Managing Skype for Business Conference Participant Level in the Call Roster Screen

• Device Lock

• Client Media Port Ranges for Quality of Experience (QoE)

• Microsoft Quality of Experience Monitoring Server Protocol (MS-QoE)

• Exchange Web Services Discovery

• Unified Contact Store

• Alert Tones for Mute Status

• Dial Plan Normalization

• Dial Plan for SIP URI Dialing

• Join a Meeting using SIP URI

• Hybrid Line Registration

• User Log Upload

• Audio, Video, and Content Port Ranges

• Media Transport Ports for audio, video, and content

• Experimental: Support for SILK Audio Codec

Firmware for the Trio’s can be found here:  Polycom Voice Software

iOS 11.0.1 and Skype Mobility Client

*Fast Publish*

My version of a fast publish, mainly because I need more people to verify the issue, condition and if my suggested fix works for you as well, so please give feedback.

We were hearing client reports that they were unable to sign in on an iOS 11.0.1 updated device, or if/when they are able to sign in, they were getting kicked out after 10 mins.

After running an UCWA trace on the Frontends, the traffic for the user I was testing with literally just ended.  My intuition led me to think of the reverse proxy.

Quick scan though the settings and the timeout value was set to 960 seconds, 16 mins.  That doesn’t quite match the 10 min punting window, but I’ve seen weirder, and I like all-skype-timeout things to be 20 min or more.

We tested first with 3600 second and 1800 second timeout values and both were successful, the Skype Mobility client was not longer getting kicked out.  A 1200 setting will probably work, and may retry again tomorrow, but my preference for all Skype related firewall timeouts is 30 mins.

I checked our corporate environment, where we weren’t having issues, and the timeout was already set to 1800.  Not quite a pattern, but a possibly solution I hope.

Regular Skype Desktop clients are supposed to renew their connections every 5-15 minutes, and that the firewall timeouts need to be 20 minute or higher.  The Mac and iOS clients aren’t regular clients as they are using UCWA, https based connections.  I’ve seen with Netscalar if you leave the default timeouts at 180 instead of using 1200 or 1800, that the desktop client signs in, and is immediately signed back out.  Almost like there is a TTL minus 300 mechanism of some kind, that will end the clients connection if it hasn’t already renewed.  Just a guess though.  UCWA logging for the client activity ended very abruptly and dirty.

I welcome feedback on:
– if you have a web services time out setting of less 1200 and not having issues
– if you are having issues with less than a 1200 setting and raising it to 1200 or higher resolves
– if you are still having issues with a 1200 or a 1800 setting
– I’m also curious if you have a 600 second Time-out setting, does your iOS client kick out after 5 mins instead of 10 mins.

Thanks,

 

Skype for Business Debug Tools 7.0.1678.1

The current build of the Skype for Business Debug Tools, 7.0.1678.1 June 9 – 2017, has a lovely new requirement for yet another version of the Microsoft Visual C++.  This time it’s Visual C++ 2015 x64 version 14.0.23026 or higher.

Said version can be found here and you will want the x64 build.   After that, no problem with installation or usage, so far…

Of course now I have Visual C++ 2008 x4 versions, 2010 x2, 2012, 2013 and now 2015…

Health Agent Probes

If you were hoping for an in depth article on Skype for Business Health Agent Probes, keep on looking, you won’t find it here.  I did wrestle with one such probe failure, Event 56001 LS Health Agent.

One or more Health Agent Probes encountered an unexpected error. The component(s)/Service(s) intended to be monitored by the Probe may be functioning correctly.

Probes:  System.ServiceModel.Security.SecurityNegotiationException: Could not establish trust relationship for the SSL/TLS secure channel with authority ‘lync01.company.com’. blah blah blah.

SSL/TLS secure channel, naturally start checking the certs; nope, they’re all good.

Next, off to check IIS, maybe the certs are mixed up or something…  Opened up the Bindings for the Skype for Business External website to view the assigned cert, the port are wrong.  For some reason the External web site was assigned 80 and 443 instead of 8080 and 4443.  Internal was set to 8080 and 4443 instead of 80 and 443.  Very odd.  Joys of troubleshooting other peoples installations, and I have no idea if this was manually done or a glitch in the system somewhere along the way.

After juggling the ports around, didn’t even have restart, poof, Agent Health Probes all happy again.  Hopefully this shouldn’t be something that people encounter very often, but at least there are some clues to look at for drilling down as to why these “Health Probes” might be failing.

Update:  Published to fast.  Turned out someone messed with the Internal and External ports in the Topology.  Unfortunately just setting them back to the correct configuration isn’t enough, probably buried deep in the settings are more references to the Ports that do not update automatically when you republish.  Final resolution was to uninstall the Web Components and re-run the Deployment wizard, re-run the Server Component installation and the Certificate wizard.

Safe to say though, the Health Agent Probes are programed with the default Web site ports, changing them will likely result in probe failures.

VVX 5.5.x logon issue

I can’t take credit for this, but I document for my own future benefit as well as for the benefit of others.  A new client received a number of VVX phones which during the projects we standardized to 5.4.5 code but without a provisioning server, but that’s not important.  There were no issues with authenticating the phone with the Skype for business user account (not PIN, user account).  BUT when we went to test 5.5.1 firmware, the phones would not authenticate.  Even phones which were already authenticated prior to the update, were no longer able to sign in.

Setting the “dhcp.option43.override.stsUri” attribute of the phone, or manually setting “DHCP Option 43 Override STS-URI” setting under Settings | Provisioning Server, DHCP Menu, to the same value in DHCP Option 43, e.g. https://sfbfe01.company.com:443/CertProv/CertProvisioningService.svc  allowed the phones to perform user authentications again.

Near as I can figure, this “might” be a result of using a VLAN for the VVX and perhaps 5.5.1 code can’t properly retrieve the option 43 from DHCP, which it doesn’t have this issue 5.4.x code.  This is merely speculation.  Very odd.

 

Local SQL Services Startup issue

I’ve come across this issue a number of times over the years, rebooting a Lync or Skype server, specifically Std deployment type, and one of the three SQL Express Instances just doesn’t start up in time before the RTCSRV Frontend Service starts to start.  “Sometimes” it goes away with patching the local SQL instance up to SP2, but not often enough.  Could be a resourcing problem, but still, for a lab even, 4 processors and 8 Gb should be enough to start services up.

Enough is enough.  Why on earth what I’m about to show you isn’t done by default, is beyond me.  Why is the RTCSRV service on a Standard Edition Deployment, or for that matter on an Enterprise Deployment, though I’ve not encountered this on Enterprise Frontend Servers.

Using the SC command from an CMD Prompt (does not work from PowerShell) use the following command to make sure no other dependencies have already been made:  SC QC RTCSRV

Second last line you can see the current Dependencies, i.e. KeyIso in this case.

When modifying the dependency list, you have to include the existing, plus what ever you are wanting to add, separated by a forward slash (/).

 

sc config RtcSrv depend= KeyIso/MSSQL$LYNCLOCAL/MSSQL$RTC/MSSQL$RTCLOCAL

Re-run:  “SC QC RTCSRV”  to confirm your new dependencies have been successfully added.

Notice the change in the list of Dependencies.  You can also view this in the Services:

And if you want to get really nerdy, go into the Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RtcSrv
DependOnService

I’ve found that with this change, the RTCSRV service starts up nice and clean, and instead of taking about 25 minutes before crapping out, all the services have started up within 5 minutes of initiating a normal Reboot of the server.

I haven’t had need to try this on an Enterprise Server but the command should be similar, just minus the MSSQL$RTC.

sc config RtcSrv depend= KeyIso/MSSQL$LYNCLOCAL/MSSQL$RTCLOCAL

I still install at least SP2 for SQL 2014.  There were some performance issues in RTM that were resolved around CU7 or CU8, so SP1 should be your minimum anyway, that should help speed things up.  SQL Download Table

Magic CsDatabase Command

Hopefully the use of this will be rare for most, but its come up a couple times of late and magically solved a number of glitches, hiccups and downright headaches.  I’ll save the suspense and give it to you first, then the scenario’s.

Install-CsDatabase -Update -LocalDatabases

A) I needed to add a new SIP trunk to the Topology of a Lync 2013 environment, done it a thousand times with out issue.  Unfortunately this time the databases weren’t happy or in a properly updated state as the RTCSRV service crashed after running the Deployment Wizard, which also crashed, leaving the system in an in operable state.  With similar or the same error messages below, in scenario B.  In this case the CPSDyn and RTCDyn were irreparably damaged and un-mountable.  Fortunately from past experience with Lync 2010 database updates, I knew Dyn databases can be toasted without loss of life.  CPSDyn came back no problem with the Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn, but the RTCDyn database did not.  Lync 2013 had “deprecated” the use/need for the -update switch, so I didn’t even think about it and must have tried 15 other methods or variations of getting this Dyn database back.  @RealTimeUC and I both seemed to have the same divine inspiration, as I was typing, he also suggested “Try with the -Update switch”.  Low and behold, it worked.  RTCDyn database was brought back to life, and the Frontend RTCSRV service can finally start again.

B) A recent Standard Deployment of Skype for Business resulted in the starting of the RTCSRV, Call Park Server and RGS services.

LS Call Park Service Event ID 31008
Connection: Data Source=(local)\rtc;Initial Catalog=cpsdyn;Integrated Security=True
Message: Cannot open database “cpsdyn” requested by the login. The login failed.
Login failed for user ‘NT AUTHORITY\NETWORK SERVICE’.

LS Response Group Service Event ID 31201
Exception: System.Data.SqlClient.SqlException – Cannot open database “rgsconfig” requested by the login. The login failed.

Login failed for user ‘NT AUTHORITY\NETWORK SERVICE’.

LS User Services Event ID 32134
Back-end Database: rtcxds Connection string of:
driver={SQL Server Native Client 11.0};Trusted_Connection=yes;AutoTranslate=no;server=(local)\rtc;database=rtcxds;
Cause: Possible issues with back-end database.

I checked, and the 3 SQL Services were running (LYNCLOCAL, RTC and RTCLocal).  I also have a neat trick for these databases I’ll show in my next blog.

A coworker had seen this before and suggested using the SQL Mgmt tools and compare the permissions of the databases to a working one.

Forget that, I have a magic PS command.  I figured if it can bring back a missing database, why not correct the database permissions.  I ran the same command successfully, and the system came to life.

Summary

I don’t believe in short cuts through life, but work smarter, not necessarily harder.  PS is your friend.

Group Series Skype Meeting Join Issue

I would like to think I had a pretty darn good OCS/Lync mentor when I started transitioning from mainly an Exchange focus to more with actual Unified Communications.  One of his mantra’s, “If you set things up right, they just work”, case in point, Polycom’s Group Series.

Client/users were complaining that they were having troubles joining scheduled Skype for Business meetings from the console.  They were experiencing odd voice messages like “That number is not in service”, “That call can not be completed as dialed”, or just ring 1-2 dozen times and disconnect…  Yup, that ain’t right, and yes, those very much sound like PSTN dialing issues.

This is exactly why you deploy Monitor Reports.  Pulling up the activity for the meeting room in question, one can see that the GS500 in this case was in fact dialing the Skype Conference ID’s, some were 6 digit and some were 7, making a phone number that either didn’t normalize at all, or managed to resolve to International dialing rules.

Eventually the user has learned to just drag the GS device in to the meeting, which is the case in row 3 above.

Client was running version 6.0, and both 6.0 and 6.1 are supported with Skype for Business.  We provided the client with James Arber’s post for setting up Group Series devices.  It’s more about 5.x version, but most of the settings are still relevant.

In the scenario we were troubleshooting, Skype for Business was running CU272, but looking at the history of the devices, this behaviour was not recent and occurred with previous CU’s.  Updating the GS to 6.1 did not resolve the issue.

The critical setting that was required to make the system work was under Admin Settings | Network | Dialing Preference, and specifically the Voice and Video Dialing order.  Here the client had left it defaulted to H.323 instead of changing to SIP.  Changing this setting on other systems still running 6.0 didn’t have the desired affect, 6.1 and prioritizing SIP seems to be the magic trick here.  This environment also had no Gatekeepers or RMX type systems, strictly a Skype for Business environment, otherwise you may need to test out various scenarios if you are running a combined environment.

Group Series updates can be found here:  http://support.polycom.com/content/support/North_America/USA/en/support/video/group_series.html

 

Shared Line Appearance and SimRing

This would be my own version of a “Fast Publish”, and haven’t fully tested out all the different scenario’s, so provide feedback if you like.

A client was experimenting with with Skype’s Shared Line Appearance (SLA) and was experiencing a problem where the shared line would ring once and go straight to voice mail of the -Target.  In this particular scenario, the -Target was also a Delegate, but that shouldn’t be an issue.

After checking 82 other things, I then installed the Skype Resource Kit, configured Sefautil and pulled out Johan’s SefaUtil GUI script, and reviewed the settings of the delegates.  Turned out that the Target had their SimRing enabled.  As soon as it was off, SLA worked as expected.

A scenario I’ll have to try some time, is there the same issue when just a Delegate has SimRing enabled.  I don’t beleive this will be the case.

I do suspect that the Target object will not be able to use Call Forwarding either.

Skype4b Online SIPAddress/UPN Mismatch

A recent troubleshoot case for which I did not have enough alcohol for to deal with.  A client was enabled in Office 365 for Skype Online, but had issues with Signing into the Skype client.  Checked all the usual suspects like DNS, licensing, PEBCAK, all without success.  Everything in the Portal looked correct.

PowerShell time:
Import-Module SkypeOnlineConnector
$credential = Get-Credential
$session = New-CsOnlineSession -Credential $credential
Import-PSSession $session -AllowClobber

Get-CsOnlineUser -Identity “Bob Smith” | fl *voice*,*PSTN*,*lineuri*,ObjectID,*SIP*,UserPrincipalName

In my output, the the SipAddress and the SipProxyAddress was a combination of the users ObjectID and UserPrinciplaName.  Armed with this new information, the user was able to use the combined SIP address as the Sign in Address, then use his UPN name for the User Name, and then the password.  It worked, but not acceptable.

Unfortunately we are provided with few tools to affect changes.  I am more accustomed to On Premises deployments where I can play god, but in Skype Online, I just feel more like Perseus or Hercules, some god-like powers, but outside looking in and a little bitter…

Set-CsUser is very limited in the Skype Online PowerShell, and you definitely can not modify the SIP Address, as per Article ID: 2909916.  So, very frustrating.

Technically, the SIP address is supposed to be populated with the User Principal Name (UPN), but in some odd cases, this does not happen.  After trying way to many ways to list to correct this, the “only” way currently (April 4, 2017, it’s O365, things change monthly) is to change the users UPN attribute via PowerShell.  You can try Option A and see if it works.  This particular case required Option B, much more extreme and time consuming.

Option A)
1) Start Windows PowerShell
2) run: Install-Module -Name MSOnline
3) after installation is complete, run: Connect-MsolService and enter credentials.
4) Run: Get-MsolUser -UserPrincipalName “bob.smith@company.com” | fl to confirm successful connection.
5) To change the UPN: Set-MsolUserPrincipalName -UserPrincipalName “bob.smith@company.com” -NewUserPrincipalName “bob.smith@company.onmicrosoft.com”

Now wait and O365 Minute (15-60 minutes), and observe that the users Account changes in the Portal.  Their Sign in address as well as their default SMTP address change.  Using your SkypeOnline powershell, recheck the SIP address.

Option A is actually very similar to a Online user name change, where you would set the UPN to their new name in essence, and once changes have completed, you would just stop there.  In this situation, we want to change back to bob.smith@company.com, and assuming the above process worked,  run the following command and wait another O365 Minute:

6) Run: Set-MsolUserPrincipalName -UserPrincipalName “bob.smith@company.onmicrosoft.com” -NewUserPrincipalName “bob.smith@company.com”

Bob wasn’t so lucky in his case.

Option B)
1)  Make note of the user’s current UPN, and any other Skype properties like LineURI, ect:  Get-CsOnlineUser -Identity bob.smith@company.com | fl *voice*, *PSTN*, *lineuri*, ObjectID, *SIP*, UserPrincipalName
2) Skype Online disable the user by removing all Skype licensing including but not limited to: Skype for Business Cloud PBX, Skype for Business PSTN Conferencing, Skype for Business Online, Skype for Business PSTN Consumption
3) Wait a O365 minute for the users Skype properties to fall off
4) Follow steps 1-5 in Option A using PowerShell to modify the UPN and wait the O365 Minute.  Additionally check the Users Exchange email address properties.  Here you can also see the incorrect SIP address prior to changing the UPN. It should disappear and the EUM address should also change.  IF the default SMTP address has changed to the new UPN, but the EUM has not, manually change it by just removing the ObjectID from the address, and then remove the bad SIP address.
5) Run step 6 of Option A, wait the O365 Minute for the Primary email address and user name to change back.  Check the Email Addresses again, see that the EUM has also changed to the correct UPN/email address and not the ObjectID
6) Re-enable the Skype Licensing that you previously disabled, and wait for Skype Online Provisioning to take place again for the user.  (O365 minute)

Assuming everything went well, the SIP Address should end up populating with the UPN address once again.  Verify the Email Address properties, PS or Portal, see that EUM and SIP are correctly populated.

Site wide validation couldn’t hurt right, try this Skype Online PS command:

get-csonlineuser | where {$_.SipAddress -ne “sip:”+ $_.userprincipalname} | fl DisplayName,UserPrincipalName,Sip*

Oh, and no explanation as to why this might happen, though the internal thinking is it’s DirSync related, BUT this client never had a Domain let alone DirSync.