Archive for the ‘UC’ Category

Skype for Business – Deploying Handsets Checklist

November 30, 2017 1 comment

For many folks that have deployed Skype for Business (or one of its predecessors) this post might seem a bit dated. Still, I can’t help that lately, I’ve seen quite a number of issues arise while deploying handsets with Skype for Business.


When deploying handsets for Skype for Business, there are certain requirements that need to be met from a network and systems perspective to ensure that they can function properly. This post is mainly to provide my readers a checklist of sorts to ensure that phones can log in, function, as well as be managed.


First, some global basics.


NTP (DHCP Option 42): We should always ensure that all the devices on our network are getting the correct time, and handsets are no exception. When the handsets are not set to the right time it can cause issues with sign-in. Bonus level: ensure that the local time zone is being set by the management tool or offered via DHCP so that the phone automatically shows the right time for the location. DHCP Option 002 can be used to set the Time Offset:


Network Access: Verify that the handsets have access to critical services if they are located on a separate voice VLAN. Too often I see these dedicated VLAN’s not have access to things like Active Directory, Skype for Business, or in the case of Skype for Business Online, the Internet. Ensure that appropriate ports such as HTTPs (TCP/443) and the media ports are allowed.


SIP URI and the UPN: This one seems to rear its head more commonly. If your user’s Skype for Business sign-in address is, then their AD account’s UPN Suffix should be also. When the UPN Suffix is not the same as the SIP URI, then you get issues such as being prompted for the username at sign-in as well as calendar integration breaking. It is also important to note that ideally, the UPN Suffix and the primary SMTP domain are the same as well.


Phone Management: Are you using Skype for Business (on-premises or Online) to manage the firmware? Or are you using a third-party such as AudioCodes, EventZero, or Polycom? If the latter is true, then there are a few things you need to do to ensure that you will be able to successfully manage the devices.


The first thing when dealing with a 3rd party device manager is to ensure that DHCP Option 160 is set up. For some devices, they will search other options such as 66 or 161 but all of the 3rd party phones will look for Option 160.


We also need to make sure that the phones have access to the device manager. This ties back to the Network Access comment that I made above. If the handset is on a dedicated VLAN, you need to ensure that it has access to the device manager that will most likely be on a data network.


If you are using Office 365/Skype for Business Online, there is one more step you need to take. Within the O365 tenant, you need to set the EnableDeviceUpdate to False. If you don’t, every time the device signs in, it will get updated by Microsoft back to whatever their current released software is which many times is older than what is currently published by the manufacturers. The screen shot below shows that this tenant will provide updates to devices registered to it.

You will also want to make sure that Better Together over Ethernet (BToE) is set to True (see the EnableBetterTogetherOverEthernet setting in the screenshot above). The default is $True but I have seen a few cases where it was set to $False and causing issues.


Now that we have covered the basics that apply to both Online and On-premises, let’s focus in on a few things that only apply to On-premises:


DHCP Option 43: this option allows for Lync/Skype for Business clients to find the Lync/Skype for Business certificate provisioning server on the network. To get more details on this, we can go waaaay back to an old Lync 2010 Technet article: When DHCP Option 43 is not working correctly, phones cannot find the certificate provisioning server, which then means that the phones cannot sign-in due to not having the proper certificate.


DHCP Option 120: This option allows the phone to actually find the Front-end server. Most phones now will also look for Lyncdiscover records so this one is a bit more legacy. It’s always nice to have this published when dealing with on-prem as it can help if for some reason, you Lyncdiscover record is not working.


Verify Media Ports: This one is missed in many deployments. When using Skype for Business, our clients are set to use specific media ports (at least they should be per best practice). We look for these media ports for things like QoS. If these media ports are being blocked (see the Network Access point above) or being routed through a proxy, VPN, or a WAN Accelerator, we can see voice quality or dropped call issues arise. To find out more about planning out your Media Port range, check out Technet:


Now, one last comment, all of these things are for handsets to connect to Skype for Business (On-premises or Online) or Lync. With the recent announcements at Microsoft Ignite 2017, all of the phone vendors have announced that they will support Microsoft Teams with their devices. While none of the major vendor devices will register with Teams today, that will come and we will see what is needed for that in the (hopefully) near future. For more information about what might be coming for handsets with Microsoft Teams, check out this post:


Categories: Skype for Business, UC Tags: ,

Reflections on using Microsoft Teams at Ignite

October 2, 2017 Leave a comment

After spending a week at Microsoft Ignite, I thought I would give a quick reflection on how I used Microsoft Teams during the conference.

For background, I have been using Teams at work since it was released as a public preview. We utilize it quite heavily for group communication. In fact, we replaced GroupMe at our team event back in April with Microsoft Teams in order to communicate where people were at and what they were doing. Overall, I’ve been super happy with Teams for it’s original purpose of group communication.

First, Instant Messaging (IM). I utilized Teams as my primary (read: Only) IM client for the week of Ignite. Most of my messages were to my colleague who was at the conference with me. We would use IM to figure out where to meet up as we split up sessions that we went to in order to compare notes. This was super handy at times when a session I was in ended up early and his session was still going with good Q&A. I was able to know and slip in to catch some of the Q&A.

In addition to 1:1 IM, I used Teams to essentially live blog sessions back to my co-workers who were not able to attend. This was helpful as they could then ask questions that I would then ask in the session for them. I know other folks did similar things with shared OneNote notebooks but the live blog method worked for us.

Second, Voice. This is the area that surpised me. I have done many meetings on Teams. In fact, we have a monthly happy hour on Teams. What surprised me was when I got a call on the mobile client. I was not on the WiFi, I was just on 4g. If you have used the Skype for Business Mobile client, then you know how sketchy doing a VoIP call could be over 4g. Not so with Teams. Every call was super clear and stable. I was really impressed.

As I look forward to the change to Teams, I can honestly say, that from a user experience, I’m excited. When PSTN capabilities comes to Teams, it will very quickly replace Skype for Business as my primary client. While I realize that my experience might be unique based on how I work, I think that many organizations are going to benefit from these changes.

Categories: UC

Skype for Business at VMworld 2016

July 27, 2016 Leave a comment

Are you going to VMworld? Do you work with Skype for Business? Are you planning a deployment of Skype for Business that you want to virtualize? Are all your first choice sessions full?

If you answered “Yes” to any of these questions, you should register for VIRT7620: Successfully Virtualize and Operate your Microsoft Skype for Business Infrastructure on the VMware vSphere Platform.

I will be speaking alongside VMware IT on how they deployed Skype for Business and the best practices that were implemented. We will highlight why latency, IOPs and other resources are important to Skype for Business and other Real Time Protocol products.

We will also talk through what happens to a virtual machine when you vMotion it from one host to another and how that would impact Skype for Business.

I hope you will join us to hear all about Skype for Business and virtualization!

Categories: UC

Centralized Logging Service not working in Skype for Business

July 26, 2016 5 comments

I haven’t written a new post in a while as I have not been doing as many deployments lately. I have been focused more on evangelism and speaking with different organizations that are thinking about deploying Skype for Business.

That said, recently I had the opportunity to get back in to the game and start a deployment for a large organization. We were experiencing some issues that necessitated us to do some logging on the Front-end servers. I turned to my favorite tool for this, the CLSLogger which takes advantage of the Centralized Logging Service (CLS).

I would start up CLSLogger and when I attempted to start the scenario, I would get an error like this:

WARNING: Failed on 1 agents
Agent -, Reason - Error code - 20000, Message - Unknown error - 
Error calling agent; Could not connect to 
net.tcp:// The connection attempt lasted for 
a time span of 00:00:02.0228175. TCP error code 10061: 
No connection could be made because the target machine actively
 refused it . Please refer CLS logs for details.

When I went to the server and did a netstat, I saw that CLS was not actively listening. I should have seen the system listening on ports 50001-50003.

PS C:\Windows\system32> netstat -an | findstr 5000*
  UDP            *:*
  UDP           *:*
  UDP    [::]:500               *:*
  UDP    [::]:4500              *:*

I went round and round with this and ultimately had to open a case with Microsoft on it. After doing some traces and pulling the ETL logs, the Microsoft Engineer got back with and asked how we had generated the certificate. He was seeing the following message in the ETL log (which us mere mortals don’t have the ability to read and the real reason I’m writing this blog article):

29 TL_ERROR(TF_COMPONENT) [3]14CC.1728::06/08/2016-16:53:00.193.00000010 
(CLSAgent,CommandProcessor.Initialize:commandprocessor.cs(247))Exception - 
[System.ArgumentException: It is likely that certificate 
', OU=IT, O=Domain, C=US' 
may not have a private key that is capable of key exchange or the process 
may not have access rights for the private key. 
Please see inner exception for detail. ---> System.Security.Cryptography.CryptographicException: 
Invalid provider type specified.

We then looked at the certificates installed on the machine by running “certutil -store my”. (I’ve purposfully deleted identifying information and highlighted in red the Provider which is the key piece of information.)

PS C:\Windows\system32> certutil -store my
my "Personal"
================ Certificate 0 ================
Serial Number: 5xxxxxx
NotBefore: 4/15/2016 11:29 AM
NotAfter: 4/15/2019 11:59 AM
Subject: CN=, OU=IT, O=Domain, C=US
Non-root Certificate
Cert Hash(sha1): 39 2d..... 
  Key Container = le-360ab342
  Unique container name: 5d26bec417ed43b7840b7bf82c2fb363
  Provider = Microsoft Software Key Storage Provider
Encryption test passed
CertUtil: -store command completed successfully.

When we talked to the group that generated the certificate, we found that they used their own template instead of the Wizard in Skype for Business. While you certainly don’t have to use the Wizard, Skype for Business definitely has some requirements on the certs that will work with it. As an example, going to a key length longer that 256 usually doesn’t work out too well. In this case, the Provider was what was wrong.

I then turned to the Digicert Utility, one of our other favorite tools to generate the Certificate Request (CSR). This then utilized the correct Provider which is the Microsoft RSA SChannel Cryptographic Provider. After we issued the new cert and assigned it, we restarted the servers and checked the certs.

PS C:\Windows\system32> certutil -store my
my "Personal"
================ Certificate 0 ================
Serial Number: 5xxxxxx
 NotBefore: 6/9/2016 12:02 PM
 NotAfter: 6/9/2019 12:32 PM
Subject: CN=, OU=IT, O=Domain, C=US
Non-root Certificate
Cert Hash(sha1): 3c e2....
  Key Container = 70C232....
  Unique container name: 9ed77....
  Provider = Microsoft RSA SChannel Cryptographic Provider
Encryption test passed

We also started seeing CLS listening as expected:

PS C:\Windows\system32> netstat -an | findstr 5000*
  TCP              LISTENING
  TCP              LISTENING
  TCP              LISTENING
  TCP    [::]:50001             [::]:0                 LISTENING
  TCP    [::]:50002             [::]:0                 LISTENING
  TCP    [::]:50003             [::]:0                 LISTENING
  UDP            *:*
  UDP           *:*
  UDP    [::]:500               *:*
  UDP    [::]:4500              *:*

I hope this helps someone else who might end up in this situation.

Categories: Lync, UC

COUCUG Feb Meeting – Identity Management and #Office365

February 25, 2014 Leave a comment

For folks in the Denver area, the February meeting of the Colorado UC User Group is this Thursday (2/27) from 4-6pm at the Microsoft offices in the DTC.

We are going to be discussing Identity Management with Office365. This is an important topic if you are wanting to utilize Office365 with Single Sign-on or if you are running (or going to run) a Hybrid setup.

You can find out more and RSVP at

Categories: UC Tags: ,

#Lync Conferencing Anonymous User Time-out

January 16, 2014 Leave a comment

Ran into this awhile back and documented it in my “To Blog” note pile. Client wanted to know how long someone who isn’t the meeting owner (i.e. a guest from another company) could stay in a meeting before they were kicked out if the meeting owner (aka Presenter) dropped.  I found this article on Technet: and it explained the following:


Represents the amount of time an anonymous (unauthenticated) user can remain in a meeting without an authenticated user being present in that same meeting. For example, if this value is set to 15 minutes an anonymous user can stay in the meeting for, at most, 15 minutes before an authenticated user must join. If an authenticated user does not join before the grace period expires then the anonymous user will be removed from the meeting. This setting applies to both scheduled meetings and to ad-hoc meetings created by clicking Meet Now in Microsoft Lync.

 The AnonymousUserGracePeriod must be specified using the following format: days.hours:minutes:seconds (for example, 0.00:30:00 for 30 minutes). The grace period can be set to any value between 0 second and 1 day; the default value is 90 minutes (01:30:00).

Note that the default value is 90 minutes. That means if you have people in a call and all of the authenticated users drop, the non-authenticated users could continue to chat for 90 more minutes.

For this particular client, they wanted to ensure that if an authenticated user (aka Presenter) dropped from the call, that the other non-authenticated (aka Guests) user would drop after 5 minutes. We achieved this using the following command:

Get-CsUserServicesConfiguration | Set-CsUserServicesConfiguration -AnonymousUserGracePeriod "00:05:00"


Categories: Lync, UC Tags: ,

COUCUG January Meeting (1/30)

January 13, 2014 Leave a comment

The January meeting of the Colorado Unified Communications User Group (COUCUG) will be held on January 30th from 4-6pm at the Microsoft offices in the DTC. Plantronics will be sponsoring the meeting and will be providing food and drinks.

Our topics this month are:

  • Lync Meeting Etiquette
  • Deploying Lync Voice

Please RSVP at so we can bring in the right amount of food.

We’re looking forward to a great year with lots of great topics and hope you will join us.

Categories: Lync, UC Tags: ,