/
/

How to Standardize Device Reset and Reassignment Workflows for Exiting Users

by Grant Funtila, Technical Writer
How to Standardize Device Reset and Reassignment Workflows for Exiting Users blog banner image

Improperly handled device offboarding may result in data loss, enrollment conflicts, and a security gap. A consistent workflow prevents teams from missing cleanup steps. In addition, using capabilities like the Intune reset device command helps standardize the process.

This guide will outline a structured, documented process using Microsoft Intune and PowerShell to ensure secure and efficient reassignments.

Standardizing device reset and reassignment workflows for users

Standardizing device resets and reassignment workflows involves six steps: choosing the correct reset method, building a structured reset and reassignment runbook, using PowerShell to clean up enrollment artifacts, applying naming conventions, maintaining a governance checklist, and scheduling staff training and reviews.

Note: The examples and scripts in this guide apply to Windows devices managed through Microsoft Intune and Autopilot. Similar principles can be adapted for macOS or other operating systems using their respective MDM platforms.

Step 1: Choose the correct reset method

The table below helps IT teams choose the most appropriate reset type based on the device’s condition and business requirements. This ensures the right balance between speed, security, and manageability.

📌 Use Case: When an employee leaves the company and their laptop is reassigned to the new hire, the IT team can choose an Autopilot reset to retain enrollment and provisioning instead of performing a full data wipe.

Reset typeDescriptionUse case
Full wipeResets the device to factory default, removes all data and enrollmentStolen, lost, or fully decommissioned devices
Fresh startRemoves OEM bloatware while retaining MDM enrollmentInternal devices with cluttered setups
Autopilot resetRemoves user data but retains enrollment and provisioningRedeployment within the same client or team

⚠️ Important: Selecting the wrong reset type may result in unnecessary delays in redeployment. (For more info, refer to: Things to look out for)

Step 2: Build a structured reset and reassignment runbook

This step documents a structured reset and reassignment workflow to ensure every device follows the same lifecycle path from user termination to redeployment readiness.

📌 Use Case: An organization is onboarding multiple contractors while simultaneously offboarding full-time employees. Devices used by the outgoing staff need to be reassigned to the new hires. This step ensures each device is wiped, deregistered, and tracked before being handed off.

TaskDescription
1. Identify user and associated device(s).Confirm which devices belong to the departing users by cross-referencing platforms like Intune or NinjaOne to prevent devices from being overlooked.
2. Select the reset method.Use the reset decision table above to match the reset action to the business context to ensure a balance of security, efficiency, and redeployment readiness.
3. Trigger the reset via Intune or RMM.Initiate the chosen reset action using Intune or NinjaOne. Running the reset from a centralized system ensures visibility and consistency.
4. Rename or tag the device post-reset.Update the device name or apply a tag to filter devices easily when reporting and prevent confusion about readiness.
5. Remove the device from Azure AD, Autopilot, and Intune.Deregister the device to prevent re-enrollment under old profiles and avoid future conflicts. This step is crucial for decommissioned devices being reassigned outside the original team.
6. Update the PSA or asset tracking system.Log the reset, reassignment status, and other documentation directly into the PSA or asset management platform to create an audit trail and keep IT, HR, and compliance teams aligned.
7. Prepare for redeployment.Re-enroll devices being reused with the appropriate baseline configuration to ensure new users receive a secure, fully provisioned device from day one.

Step 3: Use PowerShell with Microsoft Graph to remove Windows Autopilot identities

Removing devices from Windows Autopilot when decommissioning or repurposing hardware is often necessary, so they don’t automatically re-enroll under old profiles.

📌 Use Case: An IT admin is preparing a batch of laptops for resale after an equipment refresh. While a full Intune wipe secures the data, leaving devices registered in Autopilot would cause them to automatically reapply corporate profiles during setup

📌 Prerequisite:

  • Active Intune subscription and a role with permission to delete Autopilot devices (e.g., Intune Administrator).
  • PowerShell 7+.
  • Microsoft.Graph PowerShell SDK installed.
  • Sign in to Graph with DeviceManagementServiceConfig.ReadWrite.All.
  1. Press Win, type PowerShell, then click Run as administrator.
  2. Copy and paste the following script into the prompt, then press Enter:
$ErrorActionPreference="Stop"

if(-not (Get-Command Connect-MgGraph -ErrorAction SilentlyContinue)){Install-Module Microsoft.Graph -Scope CurrentUser -Force -AllowClobber}

Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All" -NoWelcome

$sn=(Get-CimInstance Win32_BIOS).SerialNumber

$id=(Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/deviceManagement/windowsAutopilotDeviceIdentities?`$top=999").value |

Where-Object {$_.serialNumber -eq $sn} | Select-Object -First 1 -ExpandProperty id

if(-not $id){Write-Host "No Autopilot identity for serial $sn"; return}

Invoke-MgGraphRequest -Method DELETE -Uri "https://graph.microsoft.com/v1.0/deviceManagement/windowsAutopilotDeviceIdentities/$id"

Write-Host "Deleted Autopilot identity for $sn"

💡 Note: You’ll need the DeviceManagementServiceConfig.ReadWrite.All permission in Microsoft Graph. Ensure that the signed-in account has Intune Administrator rights or equivalent.

⚠️ Important: Before deploying the settings change on different endpoints, testing it out on a local machine is best. (For more info, refer to: Things to look out for)

Step 4: Apply tagging or naming conventions to track device status

This step ensures devices are tracked accurately and reporting reflects real-world status.

📌 Use Case: A device has been data-wiped and is scheduled for redeployment. Instead of manually tracking it, IT teams can apply the STATUS-WipedReady tag. NinjaOne picks it up to trigger validation scripts and move the device into a “ready-for-reassignment” inventory view.

STATUS-WipedReady

This tag signals that a device is available for redeployment and is applied once a reset or wipe is finished. STATUS-WipedReady can trigger conditional automations like re-enrollment scripts or move the asset into a queue for reassignment.

STATUS-InUse

This tag helps filter inventory reports to focus on devices assigned to users and is assigned to active, deployed endpoints. It ensures active fleet management and faster troubleshooting.

STATUS-DecomPending

Lastly, this tag is for devices that need decommissioning or resale. Automations can exclude these devices from policy pushes, while reporting views keep them visible for tracking until the decommissioning is finalized.

Step 5: Maintain a governance checklist

This step lets IT teams maintain compliance, reduce security risks, and eliminate gaps.

📌 Use Case: A long-term employee is leaving the company, and their laptop is being reassigned to a contractor. This way, the IT team follows a governance checklist that ensures a secure device reset.

ActionDescription
1. Remove from Intune.Ensure the device is unenrolled from Intune to prevent duplicate enrollment issues when reassigned. This process also clears old compliance baselines.
2. Remove from Microsoft Entra ID (formerly Azure AD).Removing the device from Azure Active Directory means it doesn’t appear as a trusted corporate endpoint. This process also closes lingering authentication paths.
3. Delete the Autopilot profile.Remove the associated Autopilot profile on decommissioned or resold devices to prevent it from attempting to auto-enroll with outdated configurations.
4. Trigger the reset.Based on the table above, perform the appropriate reset action to clear user data and ensure the device is clean and secure.
5. Update the asset record.Log the reset action, current lifecycle state, and any notes about reassignment or decommissioning in the asset management system. This process maintains accountability and creates a reliable audit trail.
6. Assign a new user profile or configuration.Apply the correct baseline configuration or reimage the device for redeployment. If reassigned, link it to the new user’s profile for accurate inventory and compliance tracking.

⚠️ Warning: Skipping steps or maintaining an outdated checklist can create security vulnerabilities or cause devices to re-enroll under outdated configurations. (For more info, refer to: Things to look out for)

Step 6: Schedule staff training and quarterly process reviews

This step turns a one-time project into a sustainable governance practice, as regular training and review cycles ensure technicians are confident in their execution.

📌 Use Case: IT manager schedules a quarterly training session to walk technicians through the decision matrix, review updated documentation, and analyze last quarter’s metrics

Train technicians on reset types, tool-specific steps, and documentation locations

This ensures staff understand the differences between a full wipe, a fresh start, and an autopilot reset, and when they should use them. Training can also cover tool-specific executions and where to find supporting documentation or logs.

Review reset metrics quarterly

Analyze performance indicators and review surface bottlenecks, missed steps, or recurring issues that could require process changes.

Update runbooks

Quarterly reviews provide a way to update runbooks so technicians have accurate instructions, since Intune and RMM platforms evolve quickly, introducing new reset options.

⚠️ Things to look out for

RisksPotential consequencesReversals
Selecting the wrong reset typePotentially unnecessary delays in redeployment, lost configurations, or data not fully clearedTrain staff on the decision matrix, require manager review for edge cases, and document the recovery path.
Not testing on a local machineDeploying an untested script may cause devices to crash due to issues such as registry key incompatibility.Apply the changes you want on a local machine, and then verify if the configuration reflects the intended results.
Skipping checklist steps or leaving the checklist outdated after platform changesSecurity gaps, audit failures, and duplicate enrollment issues could cause problems.Enforce checklist completion via the ticketing system and require sign-off before device redeployment.

NinjaOne services that help standardize device resets

Embedding the process above into NinjaOne’s automation and reporting workflows helps reduce variability and improve security posture. You can align the workflow above with NinjaOne using the following platform capabilities:

Script library

NinjaOne’s script library lets IT teams store and manage PowerShell scripts they can use as part of the offboarding workflow. After an Intune reset, these scripts can automatically perform additional steps like deregistering a device from Windows Autopilot.

Standardizing scripts in one place lets organizations ensure technicians follow the same process, eliminating the variability and risk that comes with manual work.

Automation policies

Use policies to automatically apply system settings, enforce configurations, or trigger scripted actions when devices meet specific conditions or compliance states.

Device custom fields

NinjaOne’s device custom fields let teams record additional details such as the last user assigned, reassignment notes, or maintenance dates.

This information improves documentation accuracy, supports compliance tracking, and helps IT maintain visibility into each device’s history.

Tag-based reporting

Applying structured tags lets IT teams filter and generate reports of devices prepared for redeployment. This capability enables bulk actions like assigning devices to new onboarding workflows.

Documentation fields

Embed runbook links, reset logs, or Intune wipe confirmation references into the asset record, giving future technicians a clear audit trail and access to the offboarding checklist.

Ticketing integration

NinjaOne’s ticketing integration ensures precise and efficient offboarding tasks. NinjaOne automatically generates a ticket with a predefined checklist of steps. The ticket can include documentation links, space to capture logs, and checkpoints for each process.

Prevent mistakes by standardizing resets and reassignment processes

Standardizing resets and reassignment processes prevents mistakes, secures data, and accelerates device turnovers across clients. Cleanup scripts, documentation, and lifecycle tagging ensure handoffs are consistent and audit-ready. In addition, using NinjaOne’s automation and reporting workflows reduces variability.

Related topics:

You might also like

Ready to simplify the hardest parts of IT?