Who said “not possible”? Build your Surface Hub 2S VM

If you are working on Surface Hub deployments, it’s always a bit tricky to test it, because a) you have to find a Hub to play with and b) reset takes very long if you want to test from scratch.

Thats why I tried to create a Surface Hub Virtual Machine to get around this, and guess what: it worked 🙂

How to do it

At the end, it was pretty easy. First, download Surface Hub Recovery Media (if you don’t have a Serial Number, you can download the 2020 Edition .iso from here).

Next step, create a Windows Recovery ISO (i did with the Windows Media Creation Tool, but for sure you could do this with Rufus or something like this as well)

Then, the last (and most important) step, is to replace the binaries in the Windows ISO with the ones from Surface Hub Recovery Zip. This I did with Anyburn, but again, can be done with any ISO Editor I guess:

Edit image file
Replace Files with the ones from Extracted Surface Recovery Media
write to .iso File

Thats it, now you can mount the .iso in your Hyper-V, Virtual Box or whatever you use to spin up VMs and let the Surface Hub installation wizard go through!

Mount as DVD
Recover from drive. Full Clean
Surface Hub OOBE 🙂
Choose your desired Surface Hub Deployment Mode
heeeeere we are 🙂


This has to be done just once, then you can run as many Surface Hub VMs you like, which makes it much easyier to test and develop your deployments.

Because its a generice ISO, I can share it with you, just PM me on Linkedin if you need it 🙂 cheers!

New Sheriff in Town: Hello for Business Hybrid Cloud Trust (Preview)

Since we can use Kerberos on Azure AD Joined Devices to access onpremises resources without typing the password, there are no more good reasons to join the endpoints to the good old Domain. But to go for this pretty nice design, there is a need for an Enterprise CA with a proper CRL publishing, to issue some certificates for the onprem Domain Controllers. Without this certificates, there will be no Kerberos Tickets issued to the endpoints when they use Windows Hello for Business. This configuration of Windows Hello for Business, was called “Windows Hello for Business Hybrid Key Trust” (you can find many Blogs regarding this topic out there).

This worked pretty well, but there was an issue when people cconfigured WHfB during Autopilot, because there is an Azure AD Connect Sync to be waiting for, to get some Attributes on the User Account set, which then makes it possible to get the Kerberos Ticket.

To work around this, we mostly brand 2 Registry Keys during Autopilot in the Default User Registry (with PSADT usually), to hide the Windows Hello for Business Wizard without disabling it through Intune:

‘HKCU\SOFTWARE\Policies\Microsoft\PassportForWork’ -Name ‘Enabled’ -Value 1 -Type DWord

  ‘HKCU\SOFTWARE\Policies\Microsoft\PassportForWork’ -Name ‘DisablePostLogonProvisioning’ -Value 1 -Type DWord

Hello for Business Hybrid Cloud Trust

But now we have a very interesting announcement, called “Hello for Business Hybrid Cloud Trust” (currently in previw). This new WHfB Method, uses an onprem Computeraccount, created for exactly the same purpose, to get some Kerberos Tickets out to the devices. The two main advantages of this method, compared to the Hybrid Key Trust Model are:

  • No more Enterprise CA Infrastructure needed
  • Because of the used Kerberos Delegation, there is no need to wait for Azure AD Connect sync anymore

how cool is that???

How to configure

There are a few prerequisites needed to get this running, all documentd here, most important:

  • a couple lines Powershell code to deploy Azure AD Kerberos
  • an Intune CSP Setting
  • Full patched Win10 / 11 and Server 2016 on Domain Controller

Installing Azure AD Kerberos

based on this article, you install the required PowerShell Modules, then run the configuration script with your required values on one of your onprem servers:

# First, ensure TLS 1.2 for PowerShell gallery access. [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

# Install the Azure AD Kerberos PowerShell Module.
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.

$domain = “intra.domain.com”

# Enter a UPN of an Azure Active Directory global administrator

$userPrincipalName = “admin@domain.ch”

# Enter a domain administrator username and password.
$domainCred = Get-Credential

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Azure AD.

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred


Intune Config

Next we have to deploy the required Intune Settings. In my Lab I will configure Hello for Business and the Cloud Trust policy only (on your tenant there will be probably some more settings for sure).

go to Windows Hello for Business
select “Enabled”

and then as a custom Windows Configuration Profile, the Hybrid Cloud Trust CSP with your Tenant ID in it:

./Device/Vendor/MSFT/PassportForWork/xxxxxxxx-yyyy-uuuu-zzzz-516107738775/Policies/UseCloudTrustForOnPremAuth (dont forget to replace the Tenant ID)


If all went well, you can now layback and watch your devices going through Autopilot, then directly to the Hello for Business Wizard and then finally using their first Kerberos Tickets to access Fileshares or other legacy stuff.

This is a game changer!

yes, there we go 🙂

Autoactivate Sensitivity Label Bar

If you deploy the all new AIP Unified Labeling Client to your machines, every user has to enable the status bar in Office if they want to apply some labels. This behavior can be changed through some Powershell Commandlets.

First of all, download the client MSI and deploy it through Intune https://www.microsoft.com/en-us/download/details.aspx?id=53018

download  intune

Then, we need to create the required Labels in Office 365 (will cover that in a separate blog some days):

Annotation 2019-11-06 162120  Annotation 2019-11-06 162710

Next step is to connect the Office 365 Security & Compliance Center Powershell, easiest way if you are using MFA (which I hope you do), is to download the Exchange Online Powershell Commandlets in Internet Explorer (no comment), this can do your modern auth (connect-ippssession -userprincipalname asfd@asdf.com):

ps  connect

Then you can run a single command line to automatically enable the status bar for every scoped user in you label publishing (just replace the label policy name):

Set-LabelPolicy -Identity “Schützenswert / Sensible” -AdvancedSettings @{HideBarByDefault=”False”}


so, thats it, now the bar will be displayed automatically on the next start of the Office App.



Surface Hub 2s Deployment Part III: Room List for Teams Meeting Requests

The last part is about creating a Roomlist, to get the Surface Hub as Resource in Teams Meetings Requests. Learned from Yoav (https://y0av.me/2018/11/07/add-surface-hub-and-srs-rooms-to-microsoft-teams-meetings/)

#1: Connect Exchange Online with MFA
If you are using MFA for you Admin Accounts: Download Exchange Online Powershell in Exchange Online Admin Center with Internet Explorer (had to Install IE again first haha), then connect with Powershell

#2Create the Roomlist and Add you Surface Hubs into it

#3: You can now select your Surface Hub as a resource in Teams

Go back to Part 1 or Part 2

Surface Hub 2s Deployment Part II: Intune Policies & Configuration

In the first part, Resource, User and License has been provisioned. Now it’s time to configure some Intune Polices for the device. The following Settings has been defined for deployment:

  • App Deployment from Microsoft Store (Win32 is not Supported)
  • Teams as Default Phone Client
  • PIN for Projection
  • Custom Start Layout

For AppDeployment, the Store for Business needs to be synchronized into Intune, Offline Licensing is required for every deployed App.

#1: Enable Store for Business Offline Apps

#2: “Buy” Teams and sync it into Intune

#3: Deploy it to your Surface Hubs

#4: Create Device Configuration Settings
Create a Custom Settings Profile for the 2 required OMA/URIs and deploy it to your Surface Hub (Details over here: https://docs.microsoft.com/en-us/microsoftteams/teams-surface-hub)

#5: Create Device Restriction Profile for Start Layout and PIN
To create the Startlayout, you can download and modify this template: https://docs.microsoft.com/en-us/surface-hub/surface-hub-start-menu (could not test that one yet)

In Part III, a Roomlist will be created for Teams Meeting Requests: Part III

Surface Hub 2s Deployment Part I (Resource & User)

Last week I was lucky and could get some hands on a brand new Surface Hub 2s; of course managed through Intune. A few printscreens and experiences from setup and configuration:

#1: Create Resource

#2: Set Auto-accept and Booking window

#4: Assign License to the User (we decided to go for the Meeting Room license wich contains Intune, Teams, and Phone System as well)

Part II: Intune Policies & Settings

Self Service PW Reset from LogonScreen

With W10 1803, it’s now possible to reset your password with a Hybrid Azure AD Joined (Domain Joined, Synchronized to Azure AD) device directly from Logon Screen.


The following actions needs to be done to fullfill this:

  • Configure your Azure AD Connect Service to synchronice device records


  • Set the following registry key to enable the “reset password” button on your logon screen: “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount\AllowPasswordReset” dword:00000001


Thats it, now your users are able to reset their passwords through the well known Azure AD SSPR feature:


New Tool: SetupDiag.exe

With setupdiag.exe, Microsoft is providing us an easy way to troubleshoot faild inplace upgrades. This is handy if you don’t like to crawl through massive logs in different places.

Here is a first impression:

First, download it here: https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag

Then run it on your failed client with /online, or copy down all the logs and refere within the /offline switch. In my case, I’m troubleshooting directly on a failed client:


Now it’s collection every relevant entry in all the different locations and displays the interessting lines:


this is it, in my case it was the EFI Disk which was in a bad shape (led there by searching the 0x80070002 error). If you need the results collected, it stored in the path specified in the /Output parameter, the log itselfs looks like this: