1. Microsoft Entra Registered

When to Use:

• Ideal for personally owned devices (BYOD - Bring Your Own Device).
• Suitable for scenarios where users need access to corporate resources without full device management.

Benefits:

• Flexibility: Users can register their personal devices, allowing access to corporate resources while maintaining personal use.
• Security: Provides a layer of security by enabling conditional access policies and multi-factor authentication (MFA).
• User Experience: Simplifies the user experience by allowing single sign-on (SSO) to corporate applications.

Supported Operating Systems:

• Windows 10 or newer
• MacOS 10.15 or newer
• iOS 15 or newer
• Android
• Linux (Ubuntu 20.04/22.04 LTS, Red Hat Enterprise Linux 8/9 LTS)

2. Microsoft Entra Joined (Recommended join type)

When to Use:

• Best for corporate-owned and managed devices.
• Suitable for organizations that are cloud-first or have a significant cloud presence.

Benefits:

• Enhanced Security: Devices are fully managed by the organization, ensuring compliance with security policies.
• Seamless Access: Users can access both cloud and on-premises resources with their Entra ID credentials.
• Centralized Management: IT administrators can manage devices centrally through Entra ID, simplifying device management and policy enforcement.

Supported Operating Systems:

• Windows 10 or newer, except Home edditions
• Windows Server 2012 or newer VMs running on Azure, except Server core.
• MacOS 12 or newer (with Platform SSO)

3. Microsoft Entra Hybrid Joined

When to Use:

• Ideal for organizations with a mix of on-premises and cloud resources.
• Suitable for scenarios where devices need to be managed by both on-premises Active Directory and Entra ID.

Benefits:

• Dual Management: Provides the flexibility of managing devices through both on-premises Active Directory and Entra ID.
• Seamless Transition: Facilitates a smooth transition for organizations moving from on-premises to cloud environments.
• Comprehensive Security: Ensures devices comply with both on-premises and cloud security policies, enhancing overall security posture.

Supported Operating Systems:

• Windows 10 or newer
• Windows Server 2016 or newer

Conclusion

Choosing the right device registration join type is essential for balancing security, management, and user experience. By understanding the specific use cases and benefits of Microsoft Entra Registered, Microsoft Entra Joined, and Microsoft Entra Hybrid Joined devices, organizations can optimize their device management strategy and enhance security.

Note: You can connect your device to Entra ID as long as you have an Entra ID license, even the free/basic one, and you do not need to pay any extra license.

Hope this cover everything you wanted 😊

References:

• Microsoft Entra joined devices
• Microsoft Entra registered devices
• Microsoft Entra hybrid joined devices

• Dual state appears when the device being connected to Azure AD as Azure AD Registered, and you enable Hybrid Azure AD Joined. So the device will be connected twice to Azure AD, and you will see two different computer objects for the same device name.
  
  
• Starting form Windows 10 1803, with KB4489894 applied, dual state being removed automatically from the device itself.
  
  
• For pre-Windows 10 1803, its recommended to upgrade them to 1803 (with KB4489894 applied) at least to remove dual state. Otherwise, dual state should be removed manually from the device itself.
  
  
• Also, IT professionals can execute the cleanup tool on pre-Windows 10 1803 devices (by GPO or SCCM) which will unjoin the device and clean workplace account. The device will re-join automatically on the next sign-in.
  
  
• You can prevent your domain joined device from being Azure AD registered (which may led to dual state) by adding this registry key:
  • HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin, create REG_DWORD value BlockAADWorkplaceJoin = 1.
    
    
• Removing dual state from the devices themselves may not remove them from AAD, so we need to remove them from AAD manually.
  
  
• It is recommended to disable stale devices for a grace period before deleting them because you cannot undo a deletion. For more info, visit the link: How to: Manage stale devices in Azure AD.
  
  
• You can use the following PowerShell script to verify, disable and clean stale devices from AAD: https://aka.ms/AADDeviceCleanup
  
  
• Also, you can use the following PowerShell script to troubleshoot all devices join types, verify health state for the device including if it is in dual state or not.
  • https://aka.ms/DSRegTool
    
    
• Using the following script, you can verify the health status for multiple devices remotely including dual state, and get HTML report when choosing the correct parameter: http://aka.ms/HAADJHealthChecker
  
  Stay safe until the next article 🙂

Does it worth to connect my user’s devices to Azure AD while they are working remotely?!!

By connecting devices to Azure AD, you will reach the best user experience as Azure AD enables single sign-on to devices, apps, and services from anywhere through connected devices. Also, IT professionals get controls they need to manage and secure your organization resources. For more information, kindly visit https://docs.microsoft.com/en-us/azure/active-directory/devices/overview#getting-devices-in-azure-ad

What are the available types of connecting devices to Azure AD?

You can connect devices to Azure AD in three different types: Azure AD Registered, Azure AD Joined or Hybrid Azure AD joined depends on your infrastructure. For more information, kindly visit https://docs.microsoft.com/en-us/azure/active-directory/devices/overview#getting-devices-in-azure-ad

Do I need an additional license to connect my device to Azure AD?

No, you don’t need an additional license. As soon as you have Azure AD free license which is enabled by default once you have any of office 365 license, any user can connect his device to Azure AD.

I am working remotely from home, and I am not able to access Office 365 services after resetting my password from my Azure AD joined device.

After resetting your password, you need to log off and login back again with the new password to take a new valid Azure AD PRT which is responsible for Single Sign-On.

I am working remotely from home, and I am not able to access Office 365 services after resetting my password from my Hybrid Azure AD joined device.

When resetting your password on Hybrid Azure AD joined device, you need to make sure that you have a line of sight to the Domain Controller. So, if you are outside the corporate network, you need to make sure that you are connected via VPN. Then, you need to log off and login back again with the new password to take a new valid Azure AD PRT which is responsible for Single Sign-On.

Do I still have access to Office 365 resources from Hybrid Azure AD joined device while I am working remotely outside my corporate network?

Yes, you will still have access to O365 resources from Hybrid Azure AD joined devices from outside the corporate network unless you changed your password.

Is there a way to keep having access to Office 365 resources from Hybrid Azure AD joined devices even if I changed my password while I am outside the corporate network?

If you are using Windows Hello for Business (WHfB) to sign into a Hybrid Azure AD joined device, you will remain having the ability to access Office 365 resources even after you change your password.

How can I verify the health status of my Azure AD device?

You can verify the health status for all join types (Hybrid Azure AD joined, Azure AD Joined and Azure AD Register) using Device Registration Troubleshooter Tool

How can I verify that Single Sign-On (SSO) is working as expected on my device?

You can run “dsregcmd /status” command from Hybrid Azure AD joined, or Azure AD joined device and verify if “AzureAdPrt” equals “YES”. For more information, kindly visit the link: https://docs.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-device-dsregcmd#sso-state

As an IT professional, I want to understand Hybrid Azure AD device registration steps.

Device registration high-level steps for Hybrid Azure AD joined:

1. The device tries to retrieve tenant id and the domain name from registry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD].
2. If it fails, the device communicates with Local AD (config partition) to get the tenant’s information form Service Connection Point (SCP). You can get SCP information using Device Registration SCP Tool PowerShell.
3. Then, the device communicates with the Azure AD tenant.
4. The device authenticates against either Azure AD or federation service (e.g. ADFS).
5. The device registration process finishes.
6. 
   For more information, kindly visit the link: Hybrid Azure AD Device Registration
   

Why are we facing delays in getting remote devices connected to Azure AD as Hybrid Azure Active Directory join?

Many customers are facing delays in getting devices registered. The time taken to complete device registration depends on many aspects, for example:

• The domain’s type ( Managed or Federated)
• Does the remote device have a line of sight to DC via VPN
• Did the device synced to AAD (with Managed domains)
• When does the device registration process trigger? For more information, visit Configure hybrid Azure Active Directory join for remote users.
  

As an IT professional, I want to know if there is a way to troubleshoot device registration issues.

You can use the Device Registration Troubleshooter Tool, which performs more than 30 different tests. This tool helps to identify and fix the most common device registration issues for all join types (Hybrid Azure AD joined, Azure AD Joined and Azure AD Register).

I am working from home, and I am not able to access cloud resources as Conditional Access Policy mentioned my device is not registered. However, it is connected to Azure AD.

You have to be sure that the device is connected to Azure AD successfully and verify Azure AD PRT value. For more information, kindly visit the link: https://docs.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-device-dsregcmd#sso-state

Previously, I shared an article and discussed how to Increase productivity and protection by connecting devices to AAD and configuring Device-based Conditional Access Policy.

We are receiving lots of queries from customers who are facing challenges in configuring Hybrid Azure AD joined for the remote domain-joined device where users are working from home.

In this article, we will discuss one of the most repeated challenges, which is connecting remote domain-joined devices to Azure AD as Hybrid Azure AD Joined devices. Also, we will make it more transparent to deal with this challenge to reach out to our needs.

One of the most important prerequisites is making sure that the device has a line of sight to Domain Controller as discussed before in device registration high-level steps. Windows 10 device needs to communicate with the Domain Controller during the device registration process due to the following facts:

1. Retrieve the Service Connection Point (SCP) information, which has Tenant ID and Domain Name, where the device will be registered.
2. Push the self-signed certificate under Active Directory computer account in the userCertificate attribute, and this is a mandatory step to get the device registered for managed domains. Also, to get the device registered if the authentication failed against the federation server, so the device registration falls back to sync join and goes through managed domains steps; this applies for windows 10 1803 and above.

So it is a must to have a line of sight to Domain Controller either by setting inside the corporate network or by connecting to VPN. Without the connection to Domain Controller, the whole device registration process is going to fail.

Many customers are facing delays in getting devices registered. The time taken to complete device registration depends on when the registration process triggers and also depends on the type of domain it is Federated or Managed.

The device registration process triggers when a user signs in to his device. The challenge for most remote users is that they connect to VPN after sign in to the device. So device registration does not succeed as before connecting to the VPN, remote devices do not have a line of sight to DC. Therefore, to get the device registered after VPN, the user needs to trigger device registration manually using one of the following options, this requires the user to have local admin permissions on his remote device.

1. Open Task Scheduler as admin, and run “Automatic-Device-Join” task which is located under the path:
   • Task Scheduler Library > Microsoft > Windows > Workplace Join
2. Run CMD as admin, and run the following command:
   • schtasks /Run /TN “Microsoft\Windows\Workplace Join\Automatic-Device-Join”

Many IT professionals do not allow end-users to have local admin permissions on their devices. In this case, users will have a delay, and they need to wait an hour to get the device registration process triggers as the device registration process is hardcoded to trigger every hour if the device is domain-joined.

Another delay users are going to face if one of the following applies:

• Users have Managed domain, which requires sync device objects to AAD using AAD connect that syncs objects to AAD every 30 minutes, the default sync cycle.
• Users have Federated domain, and device registration failed against the federation service, so the device will fallback to sync join and uses Managed domain steps. This applies to windows 10 1803 versions and above.

In conclusion, kindly find the following points:

• Remote users should connect to the VPN to have a line of sight to DC. Then, they need to trigger the device registration process manually if they have local admin permissions. Otherwise, they need to wait an hour to get the device registration process trigger automatically.
• If remote users’ domain is federated, the device registration completes, and the device gets registered directly after the device registration process triggers.
• With a federated domain, if the remote user does have admin permissions, he can trigger the device registration process as described earlier, and he gets his device registered in a matter of seconds.
• With a federated domain, if the remote user does not have admin permissions, he needs to wait an hour to get his device registered. So the delay will be up to one hour after he signs in and connects his device to VPN.
• With managed domains, there are lots of aspects that increase the delay as the following steps should be completed in order:
  • User needs to be connected to the VPN.
  • Device registration process triggers; the device creates a self-signed certificate and pushes it under the AD computer account.
  • AAD Connect syncs the computer object to AAD in its next sync cycle.
  • The device registration process triggers again; the device finds itself in AAD and registers itself successfully.
• With managed domains, if the user does have admin permissions, he can trigger the device registration process manually. Still, he needs to make sure that the device object synced successfully to AAD using AAD Connect before trigger the second device registration process. The delay in this scenario could be up to 30 minutes, which is the default sync cycle.
• With managed domains, if the user does not have admin permissions, delay takes a longer time to get the device registered, which could be up to two hours. In this scenario, after the user signs in and connects to the VPN, he needs to wait an hour to trigger the first device registration process, which creates the self-signed certificate. Then, he needs to wait for the next sync cycle to sync the computer object to AAD. After that, the user needs to keep waiting for the second device registration process to trigger (after an hour) to get the device registered.

Reduce device registration time

In the next section of this article, I am going to discuss how we can reduce this delay from hours to minutes to get remote devices connected to Azure AD as Hybrid Azure AD Joined devices.

To reduce the delay, especially for remote users who do not have admin permission, we need to think of triggering the device registration process in less than one hour. To accomplish this, we can create the following Group Policy Object that triggers the device registration process every 15 minutes (for example) after it confirms that the device is not connected to AAD.

1. Configure a shared folder:
   • Create a folder with the name of “Scripts” on the file server or the shared storage.
   • Share the folder with a meaningful name (e.g., Scripts).

     Note: you can add a “$” character at the end of the share name to make it hidden.

2. Create a batch file:
   • Name the batch file with a meaningful name (e.g., Start-DsRegCMD.bat).
   • Add the following command lines to the batch file: ```powershell dsregcmd /status | findstr /c:”AzureAdJoined : NO” if errorlevel 1 (echo notfound) else (schtasks /Run /TN “Microsoft\Windows\Workplace Join\Automatic-Device-Join”)
3. Configure GPO:
   • Open “Group Policy Management Console” on the domain controller and create a new GPO with a meaningful name (e.g., DsRegCMD- Task).
   • Link the GPO to the desired Organizational Unit (OU).
   • Edit the above created GPO, and open “Computer Configuration\Preferences\Control Panel Setings\Scheduled Tasks”.
   • Right-click and choose New > Scheduled Task (At least Windows 7) image
   • In “General” tab, configure the following:
     • Choose “update” from the “Action” dropdown list.
     • Name the task e.g., “Start-DsRegCMD”
     • in “when running the task, use the following user account” box, choose “NT AUTHORITY\System”
     • Check the “Run with highest privileges” option.
   • In “Triggers“ tab, create a new trigger and make it repeat every 15 minutes as the following:
   • In “Actions“ tab, create the following new action to run the previously created batch file:
   • In “Conditions” tab, check “Start only if the following network connection is available” option and choose “any connection” from the dropdown list.
   • In “Settings” tab, check both “Allow task to be run on demand” and “If the running task does not end when requested, force it to stop” options.

After creating the GPO, now we need it to be updated on the user’s machine. End-user can run the “gpupdate /force” command even if he does not have admin permissions, and the new task will be created.

Additionally, Group Policy refreshed when a user logs on. It also periodically refreshed; by default, this periodic refresh is performed every 90 minutes with a randomized offset of up to 30 minutes. For more information, visit Refresh Group Policy

Finally, by having the above task scheduler created, the device registration time will be reduced for normal remote end-users to be 15 minutes for federated domains, and up to 30 minutes for managed domains.

Hope this helps, and please stay safe at home 😊

Before answering this question, lets discuss first some of the benefits from end users, IT admins and security perspectives that will be gained when connecting devices to Azure AD.

End user Experience:

Azure Active Directory allows the users (who connected their device to it) to automatically sign in which means when users sign in successfully once they do not need to enter their passwords to sign in to Azure services anymore. This gives the users an easy access to cloud-based applications without any additional on-premises components.

Also, when connecting devices to Azure AD, end user gains the best Single Sign-On (SSO) experience of utilizing and accessing Azure services like:

• Windows activation.
• Enterprise applications.
• Encryption using Bit-Locker.
• Azure AD app proxy applications.
• Access Windows Store for Business.
• Office 365 services and applications.
• Activate Windows Hello for Business.
• Mobile Device management (Intune).
• Enterprise roaming across joined devices.

IT Administrators:

Azure AD provides centralized administration to control and manage the connected devices. Admins can easily control Azure AD devices by doing the following:

• Join devices to Azure AD and control who can do it.
• Enable/Disable Azure AD device.
• Delete devices from Azure AD and control who can do it.
• Wipe corporate data with assistance of Intune MDM.
• Add local admins to the joined devices.
• Retrieve Bit-Locker Recovery keys.
• Control the number of connected devices per user.

Security Perspective:

Single sign on (SSO): user has a single identity and SSO is enabled for him to simplify the security model. When user’s roles being changed or the user leaves the organization, access modifications are tied to that single identity, and SSO greatly reduces the efforts needed to change or disable the user’s account. Using Single Sign-on for accounts makes it easier to manage users identities and increases the security capabilities for the organization.

Connecting devices to Azure AD allows administrator to manage how cloud or on-premises devices access the corporate data by Azure Conditional Access Policies. Using Conditional Access policies, administrators make sure that users are accessing resources from devices that meet standards for security and compliance, for instance, admins can control the access to O365 services only from trusted devices (Hybrid Azure AD devices and/or compliant devices).

Intune Mobile Device Management (MDM) solution which is fully integrated with Azure AD gives IT Admins the need power to control, manage and apply security settings in heterogeneous options in order to protect the enrolled devices and keep data protected.

Finally, as a conclusion, the answer is YES you need to connect your devices to Azure Active Directory to reach the best user experience, device management and to be more secure.

Previously, I shared an article that answers Do I really need to connect my device to Azure AD?! and in this article we will discuss how to configure device-based Conditional Access Policies.

When configuring Device-based Conditional Access Policy, customer falls into one of the following scenarios:

Scenario #1: Cloud customers with no Azure AD Premium license or Intune license.

To configure Device-based conditional access, cloud customers should have both Azure AD Premium license and Intune license. Cloud customers who are not having both licenses, can enable Azure Active Directory Premium free for one month and sign up for a Microsoft Intune free trial for 30 days.

After enabling the tenant for both Azure AD Premium license and Microsoft Intune license, cloud customers will have both Azure AD Premium and Intune licenses and they can go with scenario #3 in this article.

Scenario #2: Cloud customers with Azure AD Premium license but no Intune license.

Cloud customers who have Azure AD premium license can configure an easy Conditional Access Policies, but they cannot configure Device-based conditional access policy as users will always fail because their devices are not managed by Intune which is Microsoft MDM solution.

For cloud customers who are having Azure AD Premium license but not Intune license, they can sign up for a Microsoft Intune free trial for 30 days.

After enabling the tenant for Microsoft Intune, cloud customers will have both Azure AD Premium and Intune licenses and they can go with scenario #3 in this article.

Scenario #3: Cloud customers with Azure AD Premium and Intune licenses

Cloud users who are having Intune license can connect their devices to Azure AD as Azure AD Joined for corporate devices (aka. CYOD) or as Azure AD Registered for personal devices (aka. BYOD). Also, they can enroll their devices to Intune automatically after they become connected to Azure AD.

In this scenario, IT professionals can protect identities and their information by allowing the access to Office 365 services and applications from compliant devices only. The device will never become compliant before it meets the device compliance policies. More information about device compliance policies can be found in the article, Set rules on devices to allow access to resources in your organization using Intune.

To configure a Conditional Access that Requires compliant devices, visit Conditional Access: Require compliant devices article.

Scenario #4: Hybrid customers with no Azure AD Premium license or Intune license.

Hybrid customers are having local Active Directory as well as Azure Active Directory and they are syncing their users to Azure AD in order to gain the benefits of utilizing Azure cloud resources.

To configure Device-based conditional access, hybrid customers who do not have Azure AD Premium license and do not have Intune license have two options:

• Option #1: Hybrid customers can enable both Azure Active Directory Premium free for one month and sign up for a Microsoft Intune free trial for 30 days.

  After enabling the tenant for both Azure AD Premium license and Microsoft Intune license, hybrid customers will have both Azure AD Premium and Intune licenses and they can go with scenario #5 in this article.

• Option #2:Hybrid customers can enable Azure Active Directory Premium free for one month only.

  After enabling the tenant for Azure AD Premium license, hybrid customers will have Azure AD Premium license and they can go with scenario #6 in this article.

Scenario #5: Hybrid customers with Azure AD Premium license and Intune license.

Hybrid customers are having local Active Directory as well as Azure Active Directory and they are syncing their users to Azure AD in order to gain the benefits of utilizing Azure cloud resources.

The number of users working from home (WFH) increases in response of COVID-19 (coronavirus) outbreak, and many of them do not have access to local Active Directly, at the same time, IT professionals need to manage and protect their devices to make sure those devices that accessing corporate data are meeting configuration and security policies. To accomplish this, users need to connect their devices to Azure AD and enroll them to Intune.

Users who are having Intune license can connect their devices to Azure AD as Azure AD Joined for corporate devices (aka. CYOD) or as Azure AD Registered for personal devices (aka. BYOD). Also, they can enroll their devices to Intune automatically after they become connected to Azure AD.

In this scenario, IT professionals can protect identities and their information by allowing the access to Office 365 services and applications from compliant devices only. The device will never become compliant before it meets the device compliance policies. More information about device compliance policies can be found in the article, Set rules on devices to allow access to resources in your organization using Intune

To configure a Conditional Access that Requires compliant devices, visit Conditional Access: Require compliant devices article.

Very Important Points:

• Users can access on-premises resources from Azure AD Joined devices automatically and Single Sign On (SSO) is working. More information about accessing on-premises resources from Azure AD Joined devices can be found in the article, How SSO to on-premises resources works on Azure AD joined devices
• Also, users can access on-premises resources from Azure AD Joined devices using Windows Hello for Business (WHfB). More information about accessing on-premises resources from Azure AD Joined devices using Windows Hello for Business can be found in the article, Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business

Scenario #6: Hybrid customers with Azure AD Premium license but no Intune license.

Hybrid customers are having local Active Directory as well as Azure Active Directory and they are syncing their users to Azure AD in order to gain the benefits of utilizing Azure cloud resources.

The number of users working from home (WFH) increases in response of COVID-19 (coronavirus) outbreak, and IT professionals need to manage and protect their devices to make sure those devices that accessing corporate data are meeting configuration and security policies. To accomplish this, IT professionals join devices to local domain.

Devices of remote users are either connected to the local domain or not. If the device is not connected to local domain, the easiest option is to connect it directly to Azure AD as Azure AD Joined or Azure AD Registered and IT professionals need to go with scenario #4 option #1. Otherwise, if the device is connected to local AD, we have one of the following options:

• Option #1: Devices are connected to Azure AD as hybrid Azure AD joined:

  Hybrid customers who connect devices to Azure AD as Hybrid Azure AD joined and have Azure AD Premium license, can configure Device-based conditional access and require the access to Azure cloud resources from Hybrid Azure AD joined devices. More information about configuring Device-based conditional access to require hybrid Azure AD join devices can be found in the article, Require Hybrid Azure AD joined devices

• Option #2: Device are NOT connected to Azure AD as hybrid Azure AD joined:

  Hybrid customers who have Azure AD Premium license, need to connect devices to Azure AD as hybrid Azure AD joined to configure Device-based conditional access to require hybrid Azure AD join devices.

In this section we will discuss how to connect devices to Azure AD in both Managed and Federated environments. More information can be found in the article, Plan your hybrid Azure Active Directory join implementation

Managed environment

Hybrid customers who have Managed domains can configure auto Hybrid Azure AD joined using Azure AD connect application. More information about the configuration steps can be found in the article, Configure hybrid Azure Active Directory join for managed domains

After completing Azure AD connect wizard, Service Connection Point (SCP) will be created under configuration partition which has information about the tenant ID and the Tenant name. Devices in Managed environments should have a line-of-sight connection to local Active Directory either by connecting it to the local network or by using VPN to read SCP information in order to connect itself to Azure AD.

Device registration process for Managed domains depends on Azure AD Connect synchronization cycle which is 30 minutes by default. More information about high level device registration steps can be found in the article, Hybrid Azure AD Device Registration

Federated environment

Hybrid customers who have Federated domains can configure auto Hybrid Azure AD joined using Azure AD connect application. More information about the configuration steps can be found in the article, Configure hybrid Azure Active Directory join for federated domains

After completing Azure AD connect wizard, Service Connection Point (SCP) will be created under configuration partition which has information about the tenant ID and the Tenant name. Also, ADFS claim rules will be created on Active Directory Federation service if it is managed by Azure AD Connect. If ADFS id not managed by Azure AD connect for some reason, we recommend to create ADFS claim rules using Azure AD PRT Claim Rules

Devices in Federated environments should have a line-of-sight connection to local Active Directory either by connecting it to the local network or by using VPN to read SCP information in order to connect itself to Azure AD.

Device registration process for Federated domains completes in few seconds as the device authenticates directly from ADFS server. More information about high level device registration steps can be found in the article, Hybrid Azure AD Device Registration

We still do recommend the devices to be synced to Azure AD even if device registration process does not depend on Azure AD Connect synchronization. More information about high level device registration steps can be found in the article, Hybrid Azure AD Device Registration

Additionally, you can use Device Registration Troubleshooter tool which performs more than 30 different tests that help you to identify and fix the most common device registration issues for all join types (Hybrid Azure AD joined, Azure AD Joined and Azure AD Register).

Thanks for reading, and please stay safe at home 😊

Pending devices indicates that the device has been synchronized successfully using Azure AD connect form your on-premise Active Directory and it is ready for device registration, but is not registered to Azure AD yet.

This also means that the device object in Azure AD waits the device registration process to be triggered and complete successfully to get the device connected to Azure AD as hybrid Azure AD joined device as needed. Learn more about Hybrid Azure AD Device Registration procedure.

The device state could be changed from having a registered state to PENDING, if one of the following actions:

• The device deleted from Azure AD, and then synced back form the on-premise Active Directory.
• The device removed from sync scope and added back.

Due to the fact that it is not easy to search for all PENDING devices in Azure AD devices blade. Get-AADPendingDevices PowerShell script gives you the power to accomplish the following:

• Retrieve all pending devices from an Azure AD tenant.
• Manage pending devices by removing them form Azure AD tenant.

Why is this script useful?

• To check pending devices in Azure AD tenant.
• To generate a powerful Excel report with the pending devices.
• To automate Azure AD pending devices cleanup procedure by running it in a scheduled task.
• To show the result on CSV or/and Grid View or/and Excel, so you can easily search in the result.

What does this script do?

• Verifies the pending devices as per the entered threshold days.
• Cleans pending devices from Azure AD.
• Checks if ‘MSOnline‘ module is installed and updated. If not, it takes care of this.
• Checks if ‘ImportExcel‘ module is installed. If not, it installs and imports it.

User experience:

• If there is no pending devices in AAD tenant:
  

• CSV file output:
  

• Excel output:
  

You can always download the updated version directly from the link: https://github.com/mzmaili/AADPendingDevices

1. The device tries to retrieve tenant id and domain name from registry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD].
2. If it fails, the device communicates with Local AD (config partition) to get the tenant’s information form Service Connection Point (SCP). You can get SCP information using Device Registration Troubleshooter Tool PowerShell.
3. Then, the device tries to communicate with Microsoft resources under the system context. You can verify if the device can access Microsoft resources under the system account by using the Test Device Registration Connectivity script.
4. The device authenticates against either Azure AD or federation service (e.g. ADFS).
5. The device registration process finishes.

Managed vs Federated

In this section, let’s discuss device registration high level steps for Managed and Federated domains

Managed Domain

• The device generates a certificate. This certificate will be stored under the computer object in local AD.
• AAD Connect application syncs all computer objects that have the ‘user certificate’ attribute populated to Azure AD in the next synchronization cycle. (the device will show in Azure AD as a hybrid Azure AD device, and the
• The device communicates with Azure AD once again to register itself.
• Azure AD compares the device’s certificate with what it has in Azure AD.
• If the device certificates matched, the device will be connected to Azure AD as Hybrid Azure AD joined, hence “Registered” value of Azure AD device object will be populated.

Federated Domain

• The device communicates with Azure AD to register itself using the SCP.
• Azure AD redirects the device to authenticate against the federation server.
• The device takes a token from the federation server and pass it to Azure AD to register itself.
• Device registration finishes, and the device present in Azure AD devices section.

Things to know:

• Device registration in federated domains is faster than managed domains since it does not wait the sync cycle.
• Identity provider should support the following (they are already supported in ADFS):
  • WS-Trust protocol: for windows current versions.
  • WIAORMULTIAUTHN claim : for down-level devices.
• Starting from 1803, if device registration fails with federated domain, it will try to complete the registration using the synced computer/device.
• 1703 or earlier, if the organization requires access to the internet via an outbound proxy, Web Proxy Auto-Discovery (WPAD) must be implemented.
• Starting from 1709, WPAD can be implemented via GPO.
• To verify if the device is able to access Microsoft resources under the system account to register itself, you can use Test Device Registration Connectivity script.
• Windows 10 devices registered under the machine context.
• Windows down-level registered under the user context.
• Hybrid Azure AD join is currently not supported:
  • If your environment consists of a single AD forest synchronizing identity data to more than one Azure AD tenant.
  • Windows current devices with non-persistent virtual desktop infrastructure (VDI).
  • For FIPS-compliant TPM.
  • For Windows Server running the Domain Controller (DC) rule.
  • On Windows down-level devices when using credential roaming or user profile roaming
• When using “Sysprep” tool with pre-Windows 10 1809 images for installation, make sure that the image is not from a device that is already registered with Azure AD as Hybrid Azure AD join.
• If you are relying on a Virtual Machine (VM) snapshot to create additional VMs, make sure that snapshot is not from a VM that is already registered with Azure AD as Hybrid Azure AD join.
• Dual state being avoided starting from:
  • Windows 10 1809 release
  • Windows 10 1803 release with KB4489894

Important scripts:

Device Registration SCP Tool

Test Device Registration Connectivity

Hybrid Azure AD Joined Devices Health Checker

• Non-persistent VDI machine created when a user signs in, and it destroyed once the user signs out.
• Non-persistent VDI machine connects to Azure AD as hybrid Azure AD joined device when a user signs into it, and if auto hybrid Azure AD join configured correctly.
• Users should sign into a hybrid Azure AD device to acquire Azure PRT which is responsible for single sign on (SSO), and which allows users to pass device-based conditional access policy that requires the user to sign in form hybrid Azure AD device.
• If a non-persistent VDI machine took time to connect itself to Azure AD during the user’s login, the user will sign into a non-hybrid device, and he will not be able to acquire Azure PRT. Hence, SSO will not work for him, and he will be blocked by any device-based conditional access policy that requires the access from hybrid device.
• Azure AD device object remains exist, although the non-persistent VDI machine has destroyed and does not exist anymore after the user signs out from it. This ends up with a huge number of stale device objects in Azure AD.
• Azure AD stale devices should be cleaned up periodically to avoid keeping unwanted objects in Azure AD tenant, and reaching the default quota limit which may cause service interruption due to running out of quota.

In this article, I am demonstrating the steps to configure Hybrid Azure AD joined devices with non-persistent VDI for federated environments taking the above challenges into account.

Before we start, Keep in mind that Hybrid Azure AD joined for non-persistent VDI (NPVDI) for federated environments requires additional considerations in order to be supported. For more information about supported scenarios, check supported scenarios document.

Now, lets continue. Our goal is to make the user sign in successfully to a hybrid Azure AD domain joined device and acquire Azure PRT which gives him the ability to utilize single Sign-On (SSO), as well as, allows him to access Office 365 resources by passing any conditional access policy requires the access from trusted devices like hybrid Azure AD joined devices.

In the following steps, we will accomplish the following:

• Create a GPO and attach it to VDI machines to run a batch file that executes the command “dsregcmd /join” to register the machine to Azure AD when it starts and before the user login to it. (since the user needs to login a connected machine to acquire Azure PRT).
• Configure the same GPO to run another batch file that executes the command “autoworkplace.exe /leave” to disconnect the machine from Azure AD when the user sign out. (since the machine destroys once the user log out).
  

  This step is only needed for down-level devices, and we do not want to run “dsregcmd /leave” command for current level OS versions.

1. Configure join batch file:

• Create a batch file to be run when the user logon to the machine.
• Name the batch file with a meaningful name (e.g. VDIJoin.bat).
• Add the following command to the batch file:
  dsregcmd /join

2. Configure disjoin batch file (this step is needed only for down-level devices):

• Create a batch file to be run when the user log off form the machine.
• Name the batch file with a meaningful name (e.g. VDIDisjoin.bat).
• Add the following command to the batch file:
  autoworkplace.exe /leave

3. Configure Startup GPO:

• Open “Group Policy Management Console” on domain controller and create a new GPO with a meaningful name (e.g. VDIHybridDevices).
• Edit the above created GPO, and open “Computer Configuration\Windows Settings\ Scripts (Startup/Shutdown)”.
• Choose Startup and add the above created batch file in first step.
• Open “User Configuration\Windows Settings\ Scripts (Logon/Logoff)”.
• If you have down-level devices, choose Logoff and add the above created batch file in second step.
• Link the GPO to the needed OU that contains NPVDI machines.

Now, we have created the needed GPO so that the machine will be connected to AAD as hybrid Azure AD joined device once it starts, and the user will be able to get PRT and SSO will work when he signs into it as he will sign into a hybrid device.

The next challenge is to avoid keeping unwanted device objects in Azure AD tenant and reaching the default quota limit, you can accomplish this and automate cleaning Azure AD stale devices in an efficient way using Azure AD Device Cleanup script keeping in mind that for non-persistent VDI deployments on Windows current and down-level, you should delete devices that have ApproximateLastLogonTimestamp of older than 15 days.

Very important notes before you go:

• Consider using a prefix for the display name (e.g. NPVDI-) for non-persistant VDI devices to make it easier when implementing cleanup strategy.
• Keep track your Azure AD quanta limit, specially when having large number of VDI machines. For more information, kindly visit the link.
• DO NOT execute dsregcmd /leave as part of shutdown/restart process of windows current devices (Windows 10, Windows Server 2016, and Windows Server 2019).
• For Windows down-level (Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2), the device will be connected to Azure AD as hybrid device once the user login to it and it will not use “dsregcmd /join” command.
• To clean Windows down-level devices from Azure AD when the user sign out, you can add “autoworkplace.exe /leave” command to the above created GPO.
• Internet connectivity to the following Microsoft resources under the system context should be allowed automatically once Windows 10 device starts to get it registered before the user signs in:
  • https://login.microsoftonline.com
  • https://device.login.microsoftonline.com
  • https://enterpriseregistration.windows.net
• You can verify if the device can access the above Microsoft resources under the system account by using the Test Device Registration Connectivity script.
• Make sure that the golden/original VDI image is not connected to Azure AD as hybrid device. So, the new VDI machines will register to Azure AD when it starts with a unique device ID.
• If you are relying on the System Preparation Tool (sysprep.exe) and if you are using a pre-Windows 10 1809 image for installation, make sure that image is not from a device that is already registered with Azure AD as hybrid Azure AD joined.
• If you are relying on a Virtual Machine (VM) snapshot to create additional VMs, make sure that snapshot is not from a VM that is already registered with Azure AD as Hybrid Azure AD join.
• You can use Azure PRT Login Status Report script to validate Azure PRT.

We can connect devices to Azure AD using the following ways:

Azure AD Registered

• Used for personal devices
• Bring Your Own Device (BYOD)
• Users sign in using the local machine’s account
• Devices could be managed using Intune
• Can be used with the following Operating systems:
  • IOS
  • MacOS
  • Android
  • Windows 10

Azure AD Joined

• Used for company owned devices
• Choose Your Own Device (CYOD)
• Used with windows 10 devices only
• Devices will be joined to Azure AD domain only
• All synced users can be able to login to the machine by default
• Devices could be managed using Intune

Hybrid Azure AD Joined

• Used for company owned devices
• Choose Your Own Device (CYOD)
• Once the device connected to the local domain, it will be connected automatically to Azure AD
• Devices could be managed by GPO, CCM and/or Intune.
• Used with Windows operating systems.
  • Current devices: Windows 10, Windows Server 2016, and Windows Server 2019
  • Down-level Devices: Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2

Note: you can connect your device to Azure AD as long as you have Azure AD license even the free one, and you do not need to pay any extra license.