Category: Skype for Business

February 23rd, 2018 by Skype for Business News Aggregator

Posted in Skype for Business

February 23rd, 2018 by Skype for Business News Aggregator

It's amazing watching the adoption journey of Microsoft teams among organizations and how it is quickly becoming a mission critical tool. For me, it's mission critical because of the collaboration and teamwork that's occurring inside, and the data that is being stored is quickly becoming the heartbeat of many organizations and their project teams. There is one challenge however with storing proprietary and sensitive data in Microsoft Teams, as users are accessing the data using the Teams app on not just their PC or laptop, but mobile devices and other (even unmanaged) computers as they perform their job – if that data is leaked/spilled/exposed or compromised, it could put the organization at risk, and as IT Professionals we need to help protect against this risk.

Not to worry – Azure Active Directory Conditional Access to the rescue! Using AzureAD Conditional Access, we will ensure Microsoft Teams is only accessed on devices that are managed, whether they are Active Directory domain joined, Azure AD joined or managed by Intune. This is very easy and straight forward to setup, let's take a look together.

Important: Conditional Access requires AzureAD Premium. I won't be discussing licensing requirements in this article – please reference this site for more information.

In the Azure Portal, I am going to create a new AzureAD Conditional Access policy with the following configuration:

  • Users and Groups: "All Users"
  • Cloud apps: (Include) "Microsoft Teams"
  • Conditions: Client Apps -> Configure "Yes" -> Select Client Apps -> check "Browser" and "Mobile apps and desktop clients"

  • Access Controls: Grant Access -> Check "Require Domain Joined" and "Require device to be marked as compliant"

Important: If you check "Require device to be marked as compliant" you must create a device compliance policy in Intune. This will ensure devices such as iOS, Android, Windows, Mac that try to access Microsoft Teams using either the app, client or website must be Intune MDM enrolled (which requires an Intune subscription). If accessed from a Windows PC and is Active Directory domain joined or Azure AD joined, require MDM enrollment will not apply. Here's what an example Device Compliance policy looks like in Intune:

Back to Conditional Access…


  • Enable Policy: "On"


    Now the policy is created, let's test this out. It should deny access to Microsoft Teams.


    From a Windows PC that is unmanaged (not joined to Azure AD, Active Directory, or MDM enrolled):


    From a Web browser:

    Notice the error reads "Windows device is not in required device state: compliant"


    From the Microsoft Teams Windows Desktop Application:

    Next, from an iPad Pro (iOS) that is unmanaged (not MDM enrolled):


    Notice it gives me the option to enroll in MDM (Intune), pretty cool!

This is a quick and easy way to ensure that users are using Microsoft Teams on managed devices, where IT can control the configuration of the device and ensure the device is healthy and compliant. What's more is this policy can be reversed and disallow users from using the Teams web client if that becomes a requirement.

If you have questions or feedback, let me know in the comments below. Enjoy and have fun!

Posted in Skype for Business

February 22nd, 2018 by Skype for Business News Aggregator

The Supportability and Digital Support teams are pleased to announce the official launch of the SaRA Sign-In diagnostic for Skype for Business.


The Skype for Business SaRA sign-in scenario supports the following versions of Skype for Business:

  • Skype for Business 2015
  • Skype for Business 2016

Online Checks

  • Determines if the user is provisioned for Skype for Business in Office 365
  • Analyze SipProxyAddress vs. UPN for miss-match
  • Checks to see if user is soft deleted:

Actions it can take

  • Enables and Disables IDCRL logging
  • Clear Sign-in Cache
  • Check and Clear Check for ClockSkew DWORD in the registry

Posted in Skype for Business

February 22nd, 2018 by Skype for Business News Aggregator

If someone published your office’s chat logs, would you be okay with it…or wince at what people will find in them?

Most of us are in the latter category. I’m not even sure I’d be okay with it! But I’m at least certain that our chat logs are clean of intellectual property and PII. How do I know that? After reading this post, you’ll understand.

What’s Going On in Your Office’s Chat App?

This topic came from an article I saw in NewsDay yesterday: Workplace messaging apps offer flexibility, require vigilance –

The article reminds readers to stay vigilant over their messaging apps: Teams, Slack, Skype for Business, HipChat/Stride and the like. Good advice.

But let’s go further. HOW do we stay vigilant? How could we make sure employees stick to work-related (or perhaps I should say “work-appropriate”) conversation topics?

The article gives the following as a solution: “Firms should institute a workplace messaging policy and outline best practices to avoid abuse or unwanted distractions.” True! But there isn’t much beyond that.

Fortunately, keeping office chat to office topics isn’t too hard. In fact, we can take care of it in less than 10 minutes. In this post I’m laying out a way to not only institute a workplace messaging policy, but use human psychology to enforce it!

Institute A 3-Part Workplace Messaging Policy
First, if you don’t have a messaging policy in place already, make one. Here’s a simple workplace messaging policy anyone can use. It’s simple, only has 3 parts, and works for all messaging apps.

  1. All messaging clients are set to Full Logging.
  2. All conversations are kept in logs. If you’re chatting, your conversation is logged.
  3. All logs are included in the company’s regular backup schedule.

Okay, now you have your policy. Next, we have to spread the word. All employees need to know about this.

Give All Employees a 5-Minute Policy Brief

Informing all employees of a messaging policy only takes 5 minutes. Send them the following details via email. Or announce it at an all-hands gathering. Or send a message in chat!

  1. Tell everyone that the conversations are logged.
  2. Tell them where the logs are kept.
  3. Tell them the logs are backed up, where, and why.
  4. Employees must avoid discussing confidential material via messaging (e.g. banking information, PII).
  5. Work-related conversations should stay work-appropriate. If you need to chat about personal matters, do so privately.
  6. Finally, tell them you may use information from chat logs in customer meetings or quote documents.

That’s it!

Messaging Policy for Office Chat
You can be a LITTLE more specific than this…

Human Psychology Helps You Enforce This Policy

Seems too simple, right? There must be a trick. And there is…but it’s one you don’t need to do anything about. It works because humans think & act in certain ways.

Informing people of chat logs & why you’re backing them up isn’t just for their edification. It also creates an impression in their mind. Think about this—when you walk into a store and see one of those, “Smile! You’re on camera” signs, doesn’t it trigger an unconscious reaction? “Oh, right, better not do anything dumb.”

Nobody’s assuming you went there to shoplift or cause a scene. But the impression still pops into your head. The same thing happens with a messaging policy. When people know their work conversations are recorded…they tend to self-police.

(There’s always an exception, but we’re talking in general terms here.)

You can periodically remind employees of the policy by referencing the conversation logs. Any reason will do…here’s a couple I dredged up from our own office’s 2017 conversations:

  • “I don’t have X’s email. Is it in your conversation history?”
  • “Customer B wants to know status on their migration. Didn’t you guys talk about that in chat yesterday? Could you send me the log?”

These act as subtle reminders. The logs exist. Chats are recorded. Make sure you stick to work stuff!

Setting Up Logs for Backup

In order to fulfill this messaging policy, you’ll need to keep backups of chat conversation logs. I seriously hope you’re doing this anyway…but if not, let me give you a reminder!

backup photo
A badly-needed keyboard addition!
Photo by Got Credit
  • Server logs: Included with server backups. (If you’re not backing up servers, call us immediately!) For Skype for Business Server deployments, make sure the Centralized Logging Service is enabled.
  • Desktop Client logs: Capture logs from users’ computers by including these folders in their workstation backups.
    • Skype for Business 2016: %userprofile%AppDataLocalMicrosoftOffice16.0LyncTracing
    • Lync 2013/Skype for Business 2015: %userprofile%AppDataLocalMicrosoftOffice15.0LyncTracing
    • Web App Log location: %userprofile%AppDataLocalMicrosoftLWAPluginTracing (File name: LWAJSPersistent#.log)
  • Cloud logs (Teams, Slack): These are backed up by their respective cloud services. If you want to pull down extra copies for your own backups, here’s some help:

Workplace Messaging Policy: A Good Idea for All Teams, Slack, Skype4B Users

By now you’ve figured out why I’m not worried about our chat logs. Yes, we have a messaging policy here at PlanetMagpie. It’s more or less the same as what you just read. We’re on Skype for Business Server; the policy addresses our Instant Messaging Conversations.

You can expand on this messaging policy, of course. It all depends on how your office uses chat apps. That way you make sure they’re sticking to work-appropriate topics!

Do you use a messaging policy now? What kind?


The post How to Stay Vigilant Over Office Chat: Implement a Messaging Policy appeared first on The Skype for Business Insider.

Posted in Skype for Business

February 22nd, 2018 by Skype for Business News Aggregator
In the previous blog post, we walked through the features of Skype for Business and Teams co-existence and also covered how to configure interoperability between these two popular communications platforms. In this blog post, we take a close peek under the hood of what goes on when a user on Teams makes a video call to Skype for Business user homed on-premise. Using the Skype for Business server debugging tools, we capture the SIP messages to get a more in-depth technical understanding of video interoperability between the Teams cloud and an on-premise Skype for Business Server
Just to recap, our test environment here involves two users who are both enabled for Skype for Business as well as Teams. The first user Jack Reacher is homed on an on-premise Skype for Business FE pool prefers to use Skype for Business for audio/video calls while the other user Helen Rodin prefer to use Teams instead for all calls. Recall that in our last blog post, we configure the global Teams interop policy to use Skype for Business as the default client for audio/video calls while allowing users to override this policy by configuring their preferences in the Teams client. The global Teams interop policy is thus configured as shown in the diagram below:
With this policy, there is nothing that Jack needs to do as the default behaviour will be for all incoming audio/video calls to be land on his Skype for Business client. So when Helen, a Teams user initiates a call to Jack from her Teams client, Jack's Skype for Business client will ring and allow him to answer the call, thereby establishing an audio/video session between a Teams client and a Skype for Business client as shown in the diagrams below:
To capture the SIP details of this call, we use the CLS logging tool in one of the Skype for Business FE servers and set the logging scenario to AlwaysOn as shown below:
Once the call has been established between Jack and Helen, we retrieve the logs and use the Snooper tool to look at the SIP messages and we can find some interesting aspects of video interoperability between Skype for Business and Teams. First, lets take a look at the SIP INVITE message that is coming into Skype for Business client from the Teams client:
First thing that we can notice is that the INVITE appears to come from a regular SIP user:

Start-Line: INVITE;maddr=lyncfe1.ucprimer.local SIP/2.0
From: "Helen Rodin"<>;epid=00411A4CB4;tag=2d58dc6337

However, we know that Teams is not a SIP client, but it appears as a SIP client when calling Skype for Business. Next, we look at the contact header:

Contact: <;;transport=Tls;ms-opaque=e63097266c25ebd8>;isGateway;text;audio;video;image;application

The contact header tells us that there is a Skype-Teams gateway involved and the SIP address of the gateway for subsequent communications is on port 50105 and we can see the 'isGateway' flag is present. Next, we look at the Via fields:

Via: SIP/2.0/TLS;branch=z9hG4bK936FC3A4.F14CF28B96306D96;branched=FALSE
Via: SIP/2.0/TLS;branch=z9hG4bK6CA8D425.19305D0ECBA8E13F;branched=FALSE;ms-received-port=49827;ms-received-cid=5F01E00
Via: SIP/2.0/TLS;branch=z9hG4bK1410E788.49C03C38832F9126;branched=FALSE;ms-internal-info="atIxptmkbjd1izrPFAA_tlE0ICVS89nY4xfi_zIeokxfs4PMBJhPKeTwAA";ms-received-port=40625;ms-received-cid=37200
Via: SIP/2.0/TLS;branch=z9hG4bK17FB1738.39BC82FC440BC126;branched=TRUE;ms-received-port=54374;ms-received-cid=4793A400
Via: SIP/2.0/TLS;branch=z9hG4bK32B1B08D.5A4744E92508B126;branched=FALSE;ms-received-port=43859;ms-received-cid=329B7100
Via: SIP/2.0/TLS;branch=z9hG4bKEB7318DA.9762BB515AB68125;branched=FALSE;ms-received-port=55236;ms-received-cid=31BB6200
Via: SIP/2.0/TLS;branch=z9hG4bKd1aab0d2;received=;ms-received-port=3009;ms-received-cid=402C1C00

The Via fields shows us the path of taken by the messages since every proxy in the request path adds to top of the “Via” the address and port on which it received the message, than forwards it onwards. The first two Via IP addresses are of the on-premise FE Pool and the Edge Server. The third and sixth Via IP address (Singapore) and (USA) are from the Microsoft cloud and are likely to be addresses of the gateways handling call interop between Skype and Teams. Let's take a closer look at the SIP message:
o=- 0 0 IN IP4
The origin IP appears to belong to domain located in the US.

a=x-mediabw:main-video send=12000;recv=12000
This indicates the max bandwidth allowable for video is 12000kbps or 12Mbps, which is more than enough for high definition video up to 1080p30

m=audio 3480 RTP/SAVP 117 104 114 9 112 111 18 0 8 103 116 115 97 13 118 119 101
This indicates the audio codecs that are supported in order of preference - 117 is for G.722 while 104 is SILK and 114 is RTA

a=candidate:4 1 UDP 184547839 3480 typ relay raddr rport 50008 MTURNID 2486776825723936754
a=candidate:4 2 UDP 184547326 3480 typ relay raddr rport 50009 MTURNID 14569895359562254455
Details of the ICE candidates will not be covered here since they are well covered in many articles. This is a good Ignite session to understand more details regarding how ICE works in Teams:

Lets scroll further down the SIP message:
m=video 3480 RTP/SAVP 122 107 99 123
This indicates the video codecs that are supported in order of preference - 122 is the Microsoft implementation of SVC known as X-H264UC while 107 is industry standard H.264 protocol. These are the only 2 video codecs supported by Teams at this time.

After the necessary ICE checks and codec negotiations are complete, we can see the 200 OK SIP message as shown:
Finally, to end the session we hang up the call from the Skype for Business client which results in a SIP BYE message from the gateway
In conclusion, we can see that audio/video interoperability between Skype for Business and Teams involves a gateway which is not surprising given that Teams is not a SIP client but a http client that uses REST for signalling. However, the audio and video codecs are pretty much standard ones being used by Skype for Business as well as other industry standard audio/video endpoints, namely G.722 and H.264. This adoption of industry standard codecs by Teams will play a key factor in interoperability solutions that will be coming in the near future and we will cover these in future blog posts.

Posted in Skype for Business

February 21st, 2018 by Skype for Business News Aggregator

Microsoft has released the Anonymous Join feature for Teams Meetings.  You can use this feature by the following procedure.

  • Create and join a scheduled or adhoc meeting


  • Copy the meeting join information, you can do this by opening the meeting after creating.
  • Launch either Edge (In-Private) or Chrome (Incognito)   // Firefox and Safari are not supported yet
  • Paste the meeting join URL into the address bar
  • When prompted, use the web client to join the meeting anonymously



  • Admit the anonymous user into the meeting from the lobby


Posted in Skype for Business

February 21st, 2018 by Skype for Business News Aggregator

Don’t you just hate it when you’ve been doing things the right way for so long that you actually forget or don’t realize why it is “the right way”.  The Exchange UM Certificate is one such example.  I’ve been deploying OCS, Lync, Skype for 10+ years now, and Exchange before that since the 5.0 days (frack I’m old)…  99% of the time when integrating Skype with Exchange Unified Messaging, the UM role has either been left out or simply not configured.  I’m not going into the configuration of UM, there are a tonne of articles to that effect, but one item of extreme importance that is not always clear; The Subject Name for the Certificate used for the UM role(s) MUST be the FQDN of the server itself.

Most of the time because the certs used on Exchange servers have been deployed for a while, and a lot of the time Public Certs are already deployed on Exchange servers, BUT Public Certs now must use valid Top Level Domain Names e.g. can’t use .local .lan .domain.  So you create a internal CA cert with the FQDN of the server and assign it, no problems.  But, every now and then you come across a customer with internal and external domains matching, and they have added the server FQDN to the SAN list.  Internal calls to the the Subscriber Access line work, great, moving on…  Opps, did someone forgot to test externally, through the Edge, wait what, media failure, dang.

Ok, story time over, time to look in the weeds at the technical mumbo jumbo.

Symptom 1 – Call connects, but no bing bong “To access your mailbox…” when a User is working remotely and connected to their Edge server and trying to connect to Voicemail.

Symptom 2  – Not every time, but Event ID 32263 LS User Services error shows up in the Lync Event Log on the Frontends
Error code: 0xC3E93C2F(SIPPROXY_E_UNKNOWN_USER_OR_EPID), Error identifier: NotifySingle.Notify
Cause: Possible issues with the other front end or with this front end.

Symptom 3 – Call Detail Reports, Diagnostic ID 21 – “Call failed to establish due to a media connectivity failure where one endpoint is of unknown type”

Now for the “why”.  I’m such a GenX, I need the “why”.  Extensive logging, and reviewing of logs, and yes, support with Microsoft, I kept noticing something odd in the SIP Trace.  After the 180 Ringing and 200 OK, the ACK switched to, then delay, and then BYE.  MS went down a few other roads regarding networking, PowerShell commands, ports, port settings, and about 6 Gb more worth of logging, but this Autodiscover thing kept bugging me.

Finally we looked at the cert on the UM servers (Exchange 2010, two dedicated UM role servers), to check and make sure all the roots, intermediates and what not (FYI, this Cert checklist link, is handy have).  First thing that popped up to me, the Subject name of the Cert assigned to the UM role is yes,  The SAN list did contain the FQDN of both Servers.

Of course this seems silly, no where have I seen it documented that the Subject Name MUST be the FQDN of the UM server, but lets give that a try.  Two new internal CA certs were generated, SN and SAN being the server FQDN, assigned to the UM role, and services restarted.

Calls work.  Mothersmurfer…

I must reiterate, we made absolutely no other changes other than to replace the cert.

I did notice that in the autodiscover sip trace that there is a field, but this was insufficient for connecting calls through the Edge, even with name resolution for autodiscover hard codes in the HOSTS file to point to a UM server.  Somewhere in the code, the SIP call appears to switch to the Subject Name of the Cert for both resolution and MTLS, and it must be this way for Edge users to connect to Voice mail, and Auto Attendants too I suspect, but did not have one to test or work with.

An additional link of interest, a link to narrowing the audio port range of your Exchange UM servers and set for QoS.

Posted in Skype for Business

February 20th, 2018 by Skype for Business News Aggregator

In this episode of ICYMI: Skype for Business Server 2015 – January 2018 Update

If you were overwhelmed in late January by the rapid release of a bunch of Skype for Business and Teams features, you weren’t alone. I wanted to take a minute to highlight some key things that came out with the January 2018 Update:

  • Support of Location Based Routing with the Mac Client
  • Location Based Routing fixes where LBR users can be connected to non-LBR users
  • Support for Disclaimers on the Mac Client

Couple of things to note, first, with the Mac Client, you should have the latest deployed. LBR and E911 support came to the client back in November but we needed the December and/or the January updates to get the backend pieces.

Second, deploy the December version of the update (linked on the article) first. Then, if you are having one of the issues specified in the link, update to the January update. The January update is very specific to fix those issues.

Posted in Skype for Business

February 20th, 2018 by Skype for Business News Aggregator

Editor’s note: This post features a portion of a presentation on operational governance. The entirety of the presentation can be seen via FREE webinar on Feb. 21 at 11 a.m. EST. 

IT governance has become a very popular topic in the tech industry and in various related circles. Why? Is it to mitigate data breaches? Other reasons? This post will address some industry drivers of IT governance and some of the benefits offered by having a robust governance strategy.

Frequent signs of deficient operational governance

  • Cost and cumbersome bureaucratic processes
  • Informal processes dominate formal ones
  • Firefighting and crisis management
  • Organizational silos

Disruption forces a re-examining of operational governance for…

Mature Organizations 

  • These organizations understand the value and need for governance
  • They have likely already planned and implemented some type of solution (i.e. custom developed)
  • Many of these in-house systems need to be upgraded or re-architected for Office 365 or new SharePoint versions

Other Organizations

  • Even without established culture of governance for SharePoint, Office 365 is prompting a re-examining of this governance topic. This is due to…
  • Cloud security concerns
  • Regulatory concerns
  • These organizations will likely focus on basics first, like security and data protection

For Both Types of Organizations

  • When moving to Office 365, even basic processes like backup will change
  • IT teams have to find a way to comply with internal and external policies with significantly less control over their operations and infrastructure.

Benefits of well-governed SharePoint/ Office 365 implementations

  • Repeatable and consistent service delivery
  • Administrative efficiency
  • Accurate cataloging and monitoring of adoption, usage and governance attributes for collaboration workspaces
  • Provable compliance with internal and external policies and regulatory requirements

IT governance is something for which every 21st century organization should have a strategy and understanding. It’s crucial to operating a trusted organization and it can save countless major headaches that disrupt business and impact reputation. Don’t wait until it’s too late!

Posted in Skype for Business

February 20th, 2018 by Skype for Business News Aggregator
By Beth Schultz
Goal is to help developer teams customize their Stride experiences.

Posted in Skype for Business