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.

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).

Microsoft365 apps with UPM 1912 do not create the 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.

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.

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

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.

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.

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.

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.

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.

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.

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.

Click Configure on the Welcome screen.

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

After that, click Next on the Overview page.

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

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

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

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.

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

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

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

Confirm the configuration by clicking Next.

Now it will be checked if SCP is already configured.

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

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

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

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.

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

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

Then click OK.

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.

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.

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.

Now open PowerShell and run the code below.

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.

…

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

Command Prompt / PowerShell

For this we start the CMD or a PowerShell console.

Now enter the following command.

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.

AzureAdJoined	EnterpriseJoined	DomainJoined	Device State
YES	NO	NO	Azure AD Joined
NO	NO	YES	Domain Joined
YES	NO	YES	Hybrid Azure AD Joined
NO	YES	YES	On-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.

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.

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.

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.

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.

Click Azure Active Directory.

In the following window click Devices.

Here you can see all systems stored in Azure AD. Both Azure AD Joined, Azure AD Registered and 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

Phase	Explanation
A	The 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.
B	The 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.
C	For 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.
D	The 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.
E	The 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.
F	The 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).
G	The 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.
H	Device 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  

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. 

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.

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.

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):

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

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.

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.

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.

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

Troubleshooting

Event Logs

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

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 105

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

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 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 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 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 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 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 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 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 259

Event ID 259 with the content The task … was successfully disabled only indicates that the device sync task was 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).

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 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).

Here is a positive message before the actual join.

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.

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

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

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.

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

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

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

Check also the OU filtering under Configure Directory Partitions.

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

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

Now start the synchronization manually or wait 30 minutes.

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

In the following window click Properties.

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

This can also be found in the Azure Portal now.

If the system still does not appear in Azure AD, attribute filtering is still active. To check this, click 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).

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

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

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

Or disabled / deleted the synchronization rule.

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

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.

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.

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

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).

Validate the existing certificates under Personal > Certificates.

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:

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

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

Certificates are now included in the system.

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

AzureAdPrt: NO

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

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

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.

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.

After that, a PRT should be in place.

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

$ behind computer name in Azure Portal

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

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

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.

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