Category Archives: Windows Autopilot

Understanding Device Enrollment and Visibility in Microsoft Intune and Entra ID

Posted on by
Reply

Troubleshooting Errors Like 0x80180014 and Navigating Device Records in the Admin Portals

Introduction

Managing devices in a modern enterprise requires a clear understanding of how devices enroll into your organization’s management ecosystem, particularly in Microsoft Intune and Microsoft Entra ID (formerly Azure Active Directory). With the increasing adoption of mobile device management (MDM) and the demand for secure cloud identity integration, IT administrators frequently encounter various behaviors—and sometimes, errors—that can be confusing.

One of the more common challenges occurs when a device fails to enroll correctly, presenting cryptic error codes such as 0x80180014. This blog post provides a deep dive into how device registration and visibility work across Microsoft Intune and Entra ID. We’ll also unpack typical issues, explain where devices appear in each admin center, and how to cleanly troubleshoot enrollment errors.

This issue was thoroughly explored during a troubleshooting session with Carsten Lund Meilbak, the go-to expert for everything Microsoft Teams and Teams Meeting Room environments, where we investigated problems with a Microsoft Teams Room (MTR) device. During the session, we discovered how certain Autopilot scenarios could result in orphaned device records in Entra ID, preventing re-enrollment.

What Is Microsoft Intune?

Microsoft Intune is a cloud-based endpoint management solution that helps organizations manage user access, enforce compliance, and deploy apps and configurations to devices. Whether the devices are Windows, Android, iOS, or macOS, Intune serves as the command center for policy enforcement and inventory tracking.

What Is Microsoft Entra ID?

Microsoft Entra ID (previously known as Azure Active Directory) is Microsoft’s cloud-based identity and access management service. Devices can be registered, joined, or hybrid joined to Entra ID, and the identity status of these devices is critical for secure access, Conditional Access policies, and MDM enrollment flows.

Section 1: Device Lifecycle – From Registration to Management

Step 1: Device Registration in Entra ID

When a device first connects with a corporate identity, it can take one of several paths:

  1. Azure AD Registered (Workplace Join):
    • Typical for BYOD (Bring Your Own Device).
    • Appears under the user’s profile in Entra ID.
    • Usually paired with manual or conditional enrollment in Intune.
  2. Azure AD Joined:
    • Common for corporate-owned devices.
    • Full control over the device by the organization.
    • Required for Autopilot provisioning and device-based Conditional Access.
  3. Hybrid Azure AD Joined:
    • Devices are joined to on-prem Active Directory and then synced to Entra ID via Azure AD Connect.
    • Offers compatibility for legacy environments still using GPOs or SCCM.

Step 2: Device Enrollment in Intune

After a device is registered in Entra ID, it may also become enrolled in Intune:

  • Automatic Enrollment via group policies or Autopilot.
  • Manual Enrollment by end-users through “Access Work or School” in Windows settings.
  • Co-management Scenarios where both Intune and ConfigMgr (SCCM) share responsibilities.

This enrollment is what allows policies, apps, and configurations to be deployed to the device.

Section 2: How Devices Appear in Admin Portals

2.1 Microsoft Entra Admin Center

Link: https://entra.microsoft.com

Navigate to:

Microsoft Entra Admin Center → Devices → All Devices

Here, you’ll see all devices that are registered or joined to your Entra tenant.

Each record provides the following key information:

  • Device Name
  • Join Type (Azure AD Registered, Azure AD Joined, or Hybrid)
  • OS Type and Version
  • MDM Enrolled (Yes/No)
  • Compliant (Yes/No)
  • Owner (User Principal Name)

If a device shows up here but not in Intune, it might not be enrolled in MDM. You can confirm this via the MDM Enrolled column or by selecting the device and checking details.

2.2 Microsoft Intune Admin Center

Link: https://intune.microsoft.com

Navigate to:

Devices → All Devices

This view shows all devices that are successfully enrolled in Intune, either through automatic enrollment or manual addition.

Important fields include:

  • Compliance Status
  • Enrollment Type (Corporate, BYOD, Autopilot)
  • Primary User
  • Managed By
  • Last Check-In
  • Device Category

If a device is listed here but shows a warning or non-compliance, the issue often relates to Conditional Access, configuration profiles, or missing required apps.

Cross-Referencing Between Portals

It’s not uncommon for admins to find a device in one portal and not the other. Here’s what it typically means:

Found in Entra OnlyFound in Intune OnlyFound in Both
Device is only registered, not MDM-enrolled.Rare; usually due to stale objects or migration.Device is properly joined and managed.

A properly managed device should show up in both portals, and any inconsistency is a sign of an enrollment issue.

Section 3: Common Error – 0x80180014

What Does 0x80180014 Mean?

This error appears most often during the enrollment phase of a Windows 10/11 device. It typically means:

“The device is already enrolled.”

In other words, Windows believes the device is already managed, either because of a previous enrollment or residual data from a prior configuration.

Resolution Steps

  1. Check Admin Portals: Remove the device from both Intune and Entra if it still exists.
  2. Remove MDM Profile: Disconnect the work or school account in Settings.
  3. Use PowerShell: Run dsregcmd /leave to unjoin from Entra ID.
  4. Retry Enrollment: After cleanup, re-enroll the device manually or through Autopilot.

Section 4: Unable to Delete Device from Entra ID

If the device does not appear in Intune but is still stuck in Entra ID and can’t be deleted, follow these steps:

Step 1: Confirm Your Permissions

Ensure your account has one of the following roles:

  • Global Administrator
  • Cloud Device Administrator

You can verify your roles here: https://entra.microsoft.com → My Roles

Step 2: Check the Join Type

In the Entra Admin Center → Devices → All Devices, look at the device’s join type:

Join TypeDescriptionDeletion Method
Azure AD JoinedCloud-joined deviceCan be deleted directly if permissions allow
Azure AD RegisteredBYOD registrationCan be deleted directly
Hybrid Azure AD JoinedSynced from ADMust be deleted from on-prem AD first

If the device is Hybrid Azure AD Joined, delete it from Active Directory Users and Computers on-prem, then let Azure AD Connect sync the deletion.

Step 3: Graph PowerShell Method (Cloud-only Devices)

A. Install Microsoft Graph PowerShell SDK

Install-Module Microsoft.Graph -Scope CurrentUser -AllowClobber -Force

B. Connect to Microsoft Graph

Connect-MgGraph -Scopes "Device.ReadWrite.All"

C. Find and Remove Device

# Replace 'DEVICE-NAME' with the actual name
$device = Get-MgDevice -Filter "displayName eq 'DEVICE-NAME'"
Remove-MgDevice -DeviceId $device.Id

If you already have the Object ID, skip the lookup and run:

Remove-MgDevice -DeviceId "<device-object-id>"

Note on Autopilot Devices

In some scenarios, Autopilot devices can lose their connection to the Entra device object, especially if the device has been reset outside of Autopilot flows (e.g., manually or using third-party imaging). This causes:

  • The Autopilot object to remain in the Autopilot portal
  • The Entra ID device to become orphaned
  • Intune showing no matching device

This was exactly the case during a troubleshooting session with Carsten Lund Meilbak, where we were diagnosing an enrollment failure on a Microsoft Teams Room (MTR) device. The Entra ID device had become orphaned, preventing the MTR from successfully enrolling. Manual deletion of the Entra device object was required to resolve the issue.

In these cases, the orphaned Entra ID device must be deleted manually as described above.

Conclusion

Understanding how devices register and appear in Microsoft Intune and Entra ID is crucial for device management. Cross-portal visibility, proper cleanup, and the ability to handle errors like 0x80180014 efficiently ensure a secure and manageable environment for both users and administrators.

If device records are left stale or orphaned, they can interfere with future enrollment attempts, Autopilot deployments, and compliance policies. Always keep your portals clean and verify device join and MDM status regularly.

Introducing a New Script to Check Autopilot Prerequisites

Posted on by
2

Autopilot is an essential tool for managing and deploying Windows devices in the enterprise. However, before deploying Autopilot, it’s important to ensure that your environment meets the necessary prerequisites. This can be a time-consuming and error-prone process, which is why we’re excited to introduce a new script that automates the prerequisite checking process.

The new script, called Autopilot Prerequisite Checker, is a PowerShell script that checks whether your environment meets the prerequisites for deploying Autopilot. The script checks for the following prerequisites:

Tenant checks:

  • Check license requirements
  • Automatic Windows enrollment (MDM authority is set)
  • DNS records
  • Check user can join device to Azure AD
  • Check Enrollment Status Page
  • Check Windows Autopilot Deployment Profile
  • Check company branding

Device checks:

  • Windows OS version
  • Hardware hash uploaded to Intune
  • Check Windows Autopilot Deployment Profile assignment status

User checks:

  • User is licensed correctly

Network checks:

  • Required communication for Intune Autopilot is allowed

The script is easy to use and can be run on any machine with PowerShell installed. Simply download the script, run it, and wait for the results. The script will output indicating whether your environment meets the necessary prerequisites for Autopilot.

Download the script

The benefits of using the script are numerous. First and foremost, it saves time by automating the prerequisite checking process, allowing you to focus on more important tasks. Second, it reduces the risk of errors, ensuring that your Autopilot deployment is successful the first time. Finally, it provides peace of mind by giving you the confidence that your environment meets the necessary requirements for deploying Autopilot.

In conclusion, Autopilot Prerequisite Checker is a powerful new script that simplifies the process of checking the prerequisites for deploying Autopilot. Whether you’re an IT administrator or a consultant, Autopilot Prerequisite Checker is an essential tool for ensuring the success of your Autopilot deployment.


NOTE: THIS IS A WORK IN PROGRESS – If would like me to add a check, just ping me the info 🙂

Windows Autopilot to enroll hybrid Azure AD-joined error

Posted on by
Reply

I came across this issue where joining the on-premise Active Directory failed during Windows Autopilot.

The full error message from the event viewer of the machine where the Intune Connector is installed.

Intune Connector event viewer error:

RequestOfflineDomainJoinBlob_Failure: Failed to generate ODJ blob
RequestId: 9d1e4614-3217-4d7c-87ef-df7fceb648c9
DeviceId: 83c83fd7-10c8-49c8-9c15-8489ff126eed
DomainName: Mydomain.LOCAL
RetryCount: 0
ErrorDescription: Failed to call NetProvisionComputerAccount machineName=AutoP-PFv5HetaE
InstanceId: C07C1188-586C-44BD-93C1-F236A633DA9B
DiagnosticCode: 268435455
WinErrorCode: 8557
DiagnosticText: We are unable to complete your request because a server-side error occurred. Please try again. [Exception Message: “DiagnosticException: 0x0FFFFFFF. We are unable to complete your request because a server-side error occurred. Please try again.”] [Exception Message: “Failed to call NetProvisionComputerAccount machineName=AutoP-PFv5HetaE”]

The Intune Connector for your Active Directory creates Microsoft Autopilot-enrolled computers in the on-premises Active Directory domain. The computer that hosts the Intune Connector must have the rights to create the computer objects within the domain.


Microsoft Autopilot error details continued…

Follow the guide to delegate control to the computer account hosting the Intune Connector. It solved the issue in this case, as the rights was misconfigured.

  1. Open Active Directory Users and Computers (DSA.msc).
  2. Right-click the organizational unit to use to create hybrid Azure AD-joined computers > Delegate Control.The Delegate Control command.
  3. In the Delegation of Control wizard, select Next > Add > Object Types.
  4. In the Object Types pane, select the Computers > OK.The Object Types pane.
  5. In the Select Users, Computers, or Groups pane, in the Enter the object names to select box, enter the name of the computer where the Intune Connector is installed with Windows Autopilot.The Select Users, Computers, or Groups pane.
  6. Select Check Names to validate your entry > OK > Next.
  7. Select Create a custom task to delegate > Next.
  8. Select Only the following objects in the folder > Computer objects.
  9. Select Create selected objects in this folder and Delete selected objects in this folder.The Active Directory Object Type pane.
  10. Select Next.
  11. Under Permissions, select the Full Control check box. This action selects all the other options.The Permissions pane.
  12. Select Next > Finish.

Conclusion, Windows Autopilot

Review the full prerequisites: https://learn.microsoft.com/en-us/mem/autopilot/windows-autopilot-hybrid

Should You Allow Self-Service With Windows Autopilot?

Posted on by
Reply

With Windows Autopilot, Microsoft gives clients a collection of technologies designed to eliminate the challenges that come with building, maintaining, and applying custom images.

It’s a platform that IT professionals can utilize to set new desktops to join pre-existing configuration groups and apply profiles to the desktops. All of this is so that new users can access fully functional desktops from their first logon.

By using Windows Autopilot, you can simplify the entire lifecycle of Windows devices. Meaning that it covers devices from the initial deployment through to the eventual end of the life cycle. The question, however, is should you allow self-service?

Changing landscape with Windows Autopilot

Over the last few years, we have certainly witnessed a rapid evolution in the remote work landscape. And this evolution has become even more pronounced with the prevailing global pandemic. This has made the need for technology like Windows Autopilot even greater.

Self-service technology has plenty to offer any business. Benefits can include improved end-user experience, effortless coordination for a remote or blended workforce, less complicated management, and significant increases in productivity.

So as the way businesses operate continues to evolve, Windows Autopilot can be the perfect tool to deal with the headaches that we have faced in the past with automated deployment and self-service setups.

Using the self-service setup

The way that Windows Autopilot’s self-service setup works is that it makes workplace devices configured and ready out of the box with its self-deploying mode.

This means that when the employee receives the device they only need to turn it on to start working. Self-deploying mode automatically joins a new device into your company’s Azure Active Directory (Azure AD).

The device is then enrolled into Intune for mobile device management (MDM). Also, you don’t need to worry about apps, certificates, policies, and networking profiles provisioned on the device as they will be dealt with as well.

What this means is that everyone has a lot to gain from using Windows Autopilot, whether you’re IT or the end-user. IT people have their processes simplified and no longer have to deal with the time-consuming, outdated, and overly complex IT processes they had before.

And as for the end-user, all one needs to do is unbox the device, turn it on, connect to the internet, and then verify their credentials.

Self-deploying mode of Windows Autopilot

This feature plays a key role in making Windows Autopilot the platform that it is. Using it will allow you to deploy a device with little to no user interaction. If you have an Ethernet connection then no user interaction will be needed. But, end-users whose devices are connected via Wi-Fi will need to choose the language, locale, and keyboard. And then, they need to make a network connection.

By using self-deploying mode, you can deploy a Windows 10 device as a kiosk, digital signage device, or a shared device. Moreover, it’s also possible to completely automate device configuration by combining self-deploying mode with MDM policies. To deploy in self-deploying mode, you need to follow the steps below:

  • The first step involves creating an Autopilot profile for self-deploying mode that has the settings you want.
  • Next, you need to create a device group in Azure AD and assign the Autopilot profile to that group. Before you try to deploy the device, you should check that the profile has been assigned to the device.
  • Finally, you need to boot the device and connect it to Wi-Fi (if necessary). And then wait for the provisioning process to complete.

Gaining value from technology

As already mentioned earlier, the technological landscape is evolving and so businesses can take advantage of these changes to add value to their operations. The ability to seamlessly deploy devices without IT involvement has huge implications in an increasingly remote-working world.

With countless employees not being on-premises, companies cannot afford to have delays between delivery and deployment. Leveraging Windows Autopilot means that you can eliminate OS image re-engineering and customize the out-of-the-box-experience (OOBE).

By doing this, your processes become easier and faster. And this is going to enhance productivity and potentially increase profitability.

Possible scenarios

Windows Autopilot provides support for a growing list of different scenarios, designed to support the varying needs that most businesses will have. These needs often differ depending on the type of business as well as where you are with moving to Window 10 and transitioning to modern management. Below are some of the common scenarios:

  • Deployment of devices that will be set up by an employee of the company and configured for that person.
  • Deployment of devices that will be automatically configured for shared use, as a kiosk, or as a digital signage.
  • Re-deploying a device in a business-ready state.
  • Pre-provisioning a device with up-to-date apps, policies, and settings.       
  • Provisioning of WIndows 365 devices

User-empowered modern workplace

Windows Autopilot is one of the key components in the Microsoft ecosystem that are helping to create a more user-centric workplace. An environment where users are empowered by IT rather than restricted as they were with legacy IT.

Users will immediately see this from the very beginning as they unbox new devices and have no time-wasting setup involved. Combined with the streamlined benefits of other solutions in the Microsoft ecosystem, this creates a modern, all-digital workplace.

Leveraging digital transformation with Windows Autopilot

So much technological innovation has come to the fore in the last few decades. However, many outdated facets of legacy IT persist including device setup and configuration. But it certainly doesn’t have to be the case for your organization.

Making use of tools like Windows Autopilot has massive potential benefits for your business. Self-service deployments not only make life simpler, but they can help you to operate faster and with fewer complications.

Not to mention how you can create more productive time. The extensive range of capabilities that you get here gives you more automated and user-friendly processes that can enhance your organization’s performance.