Skip to content

Managing the Surface HUB 2s through Intune

In the beginning of this week, I was invited to a Microsoft training about the new Surface HUB 2S. The 2S is the successor of the Surface HUB, Microsoft ‘Creative Meeting Room’ solution. The Surface HUB 2S consists of the following parts out of the box:

  • 55 inch 4K Touchscreen Display (with an 80 inch option coming later this year)
  • 4K webcam
  • Surface HUB Stylus

The Surface HUB 2S integrates perfectly with all Office 365 apps like Microsoft Teams, Skype for Business, Edge, Whiteboard and many more.
The Whiteboard app on this device is really great and enables creative teams to meet with colleagues across the globe while providing a very interactive experience. Check out this video for some examples.

I will not go into any more details about the Surface HUB 2S itself, but will focus on how we can manage this device through Intune.

Management of the Surface HUB 2S

The HUB can be deployed in three different ways:

  1. Local Administrator
  2. Joined to a local Active Directory Domain
  3. Joined to Azure Active Directory

Option one isn’t preferred because this won’t give us any way to centrally manage the Surface HUB. That’s why option 2 and 3 will be used by most businesses.
An important note is that the Surface HUB 2S doesn’t support GPO’s. It uses a modified version of Windows 10 (Windows 10 Team OS more specially). So the only way to manage it is through an MDM. Microsoft prefers Intune ofcourse, but third-party MDM systems can also be used.

If you want to use Intune to manage the device, you have to manually enroll the device, because auto-enrollment isn’t supported at the moment (but it is on the roadmap).

Intune

Inside Intune, there is a special profile type for the Windows 10 Team OS. In this profile type there are some basic configurations for your Surface HUB. These include: MiraCast (wireless projection) settings, screen and sleep timeouts and settings that change the look of the start menu. A full overview of those settings can be found in the Microsoft documentation. If you don’t find the necessary options there, Microsoft has some custom CSP policies available.

Of course you aren’t limited to the specific Windows 10 Teams settings, you can also use some other configuration types, like Bitlocker and Windows Update. One important note is that the Surface HUBs don’t support Delivery Optimization. So don’t waste your timing assigning those policies to them.

Apps

Because the Surface HUBs only support Windows Store apps, you don’t have a lot of options to deploy apps. I recommend linking your Windows Store for Business to Intune to easily deploy your store apps. Deploying Windows Apps to HUB devices can be done the same way as to regular Windows 10 devices. One thing to keep in mind is that they don’t support online apps and you need to deploy offline apps.

It’s also possible to include apps in a provisioning package. Personally, I am not a fan of this, because this keeps your content more static than just deploying them with Intune.

Provisioning

Last but not least, how do we provision every Surface HUB that arrives in your organization? My first thought was: “Let’s use Autopilot!”, but unfortunately… Autopilot isn’t supported in combination with Surface HUBs. I was informed that this is on the roadmap, but there is no timeframe for that though.

The only way to automate the provisioning of HUB’s is to use a provisioning package. You can choose to use it during OOBE or after you have gone through OOBE. In this PPKG file, you can include various settings, but also your apps. This will automate your deployment of Surface HUBs, but I will be waiting for Autopilot support. That would be a very interesting scenario!

That concludes my first blog on my new site. Have any questions or remarks? Feel free to leave a comment or reach out to me on social media.

6 thoughts on “Managing the Surface HUB 2s through Intune Leave a comment

  1. How are you dealing with managing the Surface Hub devices with compliance policies via Intune? Are you assigning the policies to the device itself or do you assign compliance policies to the users?

    In my environment, I had to setup the local admin account first them manually add to Intune as we are currently looking into using passwordless signin using authenticator; I had an issue that I could not passwordless sign in if i joined them directly to AzureAD when going through the OOBE setup.

    Like

    • For Compliance Policies, I would advise them run assign to the devices.
      As you might want to have different compliance policies for your HUBs.

      There were issues with passwordless sign-in a few months ago, might be that they are still working on a fix

      Like

      • Thanks. Heard as well that it may be fixed in the upcoming 1809 release.
        I am using dynamic groups in AAD to assign the devices to a group and pushing the compliance policy to that group. One thing I noticed that I have multiple entries for the same device; seems to create another device each time someone logs into the device to register. Have you seen that?

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: