Assigning Windows 10/11 Enterprise Subscription Activation Licences to Hybrid Azure AD Joined Devices

By -

Introduction

Starting with Windows 10, version 1703, Windows 10 Pro supports the Subscription Activation feature, enabling users to “step-up” from Windows 10 Pro to Windows 10 Enterprise automatically if they are subscribed to Windows 10 Enterprise E3 or E5.

The Subscription Activation feature eliminates the need to manually deploy Windows 10 Enterprise or Education images on each target device, then later standing up on-prem key management services such as KMS or MAK based activation, entering GVLKs, and subsequently rebooting client devices.

It’s important to note that the Windows 10 Enterprise subscription activation is designed to “step-up” a device from Windows 10 Pro to Windows 10 Enterprise. Therefore, your device is required to have a Windows 10 Pro license activated as a baseline.

For Windows 10 Enterprise Subscription Activation to function, there a several prerequisites which need to be in place. This blog is aimed for organisations which have Active Directory on premises and synchronise their AD objects to Azure AD via AD Connect.

Overall Prerequisites

The below provide a summary breakdown of the prerequisites required in the setup on AAD Connect:

  • AAD Connect | Setup Check/Update
  • AAD Connect | Hybrid Azure AD Join
  • AAD Connect | Review/Amend OU Sync Scope
  • Client Device | Internet Access to Azure AD via SYSTEM Account
  • Client Device | Internet Access to Azure AD via User Account
  • Client Device | SSO IE Local Intranet Settings
  • Client Device | Windows 10 Pro Licensed and Activated
  • Azure AD | Valid Subscription Present
  • Azure AD | Applicable Users Licensed with Windows 10 Enterprise

AAD Connect | Setup Check/Update

To facilitate Windows 10 Enterprise Subscription Activation, AAD Connect needs to be configured with the following:
  • Version of 1.1.819.0 or above (you need to be v2 now anyway)
  • Hybrid Azure Active Directory Join enabled and configured
  • Sync scope to include the OU’s which contain the applicable computer objects

AAD Connect | Hybrid Azure AD Join

A Hybrid Azure AD Joined device is one that’s joined to Active Directory on premises and joined to Azure Active Directory.

Configuring Hybrid Azure AD Join via AAD Connect essentially creates a Service Connection Point in Active Directory on premises with details on your Azure AD/Office 365 tenant.  

That SCP will be used by a client device as part of the Hybrid Azure AD Join process.

Within the AAD Connect wizard navigate to Configure Device Options:





Below is an example of the where the SCP shows in Active Directory:


Within the properties of the SCP you can see reference to tenant name

AAD Connect | Review/Amend OU Sync Scope

For a device to become Hybrid Azure AD Joined, the sync scope of AAD Connect needs to include the organisational units which contain the user accounts which will have a Windows 10 Enterprise licenses assigned and computer objects which require a Windows 10 Enterprise Subscription to be assigned.
If required, amend the scope using the AAD Connect wizard as shown below: 


Client Device

To allow user to carry out Windows 10 Enterprise Subscription Activation on a Windows device, the following needs to be configured on the client side:
  • Internet Access to Azure AD via SYSTEM account
  • Internet Access to Azure AD via User Account
  • SSO IE Local Intranet Settings
  • Device licensed and activated with Windows 10 Pro

Client Device | Internet Access to Azure AD via SYSTEM Account

Before a user can successfully obtain a Windows 10 Enterprise Subscription Activation, the device in question must be Hybrid Azure AD Joined.

For a device to become Hybrid Azure AD Joined, the built-in SYSTEM account requires internet access to Azure AD for the following addresses:
  • https://enterpriseregistration.windows.net 
  • https://login.microsoftonline.com 
  • https://device.login.microsoftonline.com 
  • https://autologon.microsoftazuread-sso.com
  • Your ADFS server address if you have one e.g. https://sts.company.com 
There is a scheduled task in Windows 10 under \Microsoft\Windows\Workplace Join called Automatic-Device-Join.  The task is scheduled to run as the SYSTEM user and run with the highest privileges.  The task is triggered to run every time somebody logs onto the workstation and every hour for the duration of 1 day.

The main point of the scheduled task is to obtain a unique certificate which is then written to the UserCertificate attribute.  Without the UserCertificate attribute populated, the computer object will not synchronise from AD on premises to Azure AD.
If your device has direct access to the internet this should function without an issue. If a proxy server is used to filter web traffic, this can cause issues where the SYSTEM account is unable to access Azure AD over the internet.

Where a proxy server is in place and you don’t have direct internet access via your default gateway, you typically have the following options:
1. Make network/proxy changes to allow traffic to Azure AD via the default gateway
2. Make exceptions and push out proxy settings for computer objects via SYSTEM account for example via WPAD (Web Proxy Auto-Discovery) - https://docs.microsoft.com/previous-versions/tn-archive/cc995261(v%3dtechnet.10) 

Automatic Device Join Scheduled Task

Details on the scheduled task which obtains and writes the UserCertificate back to AD on premises are below:





userCertificate Attribute

In the example below you can see the userCertificate attribute is populated after the Automatic-Device-Join task has run:

Before:

After:

AAD Connect Device Sync Rule Filter

The below show the AAD Connect Sync rule which qualifies whether a computer object has the userCertificate attribute populated to qualify it for sync to Azure AD: 




Test Azure AD Connection for SYSTEM account

To test the connectivity to the internet under the context of the SYSTEM account, you can download and run the Test Device Registration Connectivity Script from Microsoft.  This creates a temporary scheduled task which runs as the SYSTEM account to test for successful connection to Azure AD.
https://gallery.technet.microsoft.com/scriptcenter/Test-Device-Registration-3dc944c0

Example where it fails:

Example where it's successful:

Manually setting proxy for SYSTEM account

Below is an example of how to set the proxy server to be used under the context of the SYSTEM account.  This is helpful for testing and troubleshooting:


Azure AD Hybrid Azure AD Join status

Below is an example of a device showing as Hybrid Azure AD Joined in Azure AD:

Client Device | Internet Access to Azure AD via User Account

For a user to successfully obtain a Windows 10 Enterprise Subscription Activation from a Hybrid Azure AD Joined machine, the user must have internet access.  This can be via a proxy server or direct internet access via the default gateway of the machine.

Client Device | SSO IE Local Intranet Settings

In order to provide Seamless SSO for the license subscription to works silently, the following URL’s should be added into the users Local Intranet zone in Internet Explorer:

  • https://device.login.microsoftonline.com 
  • https://autologon.microsoftazuread-sso.com 

You must also enable Allow updates to status bar via script in the user’s Local Intranet Zone.

Push Out Settings via Group Policy

You can push out the Local Intranet Settings to users via a Group Policy.  Below is an example of the settings which need to be configured under the user context:


Client Device | Windows 10 Pro Licensed and Activated

For the step-up in license from Windows 10 Pro to Enterprise to occur, you’re required to have your device licensed and activated with Windows 10 Pro as a foundation.

Note, Windows 10, version 1803 enables pulling activation keys directly from firmware where the device support firmware-embedded keys.  It is no longer necessary to run a script to perform the activation step on Windows 10 Pro prior to activating Enterprise.

Windows Edition Check

Below is an example of how the Windows 10 Pro license should display prior to step-up in license.  Disregard the partial product key as this may be different prior to the step-up in licensing:





Azure AD

To allow a user to carry out the step-up in licensing from Windows 10 Pro to Windows 10 Enterprise the following needs to be in place in Azure AD:
  • An applicable license plan in the Azure AD/Office 365 tenant
  • A license assigned to the applicable users for the step-up in licensing

Azure AD | Valid Subscription Present

A valid subscription will need to be procured and showing as present in the Azure AD/Office 365.  This typically shows under a Microsoft 365 E3 or Microsoft 365 E5 but can also show as a different license plan.

Azure AD | Applicable Users Licensed with Windows 10 Enterprise

The user account that will used to carry out the license step-up activation need to have a Windows 10 Enterprise license.

An example from the Azure AD portal is below:

Enable Licence Subscription

The enabling licence subscription tasks can be found under scheduled tasks:







Windows 10 Subscription Activation

With the previously outlined prerequisites in place, after a user has logged into the Windows 10 Pro workstation, you should find the license has been updated to Windows 10 Enterprise.
  • Note, in some places the license will still appears as Windows 10 Pro.
  • Note, that the partial product key should show with the value 3V66T.
  • Note, a user can license up to 5 devices with their user account. The activation is like a queue, the 1st activated device will drop off the list when a 6th one is activated etc.
  • At the present time, there’s no documented way to verify which and how many devices have been licensed by user account in Azure AD.
  • Upon revoking the license from the user in Azure AD/Office 365, the license will downgrade back to Windows 10 Pro.






Comments

  1. Raimundas24 October 2022 at 07:52

    Hi, great article, followed all steps. We have in the company, that we lose activation. are you familiar with such cases? who can trigger. we have CA, we excluded a lot of services that it would not cause but we are still downgrading license from Ent to Pro.

    ReplyDelete
    Replies
    1. Ben Owens27 October 2022 at 09:18

      Whenever I have seen this, it's usually due to the user no longer having a Windows 10/11 Ent license assigned.

      Delete
    2. Raimundas27 October 2022 at 19:18

      license exist, i am sure, we are losing randomly, and it is massive way now.

      Delete
    3. Ben Owens28 October 2022 at 10:25

      Very hard to say what the issue is without more detail. What have checked? I would recommned looking at items from Rudy in his site too - https://call4cloud.nl/2022/02/escape-from-windows-10-pro/

      Delete
  2. Gaz17 January 2023 at 10:58

    Great article. We are looking at doing just this. Upgrading our Win10 pros to 11 enterprise. I assume this is still relevant and current in Jan23?

    I presume if we aren't using the device options in ADC and we already have some devices showing in AAD then ADC will upgrade/replace these computer objects? The existing objects in AAD are devices that have registered Outlook app, Teams clients and Office i believe.

    My concern is that of duplicate computer IDs or replacement IDs which in turn could affect existing users/computers?

    Thanks

    ReplyDelete
    Replies
    1. Ben Owens18 January 2023 at 09:14

      Yes, this still should be relevant. As a note, a colleague of mine (https://www.linkedin.com/in/russellwbmckee/) came across an issue where HAADJ some devices conflicted with an already registered Azure AD Registered device; but they were in the minority. However, as I understand, this should typically be taken care of, where the Azure AD Registered device and HAADJ become merged.

      In cases where that merge doesn't happen, there may be a need for you to to disconnect/leave the tenant via Work/School account on the Windows devices in order to get the HAADJ process to work.

      Please feedback and let us know how you got on and what you discover in your setup.

      Delete
    2. Gaz20 January 2023 at 16:17

      Interestingly we see the our .local domain under the SCP value and not sure how to proceed.

      Delete
    3. Gaz24 January 2023 at 16:13

      Got there in the end. All synching and showing in Intune. Thanks again

      Delete
    4. Ben Owens25 January 2023 at 11:51

      Superb, glad you got there. Did you hit any snags or issues that weren't in the above?

      Delete
    5. Gaz25 January 2023 at 12:10

      No, it worked fine

      Delete

Post a Comment

Popular posts from this blog

Exchange Hybrid Mailbox Move - Corruption Due To Missing Security Principals (ACL issues) - TooManyBadItemsPermanentException

By -
Image
UPDATE 14 Jan 2020 --------------------- Microsoft have introduced DCS ( Data Consistency Scoring ) which is planned to supersede the Bad Item Limit count you declare on a migration. There are four grades of DCS; Perfect , Good , Investigate and Poor .  You can complete the migration for all grades, except Poor . Importantly, this now means they can now properly differentiate between a corruption in mailbox data and missing permissions or security principal which couldn't be set on the target mailbox. Previously you had to raise the Bad Item Limit to compensate for security principals and genuine corruption combined; this should no longer be the case. For now, DCS will be used by default where you don't set a Bad Item Count. If you do specify a Bad Item Count, DCS will not be used See the below links for more details: https://techcommunity.microsoft.com/t5/exchange-team-blog/improving-migrations-using-data-consistency-scoring/ba-p/1105920 https://docs.microsoft.c
Read more

Autopilot Hybrid Azure AD Join with Customised First Login Status

By -
Image
Introduction This is my flavour of deploying a customised HAADJ progress status, building on work by Joymalya Basu Roy's detailed article - https://joymalya.com/autopilot-hybrid-azure-ad-join-reworked-with-joy/ . The differences in my version are: Not using Active Setup to run the HAADJ retry process or Splash Screen as I found this didn't work as expected and I didn't want to add a registry item to affect all future logins with a reboot from the HAADJ process. Running the processes under the context of the SYSTEM account, but displaying status to the interactive user. Avoid the HAADJ process running again after the initial success. This provides a customised first login status which prevents the user from using the devices until Hybrid Azure AD Join from the Autopilot process. It's use is primarily for when the User ESP is configured to be skipped. Files This is my version of customised HAADJ which is built on work and guidance in blogs/articles from Michael Niehaus, S
Read more