We often hear the phrase “Seek first to understand and then to be understood” or are told to actively listen. While these are important, often time it’s simply not tactical enough. Too often what we hear is skewed by the filters that we (and our audiences) apply.

So how do we ensure what we say is heard, and what is heard is what we mean? Using these three tips will help ensure your communication quality is at peak performance.

1. Speak the Same Language as Your Audience

Are you speaking the same language as your audience?

Many years ago, my husband and I honeymooned in Chile; skiing in the Andes is an amazing experience. One day we accompanied some immersion school students on the long chairlift ride to the top of the slopes. We each jumped on a chair with three rosy-cheeked and anxious young (8-10-year-old) skiers for the ride. Much to our surprise, they spoke fluent Spanish, German, Italian — but no English. This was going to be a long chairlift ride because I speak don’t speak any of these languages, I thought. Twenty minutes later, after talking at one another in sentences, phrases, single words — and lots of pointing and laughing — the ride ended and we all went our separate ways down the slope, neither knowing if anything we meant had been heard.

Each Technology and Business Has Their Own Language — Seek to Understand it

Do you ever feel this way when speaking with business partners or technical team members? It has become increasingly important to have the ability to translate business and technology jargon. It’s important that we use terms and language that the audience understands and use their preferred terms to make sure we are on the same page. For example, “Apex” is the top or highest part of something. “Apex” is also Salesforce’s object-oriented programming language. Use the same term with two audiences and they could hear something completely different.

2. Share the Right Information

Are you sharing the right information? Understand your audience and present to them at the level they require.

Every day we talk with business partners, colleagues, clients, leaders, and more. Each group (or job role) is looking for specific information regarding their involvement in a project. Some want the dirty details of each requirement or defect while others are interested in the progress made and budget consumed. Others want only to know of the business impact, risks, and decisions that are needed. It helps to understand why someone wants a specific set of information and what their motivations are.

Some years ago I was involved in a project that required we integrate SaaS, ERP, and Legacy systems. Our steering committee was a blend of IT and business leaders. The project had been in trouble and it was critical to keep the business engaged and ensure continued resource support from IT. Each stakeholder was looking for different levels of detail during the same meeting. In response, IT-level details that spoke to the summary and decision needs required by the business were collected prior to scheduled sessions, which kept everyone engaged and allowed the technical team to ask more in-depth questions as needed.

3. Timing is Everything

Learning relies heavily on context. Consider what is on your audience’s mind when you have a question or a need. Put yourself in their shoes and consider their current challenges or struggles. Set yourself up for approval by speaking privately with the stakeholders separately before presenting. Either ensure their support or seek to understand why they can’t do so and rethink the timing for your request.

For example, before walking into a meeting with the intent of asking for budget for a new project, take note of conversations around the team’s ability to manage their current workload. When a team is struggling to keep up, there’s a slim chance of gaining additional work approval.

Key Questions for Effective Communication

The words that we use in our discussions can make or break the effectiveness of our conversation. To ensure you are communicating to your full potential, make sure your team has a firm “yes” to these questions.

1. Do we make a point clearly and succinctly, while providing added detail to those that we know are looking for it?
2. Do we ensure that we use language familiar to those we are speaking with rather than pepper our conversations with acronyms and industry-specific terms? (It’s often necessary and appropriate to use these, but a paragraph of three-letter “words” will lose even the most attuned audience.)
3. Is this the best time for the audience to receive this information? Listen to your audience and the conditions under which you are speaking.  If the time is wrong for the conversation – don’t have it.

Companies seeking to evolve and transform need to have tools for effective communication. Communication skills are valuable to teams, especially as they take on digital transformation. Read the guide below to learn about where digital transformation is heading in the future.

Beginning December 1, 2015, Microsoft will be officially rolling out a number of new features within Office365 that significantly enhance the Skype for Business workloads.  These features have been in preview form for a few months now, but December 1 marks the date where it becomes generally available (GA) for all tenants within Office365, across the entire globe.  What’s new, you ask?  Let’s take a quick look…

Cloud PSTN Conferencing

For years, on-premises Skype4B/Lync deployments could integrate a PSTN dial-in number to access meetings generated by Skype4B/Lync Server.  When Office365 initially came to the scene, PSTN dial-in number integration was only offered only through third-party Audio Conferencing Providers such as AT&T, PGi, or Intercall.  Those ACP providers offered a wide breadth of local numbers but the feature set was limited, required separate ACP administration, and required additional costs above and beyond your existing Microsoft licensing costs.
Starting today, Microsoft now offers the dial-in service natively and best of all, Microsoft is making it very attractive from a licensing perspective.  42 local dial-in numbers are currently available, spanning APAC, EMEA, LATAM, and NOAM, with more regions and countries coming online during CY 2016.  If you were looking for a reason to ditch your current dial-in provider and save on your TCO for conferencing, you should definitely take a look at what Microsoft is offering.

Skype Meeting Broadcast

For years, on-premises Skype4B/Lync deployments were limited to hosting meetings of up to 250 users in a single meeting.  Large Meeting support was added within Lync Server 2013 to allow up to 1,000 users in a single on-premises meeting, but that support came with certain limitations & restrictions that often made it not feasible to implement.  Office365 meeting support has always been limited to 250 users in a single meeting…until now.
Skype Meeting Broadcast is a component of Office365, Skype for Business Online, and Azure Media Services that lets you organize and host meetings of up to 10,000 attendees.  Skype Meeting Broadcast is primarily targeted for town-hall style events where there is a one-to-many presentation that may include audio, video, recording, Bing Pulse, Yammer, and PowerPoint deck sharing.  The service is offered digitally only, meaning you can only access the event through an HTML5 capable device – PSTN dial-in is currently not offered.  Skype Meeting Broadcast is free, which means you could easily enable this feature for your Office365 tenant and replace other broadcast services with Microsoft’s free offering!

Cloud PBX

Cloud PBX is actually a compilation of several topologies, one of which that has existed as far back as Lync Server 2010.  The differences in the various topologies isn’t always clearly communicated, but the basic tenant of Cloud PBX is that instead of using on-premises Skype4B/Lync servers for call control, you can utilize Office365 servers for call control.  The differences really boil down to whether you already have Skype4B/Lync servers on-premises and where you desire the PSTN access to come from.  I’ve tried to boil down the different options below:

Option 1 – You Have On-Premises Skype4B/Lync Servers and Want to Keep PSTN On-Premises

If you have existing servers, you can utilize Cloud PBX by using a feature called Cloud PBX with On-Premises PSTN Connectivity (aka – Hybrid Voice).  What this means is that you can move users to Skype4B Online, and still allow those users to access the PSTN through your existing on-premises Skype4B/Lync Server deployment and whatever IP-PBX or ITSP your deployment may be already connected to.  From the user’s perspective, nothing really changes (including your telephone number), but from an administrator perspective, you’ve offloaded users from your on-premises Skype4B/Lync Servers to Office365.  There are some feature limitations here so be sure to check out what is available and what is not to see if this solution is a good fit for your users.

Option 2 – You Have On-Premises Skype4B/Lync Servers and Want to Move PSTN to the Cloud

If you have existing servers and you want to deprecate your on-premises PBX environment, you can utilize Cloud PBX by using a feature called Cloud PBX with PSTN Calling.  What this means is that you can move users to Skype4B Online and allow those users to access the PSTN through Microsoft via Office365.  PSTN Calling requires you to port your PSTN numbers from your existing on-premises provider, such as AT&T, Sprint, Verizon, etc, to Microsoft or request new numbers from Microsoft and assign those new numbers to your cloud users.  The whole porting process is easily captured within the Office365 portal and can be centrally managed as such.  Administrators will rejoice in that you’ve offloaded users from your on-premises Skype4B/Lync Servers to Office365 and offloaded PSTN access from your on-premises infrastructure as well, but at the end of the day you still maintain the same seamless integration and communication between your on-premises users and your cloud users.  There are some feature limitations here so be sure to check out what is available and what is not to see if this solution is a good fit for your users and your environment.

Option 3 – You Have No On-Premises Skype4B/Lync Servers and Want to Keep PSTN On-Premises

Prior to a month ago, this wasn’t even an option, but the recently announced Cloud Connector Edition (aka – MinTop, or Minimum Topology) allows customers the ability to integrate on-premises IP-PBXs or ITSPs with their Cloud PBX users.  While Microsoft will say “no on-premises server deployment”, the reality is that this solution implements on-premises servers, just in a special and unique way.  This particular solution is still very new and has several feature restrictions that don’t make it viable for all organizations.  Based on what I’ve seen thus far, there is a very small set of organizations that may benefit from this approach, but due to the current technical restrictions of CCE, it may be a while before this becomes a truly viable solution.

Option 4 – You Have No On-Premises Skype4B/Lync Servers and Want to Move PSTN to the Cloud

If you don’t have existing servers and you want to deprecate your on-premises PBX environment, you can utilize Cloud PBX by using a feature called Cloud PBX with PSTN Calling.  This particular option is essentially the same as Option #2 above – port your numbers or obtain new ones from Microsoft.  Your reliance in this scenario is solely on Microsoft itself which will provide Skype4B services along with PSTN access, as there are no on-premises integrations required for this approach.  There are some feature limitations here so be sure to check out what is available and what is not to see if this solution is a good fit for your users and your environment.

Wrapping it Up

These new features significantly enhance the collaboration capabilities offered within Skype for Business Online and make Office365 attractive for a much larger audience.  If you were holding off on the cloud prior to now, these features may be the tipping point that gets you to start thinking “cloud first” instead of “on-premises first”.  All of these features will be enhanced over the coming months, so start thinking about your strategy to utilize these services to not only save yourself money, but improve collaboration across your organizations.

In a previous blog post I talked about how administrators and architects should place more emphasis on planning for application sharing bandwidth in their Skype4B deployments.  Armed with that information, the next logical progression of this blog series continues the focus on application sharing and discusses the available methods within Skype4B to manage and control the bandwidth requirements for application sharing.

General Methods of Controlling Bandwidth

Speaking broadly, there are typically two methods of controlling any sort of application bandwidth across enterprise networks.  Both methods are not mutually exclusive and can be used in concert with one another, but it is largely up to network engineers and the application engineers to work together to find the best solution for your environment.
Control the traffic at the network
For most of the network engineers out there, this is the “preferred method”.  Like controlling traffic on highways via “normal lanes” and “HOV lanes”, network traffic is separated, classified and handled in a manner that is configured by the network engineers to give preferential treatment (and bandwidth) to high priority traffic while giving normal treatment to non-priority traffic.  This is most generally referred to as Quality of Service (QoS).  QoS is typically seen in two forms:

• Differentiated Services – This is a QoS designation split into two layers of the OSI stack
  • Class of Service (CoS) – This is a Data Link Layer classification method whereby a 3-bit CoS field is included in Ethernet headers in a 802.1Q VLAN
  • Differentiated Services Code Point (DSCP) – This is a Network Layer classification method whereby a 6-bit DSCP value is included in the 8-bit Differentiated Services field within the IP headers of traffic
    • This is typically the more common QoS model and the preferred model today.
• Integrated Services – This is a QoS designation where the traffic specification part (TSPEC) and request specification part (RSPEC) help to define and classify the traffic into unique flows. This is not a common QoS model still in deployment.

In either case above, network engineers can control, on a per-hop basis, how each classification of traffic is treated along the entire network path.  While flexible and powerful, this method requires engineers to know all the various types of traffic on the network and to classify it accordingly (and ensure it is classified across all devices), which can be an arduous task and result in traffic being incorrectly classified.  In addition to the work required, as more and more applications move to SaaS available across the Internet, QoS is lost as the traffic leaves the corporate network and moves across the Internet which restricts QoS from being available from end-to-end.
Control the traffic through the application
For most of the application engineers out there, this is the “preferred method”.  Think of this as the “honor system” where some type of built-in application configuration tells the application to limit itself to X bandwidth when utilizing the network.  While undoubtedly easy to deploy, this method has no awareness of other traffic around it and no integration with network devices that send/receive traffic, which results in a more limited “one-size-fits-all” approach.

How does Skype4B fit in?

In almost all enterprise deployments, architects and engineers desire to identify the traffic produced by Skype4B and fit that traffic within the available enterprise network configurations.  Skype4B offers both of the configurations above and can be configured for one or both to suit the needs of the enterprise network.
Limit Application Sharing Bandwidth Within On-Premises Skype4B Conference Policies
This method is by far the easiest option to limiting application sharing bandwidth within Skype4B.  The only built-in method to control application sharing bandwidth is via the Conferencing Policies within Skype4B.  By default, the Global policy has no functional restriction on bitrate and is set to 50000.

Get-CsConferencingPolicy | select Identity,AppSharingBitRateKb | fl
If you decide to limit bandwidth, two approaches could be taken:

1. Alter the Global policy – while this approach is easiest, it will impact all users that don’t have a site or user policy assigned to them. As a result, you may limit users to an artificially low bandwidth in certain sites that have sufficient bandwidth.
2. Create a Site or User policy – this approach allows flexibility in deployment by tailoring bandwidth requirements to a per-site or a per-user basis. As a result, you can limit users in a low bandwidth site to a low bitrate while allowing users in high bandwidth sites to a higher bitrate.

Set-CsConferencingPolicy –Identity Global –AppSharingBitRateKb 1000

New-CsConferencingPolicy –Identity TestPolicy –AppSharingBitRateKb 1000
Limits of this approach
While the second option above is my preferred option for handling bandwidth natively within Skype4B, it does come with limits.  The biggest current limitation is that the AppSharingBitRateKb parameter is handled per-user and only is applicable to the presenter.  Where this becomes a challenge is with branch sites that have much lower bandwidth than other larger branch sites with high bandwidth.

In the figure above, when the user in Site B goes to share their desktop with the user in Site A, the effective limitation is based on the user in Site B.  With Site A limited to 1.5 Mbps, that could result in 67% of available bandwidth being consumed for a single desktop share.  When you add in the possibility of multiple users sharing desktops between the two sites, oversubscription of the 1.5 Mbps circuit becomes a very real risk.  Also of note is that this AppSharingBitRateKb behavior is applied both in P2P calls and within multiparty calls.
Impact of this approach with Lync for Mac
Through several of my deployments I’ve noticed there seems to be a significant difference with RDP performance on Mac OS clients, especially the Retina display models, when the AppSharingBitRateKb setting is reduced to a low value.  Interestingly enough, the low value doesn’t seem to impact Windows-based clients but users on Lync 2011 for Mac would report that application sharing was largely unusable.  In scenarios where there are Lync for Mac clients I would strongly suggest only using the Optimal numbers referenced in my previous post for the AppSharingBitRateKb setting.
Limit Application Sharing Bandwidth Within Skype4B Online Conferencing Policies
Sadly, this is a bit of a bait-and-switch option because it really isn’t an option at all.  Microsoft pre-creates and manages all conferencing policies within Skype4B Online and as a result you cannot create new policies or edit existing ones.  As a result of this any user accounts that are homed online are restricted to using the AppSharingBitRateKb value Microsoft has defined, which is currently 50000.  For all intents and purposes, the application sharing bandwidth is not restricted for Skype4B Online deployments so architects and engineers should carefully plan your network ingress/egress points to ensure sufficient bandwidth is available.  If bandwidth restrictions are required in Skype4B Online deployments, you must begin to examine QoS restrictions for each modality.
Limit Application Sharing Bandwidth for On-Premises Skype4B Deployments through QoS
There are a number of articles on the Internet that already talk about this overall process but it boils down to telling the Skype4B client to utilize certain port ranges for each modality and then configuring client/network devices to treat each modality in a certain way by dedicating queues (loosely equal to bandwidth) for each network hop.  The pre-requisite to all of this is that individual port ranges must be specified first.  The overall process of doing so consists of:

1. Configure port ranges for clients – Remember that each port range should be unique and not overlap. Additionally, you should have 20 ports per modality.
2. Configure port ranges for the MCUs – Remember that each port range should be unique and not overlap. Since MCUs handle modalities from multiple clients be very careful reducing the port numbers to a small number of ports per modality.  Best practices should be observed here and stick as closely to what Microsoft puts on TechNet.
3. Configure port ranges for Mediation Servers – Remember that the audio port range should be unique and not overlap any other server port ranges, such as video or application sharing. Since the Mediation Server handles all traffic to/from IP-PBXs and the PSTN, be very careful reducing the port numbers.  Best practices should be observed here and stick as closely to what Microsoft puts on TechNet.

Once port ranges are defined, the clients and servers will begin utilizing those ranges for each modality when communicating on the network.  With individual port ranges in use, architects can then begin to classify the traffic using QoS using two main methods:

1. Mark DSCP utilizing Group Policy based QoS policies on Windows clients and servers – This method is typically easiest but requires that access-layer switches trust DSCP markings coming from the endpoints. If switches aren’t configured for mls qos trust dscp, then DSCP markings will be stripped and classification is lost.
2. Mark DSCP utilizing class-map policies based off the port ranges per modality – This method requires more work to configure every access-layer switch across the enterprise to mark DSCP based on either source or destination port ranges, but is sometimes the only available option if network engineers choose not to trust client/server DSCP markings.

A typical DSCP/CoS classification of traffic is listed below:

Once you have calculated the expected application sharing bandwidth through the Lync Bandwidth Calculator for each site in your environment, network engineers can configure QoS queues appropriately to handle the expected traffic.
Limit Application Sharing Bandwidth for Online Skype4B Deployments through QoS
This method is similar to on-premises deployments but is limited because administrators cannot define the port ranges utilized for Online Skype4B deployments.  Microsoft has the following port ranges pre-created for clients that are homed Online:

Architects still have the option to utilize Group Policy based QoS policies or class-map policies, but those have two major limitations:

1. Having QoS in place mostly benefits P2P traffic – In this scenario the application sharing never leaves your corporate network so it can be controlled end-to-end.
2. Skype4B Meetings and multi-party communications lose QoS upon egressing to the Internet – In this scenario you can maintain QoS up to the point where the traffic leaves your network. This can be helpful on your network, especially for endpoints that may need to traverse the corporate WAN before egressing to the Internet, but you are still at the mercy of traffic patterns on the Internet for a great deal of the hops and thus cannot guarantee QoS end-to-end.

Despite not being able to maintain QoS end-to-end in an Online deployment, you can still classify the traffic into discrete queues to ensure the bandwidth is allocated for application sharing which in turn ensures that application sharing bandwidth doesn’t impact other traffic on your network.  Without reinventing the wheel, check out this blog post for information on configuring QoS for Online deployments.
The best option:  utilize both application limits and QoS
For every on-premises deployment out there you should absolutely be coordinating application limiting in concert with QoS.  In doing so you gain the following benefits:

1. Predictable application BW limits – by configuring the AppSharingBitRateKb parameter you ensure that a maximum amount of bandwidth will be requested by Skype4B clients
2. Predictable QoS queue utilization – by having expected bandwidth from the Skype4B team network engineers can map expected bandwidth consumption to available queues.
3. Better management through improved communication between network and application teams – this one may not seem obvious but the more the two teams talk the less chance there is of misconfiguration and the better the solution is for the end user.
   1. If queues become saturated, should the application reduce bandwidth (and potentially harm the end user performance) or should queues be increased or potentially both options?
   2. If network bandwidth increases at a site, are queues going to be increased and if so, how will that impact the configuration within the application?
   3. Based on usage patterns of existing sites, how should network engineers plan for bandwidth for new sites that come online?

Note:  There’s a number of other options here I’ve left out, but in every case the benefits are helpful to both the network team AND the application team.
For Online-only deployments, you should still utilize QoS even though you are limited in configuring the application.  Despite granular application control not being available, network engineers can still classify traffic and give a roughly-predictable utilization for each queue of traffic (application sharing included).
But what about Call Admission Control?
An astute reader would point out that Skype has Call Admission Control that can be used to restrict traffic as well, and you would be correct to say that additional control may be available.  Call Admission Control is only available for the following configurations:

1. On-premises deployments – CAC is currently not available for users that are homed Online
2. Audio/Video modalities – CAC is currently available for audio and video modalities only. Application sharing is not a supported CAC modality today.

If CAC is available for your deployment, configure it in tandem with your QoS configuration.  In fact, CAC is my preferred approach to bandwidth limits for audio and video modalities because it allows flexibility per-site AND includes reporting.  Conferencing Policy configurations of audio and video are applicable to each user regardless of where the user physically resides on the network, which can result in a user using more bandwidth than may be available if the user is travelling between sites.  Since application sharing currently isn’t supported in CAC today, architects need to utilize Conference Policies for the foreseeable future.

For many of the Skype for Business and Lync readers out there, you may think to yourself, “Hey, I’ve seen a similar title like that before…”, and you would be absolutely correct. During Lync Conference 2014, Lync MVP Jeff Schertz gave a fantastic presentation about “Video – What in the World Are You Doing to My Network” in which he gave a deep-dive into the impact of Lync’s new H.264 SVC video codec and how that impacts network bandwidth across the enterprise. While it is absolutely accurate that video can stress enterprise networks, the often forgotten (and sometimes neglected) truth is that app share traffic in Lync/Skype4B has a far greater impact (in my opinion) to impact overall bandwidth figures. What follows is my attempt not to reduce video planning but to place an equal (and maybe higher) importance on planning for application sharing bandwidth in Lync/Skype4B deployments.

Foundational Concepts of Application Sharing

Application Sharing has existed, in one form or another, since the Live Communications Server days and has received updates and/or changes with each iteration of the product (OCS, OCS R2, Lync 2010, Lync 2013). Some of those largest changes include:

• Migrating from the NetMeeting protocol (H.323 based) in LCS 2005 to RDP (ITU T.120 based) within OCS 2007 R2 (also Lync 2010/2013 and Skype for Business).
• Including formal meeting desktop sharing natively within Lync 2010 instead of relying on the LiveMeeting application.
• Adding a high performance P2P desktop sharing in Lync 2013.

As stated above, application sharing in the current iterations of the Microsoft UC stack are based off the Remote Desktop Protocol. IT administrators across the globe utilize RDP every day for connecting to servers and workstations and are, as a result, very familiar with the overall capabilities offered. At its core, RDP has the following characteristics:

• RDP is delivered over the Transmission Control Protocol (TCP).
• RemoteFX was added in recent RDP clients to enhance the RDP experience by offering User Datagram Protocol (UDP) delivery.
• Configurable performance parameters in the RDP Connection client.

Generally speaking, the RDP protocol is fast, flexible and sufficient to deliver screen sharing across a wide variety of environments. Lync/Skype4B architects should exercise caution however, as there are significant differences in how RDP works and how Lync/Skype4B utilize RDP.

Foundational Concepts of RDP within Lync/Skype4B

While RDP is the foundation of application sharing used within Lync/Skype4B, there are differences in how the UC clients utilize RDP vs how RDP may be available through applications like Remote Desktop Connection.
Lync/Skype4B utilizes application sharing over TCP only

• RDP is encapsulated into TCP-based RTP packets.
• TCP is a connection-based protocol.
  • Every single TCP conversation on a network involves a three-way handshake. This handshake is utilized to ensure the remote endpoint is ready to receive data and ultimately delays the start of data transfer at the expense of guaranteed readiness.
• TCP guarantees data delivery. If data is lost on transmission, the remote endpoint reports back to the sender that data needs to be re-sent – This behavior is great for data but is not ideal for real-time applications.
  • Due to the guaranteed delivery mechanisms of TCP, data is generally sent in “chunks” instead of being sent as a stream (in UDP). This behavior can lead to additional latency and slower performance.
• UC TCP communications can be multiplexed over a single port.
  • This allows Passive (Viewer) and Active (Presenter) to be done over a single port instead of requiring individual, unique ports in UDP.
• UC TCP communications can be firewall-friendly by utilizing RTP over TCP port 443 when direct connections between hosts aren’t available.
  • Despite this “friendliness”, beware of application layer firewalls that may try to intercept/manipulate traffic and cause failures in application sharing.

RDP performance isn’t “adjustable”
Almost every IT administrator has seen it within the normal Windows RDP Connection application – a tab called “Experience”. This configuration allows you to tailor the connection for the bandwidth available on your connection to best optimize performance of the RDP session. Lync/Skype4B, however, doesn’t get to take advantage of those configuration settings and instead is limited to utilizing the following protocols/configurations:

• MS-RDPBCGR
  • RDP encryption must be turned off.
  • RDP Bulk Data Compression must be turned off for data between Viewer and the MCU.
  • RDP Bulk Data Compression must be turned on for data between the Sharer and the MCU.
• MS-RDPEMC

So how does this impact my bandwidth estimations?

Microsoft (and many others) go to great lengths at describing bandwidth required for Lync/Skype4B but mainly restrict that description for audio/video related modalities:

• https://www.bing.com/search?q=lync+network+bandwidth

If you search for information on application sharing bandwidth, you’ll likely come up with very few pieces of information. That information is actually hidden within two pieces of official Microsoft documentation:

1. Lync 2010 and 2013 Bandwidth Calculator
2. Network Planning, Monitoring, and Troubleshooting Lync Server

In both pieces of documentation, Microsoft explicitly outlines bandwidth estimations for application sharing traffic:
Table 1 – Application Sharing Bandwidth Estimations

If you look at the info above, a few points can be made…
RDP bandwidth is variable in nature and can have a wide range of bandwidth requirements
There’s no denying that a static, non-moving screen won’t require much bandwidth, but movement of applications and refreshing of screens could require a dizzying 300% (or more) increase in bandwidth requirements. Don’t always assume the lower value is a hard-and-fast-rule – it’s really more an average towards the left side of the Bell Curve. Bandwidth above the average can (and will) occur.
Bandwidth requirements are most largely coupled to screen resolution
The higher the resolution, the more bandwidth required. Simple as that.
Screen resolutions continue to increase (4K or 8K screens, anyone?) and so too will bandwidth requirements
As users continue to receive laptops and/or monitors with 1080p (or better) resolutions, the likelihood of the lower resolutions being used lessens with each generation of products. It is difficult to argue that most users don’t at least have a 1680×1050 resolution today and even more difficult to argue that users won’t have higher resolutions in the future.
What makes it “Acceptable” vs “Optimal”?
Sadly, I cannot give an official answer on this but I can say through various rounds of testing these values that the “Acceptable” numbers provide a decent user experience whilst maintaining lower bandwidth. If you go much lower than those numbers, expect users to complain of slow refresh rates, jumpy application sharing, and/or wholly unusable application sharing sessions. If you want smooth application sharing, then you should plan for the “Optimal” numbers above.
What about that High Performance application sharing you talked about?
The bandwidth numbers above are all based off the basic frame rate of 2.5 fps that is default for all versions of Lync and Skype for Business. When Microsoft added the high performance application sharing capabilities they added the ability to allow a frame rate of up to 10 fps by enabling the appropriate policy configurations. This configuration allows very smooth and fluid sharing sessions but be prepared to pay for it – in my testing I regularly see up to 10 Mbps of bandwidth when the monitors are 1080p resolution.

How is Application Sharing different than Video?

While application sharing is similar to video, there are distinct differences in how the two modalities are implemented within Lync/Skype4B and thus two very different bandwidth patterns begin to emerge. The most obvious difference between the two is that different codecs are utilized, RDP vs H.264 SVC, which does have an impact on overall bandwidth numbers. Despite different codecs being a factor, the most significant difference is due to the intelligence the UC clients have when it comes to video.
P2P video bandwidth is directly proportional to the size of the call window on your screen. P2P application sharing bandwidth is directly proportional to the resolution of the sharer’s monitor.
By itself this may seem like a trivial difference but because Lync/Skype4B only requests sufficient bandwidth to fill the size of the video window, you end up very large differences in bandwidth consumption when the video window isn’t significantly altered and is left at default. For example, assume two users have 1080p monitors and initiate a video call to one another… In that scenario when users accept the video call the window starts out at a default size that will consume roughly 400-500 Kbps per video stream (per Table 2).
Table 2 – P2P Video Bandwidth Figures

Assuming the users never resize the video window, initiating an application share during that call will result in an additional 1 Mbps to fulfill 1080p resolution requirements and will vary from 1-3 Mbps during normal application sharing usage such as minimizing/maximizing windows on the actively shared screen (per Table 1). When you begin to compare the two modalities it becomes very obvious how application sharing bandwidth can easily surpass video bandwidth.
Multiparty video bandwidth is directly proportional to the number of users in the conference AND whether application sharing is utilized. Multiparty application sharing bandwidth is directly proportional to the resolution of sharer’s monitor.
Thanks to Jeff Schertz’s presentation it is possible to see that bandwidth changes significantly as more users are added to a video conference, and in most cases the bandwidth drops. The bandwidth reduction is, again, the result of the clients only requesting sufficient bandwidth to fill the size of the video window and due to the fact that each additional user must occupy the same screen real estate as the rest of the video streams which results in lower resolution streams being utilized.
Table 3 – Multiparty Video Bandwidth Figures

When application sharing is added to a conference, the video bandwidth numbers again change due to the changing proportions of screen real estate for each modality. When application sharing takes over the Gallery View video streams are moved to the top of the window and shrink due to the increased presence of the application share.
Figure 1 – Example of Gallery View with Application Sharing

In most scenarios involving application sharing within multiparty video conferences, you’ll see video resolutions and frame rates begin to change which results in video bandwidth taking a nosedive.
Table 5 – Multiparty Gallery View Video w/Application Sharing Bandwidth Figures

Note: I’m current conducting further testing on these numbers. Please consider these preliminary for the time being.
Assuming again that 1080p resolutions are available to end users, initiating an application share during that call will result in an additional 1 Mbps to fulfill 1080p resolution requirements and will vary from 1-3 Mbps during normal application sharing usage such as minimizing/maximizing windows on the actively shared screen (per Table 1). In certain conference sizes you can have application sharing dwarfing the video bandwidth requirements by 300-400%.
Video usage is a very subjective use case in most organizations. Application Sharing is far more common for most organizations.
In many organizations video simply isn’t that common. Sometimes that is because of technical limitations (such as perceived lack of bandwidth) whilst in other cases it is due to a user culture that simply doesn’t want to utilize video. More often than not I see organizations broadly adopting application sharing whereas video remains a very small deployment. This may change over time, especially with the new generation of Millennials entering the workspace, but the hard truth is that application sharing is used far more frequently in organizations and video is an afterthought or edge case.

Show us the math!

Where all of this becomes apparent is when you start computing numbers within the Lync Bandwidth Calculator. The calculator works off of the “Acceptable” numbers in the table above and includes complex calculations for how users handle video when in a multi-view configuration.
Peer-To-Peer
Assume that you have two branch sites and a separate data center site. Users in each site regularly exchange P2P traffic including audio/video/application sharing. Also assume that these users are huge fans of Lync/Skype4B and that 5% of users in each site are utilizing the features concurrently. Lastly assume that there’s about 300+ users in each site, which results in the numbers below:

61.7% of all bandwidth required is for application sharing! Additionally, that’s only using the Acceptable bandwidth calculation of 1 Mbps for the 1920×1200 resolution monitors the users have! If you start computing numbers based on the Optimal bandwidth calculation it becomes even more lopsided with the Application Share bandwidth tripling.
Conferences
Assuming the same scenario above, the numbers will change significantly when conferences are involved. Much of this deals with the fact that the Lync client and AVMCU actually use less bandwidth for video as each additional user is added to the conference and even less bandwidth when application sharing is invoked.
Assuming the same 300 user count at each site we end up with the numbers below:

74.3% of all bandwidth required is for application sharing! Additionally, that’s only using the Acceptable bandwidth calculation of 1 Mbps for the 1920×1200 resolution monitors the users have!  The large sucking sound on your network – it’s application sharing, not video.

You’ve proven your point, so now what?

I can’t overstate the importance of properly planning for application sharing bandwidth in addition to the rest of the bandwidth calculations required for Lync/Skype4B. As a result of this it’s important to begin asking the following questions:

• What’s the most common resolution of monitors deployed within your organization?
• Do we have sufficient bandwidth to support sharing with that resolution?
• Do we intend on utilizing Quality of Service with application sharing?
• How does our user culture view video vs application sharing?

Once you begin to answer the questions above you can begin to properly plan for bandwidth for application sharing. Many customers I work with are often surprised at the numbers because they are so focused on the fear about bandwidth requirements for video, but in reality video bandwidth is likely to be a lesser concern when compared to application sharing bandwidth. In a future article we’ll discuss methods you can utilize to help control application sharing bandwidth for both on-premises and Office365 deployments. Stay tuned!

Background

I was recently working on an engagement where the customer was migrating from Exchange 2010 to Office 365 Exchange Online. The customer had been a long time Enterprise Voice customer (OCS, Lync 2010, and now Lync 2013). As the customer grew over the years, so had their Lync environment. The customer originally deployed OCS 2007 R2 for only internal use. The default SIP domain was based off their internal Active Directory namespace (corpnet.domain.com). When Lync 2010 was introduced, the publicly routable SIP domain was added to the Lync topology (domain.com) to clean things up and match their SMTP addresses. Fast forward to 2015, the customer is migrating to Office 365 Exchange Online, which means voicemail and auto attendants were also being migrated to Exchange Online Unified Messaging.
Note, this article will not walk through the actual steps necessary to configure Lync/Skype for Business with Exchange Online Unified Messaging. If you need guidance in this area, refer to this article.

Issue Overview

The issue encountered was internal Lync calls to Exchange Online Unified Messaging (voicemail, auto attendants, etc.) would complete successfully, but any call made from a PSTN caller to Exchange Online Unified Messaging (subscriber access, auto attendants, voicemail) would fail. After reviewing traces of the call, it appeared that the default SIP domain was appended to the From/To fields in the SIP INVITE.   It makes sense why a SIP domain would get appended to these types of calls (so Office 365 knows where to route traffic). The problem is, an administrator cannot control which SIP domain is appended in the INVITE. From my testing, the default SIP domain will always be the domain appended to the PSTNGateway FQDNs when egressing out to Office 365.
From the traces below, you can see that the cause of the failed calls was a result of Office 365 not being able to do a DNS SRV lookup for _sipfederationtls._tcp.corpnet.domain.com as the ms-diagnostics response from Office 365 mentions “Unable to resolve DNS SRV record.”

 

Here is where the problem took a turn for the worse…

1. The customer did not have a public DNS subdomain for corpnet.domain.com. When asked if it was possible to add a public subdomain for corpnet, the admin quickly informed me that they had tried to get the subdomain created in the past, but the public DNS provider could not support the request.
2. Out of curiosity, I attempted to change the PSTNGateway from an FQDN (gateway.corpnet.domain.com) to an IP address (192.168.123.10 in this example).
   • Unfortunately, the default SIP domain was still added to the FROM/TO fields of the SIP INVITE. It was worth a shot, but not surprised by the result.
3. I attempted to create a new PSTN Gateway in the Lync topology with 192.168.123.10@domain.com, but the topology does not allow the SIP domain name to be specified.
   • It was worth a shot, but again, not surprised by the result.

After attempting the three scenarios above, we determined that the only option was to change the default SIP domain.

Changing the Default SIP Domain

Since the public SIP domain was added during the Lync 2010 upgrade, changing the default SIP domain was not as painful as it could have been.  The certificate SAN entries were correct on all the servers (Front Ends, Edges, SBAs, etc.), users already were using the public SIP domain for their SIP addresses, etc..  All we had to do was to execute the set-cssipdomain command to change corpnet.domain.com from the default SIP domain to domain.com.   The figure below is the output of both the get-cssipdomain and set-cssipdomain commands.

Repercussions from Changing the Default SIP Domain

If you read the set-cssipdomain TechNet article carefully, the article mentions “If you change the default SIP domain you will need to restart the RTCCAA and RTCCAS services.”  This statement matches the yellow warnings that appeared after executing the set-cssipdomain command above.  Great, things are moving right along… Oh no, hold on a minute…

Mediation Services

After waiting for the default SIP domain change to replicate, I started to review the Lync event logs on the Front Ends.  There was one warning, one error, and three informational messages that caught my attention.  The informational messages were expected and looked great.  What caught me by surprise was the warning and error message.  From the event logs below, it appeared the Mediation service(s) also had to be restarted as part of the default SIP domain change.

Log Name: Lync Server Source: LS Mediation Server Date: 7/24/2015 6:02:21 PM Event ID: 25029 Task Category: (1030) Level: Information Keywords: Classic User: N/A Computer: GCR-LYNCSTDOBT.corpnet.domain.com Description: Mediation Server applied the settings changes Setting Name: PDP Property Description: ServiceGruu Old Value: sip:gcr-lyncstdobt.corpnet.domain.com@corpnet.domain.com;gruu;opaque=srvr:Microsoft.Rtc.Applications.PDP:cT_X2URjIFW0ygzTE3iGYwAA New Value: sip:gcr-lyncstdobt.corpnet.domain.com@domain.com;gruu;opaque=srvr:Microsoft.Rtc.Applications.PDP:cT_X2URjIFW0ygzTE3iGYwAA

Log Name: Lync Server Source: LS Mediation Server Date: 7/24/2015 6:02:21 PM Event ID: 25029 Task Category: (1030) Level: Information Keywords: Classic User: N/A Computer: GCR-LYNCSTDOBT.corpnet.domain.com Description: Mediation Server applied the settings changes Setting Name: Mediation Server Topology Property Description: DefaultDomain Old Value: corpnet.domain.com New Value: domain.com

Log Name: Lync Server Source: LS Mediation Server Date: 7/24/2015 6:02:21 PM Event ID: 25029 Task Category: (1030) Level: Information Keywords: Classic User: N/A Computer: GCR-LYNCSTDOBT.corpnet.domain.com Description: Mediation Server applied the settings changes Setting Name: MRAS Property Description: ServiceGruu Old Value: sip:gcr-lyncedgpool.corpnet.domain.com@corpnet.domain.com;gruu;opaque=srvr:MRAS:WjJ6-s1PyFeipMlcPV0pwwAA New Value: sip:gcr-lyncedgpool.corpnet.domain.com@domain.com;gruu;opaque=srvr:MRAS:WjJ6-s1PyFeipMlcPV0pwwAA

Exchange UM Auto Attendant Transfers

After the Mediation services were restarted, we proceeded with inbound and outbound PSTN testing.  Calls made from the PSTN to Exchange Online Unified Messaging (subscriber access, auto attendants, voicemail) were now working correctly (yeah!).
We were preparing to migrate the auto attendants to the cloud, but with any Office 365 migration, the existing Exchange environment needs to support the workloads (Unified Messaging, etc.) until they are officially migrated to Office 365.  After further testing, we discovered that the existing on-premises Exchange 2010 auto attendants were unable to complete their transfer requests to Lync.  After reviewing snooper traces, it appeared the on-premises Exchange 2010 UM services processed the transfer request correctly.  The SIP INVITE would get routed to Lync, but Lync would then attempt to route the request out the Lync Edge infrastructure.  As you can see in the screenshots below, the operator transfer request was supposed to be routed to extension 7008 which was a Lync Response Group.  After the default SIP domain change, we started receiving a “404 Not Found.”

Prior to the default SIP domain change, the format for the Exchange contacts were autoattendant.corpnet.domain.com@corpnet.domain.com.  Using the OCSUMUtil utility, we left the Exchange contact FQDNs the same, but decided to update the SIP domain for the Exchange contacts to match the new default SIP domain. The modified format matched autoattendant.corpnet.domain.com@domain.com.  After modifying the SIP domain for the Exchange Contacts, our transfers started to work again.  As you can see in the screenshots below, the same INVITE came into Lync from the on-premises Exchange 2010 UM server, but this time Lync was able to perform a reverse number look up and locate the correct operator Response Group.

Summary

There are many items and tasks to consider when migrating from an on-premises environment to Office 365.  Perficient has performed numerous Office 365 migrations where the default SIP domain was never an issue.  Hopefully you never run into this issue or if you do, you have more flexibility with your public DNS provider.  If you find yourself heading down the same path as this article, remember to:

• Restart the Conferencing Announcement service(s)
• Restart the Conferencing Attendant service(s)
• Restart the Mediation Service service(s)
• Update the SIP domain for all Exchange Contacts to match the new default SIP domain to support the on-premises Exchange Unified Messaging subscriber access and auto attendants during the transition to Office 365

Comments Welcomed.

Is she online yet? Is he free or in a meeting?

Ugh, how many times a day do you find yourself wondering whether your colleague is available for a chat?

Relax. And quit checking your instant messenger (IM) every five seconds. With Skype for Business (formerly, Microsoft Lync), your needs are met by one of my favorite features: Status Change Alerts. Simply right-click on a contact’s name and select Tag for Status Change Alerts in the drop-down. Tada! The next time they come online or drop offline, you’ll see a little pop-up. No more obsessively checking your IM window to see if they’re around. 

For life sciences companies, many of them which operate on a global scale, consistent, reliable, and fast communication is a vital part of doing business. This is why a unified communications (UC) system has become an industry standard.

If you’re seeking to implement Skype for Business as your UC solution, or if you are interested in migrating away from Microsoft Lync or Office Communicator, give us a shout.

 
First let’s start off with what a Reverse proxy is and then cover how it fits in with with Skype for Business Server.
The Reverse proxy is a device that receives requests from clients on and then forwards the request on to another resource, in this case a Skype for Business Front End server. This is done in such a seamless manner that the Reverse Proxy is transparent to the client. Ideally, the Reverse Proxy device/appliance is placed between your internal Skype for Business Front End server/s and the public internet – the recommended placement would be in a DMZ network.
So why does Skype for Business (Skype4B) need a Reverse Proxy?
Skype4B relies on the Reverse Proxy to publish its Web Services to the public Internet.
Here are some of the Skype4B Web Service functions:

• Skype for Business Mobility client
• Simple URL’s
  • LyncDiscover – client sign-in and discovery
  • Meet – Connect to meetings
  • Dialin – Dial-In Conference settings information
  • Schedule – Schedule Meetings
• Skype for Business Web App client
• Expand Distribution Groups
• Address Book download

Let’s take a quick look at the IIS settings of a Front End Server in my lab; you will see that there are two different IIS sites (Image below). One web site for Internal and one for External.

Why are there separate Web Sites for Internal and External Web Services?
Not all Skype4B Web Services are designed to be exposed to the internet – examples would be the Skype4B Control Panel and the Response Group Configuration page. Skype for Business differentiates these sites by using different ports:

• Internal Web Site: 80 and 443
• External Web Site: 8080 and 4443

Using differencing ports also allows the Skype4B Front Ends to use a single IP address.
You can view the port bindings by selecting the site and ‘Edit Bindings’

• Skype for Business Server External Web Site – which is bound to port 8080 and 4443

• Skype for Business Server Internal Web Site – which is bound to port 443 and 80

Now that we know the purpose of the two web sites, this is really where the Reverse Proxy comes into play. The reverse proxy receives internet traffic on port 80 and 443 and then forwards that traffic to the Skype4B Front End/s on port 4443 and 8080. The blow graphic depicts the port change and the placement of the Reverse Proxy Device.

This allows the Skye4B Front Ends to remain on the LAN while the Reverse proxy is placed in your DMZ and exposed to the internet.
The Reverse Proxy is highly recommended for publishing External Web Services for a Skype4B deployment, but it is important to note that it is not a native Skype4B server role and another product/appliance must be used to provide this function.
To view the Reverse Proxy in action or even just testing the traffic is getting where it is supposed to be, you can run a packet capturing program on one of your Front End servers and see the 8080 and 4443 port traffic. (Wireshark image below)

 
Qualified Reverse proxies
This section lists the Skype4B qualified reverse proxy products that have completed solution testing with Skype4B Server. While any reverse proxy is expected to work with Skype4B Server, the reverse proxies listed below have completed extensive testing and are posted with detailed deployment white papers to assist in configuration.
Qualified for Lync Server 2013/Skype for Business Server 2015

Mailbox Location	Lync/Skype account location	Preparation Required
Online	Online	Yes
On-premises	Online	Yes
Online	On-premises	Yes
On-premises	On-premises	No*

** In November, 2012, Microsoft ceased license sales of Forefront Threat Management Gateway 2010, or TMG. TMG is still a fully supported product, and is still available for sale on appliances sold by third parties.
There are other solutions that can used as a successful solution while not being qualified; Apache and PFsense are a couple examples.

It’s official – as of mid April, which was covered in another post – Microsoft Lync is now Skype for Business. As expected, customers who have Lync deployed either on premises or in the cloud have questions, and folks who use Skype for personal use are wondering how well this communication tool, which works wonders to connect with family and friends, crosses the chasm into enterprise-grade unified communications.
All these questions made for a popular webinar topic last week. Nick Elniff, a senior technical consultant at Perficient who works within our unified communications practices, packed a lot of information into the 50 minute session.
He began with a brief history lesson on Microsoft and unified communications, and then shared with attendees what the change means from a rebranding perspective, and the different clients and timelines for availability. He compared the differences in the interfaces, and then showed what’s new beyond the new look.
It’s definitely a webinar worth reviewing, whether it’s the slides or the replay. You can find both here.

v

It’s the typical issue all IT professionals face: a new system is designed, built and deployed to end users, but months down the road issues arise and administrators are faced with the overwhelming task of trying to find root cause to remediate issues. As an IT Pro (in a previous life) this is definitely something I can relate to and definitely pay attention to when discussing UC deployments with customers.  Today at Ignite Microsoft announced some very new and very needed features for your Skype4B deployments.  Admins rejoice!
Key Health Indicator Dashboard
 

Those that have been following along with Skype4B news, many people know that the Call Quality Dashboard (CQD) has been announced to big fanfare (and rightfully so).  A lesser known feature was unveiled today and that’s the Key Health Indicator Dashboard (the name isn’t finalized yet – so it may change!).  This feature is very analogous to CQD in that it will be a web-based dashboard that provides real-time monitoring of KHI counters on your entire Skype4B topology.  The dashboard will provide real-time data, drill down, heat maps and more.  For anyone who has looked at KHI data previously, you know it is a very manual process that required taking CSV’s and then interpreting the data after-the-fact.  The KHID will automate all of that and give you a single pane of glass to look at the server health statistics of your Skype4B environment.  Microsoft is still working on this feature but from what I’ve seen so far, it is a huge improvement for admins.
Key Health Indicator Spreadsheet
As stated above, trying to gather KHI data is a very laborious, manual process.  Creation of the CSV files with the perfmon data wasn’t so hard, but obtaining the MAX/AVG values and then importing that data into the KHI spreadsheet that Microsoft provided was entirely manual and time consuming, especially in environments that may have 20 or more servers.  With the new release of the KHI spreadsheet, the CSV import and statistics gathering has become completely automated through macros in the new Excel spreadsheet – hallelujah!  Additionally new insights into the data, such as Burst Counters, exist so that the data becomes more useful in identifying true issues and weeding out outliers that may occur during backup windows.
Third-Party Tool Integration
This can be stretched to many categories, including SDN, but it simply means that partners such as Nectar, EventZero, and Unify2 are providing solutions to make reporting and troubleshooting easier.  Microsoft has provided some powerful utilities with the CQD, SSRS Reports, and KHI, but it often times requires multiple places to look and difficult correlation to establish to try and troubleshoot and resolve issues.  These third-party utilities aim to provide a single pane of glass to the process and give you drill-down capabilities to help identify usage or why a user’s call failed or why jitter has increased on a certain network hop.  These utilities actually rely on the same KHI or CQD data that Microsoft provides, they just present the data in new and interesting ways to allow you to better gauge usage and resolve issues.
Call Quality Dashboard
This new feature has been known for a few months but was recently released for GA on May 4, 2015.  CQD simply takes the data that is already within your CDR and QoE databases and provides SQL Analysis Services to help slice and dice the data.  If you’ve gone through the Call Quality Methodology before, CQD now allows you to look at that data in real-time (well, your QoE and CDR databases aren’t quite real-time, but close) and manipulate the data in ways that are important to YOU.  If you find that a report offered within the SSRS reports isn’t quite enough for you, you can create a view within CQD that gives you the data you desire.  Additionally if there are troubleshooting metrics that aren’t displayed in a friendly manner within SSRS, you can easily extract that data through CQD.

I’ll admit that the title is a bit misleading because much of what existed (in regards to mobility) in Lync Server 2013 still exists in Skype for Business Server 2015.  Unfortunately there has not been a great leap forward in functionality….YET.  The “Yet” is there because there are HUGE improvements forthcoming in the Skype for Business mobile client release (and subsequent server release), which is expected sometime in Q3 CY 2015.  Looking forward to that release date, some of the information available through the Ignite conference about those future features are outlined below.
Mobile Device Management
Very limited MDM integration exists with Lync/S4B today.  Things like device posture checking or requiring encryption or requiring PIN codes for security simply are not available or enforceable by either the server or the client.  This will be changing in S4B/S4B-Online and the direction for the product will be to utilize the Microsoft Intune Service for all MDM functionality.  One of the big items that Intune will bring to the table is the concept of protected applications.  This was demo’d in the keybote where you couldn’t copy/paste text from a work-managed application into a non-work-managed application.  Some may view this as quasi-DLP funtionality, which it definitely is, but it is handled solely by Intune MDM policies.  Additionally, Microsoft will not be supporting or integrating any other MDM solution on the market into Skype for Business Server (or S4B Online).  Despite the “limitation” of only supporting Intune, the Intune service is hugely powerful and will continue to evolve and adapt.
If Intune is not utilized, Microsoft is adding a two new mobility policy settings in an upcoming CU:
Require an application PIN for the S4B mobile client
Require device encryption
Those two policy features will be configurable via the Set-CsMobilityPolicy cmdlet after the S4B mobility client is released.
Data Loss Protection
The DLP story for Lync/S4B today is lacking and third-party vendors have stepped up to try and fill the gap.  Lync Server 2013 and Lync 2013 clients today support IRM, in that they will not display via screen share a document that has been protected via IRM, but that is truly the limit of the DLP functionality.  Dynamic content inspection or compliance reporting or real-time IM analysis simply is not available in the solution – things that Exchange Server has had via Hub Transport rules and continues to grow with each product release.  That being said, the unfortunate news from Ignite is that DLP won’t truly be integrated into S4B mobile, at least not yet.  Microsoft has added loads of DLP improvements into the Office 2016 stack and Office365 service which impacts Exchange, SharePoint, and OneDrive, but the S4B client (and server) are sadly omitted.  The good news is that Microsoft is aware of this missing piece and is working with the product groups to add functionality in to future releases.  Things like dynamic content inspection and compliance reporting will be coming in future releases of the product, but the full picture is not known yet.
Authentication Improvements
In Lync Server 2013, the only way to get MFA for mobile clients was to utilize a feature called Passive Authentication.  It solved the problem of getting “MFA” but it actually introduced more problems by utilizing the feature – one of those problems was severely restricting capabilities of clients to integrate with Exchange Server.  Moving forward with S4B, Microsoft has announced that Azure Active Directory Authentication Library will be the desired solution for all MFA and in fact all authentication, period.  ADAL brings several important investments to the table:  powerful MFA configurations for conditional access are possible, it integrates tightly with AD-FS and most importantly, it will be supported across all server 2016 and client 2016 products.  No longer will you have one separate authentication piece for Lync/Skype and then another for the rest of the product portfolio.  If you are looking for a powerful authentication solution to handle not only Lync/S4B mobile, but all of your corporate applications, this is it.
 

I recently blogged about my personal experiences with the first “Know it. Prove it.” challenge that ran through the month of February 2015. The “Know it. Prove it.” challenge is back! This time it’s bigger and better than ever. The new challenge is a companion to both the Build and Ignite Conferences with 11 amazing tracks for both Developers and IT Professionals. Also, just like the first round, this set of challenges are completely Free!
Join the tour and accept a challenge today.
Whether you’re looking to learn something new or just brush up on something you’re already using, there’s definitely a challenge track for you.

Build Developer challenge
Geared towards Developers, this includes tracks focusing on: Azure, Office, Database, App Platform, Developer Tools.

Ignite IT Professional challenge
Geared towards IT Professionals, this includes tracks focusing on: Cloud, Big Data, Mobility, Security and Compliance, Unified Communications, Productivity and Collaboration.

What do the challenges consist of?
Each challenge consists of free, amazing training courses hosted on the Microsoft Virtual Academy. These are some amazing courses, it’s hard to believe their free. In addition to the training courses, some of the challenges include links to free eBooks from Microsoft Press.
The challenges range is approximately 15 hours to 30 hours of video training content. So if you take on 30 minutes to 1 hour a day, you’ll finish a single challenge in a month. Surely, you can commit just 1 hour a day for a month. Right?
Are you up to the challenge?
You know you are! Go on and sign up for one. When you’re done, I’ll wait for you to come back here an post a comment letting everyone know which challenge you’ve accepted.
I’ve already signed up for the Build Cloud and Azure challenge, and can’t wait to see how many of you take on a challenge as well!
Remember the “Know it. Prove it” challenge is FREE, so you have no excuse to start.
Join the tour.

Today is the day that the official Skype For Business Client gets released!
I have been using the Technical Preview for about a week now and can honestly say that I like the new Skype-influenced interface. I have a couple customers that have been waiting for this new UI to come out before they begin their client rollout, because they feel that there will be better user adoption due to the familiar Skype interface. Microsoft has released some Client Awareness and Readiness resources to help organizations educate their end users and have a smooth transition to the new interface. These resources can be downloaded here.
This client update is available for the Office Pro Plus and Office 2013 Professional Suite. I am expecting an update to the Mobile client as well but I have yet to see too much information on it and it has yet to show up in my Google Android App Store. The update for the Professional Suite comes in the form of a patch for the Lync 2013 client – KB2889923 – and is currently available via Windows Update. The manual patch installer will eventually be made available here for download.  Depending on your organization’s Lync policies, you may or may not see the new client UI as it can be controlled via a Client Policy with the attribute of EnableSkypeUI and by a registry key – more info on controlling the Skype UI can be found here.
The new client version is 15.0.4711.1002 if you would like to check to see what version you are running.
I did not have any problems updating my Technical Preview client via Windows Update, all that was required was a restart.
Now on to the actual client interface, there are almost too many UI tweaks to cover. I will hit on a few that I think are the best (in no particular order).

• Call Monitor – this is a compact window that will allow you to monitor the call you are in while the main call window is not up, allowing you to focus on another program. You can see the duration of the call and can mute or end the audio or video call from this collapsed view.
  • Audio Call Screenshot

• Video Call Screenshot

•  Alert customization – I can control where my alerts appear by choosing between multiple monitors and the position that the alert toasts pop up.

• Call Window – there is no more hovering to select options!  The new call control button now includes the dial pad, Call Transfer, Hold, Devices, and call volume .

My only complaint about the new Call Window is that the Participant List, Add New Participant, Instant Messaging, Call Control and Meeting Options are spread out to each corner of the window – depending on your screen real estate this can be a bit of a pain to navigate between but you can tell they had the touch experience in mind.