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:
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!
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!
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:
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:
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).
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.
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.
Then, we need to create the required Labels in Office 365 (will cover that in a separate blog some days):
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 email@example.com):
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):
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
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: