Why a Windows Server 2019 VDI should be Hybrid Azure AD joined

What is Hybrid Azure AD Join ?

Let’s just start with the official definition from the Microsoft documentation:

Hybrid Azure AD Join: Joined to on-premises AD and Azure AD requiring organizational account to sign in to the device.

This means that after the device is Hybrid Azure AD joined, it behaves the same as any other computer connected to Active Directory.

Sign in with an Active Directory account is required.
User credentials are verified against an Active Directory domain controller.
Group Policy objects for users & computers read from the domain controller are applied automatically.

Hybrid Azure AD Join

After the Active Directory connection process is complete, additional steps are performed asynchronously in the background to register the device in Azure AD as well.

Why Hybrid Azure AD Join ?

You get the best of both worlds, cloud and on-prem. Once the device is registered with Azure AD, then future user logins get an additional benefit. Not only does there get a Kerberos ticket from Active Directory, but also an Azure AD user token that can be used to access Azure AD protected resources like Teams, Microsoft365 Apps or OneDrive. Additionally, devices can also be managed in both worlds. In this way, one is able to use tools such as single sign-on and conditional access while applying GPOs and other on-premises utilities.

Furthermore, a Hybrid Azure AD Join helps with various errors with Microsoft Teams, OneDrive for Business, Microsoft365 Apps or Edge (Chromium Based). The following error cases do not occur with all of my customers, nor is it apparent when they may occur. These are our beloved RANDOM errors where a Hybrid Azure AD Join of Windows Server 2019 workers helped with.

Wichtig bei allen SSO Themen mit Teams und OneDrive for Business ist, dass Azure AD auch korrekt für SSO konfiguriert ist (Aktivierung PHS oder PTA).

Important for all SSO issues with Teams and OneDrive for Business is that Azure AD is also correctly configured for SSO (activation PHS or PTA).

Error cases Microsoft365 Apps

For Microsoft365 Apps (formerly Office365) Published Application the Office licensing fails (Citrix number LCM-7637).

Sign in to set up Office

Microsoft365 apps with UPM 1912 do not create the Shared Activation Token.

No Shared Activation Token

With UPM disabled or a version other than 1912, this works on the same system.

Microsoft365 Apps shows the error code CAA50021 and the server message Number of retry attempts exceeds expectation.

Error code: CAA50021 Server message: Number of retry attempts exceeds expectation

These errors could all be solved with Hybrid Azure AD Join.

Error cases Microsoft Teams

In Microsoft Teams, error code 80070003 occurs on the second launch of Microsoft Teams if the follow-up (second, third, etc.) launch is performed on a different worker than the first.

Error Code 80070003 Microsoft Teams

Microsoft Teams shows the error code c00ce584 for different users. However, the error does not occur with all users on one system.

Error Code c00ce584 Microsoft Teams

These errors could all be solved with Hybrid Azure AD Join.

Microsoft Edge & OneDrive for Business error cases

In Microsoft Edge & OneDrive for Business, SSO does not work cleanly on the workers. Prompt for username and password on the worker after login.

OneDrive for Business No SSO

Additional terms

Service connection points

Before you can use Hybrid Azure AD Join devices, the on-premises Active Directory must be synchronized with your own Azure AD through Azure AD Connect. Azure AD Connect uses a wizard to set up Hybrid Azure AD Join, including configuring the service connection point (SCP) in on-premises Active Directory, which is required for device enrollment in Azure AD.

Each AD forest requires its own SCP. Because Azure AD registration for hybrid Azure AD-connected devices is automatic, an SCP is required to find information about the Azure AD tenant during the registration process.

Service connection points

The SCP is registered in AD (under CN=Services) as a container under CN=Device Registration Configuration. In the properties of the container, there is an attribute called keywords that contains two strings that Windows uses to find the Azure AD tenant.

Primary Refresh Token (PRT)

The Primary Refresh Token (PRT) is a key artifact of Azure AD authentication. It is a JSON Web Token (JWT) issued specifically to enable Single Sign-On (SSO) for the applications used on these devices.

A PRT contains claims that are generally included in every Azure AD refresh token. In addition, there are some device-specific claims that are included in the PRT. These are as follows:

  • Device-ID: A PRT is issued to a user on a specific device. The deviceID claim determines the device on which the PRT was issued to the user. This claim is later issued to tokens obtained through the PRT. The device-ID claim is used to determine Conditional Access permissions based on device state or compliance.
    Session Key: The session key is an encrypted symmetric key generated by the Azure AD authentication service and issued as part of the PRT. The session key is used as a credential when a PRT is used to obtain tokens for other applications.

Once issued, a PRT is valid for 14 days and is continuously renewed as long as the user is actively using the device.

Computer Accounts and Certificates

When Windows devices see the SCP in on-prem AD, they start trying to register with Azure AD. But the registration cannot be completed until a few more conditions are met.

First, the device’s computer account must be synchronized from on-prem AD to Azure AD. By default, Azure AD Connect synchronizes the objects every 30 minutes.

Azure AD Devices

Second, Azure AD Connect does not synchronize the computer object until its userCertificate attribute is populated with a self-signed certificate generated by the device itself.

userCertificate

But independent of whether the computer object has synchronized with Azure AD, the device attempts to register with Azure AD, which results in an error.

Certificates Device

When the device has successfully registered with Azure AD, event 306 ‘Automatic registration Succeeded’ can be seen in the User Device Registration log. After registration, users also receive a Primary Refresh Token (PRT) from Azure AD that can be used for authentication to services that use Azure AD.

Automatic registration Succeeded Event ID 306 User Device Registration

If the user logs in before Azure AD enrollment is complete, they must either log out and log back in or lock and then unlock the device to authenticate to Azure AD.

Setup Hybrid Azure AD Join

Let’s start by looking at how we can set up the Hybrid Azure AD join.

Requirements

The following technical requirements must be met:

  • Operating system Windows Server 2016, 2019 or Windows 10 (version 1809) Pro or higher
  • The role of the domain controller must be configured
  • Synchronization to Azure AD (with the Azure AD Connect) must be configured
  • Local Active Directory UPN suffix with a matching custom domain in Azure AD
  • The device must be a member of the local domain
  • Internet connectivity on the Windows device and firewall approvals for the following destination addresses:
    • enterpriseregistration.windows.net:443
    • login.microsoftonline.com:443
    • device.login.microsoftonline.com:443
  • Access to the local administrator account and the global Azure AD administrator

Unsupported scenarios

  • Hybrid Azure AD Join is currently not supported when synchronizing a single AD forest with more than one Azure AD tenant
  • Hybrid Azure AD Join is not supported for Windows Server with the Domain Controller (DC) role installed
  • Server Core OS does not support any type of device registration

Configure Azure AD Connect

First of all, open Azure AD Connect.

Azure AD Connect
Azure AD Connect Splash Screen

Click Configure on the Welcome screen.

Welcome to Azure AD Connect Configure

After that, a whole list of Additional tasks is displayed, where Configure device options should be selected. Confirm this by clicking Next.

Additional tasks Configure device options

After that, click Next on the Overview page.

Overview Hybrid Azure AD join Device writeback

In the following window, the credentials of an Azure AD Global Administrator must be stored.

Connect to Azure AD

After filling in the form, click Next to establish the connection.

Connecting to Microsoft Online to verify credentials

Now select Hybrid Azure AD join and click Next to confirm.

Device Options Configure Hybrid Azure AD join

After that, you can choose which Windows versions should be supported. You can select both options to also support older operating systems or, as in our case, only the Windows 10 or later domain-joined devices option. This option will also enable Windows Server 2016 and 2019. Older operating systems, in this context, are for example Windows Server 2012 or Windows 8.1. Clicking Next confirms the selection.

Device operating systems Windows 10 or later domain-joined devices supported windows downlevel domain-joined devices

In the SCP configuration window select the forests that should be configured.

SCP configuration Forest

Select the desired forest and click on Add to add the required local Enterprise Admin.

SCP configuration Enterprise Admin Authentication Service Azure Active Directory

A login mask follows in which the on-prem administrator should be added. Confirm the credentials with OK.

Windows Security Enterprise Administrator On-Prem

Confirm the configuration by clicking Next.

SCP configuration service connection point

Now it will be checked if SCP is already configured.

Ready to configure

In the following window, you can start the configuration of the SCP in the local Active Directory. To do this, click on Configure.

Ready to configure Configure the SCP for device registration

The Azure AD Connect synchronization service will also be customized in the process.

Configuring Azure AD Connect synchronization service

Finally, the successful configuration can be confirmed. The wizard can be closed via Exit.

Configuration complete

Checking the configuration

Now you can check that the configuration of the Hybrid Azure AD join was successful. Because the above-mentioned operating systems automatically connect hybrid, you should also see them in the Azure Portal after a maximum of 30 minutes.

Active Directory Controller

The first thing to do is to check the SCP that has been set up. To do this, start ADSI Edit on an Active Directory controller.

ADSI Edit

In ADSI Edit right-click on the top entry (ADSI Edit) and in the following menu click Connect to….

ADSI Edit Connect to...

In the following window, under Select a well-known Naming Context select Configuration.

Select a well known Naming Context Configuration

Then click OK.

Configuration LDAP://DC.domain.local/configuration

In the now connected ADSI Edit click Configuration > CN=Configuration,DC=… > CN=Services > CN=Device Registration Configuration. Then right-click on the last container and on Properties. In the properties of the container, there is an attribute called keywords that contains two strings that Windows uses to find the Azure AD tenant.

Configuration CN=Configuration,DC=  CN=Services CN=Device Registration Configuration

If the SCP is in place, the Windows machines should be able to log on to Azure AD automatically.

PowerShell

The PowerShell cmdlet Get-MsolDevice can be used to check the status of the systems regarding Hybrid Azure AD Join in the Azure tenant. This requires the deviceId of the system.

Either find the system in the local Active Directory, right-click on the computer > Properties > Attribute Editor. Scroll down to objectGUID and use this number as deviceId.

Properties Attribute Editor objectGUID deviceId

Or take the deviceId from the error code in the event log (given id) of the system or the deviceID that was displayed with the dsregcmd /status command.

device ID
device ID

Now open PowerShell and run the code below.

Get-msoldevice -deviceId

Windows Worker

This can also be checked on the machine itself. For this purpose, the event log can be checked (Applications and Service Logs > Microsoft > Windows > User Device Registration > Admin) or via Command Prompt / PowerShell and the command dsregcmd /status.

Event Log

The required event logs can be found under Applications and Service Logs > Microsoft > Windows > User Device Registration > Admin.

Event Viewer Applications and Service Logs > Microsoft > Windows > User Device Registration > Admin

Event Viewer Applications and Service Logs > Microsoft > Windows > User Device Registration > Admin

An event with the ID 306 should be found here. Then the machine has successfully logged into Azure AD.

Event 306 User Device Registration Automatic registration Succeeded
Command Prompt / PowerShell

For this we start the CMD or a PowerShell console.

Command Prompt PowerShell

Now enter the following command.

dsregcmd /status Device State Device Details
Device State

Under Device State the entries indicate:

AzureAdJoined (YES) – The system is connected to Azure AD.

EnterpriseJoined (YES) – System is connected to ADFS.

DomainJoined (YES) – The system is a member of an Active Directory.

DomainName – Displays the domain name if it is associated with one.

Important!
A system cannot be AzureAdJoined and EnterpriseJoined at the same time.

AzureAdJoinedEnterpriseJoinedDomainJoinedDevice State
YESNONOAzure AD Joined
NONOYESDomain Joined
YESNOYESHybrid Azure AD Joined
NOYESYESOn-Prem ADFS Joined
Device Details

The entries under Device Details are displayed only if the system is Azure AD Joined or Hybrid Azure AD Joined. Device-identifying details stored in the cloud are listed:

DeviceId – Unique ID of the device in the Azure AD tenant.

Thumbprint – Thumbprint of the device certificate.

DeviceCertificateValidity – Validity period of the device certificate.

KeyContainerId – Container ID of the private device key associated with the device certificate.

KeyProvider – Key Provider (hardware/software) used to store the private key of the device.

TpmProtected (YES) – The private key of the device is stored in a hardware TPM.

dsregcmd /status Tenant Details User State SSO State
Tenant Details

The items under Tenant Details are displayed only if the system is Azure AD Joined or Hybrid Azure AD Joined. It lists the general tenant information.

If the MDM URL is empty, it means that either the MDM has not been configured or the current user is not in the MDM scope.

User State

Various attributes for the user currently logged on to the device are listed under User State:

NgcSet (YES) – This means that a Windows Hello key is set for the currently logged-in user.

NgcKeyId – ID of the Windows Hello key, if one is set for the currently logged-in user.

CanReset – Specifies whether the Windows Hello key can be reset by the user (DestructiveOnly, NonDestructiveOnly, DestructiveAndNonDestructive, or Unknown if an error occurred).

WorkplaceJoined (YES) – Implies that Azure AD registered accounts have been added to the device in the current NTUSER context.

WamDefaultSet (YES) – When a WAM Standard WebAccount is created for the logged-in user. An error may be displayed when running dsregcmd /status from an Administrative CMD / PowerShell.

WamDefaultAuthority – For Azure AD, organizations is displayed.

WamDefaultId – Always set to https://login.microsoft.com for Azure AD.

WamDefaultGUID– The GUID of the WAM provider (Azure AD / Microsoft account) for the default WAM WebAccount.

SSO State

SSO State can be ignored for Azure AD registered devices. Only the results for the user executing the command are displayed:

AzureAdPrt (YES) – If there is a PRT on the device for the logged-in user.

AzureAdPrtUpdateTime – Set to the time in UTC when the PRT was last updated.

AzureAdPrtExpiryTime – Set to the time in UTC when the PRT will expire if not renewed.

AzureAdPrtAuthority – Azure AD authority URL.

EnterprisePrt (YES) – When the device has a PRT from a local ADFS infrastructure.

EnterprisePrtUpdateTime – Set to the time in UTC when the Enterprise PRT was last updated.

EnterprisePrtExpiryTime – Set to the time in UTC when the PRT will expire if not renewed.

EnterprisePrtAuthority: – ADFS authority URL.

dsregcmd /status Diagnostic Data Pre-Join Diagnostics
Diagnostic Data

There are different Diagnostic Data Containers, depending on the context in which the system is located.

Pre-Join Diagnostics

It is only shown if the device is Domain Joined and is not able to be Hybrid Azure AD Joined. Various tests are performed to help diagnose connection errors. This information includes the Error Phase, Error Codes, Request ID, Https Status and Server Message.

User Context – The context in which the diagnostics is executed (SYSTEM, UN-ELEVATED User or ELEVATED User).

Important!
As the actual join is performed in the SYSTEM context, running diagnostics in the SYSTEM context is closest to the original join scenario. To run diagnostics in the SYSTEM context, the dsregcmd /status command must be run from an administrative CMD / PowerShell.

Client Time – The system time in UTC.

AD Connectivity Test – Performs a connectivity test to the domain controller. Errors in this test are likely to lead to connection errors in the pre-check phase.

AD Configuration Test – This test reads and checks if the SCP object is configured correctly in the local AD forest. Errors in this test would likely result in join errors in the Discover phase with error code 0x801c001d.

DRS Discovery Test –It calls the DRS endpoints from the Discovery Metadata endpoint and executes a User Realm Request. Errors in this test would likely lead to join errors in the Discover phase.

DRS Connectivity Test – Performs a basic connectivity test to the DRS endpoint.

Token acquisition Test – This test tries to get an Azure AD authentication token when the user tenant is Federated. Failures in this test will result in Join failures in the Auth phase. If authentication fails, sync-join is attempted as fallback unless fallback is explicitly disabled with the following registry key settings.

Fallback zu Sync-Join – Is Enabled if the above registry key is not present to prevent fallback to sync-join on auth failures.

Previous Registration – Time of the last join attempt. Only failed join attempts are logged.

Error Phase – The join phase in which the termination occurred (pre-check, discover, auth or join).

Client ErrorCode –  The returned client error code (HRESULT).

Server ErrorCode – When a request has been sent to the server and it responds with an error code.

Server Message – Message from the server returned together with the server error code.

Https Status – The HTTP status returned by the server.

Request ID – The request ID sent to the server. Useful for comparison with server-side logs.

dsregcmd /status Diagnostic Data  Post-Join Diagnostics

Post-Join Diagnostics

Displays the output of security checks performed for a device connected to the cloud.

AadRecoveryEnabled (YES) – The keys stored in the device cannot be used and the device is marked for recovery. At the next login, the recovery flow is triggered and the device is re-registered.

KeySignTest (PASSED) – The device keys are in good condition. If KeySignTest fails, the device is normally marked for recovery. On the next login, the recovery flow is triggered and the device is re-registered. For Hybrid Azure AD Joined devices, recovery is without requesting access credentials. While for Azure AD Joined or Azure AD Registered devices, user authentication appears so that the device can be recovered and re-registered if required.

Important!
The KeySignTest requires an administrative Command Prompt / PowerShell.

dsregcmd /status NGC prerequisite check
NGC prerequisite check

The Windows Hello for Business (WHFB) pre-deployment checks are displayed.

Important!
It is possible that the details of the NGC prerequisite check are not displayed in dsregcmd /status if the user has already successfully configured WHFB.

IsDeviceJoined (YES) – The system is connected to Azure AD.

IsUserAzureAD (YES) – The logged-in user exists in Azure AD.

PolicyEnabled (YES) – The WHFB policy is enabled on the device.

PostLogonEnabled (YES) – WHFB enrollment is natively triggered by the platform. When set to NO, it indicates that the Windows Hello for Business login is triggered by a custom mechanism.

DeviceEligible (YES) – The device meets the hardware requirements for registration with the WHFB.

SessionIsNotRemote (YES) – The current user is logged in directly to the device and not remotely.

CertEnrollment – Especially for the use of WHFB Certificate Trust, which specifies the registration authority for certificates for WHFB. Set to enrollment authority if the source of WHFB policy is group policy, to mobile device management if the source is MDM. Set to none if neither is used.

AdfsRefreshToken – Especially for the use of WHFB Certificate Trust. Only present if CertEnrollment is set to enrollment authority. Indicates whether the device has an Enterprise PRT for the user.

AdfsRaIsReady – Especially for the use of WHFB Certificate Trust. Only present if CertEnrollment is set to enrollment authority. Is set to YES if ADFS has indicated in the discovery metadata that it supports WHFB and if a Logon Certificate Template is available.

LogonCertTemplateReady – Specifically for the use of WHFB Certificate Trust. Only present if CertEnrollment is enrollment authority. Set to YES if Logon Certificate Template status is valid and helps to debug ADFS RA.

PreReqResult – Returns the result of all WHFB Prerequisite Evaluation. Set to Will Provision if the WHFB registration should be started as a post-login task at the user’s next login.

Azure Portal

We can also check the status of the systems in the Azure Portal.

To do this, open the link https://portal.azure.com in your browser and enter the required access data.

Azure Portal Logon Mask

Click Azure Active Directory.

Azure Active Directory

In the following window click Devices.

Azure Active Directory Devices

Here you can see all systems stored in Azure AD. Both Azure AD Joined, Azure AD Registered and Hybrid Azure AD Joined.

Azure AD Joined Azure AD Registered Hybrid Azure AD Joined

Systems in pending state have been synchronized to Azure AD via Azure AD Connect, but the system itself has not reported to Azure AD.

Flow of a Hybrid Azure AD Join

PhaseExplanation
AThe user logs on to a Domain Joined Windows system with domain credentials. This can be a user name and password or smart card authentication. The user login triggers the Automatic Device Join task.
Note: The Automatic Device Join task is triggered at domain join and repeated every hour. It is not dependent on user login alone.
BThe task queries Active Directory using the LDAP protocol for the keywords attribute of the SCP stored in the Configuration partition of Active Directory (CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,…). The value returned in the keywords attribute determines whether the device registration is routed to the Azure Device Registration Service (ADRS) or to the on-premises hosted device registration service.
Note (Not in picture): If for better control, the SCP has been cleared, the task fetches the required information from the registry (see below) as a fallback, if it is available there.
CFor the managed environment, the task creates an initial authentication credential in the form of a self-signed certificate. The task writes the certificate to the userCertificate attribute on the computer object in Active Directory using LDAP.
DThe computer cannot authenticate to Azure DRS until a device object that represents the computer and contains the certificate in the userCertificate attribute is created in Azure Active Directory. Azure AD Connect detects the attribute change. On the next synchronization cycle, Azure AD Connect sends the userCertificate, object GUID, and computer SID to Azure DRS. Azure DRS uses the attribute information to create a device object in Azure Active Directory.
EThe Automatic Device Join task is triggered every time a user logs on or every hour and attempts to authenticate the computer to Azure Active Directory using the corresponding private key of the public key in the userCertificate attribute. Azure Active Directory authenticates the computer and issues an ID token to the computer.
FThe task preferentially generates a TPM-bound RSA-2048-bit key pair known as the device key (dkpub/dkpriv). The application creates a certificate request with dkpub and the public key and signs the certificate request with dkpriv. Next, the application derives a second key pair from the TPM’s memory root key. This is the transport key (tkpub/tkpriv).
GThe task sends a device registration to Azure DRS that contains the ID token, certificate request, tkpub, and attestation data. Azure DRS validates the ID token, creates a Device ID, and creates a certificate based on the included certificate request. Azure DRS then updates the device object in Azure Active Directory and sends the device ID and device certificate to the client.
HDevice registration is completed by obtaining the Device ID and Device Certificate from Azure DRS. The Device ID is saved for future reference (viewable via dsregcmd.exe /status), and the device certificate is installed in the computer’s personal storage. When the device registration is complete, the task exits.

Regulation of the Hybrid Azure AD Join

The SCP configured via Azure AD Connect is evaluated by all Windows devices and causes, for example, that all Windows 10 devices automatically perform a Hybrid Azure AD Join. The Windows Server (2016 / 2019) operating systems attempt this only after successful synchronization of the computer objects, via Azure AD Connect, into Azure AD.

The Hybrid Azure AD Join is triggered on the local devices by a Scheduled Task, which is triggered when Windows starts and a user logs on to the system. 

Scheduled Tasks\Microsoft\Windows\Workplace Join\Automatic-Device-Join  

Scheduled Tasks\Microsoft\Windows\Workplace Join\Automatic-Device-Join  

When the task is executed, the required information is searched using either the SCP in the Configuration Partition of the local AD or the local registry of the client (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD). With the information found (TenantID / TenantName), the system now checks whether the information is valid. 

Scheduled Tasks\Microsoft\Windows\Workplace Join\Automatic-Device-Join  

Automatic Hybrid Azure AD Join 

Here, each computer account that has created the self-signed certificate and stored it in AD attribute userCertificate is automatically synchronized to Azure AD. This happens automatically when the trigger of the task is fired (logon or restart) by retrieving the required information from the SCP.

Hybrid Azure AD Join with SCP

Controlled Hybrid Azure AD Join

If you want to control this process, you can empty the SCP and distribute the required settings to the Windows devices by other ways.

Hybrid Azure AD Join without SCP

The cleared SCP contained information about the target tenant to which the client should connect. This information can be specifically stored on the target system, for example via GPO or WEM, by setting the following registry keys (the CDJ and AAD keys must be recreated):

TenantName TenantID CDJ AAD
TenantId TenantName

Furthermore, the following GPO setting can be used to disable the automatic Workplace Join on Windows 10 devices even without deleting the SCP.

Register domain joined computers as devices

This setting can be found under Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration.

Particularities of Non-Persistent Machines

Notice that with Hybrid Azure AD Join another Unique ID is created for the systems, similar to the SID in the local Active Directory. The DeviceID is also visible with dsregcmd /status and must be unique for all systems.

Device ID

When we deploy non-persistent workers via a golden image, the golden master must either be excluded from Hybrid Azure AD Join or before the image is sealed and deployed, the join must be closed via dsregcmd /debug /leave.

dsregcmd /debug /leave

If this is not done, the Golden Master’s Unique ID will be spread across all workers that are created from it. As a result, the non-persistent workers have significant problems communicating with the Microsoft Cloud (SSO problems, etc.).

If you don’t want to keep this in mind, you can also use the latest version of BIS-F for this task. In the latest version, you can configure this step and the script automatically detects that the Golden Master is Hybrid Azure AD Joined and then performs a Leave.

BIS-F Checking DSRegcmd State
dsregcmd /status bis-f

After the start of the Non-Persistent Worker, BIS-F triggers a Join again.

BIS-F Personalization

Troubleshooting

Event Logs

When troubleshooting a Hybrid Azure AD join, the event logs (Microsoft > Windows > User Device Registration > Admin) provide a lot of information.

Microsoft Windows User Device Registration Admin

Event ID 306

The content of event ID 306 says Automatic registration Succeeded. This is the completion message for a successful Hybrid Azure AD Join.

Event ID 306 Automatic registration Succeeded

Event ID 105

Event ID 105 says The complete join response was successful. This means that the join was finalized.

The complete join response was successful Event ID 105

Event ID 111

Content of Event ID 111 is The registration status has been successfully flushed to disk, which means that the registration has been successfully saved to the system.

Event ID 111 The registration status has been successfully flushed to disk

Event ID 106

Event ID 106 shows The post join tasks for the AAD Authentication Package completed successfully. The system still performs some tasks after the join (sending device information, etc.), these are now completed.

Event Id 106 The post join tasks for the AAD Authentication Package completed successfully

Event ID 104

Event ID 104 has the content The get join response operation callback was successful. The join response was successful and the response was the required certificate.

Event ID 104 The get join response operation callback was successful

Event ID 103

The content of Event ID 103 says The join request was successfully sent to server. This means that the system has sent its join request to Azure AD.

Event ID 103 The join request was successfully sent to server

Event ID 102

Content of Event ID 102 says The initialization of the join request was successful. Here you can find the tenant name. If this information is not correct or empty, something is wrong with the SCP or the added registry keys.

Event ID 102 The initialization of the join request was successful

Event ID 101

Event ID 101 has the content The discovery operation callback was successful. This means that the system has successfully contacted Azure AD and there are no network problems.

Event ID 101 The discovery operation callback was successful

Event ID 100

Event ID 100 has the content The discovery request send operation was successful. In this step, the computer sends a request to Azure AD. If errors appear in the Event Viewer seconds after this event, it means that the computer is having problems sending the discovery request. In most cases, this indicates network problems.

Event ID 100 The discovery request send operation was successful

Event ID 212

Event ID 212 has the content Error happened while accessing registry. This error occurs when the registry values are not configured and the SCP is emptied. If the SCP is used in Active Directory to publish the tenant information, this error also appears. But in this case, there is no need to worry and it can be ignored!

Event ID 212 Error happened while accessing registry

Event ID 259

Event ID 259 with the content The task … was successfully disabled only indicates that the device sync task was disabled.

The task ... was successfully disabled Event ID 259
Task Device Sync disabled

Event ID 204

Event ID 204 with the content The get join response operation callback failed with exit code, indicates that the system does not exist in Azure AD (see also Client Error Code 0x801c03f2).

The get join response operation callback failed with exit code Event ID 204

Event ID 304

Event ID 304 with the content Automatic registration failed at join phase also indicates that the system does not exist in Azure AD (see also Client Error Code 0x801c03f2). Event ID 204 and 304 almost occur together.

Event ID 304 Automatic registration failed at join phase

Event ID 331

Event ID 331 with the content Automatic device join pre-check tasks completed can be positive or negative. For this you have to look at what the preCheckResult says (see also Client Error Code 0x1).

Event ID 331 Automatic device join pre-check tasks completed

Here is a positive message before the actual join.

Event ID 331 Automatic device join pre-check tasks completed

Errors

To debug the connection the event log and the command dsregcmd /status helps. Here are a few examples of common errors.

Client Error Code 0x801c03f2

The Error Code 0x801c03f2 in dsregcmd /status means that the system that should be Hybrid Azure AD Joined is not in Azure AD.

Client Error Code 0x801c03f2

This can also be verified in the event log. Event ID 204 and 304 can be found here under User Device Registration.

User Device Registration Event ID 204
User Device Registration Event ID 304

Check the Azure AD portal under Devices to see if the system can be found there.

Azure Portal Device

This means that the AD synchronization in Azure AD Connect has to be adjusted because there is either an OU or attribute filtering implementation that excludes the system, or the object type Device is not included.

Starts Synchronization Service to check and edit this.

Synchronization Service
Azure Active Directory Sync Services

Click on Connectors and right-click on the local domain. In the following window click Properties.

Connectors Properties

In Properties, under Select Object Types, check what is being synchronized.

Connectors Select Object Types

As you can see here device is unchecked and therefore the systems are not synchronized with it. Correct this by enabling device.

Connectors Select Object Types device

Check also the OU filtering under Configure Directory Partitions.

Configure Directory Partitions

Click on Containers … and enter administrative credentials in the following window.

Containers Credentials

In the following window, the OU filtering can be edited. Confirm the adjustment by clicking OK.

OU Filter Select Containers

Now start the synchronization manually or wait 30 minutes.

Run Connector

In the summary click on the manually started connector and in the Export Statistic click on Add.

Export Statistic

In the following window click Properties.

Export Statistic Properties

Here you can see that the VDI1 system has been added.

Connector Space Object Properties

This can also be found in the Azure Portal now.

Azure Portal Device

If the system still does not appear in Azure AD, attribute filtering is still active. To check this, click Synchronization Rules Editor.

Synchronization Rules Editor

In the following window, double-click In from AD – Computers Filtered to check the Device Filter. The rule can have a different name, of course. Check all rules with the Connected System Object Type (computer) and Metaverse Object Type (device).

Synchronization Rules Editor Overview

Check the General Settings regarding Connected System Object Type (computer) and Metaverse Object Type (device). Then click on Scoping filter.

Connected System Object Type Metaverse Object Type

Here you can see that only systems are synchronized that have the entry Sync2O365 in extensionAttribute12.

Scoping filter

To resolve this, populate the appropriate systems with this attribute manually or via PowerShell.

Or disabled / deleted the synchronization rule.

Synchronization Rule disable

Via dsregcmd /status you can now also successfully check the status on the system.

dsregcmd /status

Client Error Code 0x1

The Error Code 0x1 and the displayed Error Phase in dsregcmd /status mean that the system is already stuck in the pre-check. It is also obvious that The Token Acquisition has test skipped status.

Client Error Code 0x1 Error Phase pre-check

This can also be verified in the event log. Event ID 331 can be found here under User Device Registration. The event is only information and does not directly indicate an error. In our Event ID 331 the resultCode: 0x1 can be found and it says as preCheckResult: DoNotJoin.

Event ID 331 User Device Registration resultCode: 0x1 preCheckResult: DoNotJoin

System exists in Azure AD, but has a pending status.

Azure AD Portal Device Pending

With this combination of errors, check if the system has stored the required certificate in the Personal computer context.

Open the mmc and add the snap-in Certificate (Local Computer).

mmc certificate local computer

Validate the existing certificates under Personal > Certificates.

mmc certificate local computer personal

Unfortunately, the required certificates are not available. You can start the join process again via the Scheduled Task by logging on to the machine again or with the command:

dsregcmd /join /debug

The mentioned Scheduled Task Automatic-Device-Join can be found under Microsoft > Windows > Workplace Join.

Scheduled Task Automatic-Device-Join Microsoft > Windows > Workplace Join

Re-logging on is also sufficient, as a trigger At log on of any user is set up.

Scheduled Task Automatic-Device-Join Microsoft > Windows > Workplace Join Trigger

Certificates are now included in the system.

mmc certificate local computer personal

Azure AD Join is now also done. You can see this via dsregcmd /status and in the Azure Portal.

dsregcmd /status AzureAdJoined YES DomainJoined YES
Azure Portal Device

AzureAdPrt: NO

If AzureAdPrt is set to NO, this means that the system has not been assigned a PRT.

AzureAdPrt: NO

We also check the system in Azure AD under Devices. It is in the Pending state in Azure AD.

Azure AD Device Pending

To solve this, the system must be joined again. For this, we start an Administrative CMD /PowerShell.

Here we enter the command dsregcmd /debug /leave to remove the system from Azure AD.

dsregcmd /debug /leave

Check under Devices in Azure AD that the system is no longer present and reboot the affected system to start the rejoin trigger.

Or manual join by the command dsregcmd /debug /join.

dsregcmd /debug /join

After that, a PRT should be in place.

AzureAdPrt: YES

And the system also no longer stands on pending in Azure AD.

Hybrid Azure AD Joined Device

$ behind computer name in Azure Portal

The “problem” solves itself after a few hours. This simply implies that a system has been renamed locally.

$ behind the name

After a few hours, the new name is visible in the Azure portal.

Resolve $ behind the name

HYBRID AZURE AD JOIN aND SAML AUTH

When connecting via a SAML Auth (e.g. via Citrix ADC), Hybrid Azure AD Join cannot recognize the user and therefore cannot generate a PRT.

SAML Auth Hybrid Azure AD Join

This can be recognized by the item IsUserAzureAD, which is then set to NO. SSO will then also not work cleanly.

IsUserAzureAD: NO

One thought on “Why a Windows Server 2019 VDI should be Hybrid Azure AD joined”

  1. Hi,
     
    regarding “Published Application the Office licensing fails (Citrix number LCM-7637).”:
    create a logon powershell script…
    if (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) { Add-AppxPackage -Register “$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml” -DisableDevelopmentMode -ForceApplicationShutdown } Get-AppxPackage Microsoft.AAD.BrokerPlugin
     
    credits:
    https://www.linkedin.com/pulse/solving-modern-authentication-issues-office-365-chris-leet/
    https://docs.microsoft.com/en-us/office365/troubleshoot/authentication/automatic-authentication-fails

Leave a Reply

Your email address will not be published. Required fields are marked *

*