Skip to content

Ulysses Neves

Microsoft Entra ID, authentication, and hybrid identity troubleshooting.

Menu
  • Início
  • Microsoft Azure
  • Microsoft AD FS
  • Microsoft 365
  • Contact
Menu

Device Registration – Investigating error message: ‘ DeviceAuthStatus : FAILED. Device is either disabled or deleted’

Posted on 2 de June de 2022

Hello everyone. Today we’re going to investigate the message ‘DeviceAuthStatus : FAILED. Device is either disabled or deleted’ on a Hybrid Joined scenario, which can cause error code 50155 on Azure AD Signing logs.

Scenario: Hybrid Azure AD Join

Checking the device join status

To check the device join status, run on the Windows client in the user context command: dsregcmd /status

On the device state section above, we can confirm my device is Azure AD Joined and Domain Joined, which means the device is Hybrid Azure AD Joined. More information on the device states, please check this official Microsoft document.

Checking the event viewer log Microsoft-Windows-User Device Registration/Admin, we see two events confirming the device join status as ‘Hybrid Azure AD joined‘.

Event ID: 331

Automatic device join pre-check tasks completed. Debug output:\r\n preCheckResult: DoNotJoin
deviceKeysHealthy: YES
isJoined: YES
isDcAvailable: YES
isSystem: YES
keyProvider: Microsoft Software Key Storage Provider
keyContainer: 357ca95f-7a99-456f-a36f-XXXXXXXXXXXXXXX
dsrInstance: AzureDrs
elapsedSeconds: 0
resultCode: 0x1

Event ID: 335

Automatic device join pre-check tasks completed. The device is already joined.

Checking the error message on the client

Checking more information on the Device Details, we see a failure. In this section, we see the device’s health in Azure AD, which in this case is failing with error message below:

DeviceAuthStatus : FAILED. Device is either disabled or deleted

More information on the Device Details section, please check this official Microsoft document.

Investigation: Based on the error message above, we can face two possible scenarios:

Scenario 1: The device has been deleted in the OnPrem AD and consequently removed from the Azure AD by the Azure AD Connect SYNC service.

Scenario 2: The device has been moved to an Organization Unit in the OnPrem AD which is not in SYNC with the Azure AD and added back, causing the device state to appear as Pending in Azure AD.

Investigating scenario 1:

Open Azure AD and search for the device ID collected from the dsregcmd /status command.

Confirming the device does not exist in Azure AD, as a next step, we will confirm if it exists in the OnPrem AD:

As confirmed above, the device with same objectGUID does exist in the OnPrem AD, next step is to confirm if the OU the device belongs to is in SYNC scope. To do so, we should open Azure AD Connect and select the option Configure » Customize synchronization options.

After validating the SYNC credential, select the option Domain/OU Filtering and confirm if the OU which the device belongs is in SYNC scope. In my case, it’s NOT which is the reason I am getting the error message ‘FAILED. Device is either disabled or deleted‘.

To fix this issue, I can either:
– Move the device to an OU which is in SYNC.
– Select the OU which the device belongs to.
In my case, I will move the device to one Organization Unit under SYNC scope and run a delta sync with the PS command below on the Azure AD Connect server:

Start-ADSyncSyncCycle -PolicyType Delta

With delta sync successfully finished, we can confirm the affected device has been added to Azure AD in the AAD Synchronization Service Manager:

Confirmed the device has been added to Azure AD after the delta sync, we are able to find the device, but with pending status:

From here, we fall into scenario 2, where you have a previously registered device move from Hybrid Azure AD Joined to pending status. This scenario and fix are documented in this official Microsoft Article, so, we’re going to follow it.

On the client machine, we will unjoin the device from Azure AD to remove all references belonging to the previous registration locally. The command below is used to unjoin the device:

dsregcmd /leave

In order to have the device join process try once again the join, we should reboot the machine.

Once the machine is restarted, running dsrecmd /status command, we confirm it has removed all references to the old registration process as Azure AD Joined is set to NO.

The Automatic Device Join task triggers with each user sign-in or every hour and tries to authenticate the computer to Azure AD.

After logout and logon to the machine, we can see the device has changed the status Azure AD Joined to YES and the DeviceAuthStatus has changed to Sucessful.

Still on the Windows device, checking event viewer log Microsoft-Windows-User Device Registration/Admin, we confirm the automatic registration through Event ID: 306:

Automatic registration Succeeded.

Looking for the same device in Azure AD, we see that is has changed the status from PENDING to Hybrid Azure AD Joined.

That should be sufficient to avoid the error message 50155 in the Azure AD Sign in logs due to the successful device authentication.

Summary

In this article, we covered how to ‘DeviceAuthStatus : FAILED. Device is either disabled or deleted’ on a Hybrid Joined scenario.

I hope you have enjoyed reading this article, and it helps you manage your Hybrid devices in Azure AD.

Enjoyed the article? Like and share. 🙂

Note: I do not represent the organization I work for, all the opinions expressed here, are my own. This post is provided AS IS with no warranties or guarantees and confers no rights.

In case you have any suggestions or feedback, please leave a comment.

[ ]’s
Ulysses Neves

Leave a Reply Cancel reply

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

Recent Posts

  • Microsoft Authenticator Will Block Jailbroken Devices in 2026 — What You Need to Know 17 de March de 2026
  • Enhancing Azure role activation security with FIDO2/Passkeys 23 de September de 2024
  • Microsoft Entra ID CAP | Enforcing WHfB using Authentication Strength 21 de April de 2024
  • Troubleshooting Error Code ‘0x000005e’ in WHfB: PIN Authentication Woes 11 de February de 2024
  • WHfB: Fixing Windows Hello for Business error ‘LogoncertTemplateReady: NO (StateNoTemplate)’ 29 de December de 2023

Archives

  • March 2026
  • September 2024
  • April 2024
  • February 2024
  • December 2023
  • September 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019

Tags

#aaddownleveldevice #aadhybridjoin #adfs #adfsonsql #azuread #azureauth #azureCA #azuredevice #azurehybridjoin #azuremfa #azuresecurity #capolicy #cloudkerberostrust #conditionalaccess #conditionalaccesspolicy #deviceregistration #gmsaaccount #gopasswordless #hybridaadjoin #mfaserver #msadfs #msazure #msidentity #namedlocation #sslcertificatevalidation #tshootadfs #tshoothybridjoin #tshootwaptrust #waptrust #WHFBcerttrust #whfbdeployment #WHfBhybridsetup #widdatabase adconnect authenticationcontext authenticationstrength az500 azuread azuremfa azurepim azuresecurity cloudsecurity microsoft365 msazure WHfB
©2026 Ulysses Neves | Design: Newspaperly WordPress Theme
Ulysses Neves
Gerenciar Consentimento de Cookies
Para fornecer as melhores experiências, usamos tecnologias como cookies para armazenar e/ou acessar informações do dispositivo. O consentimento para essas tecnologias nos permitirá processar dados como comportamento de navegação ou IDs exclusivos neste site. Não consentir ou retirar o consentimento pode afetar negativamente certos recursos e funções.
Funcional Always active
O armazenamento ou acesso técnico é estritamente necessário para a finalidade legítima de permitir a utilização de um serviço específico explicitamente solicitado pelo assinante ou utilizador, ou com a finalidade exclusiva de efetuar a transmissão de uma comunicação através de uma rede de comunicações eletrónicas.
Preferências
O armazenamento ou acesso técnico é necessário para o propósito legítimo de armazenar preferências que não são solicitadas pelo assinante ou usuário.
Estatísticas
O armazenamento ou acesso técnico que é usado exclusivamente para fins estatísticos. O armazenamento técnico ou acesso que é usado exclusivamente para fins estatísticos anônimos. Sem uma intimação, conformidade voluntária por parte de seu provedor de serviços de Internet ou registros adicionais de terceiros, as informações armazenadas ou recuperadas apenas para esse fim geralmente não podem ser usadas para identificá-lo.
Marketing
O armazenamento ou acesso técnico é necessário para criar perfis de usuário para enviar publicidade ou para rastrear o usuário em um site ou em vários sites para fins de marketing semelhantes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
Ver preferências
  • {title}
  • {title}
  • {title}