DEV Community

AdminPackStudio
AdminPackStudio

Posted on

"Your Organization Has Disabled This Device" (AADSTS135011): A Read-First Entra Device Triage

#azure #windows #powershell #sysadmin

A user opens Outlook or Word and gets "Something went wrong. Your organization has disabled this device. To fix this, contact your system administrator and provide the error code 135011." Sometimes it shows up as CAA20003 with AADSTS135011: Device used during the authentication is disabled. Teams and OneDrive stop signing in. Someone on the team wants to run dsregcmd /leave and rejoin the laptop.

135011 is not a password problem and it isn't a Conditional Access policy result. It means the device object in Microsoft Entra ID has accountEnabled = false. Every token request that uses the device as an identity gets refused. The useful questions are who or what disabled it and will it stay enabled if you flip it back. This post is a read-first order to answer both before you change anything. Every step below only reads until step 5.

TL;DR

  • Find the device object by DeviceId from dsregcmd /status, not by display name. Duplicates are common after a reimage.
  • Check whether the object is disabled or deleted. They look the same to the user but the fixes are different.
  • Read the Entra audit log (Update device, modified property AccountEnabled) to see who disabled it: an admin, the user from My Account, a stale-device cleanup script, or the Entra Connect sync account.
  • Hybrid joined? The on-premises AD computer account wins. Enabling only in Entra gets reverted on the next sync if the AD account is still disabled.
  • Don't delete the object or leave/rejoin just to clear a disabled flag. Deleting removes the BitLocker recovery keys stored on it, and it can break Autopilot re-use.

Disabled vs deleted vs the codes next to it

Read the exact code before picking a runbook:

What the user sees What it means First read
AADSTS135011 / "Your organization has disabled this device" / Office CAA20003 + 135011 Device object exists, accountEnabled is false Audit log: who set it (this post)
AADSTS700003 / "Your organization has deleted this device" / "Device object was not found in the tenant directory" Device object was deleted (audit log shows Delete device) Re-registration path, not Enable
Device shows Pending in Entra, hybrid joined Registration never completed Hybrid join Pending triage
AzureAdPrt : NO but the object is enabled Token issue on the client, not a disabled object PRT triage
"You cannot access this right now" with AADSTS53003 A Conditional Access Block policy matched Sign-in log CA tab, not the device object

Microsoft's own guidance is that disabling a device prevents it from authenticating to Entra ID, revokes its Primary Refresh Token and refresh tokens, and stops Windows Hello for Business credentials from working. So once the object is disabled, the whole sign-in chain on that machine fails together.

Step 1: Get the device's own identifiers

From a session on the affected machine (the user's session is fine for this):

dsregcmd /status | Select-String 'AzureAdJoined|DomainJoined|WorkplaceJoined|DeviceId|TenantName|AzureAdPrt'
Enter fullscreen mode Exit fullscreen mode

Write down:

  • DeviceId: the Entra deviceId, which is the reliable key
  • Join type: AzureAdJoined YES + DomainJoined NO is Entra joined; both YES is hybrid joined; WorkplaceJoined YES is a registered (often personal) device

Display names drift after renames and reimages. If your helpdesk opened the device in the portal by name, they may be looking at the wrong twin.

Step 2: Find the object and read its state

In Entra admin center > Devices > All devices, search by the DeviceId, then check the Enabled column. Or pull it read-only:

Connect-MgGraph -Scopes 'Device.Read.All' -NoWelcome

$deviceId = '<DeviceId from dsregcmd>'
Get-MgDevice -Filter "deviceId eq '$deviceId'" `
  -Property Id,DisplayName,DeviceId,AccountEnabled,TrustType,OnPremisesSyncEnabled,ApproximateLastSignInDateTime,OperatingSystemVersion |
  Select-Object DisplayName, DeviceId, AccountEnabled, TrustType, OnPremisesSyncEnabled, ApproximateLastSignInDateTime
Enter fullscreen mode Exit fullscreen mode
Result Meaning Next
One object, AccountEnabled = False Disabled; this is your 135011 Step 3: who disabled it
No object for this DeviceId Deleted; the client still thinks it's registered Re-registration path (step 5)
Two objects with the same name, one disabled Old twin from a reimage; the user may be fine on the other Confirm which DeviceId the client actually uses
TrustType = ServerAd, OnPremisesSyncEnabled = True Hybrid joined and synced from AD Step 4 before anything else

TrustType values: AzureAd = Entra joined, ServerAd = hybrid joined, Workplace = registered.

To see the size of the problem (one laptop, or a cleanup script that just hit 200 devices):

Get-MgDevice -Filter "accountEnabled eq false" -All `
  -Property DisplayName,DeviceId,TrustType,ApproximateLastSignInDateTime |
  Sort-Object ApproximateLastSignInDateTime -Descending |
  Select-Object -First 50 DisplayName, TrustType, ApproximateLastSignInDateTime
Enter fullscreen mode Exit fullscreen mode

If a lot of disabled devices show recent activity, look for a cleanup job, not a one-off mistake.

Step 3: Read the audit log: who disabled it

Disabling a device shows up in Entra admin center > Monitoring & health > Audit logs as category Device, activity Update device, with the modified property AccountEnabled going from true to false. The Initiated by field is the answer.

A read-only pull for the last 30 days (scope AuditLog.Read.All; how far back you can see depends on your Entra license):

Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome

$since = (Get-Date).ToUniversalTime().AddDays(-30).ToString('yyyy-MM-ddTHH:mm:ssZ')
$events = Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Update device' and activityDateTime ge $since" -All

$events | ForEach-Object {
    $target = $_.TargetResources | Select-Object -First 1
    $prop   = $target.ModifiedProperties | Where-Object { $_.DisplayName -match 'AccountEnabled' }
    if ($prop) {
        $by = if ($_.InitiatedBy.User.UserPrincipalName) { $_.InitiatedBy.User.UserPrincipalName } else { $_.InitiatedBy.App.DisplayName }
        [pscustomobject]@{
            TimeUtc = $_.ActivityDateTime
            Device  = $target.DisplayName
            Old     = $prop.OldValue
            New     = $prop.NewValue
            By      = $by
        }
    }
} | Sort-Object TimeUtc -Descending | Format-Table -AutoSize
Enter fullscreen mode Exit fullscreen mode

How to read By:

Initiated by Usual story Who owns the fix
An admin account Manual disable: offboarding, lost device, or the wrong row in a bulk select That admin / the ticket that asked for it
The user's own account User clicked Disable in My Account > Devices (often thinking it would "remove an old device") Admin re-enables; the user can't undo it themselves
An app / service principal Stale-device cleanup script or automation Whoever owns the script; check its timeframe
The Entra Connect sync account Hybrid: the AD computer account was disabled on-premises AD admins (step 4)

Step 4: Hybrid joined? Read AD first

For hybrid joined Windows 10/11 devices synced by Entra Connect, Microsoft's model is that on-premises AD owns the device lifecycle. Disabling the computer account in AD disables the Entra device at the next sync. Enabling it only in Entra gets overwritten while the AD account stays disabled.

Read-only check on a domain-joined admin box with RSAT:

Get-ADComputer -Identity '<COMPUTERNAME>' -Properties Enabled, LastLogonTimestamp, DistinguishedName, whenChanged |
  Select-Object Name, Enabled, @{n='LastLogon';e={[datetime]::FromFileTime($_.LastLogonTimestamp)}}, DistinguishedName, whenChanged
Enter fullscreen mode Exit fullscreen mode
AD finding Meaning
Enabled = False An AD stale-computer script, offboarding step, or admin disabled it; Entra is only mirroring that
Computer moved to a "Disabled Computers" OU outside sync scope Moving it out of sync scope deletes the Entra object; bringing it back creates a new Pending object that needs re-registration
Enabled = True, Entra still disabled Wait for the next sync cycle, or check sync health, before touching the Entra object

Step 5: When a change is justified

Only after you know who disabled it and that they didn't mean to:

Finding Prefer Avoid
Entra joined or registered, disabled by mistake Enable on the device object (Cloud Device Administrator or Intune Administrator), then have the user restart and sign in dsregcmd /leave and rejoin; you lose nothing by enabling, and a lot by rejoining
Hybrid joined, AD computer disabled Enable the computer account in AD and let Entra Connect sync it Enabling only in Entra and closing the ticket
User disabled it from My Account Enable it, and tell the user what the Disable button does Leaving it for the user, who can't reverse it
Cleanup script hit an active device Enable it, then fix the script: Microsoft suggests no stale timeframe shorter than about 21 days, and disable for a grace period before any delete Running the script again with the same filter
Device was deleted, not disabled Re-register (Entra joined: dsregcmd /forcerecovery; hybrid: dsregcmd /leave, reboot, then sign in with domain credentials so the scheduled task re-registers; registered: disconnect and reconnect the work account) Expecting an Enable button for an object that no longer exists
Device really is lost, stolen, or gone Leave it disabled; retire/wipe in Intune per your offboarding process Deleting it before the BitLocker recovery key is saved somewhere else

If Office keeps showing the error after the object is enabled, have the user restart and sign in again before anything heavier. Microsoft's activation article also covers resetting the Office activation state and clearing old token broker accounts, but treat those as the last step, not the first.

One more reason to prefer Enable over delete-and-rejoin: BitLocker recovery keys for Windows devices are stored on the Entra device object. Delete the object and the key goes with it. If that's the laptop that prompts for recovery next week, you're in the BitLocker recovery key missing ticket.

FAQ

Does AADSTS135011 mean the user account is disabled?
No. A disabled user gets a different error (AADSTS50057). 135011 is about the device object. The same user can usually sign in fine from another device.

Can the user fix this from My Account?
No. If the user disabled the device in My Account, Microsoft says they can't undo it themselves. An admin has to enable it in Entra.

I enabled the device in Entra and it went back to disabled. Why?
It's hybrid joined and the AD computer account is still disabled. Entra Connect syncs the AD state over the cloud change. Enable it in AD.

Does Intune disable the Entra device when I retire or wipe it?
Retire and wipe are Intune actions on the managed device. Disabling is a separate Entra action. Microsoft's stale-device guidance is to retire the device in Intune before you disable or delete it in Entra, so check the audit log rather than assuming Intune did it.

Should I just delete the object and let the device re-register?
Only if you've confirmed the BitLocker recovery key is stored somewhere else and the device isn't an Autopilot device you plan to reuse. Deletion can't be undone, and an Autopilot self-deploying or pre-provisioned rebuild can fail without its original object.

Related posts

Free checklist

A disabled device fails every device-based Conditional Access check at once. If you are about to require compliant or hybrid joined devices, the free Conditional Access pre-enforcement checklist keeps device readiness, pilot groups and report-only review on one page so a cleanup job doesn't turn into a Monday lockout:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=your-organization-has-disabled-this-device

If you want the device lifecycle written down for the team (enrollment hygiene, break/fix cards, and when to retire, disable or delete), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=your-organization-has-disabled-this-device

Admin Pack Studio; not affiliated with Microsoft. Steps 1–4 only read. Enable, delete and re-register are changes: confirm who disabled the device and why, save the BitLocker recovery key first, and record the ticket ID.

Top comments (0)