Wednesday, 18 August 2021

SSO Profile Assignment arrives at last.

The sequence of posts describing how to federate from Google to Microsoft Azure AD (SSO) has remained one of the most popular subjects on the site.

However, ever since the process was first described it always came with a warning.

If you turn on SSO it applies to all non-admin accounts in the Google organisation. 

Historically the capability to scope SSO to a particular group of users was never provided, it was either ON or OFF for everybody. The IP subnet field gave you some control over testing and rollout but other than that it was all or nothing.

This wasn't too much of an issue for a school operating within a single organisation but for larger Multi-Academy Trust (MATS) that managed dozens of schools under one tenancy it was a bit of a show stopper. In this situation you couldn't turn on SSO for one school without affecting all the others. 

However now that SSO profile assignment has arrived as a beta feature, all that has changed.

SSO profile assignment is simple and easy to implement. The standard Single sign-on (SSO) with third-party identity providers (IDPs) dialog in the Security section remains unchanged. You need to fill that in with the same data as before.

What has changed is the fact that once you turn the profile ON this action simply marks the profile as being active from the root OU and provides you with a dialog to update it.

Therefore to fix SSO to a particular OU you need to edit the root entry to turn the feature OFF and then add additional entries at lower OU levels to override the setting and turn it back ON. Basically SSO now operates like all the other Google Apps features and settings.

In the example above SSO is turned OFF at the root and is only active for the Students OU.

Selecting the MANAGE option (above) displays the OU tree with the ability to select and edit the properties of each OU. Those OU’s with overrides set are marked with a grey dot (below)

Removing the settings from an OU is not quite as simple as selecting the REMOVE SCOPE option. You first need to clear the override by selecting INHERIT. The Remove Scope option then removes it from the list shown above.

As well as OU’s Google provides the ability to set SSO based on Groups and Users. This is a particularly useful feature if your OU structure does not map directly to the requirements for SSO.

Like other implementations of groups, assignment to a group or user can only be used to turn the feature ON and not as an exclusion


Although still a beta feature SSO profile assignment worked exactly as expected in a recent implementation for a multi-site MAT and certainly removed a large amount of risk from the project. All in all, a great new feature that’s been long overdue on the G Suite Admin console.

Wednesday, 14 July 2021

Returning the Windows 10 key from Powershell.

It's sometimes a useful skill to be able to return the Windows 10 key from a device that has lost a sticker.

Fortunately you can get the windows key from a simple Powershell command run as admin.

(Get-WmiObject -query 'select * from SoftwareLicensingService').OA3xOriginalProductKey

Microsoft Office 2019 and Office 2016

Press Windows logo key+X on your keyboard to open the quick action menu.

Select Command Prompt (Admin).

If a security prompt window is displayed, select Allow.

Using the command line to check your license type

Open an elevated Command Prompt window.

Type the following command to navigate to the Office folder.

For 32-bit (x86) Office

cd c:\Program Files (x86)\Microsoft Office\Office16\

For 64-bit (x64) Office

cd c:\Program Files\Microsoft Office\Office16\


  cscript ospp.vbs /dstatus

and then press Enter.

In the example above the screen displays the Retail type license. If you have a volume license (VL) product, the license type is displayed as VL or Volume Licensing.

Thursday, 17 June 2021

Turning off Hello for Business in EDU

IT managers using MEM to manage Windows devices for schools often struggle with Windows Hello for Windows (WH4B).  While the corporate world has a clear requirement for the type of 2FA that WH4B provides it's not that useful in schools. 

Unfortunately the default setting found in the Windows-Enrolment in the MEM console turns WH4B on and targets the All Users group and unlike other settings there's no option to edit this group assignment or add an exclusion policy.

In essence you can turn WH4B on or off for all users but that's about the limit of the scope control.

Another common complaint is that once you have noticed your mistake and turned WH4B off, this only affects new device enrolments, not devices and user accounts that have picked up the policy. While there are various workarounds for this situation it's not one you really want to be in.

However a preview feature in the MEM Endpoint Security section now allows you to enable/disable WH4B based on user groups, effectively providing a scoping control.

On the MEM console navigate to -  Endpoint Security - Account Protection and create a new policy.

The options are limited but you do have the ability to block Windows Hello for Business. If you set this against a a user security group WH4B is removed, exactly as you would expect.

Lastly you should note that the WH4W settings in the Windows Enrolment pane are the only ones that apply during OOBE and apply to the entire tenant and, as we have noted, this can’t be scoped. So if you want to remove the WH4B prompt during OOBE you would have to block it for everyone using the tenant wide setting but then turn it back on in the Endpoint Security - Account Protection section making sure you only assign to the appropriate user group.