The Microsoft Surface Hub has been a popular choice for a next generation collaboration device for Skype for Business & Teams with it’s immersive and feature rich meeting experiences. As organizations migrate to the cloud and look to upgrade their collaboration devices, this quick post addresses a common question - does the shipping version of Surface Hub support Microsoft Teams, and is it worth waiting for the newly announced Surface Hub 2.0?

Surface Hub 2 Not Widely Available Until 2019

Earlier this spring, Microsoft announced, the second generation of this device: the Surface Hub 2: https://www.microsoft.com/en-ca/surface/business/surface-hub-2. This generated a lot of buzz given the success of the existing Surface Hub and the beautiful dazzling graphics and capabilities announced in the forthcoming version 2.

The first thing to know is that if your timeline is this calendar year (2018), the Surface Hub 2 is out of the question unless you are part of a select few commercial customers willing to engage with Microsoft to test it in the later half of 2018. Simply put the Surface Hub 2 will not be available for purchase until 2019. Microsoft has not publically released a specific date in 2019.

Does the Surface Hub 1 Support Teams Today?

Support for the Surface Hub has been on the Teams roadmap (under Meetings) for sometime, and slated for “Q2 CY2018″. Indeed, on June 27, 2018, Microsoft announced a Microsoft Teams Surface Hub app in the Microsoft Store that allows Teams to run on a Surface Hub. Currently (July 2019) it is in Preview Status however and as such there is a significant caveat: you should not use it in production. In other words, you should only try it on a that spare non-production Surface Hub that you have lying around

The reason for this is that to install the Microsoft Teams for Surface Hub Preview, the device must be enrolled in the Windows Insider Program. This program by nature is meant for non-production pre-release use, and will not have the support or stability for a production quality release. Participation in this program also requires that Full Telemetry must be turned on, and to leave the Insider’s program you need to reset the Surface Hub (there is not rollback option).

There is no public date for the Surface Hub app to come out of preview, but my guess is that it would be before the end of the 2018 calendar year (and I’ll emphasize, that is just my guess based on experience).

Another challenge however, is availability of the Surface Hub. In many areas in North America, such as Canada, any remaining inventory that suppliers had of the Surface Hub 1 are depleted or spoken for, and it can be really difficult, if not impossible to get one. This includes big suppliers such as CDW and AVI-SPL.

Note: when you install the Surface Hub app, there is an installation package available (here), which allows you to set the preferred default application to use on the Hub:

So, What to Do?

If you are set on getting a Surface Hub before 2019, can find an existing Surface Hub 1, and do not need production Teams support, going that route is a good idea. Otherwise, it would make sense to hold of until 2019 when version 2 is ready, and Teams support will be more production ready.

There has been no price divulged for the Surface Hub 2, but there is plenty of chatter that will be competitive with the Google Jamboard which is around $6,000 USD.

The other option, either outright instead of the Surface Hub or to bridge the gap until 2019, is the Microsoft Skype Room System (SRS). They are fantastic conference room collaboration systems pre-packaged from 5 vendors: https://docs.microsoft.com/en-us/skypeforbusiness/room-systems/. They support Skype and Teams (on the SRS v2), and can always be redeployed into another conference room if a Surface Hub is purchased later.

At Ignite 2017 we first learned of Microsoft’s plan to deliver a new Office 365 Admin Center that unifies the management experience for both Teams and Skype for Business Online (SfBO). Since then, many ITPro’s have had questions such as what features will be included, what is the fate of the existing SfBO Admin Center, and when will it be available?

1. When will I have Access to the new Teams & Skype for Business Admin Center in my Tenant?

Microsoft is rolling out the first version of this unified Admin Center this month (the article quotes mid-March 2018). Microsoft is rolling it out in stages, so not all tenants will have it immediately, but as the article says, you will be notified when it is ready for your tenant, which should be soon if it is not already available.

2. What will Happen to the Current Skype for Business Online Admin Center?

Status quo in the short term, and you can continue to use it to manage your SfBO tenant. Management features for SfBO will be gradually migrated into the new Admin Center, and at some point, after a set of specific management features are fully migrated, they will be disabled in the legacy SfBO Admin Center. In the short term however, the focus is not on migrating SfBO management features, but rather:

Introducing new Teams capabilities such as the ability to configure the interoperability experience between SfBO and Teams, and,

Migrating most of the existing Teams settings currently in the Office 365 Admin Center under Settings | Services & add-ins as shown below).

Note: The Messaging Policy refers to the Teams chat and does not apply to SfBO.

4. What is the Biggest Change I Should Pay Attention Too?

From a Teams perspective one important setting that is migrating from the Office 365 Admin Center Teams App settings (as shown above) into the new Admin Center that will be treated differently is the “Settings by user/license type” which controls user access to Teams.

In it’s current form, the Teams App UI settings is a little deceiving, but what it allowed tenants to do, is to configure Teams capabilities (including turning Teams on/off) for users of different Office 365 license types (e.g. E1 vs E3 licensed users) and Guests.

For example, in the screenshot below, specific Calls and meetings features could be configured for just Guests users (versus licensed users):

When these setting are migrated into the new portal, administrators will be able to set at them at a user level (per-user basis) versus the ‘bulk user type’ in the Office 365 Admin portal today.

However, if you are using the above setting to disable Teams for a specific set of licensed users (e.g. turn off Teams for all E3 licensed users), the current configuration will persist, but you will not be able to modify this in the new portal (at least at this time – March 2018). Instead you will need to modify the Teams Service Plan (turn it on or off) in the associated Office 365 user license in the Office 365 admin center.

5. What other SfBO Management Capabilities will be Available in the New Admin Center?

As shown on the Office 365 public roadmap the recent call analytic and call quality dashboards introduced for SfBO will surface in the new Microsoft Teams and Skype for Business Admin Center:

Skype for Business Online integration directly within the Yammer web client rolled-out in the latter half of 2017. As more organizations adopt Skype for Business Online, Yammer users are leveraging this integration.

This post summarizes the features available, and more importantly, two common issues and how to resolve them.

Feature Recap

At a high level, the SfB integration enables Yammer users:

Use basic Skype for Business features in a thin web client embedded directly in the Yammer web client

See the SfB presence of other Yammer users and initiate communication with them

Receive IM conversations directly within Yammer

Key Limitations:

The Yammer user must have a Skype for Business Online license; there is no on-premises account integration

There is no direct audio or video communication capabilities, however users can launch calls into the native desktop client from within Yammer

There is no integration available (yet) in the Yammer mobile apps

To launch the SfB functionality from the Yammer web client, click the Skype icon from the Yammer navigation bar. This will show a simplified web version of SfB and provide the ability to Search for Contacts, View Presence, and Start IM Conversations as shown here:

To see the Skype presence of a Yammer user, and initiate a call if the rich Skype for Business client is installed, hover over a Yammer user or view their user profile as shown here:

To enable this integration, the Yammer user must be able to sign into the Skype for Business web client in Yammer. If there are sign-in problems, it will directly visible when the user attempts to launch the SfB functionality from the Yammer navigation bar as shown here:

Two common issues prevent this from happening.

Sign-In Problem #1: Select the Right Yammer Network

This is by-far the biggest hurdle to overcome when using SfB integration in Yammer. If the Yammer user is only part of one Yammer network, this likely will not be an issue. The concept and workflow of a Yammer network frequently causes confusion. If you are coming from a SfB or Exchange context, it’s best to think of a Yammer network as a separate ‘tenant’.

If the user is having difficulty signing into SfB in Yammer, they likely have a current network selected that is not part of the organizations SfB company/tenant/domain. To switch networks, select the very-subtle “Settings” icon in the left-hand navigation bar in Yammer as shown here:

Sign-In Problem #2: Authenticated to Office 365 with Another Set of Credentials in a Different Browser

I have seen several cases where even being signed into an Office 365 session in a different browser type, and even in private mode, still causes issue with the Yammer SfB sign-in! I cannot explain this other than the SfB integration is likely using a web and/or authentication component which is shared and does not support multiple authentications with different identities.

Have the user sign out from all other browser sessions, and they will likely be able to successfully login to the simplified SfB client embedded in Yammer.

Questions often arise in Skype for Business Online (SfBO) administration regarding the a user’s registered “location”. In the SfBO admin center we see it as the location field in the user listing as shown here:

This subtle setting is important for the voice Phone System calling plan (PSTN) service configuration in SfBO because it restricts what phone numbers can be assigned to a user, and their associated emergency location. Specifically, only registered emergency locations (addresses) that belong to the same country as a users’ location can specified for that user. In addition, when assigning phone numbers to a user, only acquired numbers in the same country are available for assignment.

This is usually only confusing for multi-national companies when the location attribute is not accurate, or when user relocations occur.

So Where does this Location Come from and How is it Set?

Like many user configuration properties, this Location property is sourced from the underlying Office 365 tenant user configuration, which is sourced from the underlying associated Azure AD tenant.

In Office 365 it is known as the UsageLocation attribute. It is an important attribute in Office 365 because it determines what Office 365 Licenses and and associated features can be assigned to a user based on geographic availability and laws. For example, a Calling Plan add-on service might not be available in Australia, and if a user has an Office 365 Location of Australia, that user account cannot be assigned the Domestic and International Calling Plan add-on available to the tenant license.

Where is this setting in the Office 365 Portal?

Note, the UsageLocation setting is different from the address configured in the Contact Information configured on the user (and it does not have to be the same). Because this setting directly impacts what Office 365 licenses are available to a user, it is the first setting displayed in the O365 Admin Portal by navigating to Users | Active users | select a user | Edit Product Licenses as shown here:

Where did the Value for this Setting Originally Come From?

This is a common question because the UsageLocation was usually set without explicit attention to what the default value should have been when the Office 365 tenant was originally provisioned.

There are two primary origins for the user value of UsageLocation:

Local Active Directory

If the underlying Azure AD tenant is synchronized from on-premises AD (e.g. using AAD Connect), this value was likely set from the directory synchronization.

With a pure online Office 365 tenant, there was default setting for the tenant location that was the default UsageLocation of users that corresponded to the country tenant Organization profile. I can no longer find this setting in the Office 365 Admin Center. I believe it is moved to the “Country or region” setting in the associated Azure AD tenant as shown here in the AAD Admin Portal:

How do I change it?

If it is a one-off change, or only a few users need that Location updated, it can be done through the Office 365 Admin Portal as shown above.

There is a good chance you will need to use PowerShell for anything more than a handful of user changes. There are plenty of PowerShell examples of doing this, and/or assigning Office 365 licenses, so I won’t re-hash it here, but for reference, the Office 365 / Azure AD v1 (aka MSOnline) module has two cmdlet’s that can be used to read and write this setting on a user:

As Office 365 adoption grows, more Skype for Business (SfB) hybrid deployments are being transitioned to pure online after all of the users have been migrated to online. While some steps in this final transition process are well documented, such as the decommissioning of the SfB on-premises servers, other steps are poorly documented.

This post provides some details on one step of the transition to pure online that isn’t well documented: removing the SfB user attributes (e.g. msRTC*) in on-premises AD from users after hybrid mode has been changed to pure online. This post assumes that the hybrid environment has AD directory synchronization configured (e.g. on-prem AD was synchronized to Azure AD).

Why do we Care about SfB On-Premises AD Attributes after all Users are Migrated and Hybrid is Switched to Pure Online?

This is a good question, and there is no official documentation. However, two reputable sources reference deleting these on-premises AD user attributes after migration (or a when doing a full cut-over), but without much explanation:

As stated in the first article mentioned above, the recommended method to clear those on-premises AD user attributes is to use the Disable-CsUser (e.g. Get-CsUser -Identity User01@contoso.com| Disable-CsUser -Verbose). In field experience this sometimes does not fully clear the msRTC attributes, and in at least one deployment I have seen it leave behind the msRTCSIP-DeploymentLocator attribute.

So why do we need to clear these attributes? After doing some research, it seems the risk of not clearing those user attribute on-premises is that some SfBO features – specifically voice features using Cloud Connector Edition (CCE) – will use those msRTC* attributes to determine where the user resides (on-prem or online). Specially after the switch to pure online is completed (e.g. DNS records point to online, etc…), CCE will see those synchronized Azure AD attributes, or the InterpretedUserType attribute set as “HybridOnline”, and conclude that the user voice services are still serviced by SfB on-premises, and attempt to direct the calling services to on-premises. The calling features will fail because the SfB on-premises is no longer operational.

What is this InterpretedUserType attribute?

This is another good question with little documentation. The InterpretedUserType attribute has two values which reflect whether a user is in hybrid mode (value = “HybridOnline”), or pure online (value = “PureOnline” or “DirSyncedPureOnline”).

From what I can tell, SfBO sets this value based on the presence of the msRTC* user attributes in the underlying Azure AD user object. Meaning, if the user object has those msRTC* attributes, InterpretedUserType is set to “HybridOnline”.

If the remaining msRTC* attributes are cleared in AD on-premises and synchronized into Azure AD, it appears SfBO will see those blanked attributes and change InterpretedUserType to “PureOnline” or “DirSyncedPureOnline”. Any features such as voice features in CCE will then know to properly use SfBO.

If you have any thoughts on manually manipulating this value, it cannot be set manually with PowerShell.

Should I Remove the Remaining SfB/Lync User Attributes from On-Premises AD?

This step is documented in the two reputable Microsoft sources above, and is recommended. My initial concern with doing this is that it would break integration of some existing on-premises applications or clients; specifically Outlook integration with the Skype for Business or Lync client.

This integration is purely client based integration as there is no server-side API’s used per se. Meaning when a user see’s the SfB presence for another user in Outlook, it is the Outlook client is retrieving that from the SfB or Lync client running on the same desktop. It is actually the Skype for Business Outlook Add-In, and not Outlook itself.

Although this is client-side integration, I have read forum references stating that Skype for Business Outlook Add-In uses the SIP address to establish the link, so if we clear that attribute won’t the integration break? The next section explains that.

Note: the reverse integration – the Skype for Business client integration with Exchange is a bit different. This is not pure client-to-client integration. It uses an API, Exchange Web Services (EWS), to retrieve free/busy, store conversation history, and other information. The bigger dependency here is that the SIP address used in the SfB client matches the email address.

ProxyAddresses vs msRTCSIP-PrimaryUserAddress Attribute

Back to the question of possibly breaking Outlook or Outlook Web App integration if we delete or blank the msRTCSIP-PrimaryUserAddress attribute.

The Outlook client (via the Skype for Business Outlook Add-In) will use the SIP address in the list of email addresses in the ProxyAddresses attribute to establish the link to the SfB client for integration.

Generally the answer is that we should populate the users proxyAddresses attribute with the SIP address. I use the word ‘generally’ because there are many sources (such as this one) which refer to Outlook needed the SIP address in the proxyAddresses but I have seen Exchange integration (Outlook 2016) work without either (with Exchange on-premises and SfBO). It likely depends on the hybrid configuration and clients used.

When using Exchange Online, the Outlook Web App does need the SIP value in the proxyAddresses attribute, so my recommendation is to populate it with the SIP address and fully remove the msRTCSIP-PrimaryUserAddress as part of completing the move to pure online.

Another Reason to Populate the SIP Address Value in the ProxyAddresses Attribute

When a user object is synchronized to Office 365 their UserPrincipalName (UPN) is used to provision the identity and service addresses for Exchange and Skype for Business Online.

In some enterprises, this UPN does not match the users email or SIP address, which breaks the golden rule for smoothly integrating Exchange and SfB integration. That is, the user’s SIP address should match their primary e-mail address.

One way around this problem, is to set the msRTCSIP-PrimaryUserAddress attribute in the associated on-premises AD user object to be the same as the email address. However, in this case, where we have just completely the transition to pure online, and deleted this attribute, this can’t be used.

As fellow MVP Mark Vale documented here, a way around that is to populate the ProxyAddresses value with the properly formatted SIP address and let dirsync populate it in Azure AD. SfBO will then use this value as the SIP address, which will match the email address, and not the UPN.

The world is adopting multi-factor authentication, and Microsoft is rapidly adding support in their server, services, and clients to support it. Microsoft’s name for multi-factor support is Modern Authentication (MA) and support has been added for Skype for Business Server (SfB), Exchange Server, and more recently, the equivalent online cloud services (Exchange Online and Skype for Business Online).

In practice, with potentially a decade of legacy client versions, and a now matrix of possible SfB and Exchange hybrid topologies, supporting MA for all the users in an enterprise requires some planning.

There is plenty of good documentation about how to enable MA both on-premises and online. This article highlights 5 specific things you’ll want to have answers to before enabling MA in an enterprise.

As we all know, Skype for Business (SfB) is highly integrated (and therefore dependent) on Exchange, which increases the matrix of topology scenarios. MA is not supported in all scenarios of Exchange and SfB MA, or requires special configuration. There is a very good TechNet article which clearly describes what mix of Exchange on-premises, SfB on-premises, Exchange Online, and SFBO topologies support MA:

Exchange Integration and Mobile Clients will not work for SFB on-premises with MA and Exchange on-premises with no MA.

Exchange On-Premises and SFBO with MA is Supported (a common scenario). Azure AD needs to be the identity provider for SFBO, and on-premises AD needs to be the identity provider for Exchange on-premises.

Multiple Prompts for Users: the TechNet article referenced above calls out an important point that will happen if MA is not enabled equally across all the server resource the SfB clients are using (e.g. the related Exchange resources):

“It’s very important to note that users may see multiple prompts in some cases, notably where the MA state is not the same across all the server resources that clients may need and request, as is the case with all versions of the Mixed topologies. Also note that in some cases (Mixed 1, 3, and 5 specifically) an AllowADALForNonLynIndependentOfLync registry key must be set for proper configuration for Windows Desktop Clients“

2. Plan for Client Support

If SfB has been used in an organization for several years, there are likely a wide variety of clients out in the wild such as older Lync clients on unmanaged devices, Office 2013 and Office 2016 clients, and mix of mobile Android, iOS, and Windows Phone versions.

A summary of the various client applications and the associated modern authentication support for Office 365 is available here: Updated Office 365 modern authentication. In a nutshell, any Skype for Business client version that is not part of Office 2016 (or later) will not have built in support for Modern Authentication.

For the Skype for Business client specifically, here is a summary of that support:

iOS – yes, but watch the caveat if you are in a SfB hybrid shared namespace scenario (see below)

Android – yes, but watch the caveat if you are in a SfB hybrid shared namespace scenario (see below)

Windows Phone – not supported yet

The supported client list is similar for Skype for Business Server on-premises

3. App Passwords can be used for Legacy Skype for Business and Lync Clients using Office 365

There is another option for legacy non-MA clients (e.g. Office 2013) clienst This is a somewhat cumbersome option for end users, but a viable option for those users that require legacy clients (client versions that do not natively support MA such as Microsoft Lync and Skype for Business client in Office 2013).

The App Password option involves the end user signing into the Office 365 portal and creating a special app password that is used in legacy clients and bypasses MA. The big drawbacks are that the app password is yet another password the user needs to have available and ready to use. It is auto-generated and difficult to enter on a mobile device.

One major limitation to be aware of is that this option is not available in hybrid as described here :

App passwords don’t work in hybrid environments where clients communicate with both on-premises and cloud autodiscover endpoints. Domain passwords are required to authenticate on-premises. App passwords are required to authenticate with the cloud.

4. Mobile Clients will not Work if MA is Enabled for SfB Server On-Premises and SfB Online in Hybrid

Modern Authentication for mobile clients is not yet supported in the following deployment topologies:

Exchange Online with Modern Authentication turned on and Skype for Business on-premises without Modern Authentication turned on.

Skype for Business Server 2015 and Skype for Business Online in a split domain hybrid configuration (for example, SharedSIPAddressSpace = true) with Modern Authentication turned on for both Skype for Business Server and Skype for Business Online

5. Update those Mobile Clients

Even with supported MA topologies, I’ve seen mobile clients have sign-in problems after MA has been enabled. Several times updating the mobile client – specially iOS – the latest-and-greatest as solved the issue. There are also mobile client side logs which can be useful in tracking down MA sign-in problems.

For example, one user could not sign in with MFA for the iOS Skype for Business client version 6.10.1.0. Upgrading to 6.17.3 (released Nov 15, 2017) worked.

I have talked to several people lately who have had the need to mute the audio coming from a Skype for Business meeting or web conference. Not mute their microphone, but the speaker/headset audio stream from the conference. They they are needing to listen to something else – take another call, listen to music while they just watch the conference, or even trying to participate in two conference calls at the same time.

They have struggled in the Skype for Business 2016 client on how to control this, so I wanted to pass along a couple of tips.

The simplest option to just mute the incoming audio stream is using the volume controls on the call control icon in the client. As shown below, you can either fully mute the audio, or reduce the volume.

Another option is to use the “Hold” control on the same Call Controls (as shown with the ‘pause’ icon in the screen shot above). My web conferences are all VoIP audio, so many users do not realize they can put the audio stream "on hold", just like a regular phone call. This is nice for momentary interruptions where you just need to pause the audio, do something, and then resume it.

Putting the call on-hold has some pros and cons. When you put the call on hold, a visual indicator updates in your participant entry which let’s other participants know that you have the call on hold and are not available right now, as shown here:

Another advantage is that you can a periodic ‘beep’ reminder that the call is on-hold, so that you know to return to it if you get disrupted or distracted.

A major disadvantage one reader pointed out is that a Skype for Business user can choose to configure their client to Play Music On Hold. Obviously this would be a major distraction for the rest of the participants if you put the call on hold because they would all hear music being played. The is off by default (and can be disabled by an Administrator client policy), but if you have this enabled, do not put the call on hold. The ‘play music on hold’ setting is in the Skype for Business ‘Ringtones and Sounds’ setting in the client as shown here:

Another useful feature in this scenario is the Devices button (next to the Hold). You can use this to transfer the audio to another device (like a headset instead of an external speaker).

A quick blog post to let folks know about an audio conferencing capability in Skype for Business Online (SfBO) that can be leveraged in Microsoft Teams – the ability to use (re-use) your Audio Conferencing configuration.

For example, I am configured for SfBO Audio Conferencing with a bridge number, etc.. in the SfBO Admin Center via an E3 license and Audio Conferencing Add-On. In Outlook, when I schedule an SfBO meeting, my Audio Conferencing information is included as shown here:

I can also schedule and organize a Teams meeting with the same SfBO Audio Conferencing configuration & bridge as shown here:

The only difference is the Conference ID.

This feature highlights the ability to leverage voice and audio capabilities in SfBO, from Teams.

As Skype for Business Online gains adoption, there are more questions regarding feature support with Exchange On-Premises and pure Skype for Business Online (not hybrid). Specifically, what integrated features are supported and what limitations exist? This article provides a summary of what to expect in this scenario.

More details on co-existence with Exchange Server, support criteria, and limitations in various combinations of on-premises and online are detailed in this TechNet article: Plan to integrate Skype for Business and Exchange. Note, this article highlights a best practice, which is to “move the user’s mailbox to Exchange Online before moving the user’s Skype for Business home“. In practice, I have not found anything detrimental to moving the Skype for Business user first; aside from the feature limitations discussed here.

The most challenging issue I’ve seen so far is multiple sign-in prompts in the SfB client, especially when MFA is enabled. This can happen with SfB on-premises and Exchange as well however, and I have not been able to pinpoint anything specific with the SfB user residing online.

Generally, from a feature standpoint, the full set of integrated features are supported with the exception of:

Outlook Web App integration – Instant Messaging and Presence

Outlook Web App integration – Scheduling Meetings

Unified Contact Store

High Resolution Photo’s (in the SfB/Lync client)

Feature support does differ slightly between Exchange 2016/2013 and 2010. Here I’ve summarized the feature support for just Exchange 2016/2013 vs 2010 on-premises and SfBO scenarios, and highlighted unsupported features in red:

Legal

The posts and information on this blog are provided "as is" with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer or anyone else for that matter. All trademarks acknowledged. Copyright 2013 Curtis Johnstone.