Surface Hub: Skype for Business vs Teams

Surface Hub supports running both Skype for Business and Microsoft Teams, based on the Teams mode you configure.

Skype for Business supports both On-Premises and Online deployments, whereas Teams is available online only.

The following table lists the major differences between the Skype for Business and the Microsoft Teams functionalities on Surface Hub:

Functionality	Microsoft Teams	Skype for Business
Join Scheduled meetings	✔	✔
Create Ad-hoc meetings	✔	✔
Make/Receive PSTN calls*	✔ Outbound only	✔
Make/Receive Audio calls	✔	✔
Make/Receive Video calls	✔	✔
Instant messaging	❌	✔
Screen sharing	✔	✔
Auto camera switching	✔	✔
Store update**	✔	❌
Windows update**	❌	✔
Whiteboard launch	✔	❌
Maximum live incoming video	4 simultaneous streams	2 simultaneous streams
Connect to On Premises environment	❌	✔
Can be used with Meeting Room license	✔	✔
Can be used with another UC app	✔	✔
QOS Ready	✔	✔

* PSTN calling is Subject to licensing
** Skype for Business is part of the OS and will update when OS updates are available. Microsoft Teams is a Windows Store UWP app and will update automatically from the store as updates become available.

• In Teams mode 0 and 1 the appropriate UI will launch based on the type of the invite; the Skype UI will launch if it’s a Skype for Business scheduled meeting, and the Teams UI will launch id it’s a Teams scheduled meeting.
• You can still launch the full Teams client from the Microsoft Edge browser on Surface Hub, that will provide you with the full Microsoft Teams experience, using the Surface Hub’s cameras, microphones, speakers and touch.
• Launching the Microsoft Whiteboard from inside the Teams app will automatically grant access to anyone in the meeting (Tenant limitations apply), enabling them to co-author simultaneously from any supported device.

Changes coming to Microsoft Whiteboard

Published on March 15 in the Office 365 Admin Center, there are several changes coming to Microsoft Whiteboard you should be aware of, especially if you have Surface Hub in your organization:

In Office 365 services, organizations that have “Whiteboard” enabled will see “Microsoft Whiteboard” that will be automatically enabled. No action required by admins.

Office 365 organizations that are located in Europe will have their data content move to their regional data centers rather than the US data centers that were used so far. No action required by admins.

For Surface Hubs, the “Microsoft Whiteboard 2016” app that’s installed by default in the Windows 10 Team OS will be automatically upgraded to the new “Microsoft Whiteboard” app by May 21, 2019.
The legacy “Microsoft Whiteboard 2016” collaboration feature will stop working in early June 2019 and the app is expected to stop functioning and will no longer be supported starting June 7, 2019.
If you disabled automatic Store updates on your Surface Hub’s Store app, make sure you re-enable them to get these updates.

Download and install the Microsoft Teams app using Intune

I was looking for an ‘easy’ way to push the Microsoft Teams app to devices using Intune.

Since the ‘Windows S’ Teams app is no longer available, the options were to either create a ‘Line of Business’ app in Intune or use Graph API. Both valid options, but – why?

Looking at the documentation to install Microsoft Teams using MSI, you can use System Center Configuration Manager, Group Policy or any third-party distribution mechanisms for broad deployment. As Intune falls into the latter, if you’re on a modern-managed environment – I prepared a script for that purpose.

The script will do the following:

• Download the x64 MSI installer directly from Microsoft. (You can use the x86 MSI as well if you need)
• Extract the installer to a folder on the client machine and run the installation quietly with the least possible privileges .

New-Item -ItemType Directory -Force -Path  C:\TeamsAutomation
Set-Location C:\TeamsAutomation
Invoke-WebRequest -Uri "https://aka.ms/teams64bitmsi" -OutFile "Teams_windows_x64.msi"
msiexec /i Teams_windows_x64.msi

Based on the default behavior of the installer, whenever a user signs into a new Windows User Profile, the installer will be launched and a copy of the Teams application will be installed in that user’s appdata folder. If a user already has the Teams app installed in the appdata folder, the MSI installer will skip the process for that user. So you can rest assure that the client doesn’t reinstall itself every time a user signs in.

Save the above script as a .ps1 file and upload in to Intune PowerShell:

In the Intune Devices Management Portal (https://aka.ms/apmgmt), go to Device configuration – PowerShell scripts and click to Add a new PowerShell script.

Provide a name and the location of the .ps1 file you created:

 

Click to configure settings, and make sure that both ‘Run this script using the logged on credentials’ and ‘Enforce script signature check’ are set to ‘No’:

Click ‘OK’ and ‘Create’ and assign the scripts to the device groups you desire.

Right after syncing, you’ll see the following events on your machine:

These will confirm that the installation was successful and users will be signed in to Teams automatically on the next log on.

 

 

 

 

 

 

Add Surface Hub and SRS Rooms to Microsoft Teams Meetings

(Or any room, as a matter of fact)

 

If you’re using Outlook and have the Teams Meeting add-on, you can schedule a Teams meeting and add a room to the meeting:

 

 

But if you try to schedule a meeting from Teams and look for a room to find its availability, you might face a challenge as Teams would not show any rooms:

 

Looking at the glass half full, this is a great opportunity to make some order in how users book rooms with Teams:

Teams takes advantage of Exchange’s New-DistributionGroup cmdlet -RoomList switch. The RoomList switch specifies that all members of a specific distribution group are room mailboxes.

You can create as many distribution groups as you need – based on any parameter that you want. In my scenario, I chose to create two lists:

• One for rooms equipped with Surface Hubs
• One for rooms equipped with Skype Room Systems.

This way my users will know which collaboration devices are available for them when they book a room.

Creation process of the distribution groups is easy.

Connect to Exchange Online:

$365Cred = Get-Credential
$365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $365Cred -Authentication Basic –AllowRedirection
$ImportResults = Import-PSSession $365Session

Create the new distributiobn groups with the -RoomList switch:

New-DistributionGroup -Name “Surface Hubs” -Roomlist

Add rooms to the distribution groups:

Add-DistributionGroupMember -Identity “Surface Hubs” -Member “SurfaceHub01"

Log back into your Teams client and see the new lists:

 

Choose the available room from the list:

 

 

And you’re all done:

 

The room is now booked. If you’re using a Surface Hub or a Skype Room System the meeting will be displayed on the device.

---

This post was originally posted on my TechNet blog: https://aka.ms/y0av.

Deploy the Microsoft Teams for Surface Hub app using Intune

Originally written for the Microsoft Teams for Surface Hub (Preview) app, this article is now updated to support the GA version of the app. Images may still contain ‘Preview’.

In this post, I’m going to cover the steps required to push the Microsoft Teams for Surface Hub app to Surface Hubs and configure its options using Intune.

To push the app to the Surface Hub you’ll have to you’ll have to configure Intune and the Microsoft Store for Business to push apps to the Surface Hub. Follow this post to configure both if you haven’t done it yet.

Remember – you must acquire the offline license version of the Microsoft Teams app (No purchase required) to be able to push it using Intune:

After syncing the store with Intune, you’ll see the app in the Apps list:

Next, configure the Microsoft Teams app CSP settings in Intune.

Create a new Device configuration profile in Intune. Set the Platform to Windows 10 and later, and the Profile type to Custom:

There are two dedicated CSPs we’re using to configure the app on the Surface Hub. Both must be present for the app to work:

./Vendor/MSFT/SurfaceHub/Properties/SurfaceHubMeetingMode is the CSP that replaces the .ppkg files you’ll be using if you’re manually installing the app. it comes with the values of 0, 1 or 2 and would act as follows:

• 0 – Skype for Business is the preferred app on the Surface Hub’s Start Screen, however you can still join Microsoft Teams meetings.
• 1 – Microsoft Teams is the preferred app on the Surface Hub’s Start Screen, however you can still join Skype for Business meetings.
• 2 – Microsoft Teams is the exclusive app on the Surface Hub’s Start screen and Skype for Business is disabled.

The Data type for this setting is Integer and you can choose any value from the above as illustrated in the following image:

./Vendor/MSFT/SurfaceHub/Properties/VtcAppPackageId is the CSP representing the app ID that’s replacing Skype for Business; Microsoft Teams. The value for this CSP is always Microsoft.MicrosoftTeamsforSurfaceHub_8wekyb3d8bbwe!Teams

The Data type for this CSP is String. Copy and paste the value from the line above as illustrated in the following image:

To assign the policies (App deployment and Device configuration) to the Surface Hubs, create a security group with the Surface Hubs device accounts:

Go back to the Microsoft Teams for Surface (Preview) app in the Apps list and click ‘Assignments’. Assign the app to the Security Group you created with the following settings:

• Assignment type must be Required.
• On the Select groups to include list, choose the group you created earlier and set the license type to Device Licensing:

Click ok and save the configuration.

Next, for the Device configuration profile, assign it to the Security Group you created:

Intune will push the and settings immediately. You may need to restart the Surface Hub to complete the process.

Servicing, Flighting and Managing updates for Surface Hub

Whether you have five, fifty or five hundred Surface Hubs, managing and delivering updates to your Surface Hubs is as important as servicing your other Microsoft products.

  Let’s see how to get it done right:

What are our options?

No matter how you manage your Surface Hubs, you have two update options:

• WSUS – In which you can utilize an on-premises WSUS infrastructure to approve and deliver updates to your Hubs.

   

• Windows Update for Business – Also known as WUfB or just “Windows Update”, where updates are being downloaded directly from Microsoft. Based on you organization’s policy, you might choose to deliver only some updates and defer\delay other updates to your Windows devices.

  There are 3 types of updates offered by WUfB: (Source)

• Feature Updates: previously referred to as upgrades, Feature Updates contain not only security and quality revisions, but also significant feature additions and changes; they are released semi-annually.
• Quality Updates: these are traditional operating system updates, typically released the second Tuesday of each month (though they can be released at any time). These include security, critical, and driver updates. Windows Update for Business also treats non-Windows updates (such as those for Microsoft Office or Visual Studio) as Quality Updates. These non-Windows Updates are known as Microsoft Updates and devices can be optionally configured to receive such updates along with their Windows Updates.
• Non-deferrable updates: Currently, antimalware and antispyware Definition Updates from Windows Update cannot be deferred.

Is the Hub different?

Surface Hub is running a special version of Windows OS called “Windows 10 Team Edition”. It’s a locked-down, secured, Surface Hub-specific version of Windows 10. It is being serviced with the entire Windows 10 branch, and therefore will be getting the regular security updates and monthly updates just like any other Windows 10 OS. This means that whenever we release an update to Windows 10, even if the KB states that “This update introduces no changes to Surface Hub” or if the update doesn’t mention Surface Hub, it would still apply to the Surface Hub as the Windows 10 Team Edition OS is a Windows 10 OS. Since Windows 10 Team Edition is designed to only work on Surface Hub, it has a few apps and features embedded into it that would require special attention when we release new features to Windows 10. This is why we moved to a services-approach for Surface Hub, releasing updates as they become available instead of bundling them into larger software updates. This enables us to be more agile and ensure we are providing the best experience to our customers. It helps us deliver tailored, stable updates based on your feedback, that are tested for delivering the required Surface Hub features – all bundled as quality updates. This is also why we release Surface Hub-Specific updates on the week following ‘Patch Tuesday’ – We’re assessing and confirming the standard Windows updates released on the second Tuesday of every month, and releasing fixes and other Surface Hub-related updates on the following Tuesday, the third Tuesday of every month.

How to prepare?

Well, there isn’t really a “One size fits all” solution here. Some organizations like to have time to test updates, some don’t. Some would have Surface Hubs on the Windows Insider program, some are only interested in the more stable updates. If your organization is large enough, my recommendation would be:

• Insider – Have at least one Surface Hub on the Windows Insider program. We’re trying features all the time and your feedback is priceless. Make sure you do submit your feedback if you like something, and make sure your voice is heard if we’re missing something or removed your favorite feature. As always with Insider, some builds could be glitchy and unstable, and not all features will make it to the production builds. Note that Insider Surface Hubs have a message on the top left corner saying they’re on an Insider build, and that the only way to revert to a production build is to reset your device.
• Test – Have a few Surface Hubs on immediate release, These devices can be used to test the stability and new features of Surface Hub as updates are delivered. This is the default configuration of Surface Hub, so should be fairly easy to manage.
• Production – For all the rest of your Surface Hubs, measure how long it takes you to test and assess the builds and updates we’re shipping and then defer the updates based on this evaluation. As we’re applying Surface Hub updates on the week following Patch Tuesday, I recommend allowing at least 14 days before you apply the updates to your production devices. This means:  That if, for example, we release the Windows 10 updates on Tuesday June 12, we will be releasing Surface Hub specific updates (if any) on Tuesday June 19. This will give you enough time to test the builds and updates and also enough time to apply the updates after potential Surface Hub updates. By July 3rd, you’ll be running the tested patches across all your Surface Hubs.

How to Control this?

Intune to the rescue! If you only have 2 or 3 Surface Hubs you want to connect to the Insiders ring, you might be better off adding them manually. Remember that now with the Surface Hub Recovery Tool, it’s much easier to recover your devices’ hard drives is something went wrong. For your test Surface Hubs – you don’t have to apply any update ring. They’re programmed to automatically install all Windows updates during the daily maintenance window, and will do so by default. For you production Surface Hubs – Create a new update ring (or rings, if you want to divide by region, department, screen size, etc.) in Intune (Software Updates -> Windows 10 Update Rings) and follow these guide lines:

• Use the Semi Annual Channel to update Surface Hub. This is the most frequent update channel, and will of course allow for all other Windows Updates to be delivered.
• Allow Microsoft Product Updates and allow Windows Drivers Updates.
• For “Automatic Update Behavior”, leave the setting on “Auto install at maintenance time”. You can control this setting with a Device Configuration profile in Intune.
• You can Skip the “Restart Checks”, Surface Hub will take care of that during the daily maintenance window.
• Defer the Quality and Feature updates for up to 30 days. You can always pause the ring if you need more time.
• Ignore the “Delivery optimization download mode” setting. Surface Hub will not honor this part of the policy as it can’t be changed anyway.

Assign this policy to your Surface Hubs and monitor it using “Device Status”. 

Deploy Windows Store apps to Surface Hub using Intune

Visit my TechNet blog to read my latest post:

https://blogs.technet.microsoft.com/y0av/2018/01/18/7-2/

Surface Hub in a Multi-Domain Environment

There are quite a few considerations (and benefits!) when introducing Surface Hub to your organization. It introduces great new collaboration abilities, but also challenging the way you configure, manage and monitor it.

This gets even more challenging when working in a Multi-Domain or Mutli-Forest environment, where allowing users from different domains and forests to book resources on other domains.Let’s see if we can break that down in a way that makes sense:

 

(Going back to Windows Server 101, let’s recap what Active Directory Forest and Domains are…)

• Domains are container objects; They are a collection of administratively defined objects that share a common directory database, security policies, and trust relationships with other domains.
• Domain trees are collections of domains that are grouped together in hierarchical structures; When you add a domain to a tree, it becomes a child of the tree root domain. The domain to which a child domain is attached is called the parent domain.
• A forest is a complete instance of Active Directory; A forest acts is a container that houses all the domain containers for that particular Active Directory instance. A forest can contain one or more domain container objects. By default, information in Active Directory is shared only within the forest.

So basically, you can have multiple forests that have multiple domains in them. By default, a domain provides authentication and authorization services for all its accounts, in order to facilitate logons and single sign-on access control to shared resources within the boundaries of the domain.
Forests can be used to segregate domain containers into one or more unique DNS namespace hierarchies known as domain trees. Because the forest is a security boundary, each forest does not trust or allow access from any other forest by default.

If your environment has multiple forests such as a User forest and a Resource forest, you might want to check this article in the Surface Hub Admin Guide.

 

Nevermind the setup, how do we get collaboration working right?!

Let’s try to answer some of the common questions that we normally see:

– How would you handle booking hubs? If we tied all the hubs to one parent domain, would TNEF & and proper federation allow for any of the sub domains to book hubs?

First, allow your Surface Hubs to receive external meeting invites. This will allow users outside your Exchange Organization to invite the Hubs’ room mailboxes.
To enable that, run the following command against your Hubs:

 

Set-MailboxCalendarSettings HubRoom1@contoso.com –ProcessExternalMeetingMessages $True

 

TNEF configuration is not required for Surface Hub when sending meeting invites from remote domains. The Skype for Business client on the Hub can read the meeting url in the invite, and does not require the “winmail.dat” attachment in the invite header. If you’re using Skype Room Systems as well as Surface Hub – TNEF is required for SRS and can be configured using these instructions.

Federation is required and must be configured between both organizations for the Hub to join the meeting. Check with your Skype for Business admin that federation is enabled and add the remote domains if required:

 

New-CsAllowedDomain -Identity "fabrikam.com"

 

To further simplify the process, create a Mail Contact for the Hub in every remote organization so that users can easily find it and send it meeting invites:

 

New-MailContact -Name "Fabrikam Surface Hub 20" -ExternalEmailAddress "SurHub20@fabrikam.com"

 

Now for some context:

Diagram 1 above explains what happens when Jess from the Fabrikam domain wants to invite “Surface Hub 20” on the Contoso domain:

1. Jess will use the Address Book in the Fabrikam domain to find the Mail contact for Surface Hub 20 in the Contoso Domain.
2. The invite will be sent to SurHub20@contoso.com
3. A response will be sent directly to Jess based on the resource availability.

This is common in multiple-domain environments where admins can create mail contacts for users in other domains.

Diagram 2 above explains what happens when Jess from Fabrikam invites Alan from Contoso to a meeting, which Alan then forwards to “Surface Hub 20” in his organization:

1. Jess sends a Skype Meeting invite to Alan.
2. Alan forwards the meeting invite to “Surface Hub 20”.
3. “Surface Hub 20” will accept or decline the meeting based on availability.

 

– Will users from any Office 365 tenant be able to login to “my files” on OneDrive?

Yes. Especially if your organization is using Office 365 and your environment is optimized for Office 365.
Any user can log on to their files on Office 365 once they authenticate, subject to their organization’s policies.

 

– Will users from any tenant\domain be able to Miracast?

Yes, Miracast does not require user authentication in order to project your screen to the Hub. Anyone with a Windows 10 device or a compatible device can project to the Hub.

 

For more information check the Surface Hub Admin Guide here.

Surface Hub and the Skype for Business Trusted Domain List

Check out the post I wrote on my Microsoft TechNet blog:

https://blogs.technet.microsoft.com/y0av/2017/10/25/95/

Surface Hub and the Skype for Business Trusted Domain List

Surface Hub takes advantage of all the automatic configuration options Microsoft’s Productivity tools has to offer; it will use Exchange’s autodiscover to find the Room Mailbox’s account and policies, and will use Skype for Business’ Lyncdiscover to locate the Conference Room’s registrar.
Due to the nature of Surface Hub’s OS (Windows 10 Team Edition), and due to the fact that it’s a locked-down, secured, communal device, it will not show you any popups during the step-by-step configuration (OOBE) or later when it attempts to connect to services and servers. This makes the environment preparation task even more critical: When installing them, Surface Hubs can be configured individually by the installer if they have the required information, or using a PPKG file for mass deployments. In any case, having all the required information is crucial – as the installation will not complete if it hits an issue along the way.
One of the most common issues with Surface Hub installation and Skype for Business is the Trusted Domain List.

What is the Trusted Domain List and how to get it right?

The Trusted Domain List, also referred to as the “TrustModelData” is a List of the trusted domains that don’t match the prefix of the your SIP domain.
When a user (or a device, in this case) connects to the Skype for Business server, the client validates the connections against a list of trusted servers.
Who are the trusted servers?

1. The users’ SIP URI domain
2. Any server that the client connected to in the past, and that was added to the Trusted Domain List (More on this below)
3. The domain of the server that the client last connected to

Let’s break these down:

Scenario 1 is pretty straight forward; if  the users’ SIP URI domain and the servers’ domain are the same, there’s an automated trust and the client will sign in immediately.

User’s SIP URI	Alan@contoso.com
Server’s FQDN	SfBFE01.contoso.com

Scenario 2 is where the users’ SIP URI is different than the servers’ domain (due to internal naming convention – for example: domain.local, or due to users\resource forests, etc.)

User’s SIP URI	Alan@contoso.com
Server’s FQDN	SfBSVR.01.Resource.contoso.local

In this case, the Trusted Domain List can be prepopulated by the admin via GPO or manually configuring Registry keys, and also by the user:

Every time the client connects to a new server – an untrusted server – the user will receive a prompt saying “Skype for Business cannot verify that the server is trusted for your sign-in address. Sign in Anyway?”

Once the user clicks Connect, the server is added temporarily (See Scenario 3) to the  Trusted Domain List. If the user will go ahead and check the “Always trust this server” box, the server will be added to the Trusted Domain List and the warning will never appear again.

Scenario 3 is what’s happening when the user connects to an untrusted server and acknowledges the ‘Sign in Anyway?’ popup. The server we’re connected to is saved in the registry and will remain there until the user connects to a new server. As long as the server is there, the user will not be prompted to trust the server:

For most workstations, the Trusted Domain List will be pushed via using Skype for Business Server 2015 in-band provisioning, but it can also be pushed using Registry keys or GPO.

What does this have to do with Surface Hub?

Surface Hub will not prompt you to ‘trust a server’ if its not on the Trusted Domain List. Instead, you’ll have to make sure that all possible domain names are represented in Surface Hub. Otherwise, the Skype for Business client will not connect:

However, other features, like Emailing the whiteboard, will work, as Exchange doesn’t require a Trusted Domain List:

The Trusted Domain List on the Surface Hub can be edited in one of the following ways:

• Add the domain name in the “Configure domain name” window , under Settings -> Surface Hub -> Calling and Audio

• Using the Windows Configuration Designer, perpare a PPKG file that contains the domain name under RuntimeSettings/WindowsTeamSettings/SkypeForBusiness/DomainName

• Using Microsoft Intune, crate a new custom configuration policy for Windows 10 Desktop and add the following OMA URI:

  ./Vendor/MSFT/SurfaceHub/InBoxApps/SkypeForBusiness/DomainName

In the value field, add the domain name of your server:

Following these steps will ensure that Surface Hub can easily connect to Skype for Business in your environment.

For more information check the Surface Hub Admin Guide here.