EBS Analysis: Redo Workplace Join for Android Enterprise devices in Intune – Microsoft Intune

Redoing Workplace Join on Android Enterprise Devices Enrolled in Microsoft Intune

Enterprise mobility programs increasingly rely on Android Enterprise to deliver secure, flexible access to corporate resources. When a device is enrolled in Microsoft Intune but the Azure AD registration (Workplace Join) step fails or becomes out of sync, users encounter a blocked experience: the Get Started screen appears even though the device already shows up in the Intune console. This mismatch prevents access to email, Teams, line‑of‑business apps, and any conditional access policies that depend on a valid device identity. Restoring the Workplace Join relationship without forcing a full re‑enrollment saves time, reduces help‑desk load, and preserves existing app configurations and policies.

This article explains why the enrollment‑registration split can occur, outlines the technical mechanics of Workplace Join for Android Enterprise, and provides a step‑by‑step guide for IT administrators and help‑desk teams to re‑establish the link safely. It also covers security implications, operational considerations, common pitfalls, and a consulting perspective on how to integrate this remediation into broader device‑lifecycle management practices.

Understanding the Enrollment‑Registration Model

Android Enterprise enrollment in Intune consists of two distinct but tightly coupled processes:

  1. Device enrollment – The device is provisioned into Intune’s management stack. For personally owned work profiles this can happen via web‑based enrollment (using the Intune app) or app‑based enrollment (using the Company Portal). Successful enrollment creates a device record in the Intune admin center and applies any assigned compliance, configuration, and app policies.
  2. Workplace Join (Azure AD registration) – After enrollment, the device must be registered with Azure Active Directory to obtain a device object that can be evaluated by conditional access policies. This step creates a trusted identity that links the Intune‑managed device to the user’s Azure AD account. The registration flow is triggered automatically at the end of enrollment or can be initiated manually from the Intune or Company Portal app.

When these two steps fall out of sync, the Intune console shows the device as “Enrolled” while Azure AD shows no corresponding device object (or shows a stale one). Users then see the Get Started screen prompting them to complete Workplace Join, even though they are already managed.

Common Scenarios Leading to a Mis‑sync

  • Interrupted web‑based enrollment – A user begins enrollment through a browser‑based flow, supplies credentials, but aborts before the final Azure AD registration prompt. The Intune client registers the device locally, but the cloud registration never completes.
  • Migration from legacy custom DPC to Android Management API – Devices originally managed with a legacy device‑policy controller may be migrated to the newer Android Management API stack. If the migration script does not invoke the Azure AD registration endpoint, the device remains enrolled but unregistered.
  • Work account removal/re‑addition without full unenrollment – Removing the work profile (or the work account) from Android Settings can leave residual Intune state. Adding the work account again triggers a new enrollment attempt, but the existing Intune record may cause confusion, leaving the registration step incomplete.
  • Network or authentication failures during registration – Intermittent connectivity, expired tokens, or conditional access blocks that prevent the registration call from succeeding can leave the device in a half‑registered state.

How Workplace Join Works for Android Enterprise

Under the hood, Workplace Join for Android Enterprise relies on the Azure AD device registration API exposed through the Microsoft Intune client. The sequence is roughly:

  1. The Intune app (or Company Portal) acquires an Azure AD access token on behalf of the signed‑in user, using either username/password or brokered authentication via Microsoft Authenticator.
  2. Using that token, the app calls the /devices endpoint to register the device, supplying a unique device identifier (the Android ID combined with the Enterprise Mobility Management (EMM) enrollment ID).
  3. Azure AD validates the request, checks any applicable conditional access or device‑based restrictions, and creates a device object in the directory.
  4. The device receives a registration confirmation and stores a certificate or token that proves its registered status for future authentication flows (e.g., silent token acquisition for Outlook, Teams).
  5. Intune is notified of the successful registration and updates the device’s compliance status accordingly.

If any step in this chain fails, the device remains enrolled (Intune still sees it) but lacks the Azure AD device object needed for conditional access.

Implementation Considerations

Prerequisites

  • The device must already appear under Devices > All devices in the Microsoft Intune admin center with a status of “Enrolled”.
  • The end user must know their corporate username and password (or have access to a password‑less method such as FIDO2 or certificate‑based authentication).
  • Microsoft Authenticator must be installed and configured for the user’s work account, as it acts as the broker for authentication tokens during the registration flow.
  • Network connectivity to Azure AD endpoints (login.microsoftonline.com, graph.microsoft.com) and Intune service endpoints must be allowed.

User‑Initiated Redo Workplace Join Steps

  1. Launch the appropriate enrollment app
    • For web‑based enrollment: open the Microsoft Intune app.
    • For app‑based enrollment: open the Intune Company Portal app.
  2. Locate the pending Workplace Join notification
    • The app typically displays a banner or notification indicating that enrollment is incomplete and prompts the user to “Complete Workplace Join”.
    • If the notification is not visible, navigating to the app’s Settings > Device enrollment > Workplace Join often surfaces the same action.
  3. Follow the on‑screen prompts
    • The user will be asked to sign in with their work credentials.
    • Microsoft Authenticator may be invoked to approve the sign‑in or to provide a certificate‑based token.
    • Upon successful authentication, the app contacts Azure AD to register the device.
  4. Verify completion
    • The notification should disappear, and the app will show a status such as “Device is compliant” or “Enrolled and registered”.
    • Launch a work‑protected app (e.g., Outlook, Teams) and confirm that data syncs without prompting for additional authentication.

Administrator‑Side Validation

  • In the Intune admin center, navigate to Devices > All devices, select the device, and check the Azure AD device ID field. A populated GUID indicates successful registration.
  • In Azure Active Directory, under Devices > All devices, search for the device by its serial number or user name; the device should appear with a state of “Registered”.
  • Review the device’s compliance status; if conditional access policies rely on device compliance, the status should update to “Compliant” after registration.

Security and Governance Implications

Redoing Workplace Join does not diminish the security posture; rather, it restores it. However, administrators should consider the following:

  • Authentication integrity – Ensure that the user’s credentials are entered only on a trusted device and that Microsoft Authenticator is up to date. Phishing‑resistant authentication methods (FIDO2 security keys, certificate‑based auth) should be encouraged where possible.
  • Device identity uniqueness** – The registration API uses a combination of the Android Enterprise device ID and the Intune enrollment ID to generate a unique Azure AD device object. Re‑registering a device that already has a valid Azure AD entry will result in a duplicate object; Intune and Azure AD will typically merge or reject the duplicate, but it is good practice to verify that no stale device objects exist before proceeding.
  • Conditional access alignment** – Verify that any conditional access policies that require hybrid Azure AD joined or compliant devices are correctly scoped. A device that passes Workplace Join will be evaluated against these policies; if the device fails compliance, access will still be blocked.
  • Audit logging** – Both Intune and Azure AD log device registration events. Enable sign‑in logs and device‑change logs to track when and by whom the Workplace Join was redone, facilitating forensic analysis if needed.

Operational Implications

From an operations standpoint, the ability to redo Workplace Join without a full re‑enrollment delivers measurable benefits:

  • Reduced help‑desk tickets** – Users can self‑serve the fix using the company portal, lowering call volume for enrollment‑related issues.
  • Preserved app configurations** – Work‑profile apps, managed Google Play assignments, and per‑app VPN settings remain intact because the underlying Intune management stack is untouched.
  • Minimal downtime** – The process typically completes within a few minutes, allowing users to regain access to email and collaboration tools quickly.
  • Scalable remediation** – For larger outbreaks (e.g., after a migration project), administrators can push a targeted notification via Intune that directs users to the Company Portal to complete Workplace Join, leveraging existing communication channels.
  • Compliance reporting** – Once registration is restored, compliance policies that depend on Azure AD device state (such as BitLocker enforcement via Intune for Windows companion devices or mobile threat defense integration) resume accurate reporting.
  • Change‑management considerations** – Document the procedure in the organization’s endpoint‑management runbook and include it in user self‑service guides. Ensure that the help‑desk is aware of the distinction between a full re‑enrollment and a Workplace Join redo to avoid unnecessary steps.

Common Pitfalls and How to Avoid Them

Even though the procedure is straightforward, several recurring issues can impede success:

  • Missing or outdated Microsoft Authenticator – If Authenticator is not installed or is an older version that does not support brokered authentication, the registration flow will fail. Remedy: push the latest Authenticator version via Intune or instruct users to update from the Play Store.
  • Conditional access blocking the registration call** – A policy that requires multifactor authentication (MFA) or a compliant device may inadvertently block the very registration attempt needed to become compliant. Solution: create a temporary exclusion for the Device enrollment or Workplace Join action, or ensure that the user’s MFA method is functional before starting.
  • Stale Azure AD device objects causing conflicts** – If a previous registration left a disabled or stale device object, the new registration may be rejected. Administrators can pre‑emptively delete any existing device object for the user (after confirming it is safe) or use the Remove-MsolDevice PowerShell cmdlet to clean up.
  • User enrolled under a different Azure AD tenant** – In multi‑tenant scenarios (e.g., mergers, acquisitions), a device may be enrolled in Intune under one tenant but the user’s work account resides in another. Verify tenant alignment before attempting Workplace Join.
  • Network restrictions preventing outbound HTTPS to Azure AD** – Firewalls or proxy configurations that block login.microsoftonline.com or graph.microsoft.com will stop the registration token exchange. Validate that required endpoints are allowed.
  • Expired or revoked user credentials** – If the user’s password has expired or the account is locked, the authentication step will fail. Coordinate with identity‑management teams to reset credentials or enable self‑service password reset.

Why This Matters to Enterprise IT

Enterprise mobility strategies hinge on the assumption that a managed device is both enrolled in the MDM solution and recognized as a trusted identity by Azure AD. When that assumption breaks, the ripple effects touch productivity, security, and compliance:

  • Productivity loss** – Users cannot access Outlook, Teams, SharePoint, or line‑of‑business apps that rely on conditional access, leading to missed communications and delayed workflows.
  • Security gaps** – Although the device remains under Intune policy enforcement, the lack of Azure AD registration means it cannot be evaluated by device‑based conditional access rules (e.g., block legacy authentication, require approved apps). This creates a potential bypass vector if not promptly addressed.
  • Compliance reporting inaccuracies** – Compliance dashboards may show the device as non‑compliant or “unknown”, skewing risk metrics and triggering unnecessary alerts.
  • Operational overhead** – Help‑desk staff spend time troubleshooting enrollment issues that could be resolved with a self‑service action, increasing mean‑time‑to‑resolve (MTTR) and cost per ticket.
  • Risk of improper remediation** – Administrators unfamiliar with the nuance may attempt a full wipe and re‑enroll, inadvertently wiping personal data on BYOD devices and violating privacy policies.

By mastering the Workplace Join redo process, IT teams can quickly restore the identity‑management link, preserve user data and configurations, and maintain the integrity of zero‑trust access controls.

EBS Consulting Perspective

From a consulting viewpoint, the Workplace Join redo scenario exemplifies a common class of “half‑state” issues that arise in hybrid cloud‑managed environments. The enrollment‑registration split is not a bug per se, but a symptom of the asynchronous nature of modern device‑lifecycle workflows:

  • Process‑driven design** – Intune enrolls the device first, then relies on the client to trigger Azure AD registration. Any interruption (user cancel, network glitch, migration script omission) leaves the process in a pending state. Consulting engagements should map out these hand‑off points and embed verification steps (e.g., post‑enrollment compliance checks that include Azure AD device presence).
  • Automation opportunities** – For large‑scale migrations or policy changes, consider implementing a compliance policy that flags devices with an enrollment status of “Enrolled” but missing Azure AD device ID. An automated remediation script (using Microsoft Graph API) can then issue a silent Workplace Join request via the Intune Management Extension, reducing reliance on user interaction.
  • User‑experience focus** – BYOD users expect a seamless experience. Providing clear, in‑app guidance (tooltips, inline notifications) that distinguishes between “complete enrollment” and “complete Workplace Join” lowers frustration and supports self‑service.
  • Governance and audit** – Document the procedure as a standard operating condition in the endpoint‑management runbook. Include metrics such as “percentage of enrolled devices with missing Azure AD registration” in monthly health reports to detect systemic issues early.
  • Security‑by‑design** – Ensure that any temporary exclusions created to facilitate Workplace Join (e.g., bypassing MFA for registration) are time‑bound and automatically removed after success. This prevents the creation of standing security loopholes.

In practice, EBS advisors recommend treating Workplace Join redo as a routine maintenance task rather than an exception. By incorporating it into periodic device‑health checks and user‑self‑service portals, organizations can turn a potentially disruptive edge case into a predictable, low‑friction operation.

Practical Next Steps

To operationalize the ability to redo Workplace Join for Android Enterprise devices, consider the following actions:

  1. Run a health check** – Use Microsoft Graph or the Intune PowerShell module to query all Android Enterprise devices and identify those where the azureADDeviceId property is null or empty. Export the list for review.
  2. Communicate with end users** – Draft a concise knowledge‑base article (or short video) that outlines the steps to complete Workplace Join via the Company Portal or Intune app. Link it from the self‑service portal and include it in onboarding materials.
  3. Update help‑desk playbooks** – Ensure Tier‑1 support knows the difference between a full re‑enrollment and a Workplace Join redo. Include decision trees that verify enrollment status before advising a wipe.
  4. Leverage conditional access exclusions (temporarily)** – If MFA is blocking registration, create a short‑lived conditional access policy that excludes the Device enrollment or Workplace Join action for the affected user set, then retire the policy after verification.
  5. Automate remediation where appropriate** – For devices identified in the health check that belong to users who have opted into automated fixes, use a Graph API call to invoke the managedDevices/userExperienceAnalyticsBatteryHealth/issueRemediation equivalent (or a custom Intune script) that triggers the Workplace Join flow silently.
  6. Review and tighten migration procedures** – If your organization is moving from legacy custom DPC to Android Management API, update migration runbooks to include an explicit step that calls the Azure AD registration endpoint (or verifies its success) before marking the migration complete.
  7. Monitor and report** – After implementing the above, track the recurrence of missing Azure AD registrations over time. A declining trend indicates effective process controls; a rising trend may signal underlying issues such as network changes or policy conflicts.

Conclusion

Redoing Workplace Join on Android Enterprise devices that are already enrolled in Microsoft Intune is a focused, low‑impact remediation that restores the critical Azure AD registration link without disturbing existing management configurations or user data. By understanding the underlying enrollment‑registration model, recognizing the common causes of a half‑state condition, and following a structured, user‑guided process, enterprise IT can swiftly recover access to work‑protected applications while maintaining security and compliance.

For organizations seeking to strengthen their endpoint‑management posture, integrating Workplace Join health checks into routine device‑lifecycle workflows, providing clear self‑service guidance, and preparing help‑desk teams to distinguish this scenario from full re‑enrollment will reduce operational friction, lower support costs, and uphold the zero‑trust principles that underpin modern mobile security strategies.

EBS Consulting Advice

If your organization is evaluating Redo Workplace Join for Android Enterprise devices in Intune - Microsoft Intune, do not treat the technology decision in isolation. Start with the business outcome, current architecture, security and identity controls, operational constraints, migration dependencies and governance requirements. A practical assessment should identify the current-state gaps, prioritize the risks and define an implementation roadmap with measurable outcomes.

EBS can help assess the environment, develop the architecture and modernization roadmap, and translate the technical options into an actionable business plan. Relevant EBS services: Microsoft Azure consulting.

Have a technology challenge? Email info@escapebusinesssolutions.com to describe your situation. We welcome questions, consulting discussions and requests for a proposal.


Discover more from Escape Business Solutions

Subscribe to get the latest posts sent to your email.