Legacy LAPS vs Windows LAPS: Cutover, Coexistence and Permission Cleanup

Most estates that installed the legacy Microsoft LAPS MSI years ago now run two password managers for one local administrator account, plus a clear-text attribute that every old delegation can still read. Microsoft states that the legacy product is deprecated as of Windows 11 23H2, that newer Windows versions block its installer, and that it no longer considers code changes for it. Windows LAPS, shipped in the 11 April 2023 Windows updates, is a separate native implementation,, and the two interact in ways that surprise people during a cutover. This guide is a migration comparison for directory, endpoint and privileged access teams: what changes between the two, how to choose a cutover path, how to switch on encryption without locking yourself out, and how to clean up who can read passwords afterwards. For Windows LAPS settings, event IDs and the full permission model see the Local Administrator Password Solution (LAPS) Guide; this page does not repeat them.

Key takeaways

• The short answer is Windows LAPS everywhere it is supported. Legacy LAPS stays only on Windows versions that cannot run Windows LAPS, and only until those versions leave support, which Microsoft says is when legacy support ends too.
• One account, one manager. Microsoft does not support a Windows LAPS policy and a legacy policy targeting the same account; pick an immediate cutover on the same account or a short side-by-side with a second account.
• The installed client side extension decides more than the policy. While AdmPwd.dll is registered, Windows LAPS defers to legacy LAPS and emulation mode is off; once a Windows LAPS policy exists, it always wins over legacy policy.
• Encryption is a one-way door per password. The decryptor principal cannot be changed for a password once it is encrypted, so build the decryptor group before the first policy reaches a device.
• Migration is not finished until the old readers are gone. Stale ms-Mcs-AdmPwd values and old "All extended rights" grants keep exposing passwords long after the MSI is removed.

What actually differs, in one table

Threat model of staying on legacy LAPS

Architecture in words: the client side extension runs at Group Policy refresh, generates a password for one local account, and writes it in clear text to a confidential attribute on the computer object. Anyone with read access to that attribute, granted directly or through extended rights, can read every password in the OU. There is no second key, no history, and no record of the read unless directory service access auditing is configured.

• Reader sprawl is the main threat. Delegations made when the MSI was first deployed, often to desktop support or a deployment service account, are rarely revisited. A compromised member of any such group holds local administrator on every device in scope, the path described in T1078.003 Local Accounts.
• Clear text in backups. Every AD backup and every offline copy of ntds.dit carries current local administrator passwords in readable form, so the backup estate inherits tier 0 sensitivity for workstations.
• No bound on the life of a disclosed password. A password read for a support call stays valid until its scheduled expiry, typically 30 days, unless someone expires it by hand.
• Silent drift on new builds. Because newer Windows versions block the MSI, devices built from new images are either unmanaged or quietly fall into emulation mode, depending on whether a Windows LAPS policy exists.

Threat model of Windows LAPS done badly

Architecture in words: a native task reads the first policy root that has any setting, generates a password, encrypts it to one principal if configured, and writes it to AD or Entra ID. Reads are governed by AD ACLs plus the decryptor principal, or by Entra roles.

• Decryptor collapse. If ADPasswordEncryptionPrincipal is left unset, passwords are encrypted so that only Domain Admins can decrypt them. Teams then add help desk staff to Domain Admins, widening tier 0. Microsoft recommends a wrapper group when several principals need to decrypt.
• Cloud role exposure. In Entra ID, any holder of microsoft.directory/deviceLocalCredentials/password/read can recover the password. Conditional Access can be scoped to the built-in roles, but Microsoft states that administrative unit scoped roles and custom roles are not supported for that purpose, so least-privilege custom roles trade off against Conditional Access coverage.
• Recovery loss. Deleting an Entra device object loses its LAPS password with no recovery in Entra ID. Image rollback detection is not supported for Entra backup.
• Plain-text Windows LAPS. Windows LAPS can still write msLAPS-Password in clear text when encryption is off, which reproduces the legacy exposure under a new attribute name.
• Emulation as a destination. Emulation mode keeps clear-text storage in ms-Mcs-AdmPwd with no encryption or Entra support. Microsoft describes it as a transition aid and recommends native Windows LAPS.

How the two coexist on one device

Microsoft's documented precedence rules reduce to five cases.

Microsoft defines "installed" narrowly: legacy LAPS counts as installed when the DllName value under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA} points to a file that exists on disk. The file is not loaded or verified, so a leftover DLL with a broken registration still blocks emulation mode. During operating system deployment, emulation can start the moment legacy policy lands; setting BackupDirectory to 0 under HKLM\Software\Microsoft\Windows\CurrentVersion\LAPS\Config prevents that until a real Windows LAPS policy arrives. Intune adds one more rule: the CSP-based policy overrides all other LAPS sources, including Group Policy and legacy LAPS. See the Group Policy to Intune Migration.

Choosing a cutover path

Microsoft documents two paths. The choice depends on how much you trust your ability to retrieve the new password on day one.

Decision rule: use the immediate path for Windows clients once a pilot ring proves backup and retrieval, because it never creates a second privileged account. Use side-by-side for servers whose console access is hard to reach, and give the extra account a removal date in the change record. Microsoft notes that if Windows LAPS targets a different account it must already exist, because Windows LAPS does not create it unless automatic account management is enabled.

Switching on encryption and DSRM without locking yourself out

1. Confirm the floor. Encryption needs a Windows Server 2016 domain functional level. DSRM backup additionally needs domain controllers on Windows Server 2019 or later; older DCs in a 2016 DFL domain are skipped.
2. Create the decryptor groups first. One wrapper group per tier (workstations, servers, domain controllers). Microsoft notes that an invalid principal name causes a policy processing failure and no backup, so validate the name format (SID, domain\name or UPN) in a pilot.
3. Decide history. ADEncryptedPasswordHistorySize ranges from 0 to 12 and defaults to 0. A small history lets you sign in to a device restored from an older snapshot; history is only available with encryption.
4. Grant self permission, never self decrypt. Set-LapsADComputerSelfPermission gives devices the write and read they need for history. Microsoft recommends never granting a managed device permission to decrypt any password, including its own.
5. Domain controllers last, and separately. ADBackupDSRMPassword defaults to off, requires encryption, is not available through the CSP, and on DCs the decryptor always defaults to Domain Admins. Microsoft also notes that any DC's current DSRM password is retrievable while at least one DC in the domain is reachable, which is useful in recovery and is a reason to keep decrypt rights at tier 0. See the AD Domain Controller Hardening Guide.
6. Test offline recovery. Get-LapsADPassword supports a RecoveryMode retrieval from a mounted AD backup; include it in the forest recovery exercise. See the Active Directory Forest Recovery Runbook Template.

Phased migration plan

1. Inventory. Query computer objects for non-empty ms-Mcs-AdmPwd, msLAPS-PasswordExpirationTime and msLAPS-EncryptedPassword to see which product last wrote each device. Collect the GPExtensions DllName value and Windows build from endpoint management to find where the CSE is still registered.
2. Prepare the forest. Run Update-LapsADSchema once per forest. Leave the legacy schema in place: AD schema attributes cannot be deleted, and the legacy cmdlets still need it while the MSI exists anywhere.
3. Clean read rights before anything else. Run Find-LapsADExtendedRights on every OU holding managed computers. Microsoft warns that holders of extended rights can read confidential attributes, and all Windows LAPS password attributes are confidential; the same grants expose ms-Mcs-AdmPwd. Remove everything beyond SYSTEM, Domain Admins and the intended tier groups. See the Active Directory ACL and Delegation Hygiene Guide.
4. Turn on read auditing. Run Set-LapsADAuditing on each OU for the reader groups, enable Audit Directory Service Access on domain controllers, and baseline 4662 volume before the cutover so post-migration anomalies stand out.
5. Pilot ring. Apply the Windows LAPS policy to a test OU or Intune group. Expect an immediate rotation. Confirm 10018 or 10029, retrieve with Get-LapsADPassword or Get-LapsAADPassword from a privileged access workstation, and sign in at the console with the retrieved password.
6. Broad rings. Expand by OU or device group. Remove the legacy GPO link for each ring at the same time as the Windows LAPS policy is applied. Track devices that log 10005 (processing failed) or 10023 (still on legacy policy).
7. Remove the software. Uninstall the MSI (product code {97E2CA7B-B657-4FF7-A6DB-30ECC73E1E28}) or unregister and delete AdmPwd.dll where it was copied manually, checking the DllName value for non-standard paths.
8. Clear the old attribute. Once a device shows a current Windows LAPS backup, clear its ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime values so old passwords stop being readable, then remove the legacy ACL grants and the legacy ADMX templates from the central store.

Rollback: remove the Windows LAPS policy from the affected scope and restore the legacy GPO link. This only works while the CSE is still installed or emulation mode is acceptable, so keep the MSI on a ring until it has passed at least one full rotation cycle. Remember that changing PasswordAgeDays neither shortens the current password's expiry nor forces a rotation; use Reset-LapsPassword or Set-LapsADPasswordExpirationTime when a ring needs a fresh password.

Read-permission cleanup after cutover

The cutover moves passwords to new attributes; it does not move people. Rebuild the reader model rather than copying the legacy one.

The local administrator account and the groups that read it are identity problems as much as endpoint ones: a reader group is a standing privilege, and a script that reads LAPS passwords is a non-human identity with fleet-wide reach. Put both through access review. See the Tiered Administration and Enterprise Access Model Guide.

Worked scenario

A hybrid organisation has 8,000 Windows 11 clients, 600 Windows Server 2019 and 2022 servers and 12 domain controllers, with the legacy MSI deployed by Configuration Manager and a single "IT-LAPS-Read" group on the workstation and server OUs. New Windows 11 24H2 images fail to install the MSI, so 900 recent laptops have no managed password at all.

• Weeks 1 to 2: schema update, Find-LapsADExtendedRights across all OUs, which finds and removes a former deployment service account grant on the server OU, Set-LapsADAuditing on every OU.
• Week 3: clients move to Intune LAPS with BackupDirectory 1 to Entra ID, using the immediate path, since the CSP overrides the legacy GPO anyway. The 900 unmanaged laptops are the first ring. Help desk receives a custom Intune role for rotation and Cloud Device Administrator scoped to a client administrative unit.
• Weeks 4 to 6: servers stay on AD backup with encryption, history of 3 and a server-tier decryptor group. Twenty hard-to-reach servers use side-by-side for a month.
• Week 7: DSRM backup on the domain controllers, decrypt rights left with Domain Admins only, offline recovery tested from a mounted backup.
• Week 8: MSI removed, ms-Mcs-AdmPwd cleared on all objects, IT-LAPS-Read deleted, side-by-side accounts removed.

A small organisation with only Entra joined devices and no AD has nothing to migrate in the directory: apply an Intune LAPS policy, enable LAPS in Entra device settings, and remove the MSI if any old images carried it.

Detection and measurement

• Legacy exposure: computer objects with a non-empty ms-Mcs-AdmPwd. Target zero at programme close.
• CSE residue: devices where the GPExtensions DllName still resolves to a file. Target zero; any value blocks emulation and indicates the MSI remains.
• Emulation population: devices logging 10023. Should only appear transiently during rollout.
• Coverage: share of Windows devices with a Windows LAPS backup newer than PasswordAgeDays. Target above 98 percent.
• Reader population: accounts able to read or decrypt per tier, before and after. The number should fall.
• Read anomalies: 4662 events on LAPS attributes from accounts outside reader groups, bulk reads across many objects, and Entra "Recover device local administrator password" events outside help desk hours. See the Windows Event Log Guide.

Common failure patterns

• Removing the MSI before the policy lands: the device drops into emulation mode or, with no legacy policy left, is unmanaged, keeping whatever password it had.
• A partial Windows LAPS GPO: because roots do not merge, a GPO that sets only one value makes every other setting fall back to defaults, including BackupDirectory 0, which disables backup.
• Encrypting to the default principal: passwords end up decryptable only by Domain Admins, and fixing it later does not re-key passwords already encrypted.
• Old scripts that reset the local admin password: Windows LAPS blocks them with 10031, and the team switches off the policy instead of retiring the script.
• Leaving the clear-text attribute: devices that missed rotation still accept the password in ms-Mcs-AdmPwd, so the old exposure persists.
• A permanent second account: the side-by-side account is never removed and becomes an unmanaged local administrator once legacy LAPS is uninstalled.

Framework mapping

Practitioner checklist

• Inventory which product last wrote each computer object and where the legacy CSE is still registered.
• Run Find-LapsADExtendedRights on every managed OU and remove stray extended rights before cutover.
• Create per-tier read and decrypt groups and validate the ADPasswordEncryptionPrincipal value in a pilot.
• Choose the immediate path for clients and side-by-side only where lock-out risk justifies a second account, with a removal date.
• Build complete Windows LAPS policies, with BackupDirectory set explicitly, because roots never merge.
• Turn on Set-LapsADAuditing and directory service access auditing before the first ring.
• Enable DSRM backup on Windows Server 2019 and later DCs and test RecoveryMode retrieval.
• Uninstall the MSI, then clear ms-Mcs-AdmPwd and legacy ACLs and ADMX files.
• Track legacy exposure, CSE residue, emulation population and reader counts to zero or target.

Standards and references

• Microsoft Learn: Migrate to Windows LAPS from legacy LAPS
• Microsoft Learn: Legacy Microsoft LAPS emulation mode
• Microsoft Learn: What is Windows LAPS?
• Microsoft Learn: Windows LAPS concepts overview
• Microsoft Learn: Configure policy settings for Windows LAPS
• Microsoft Learn: Get started with Windows LAPS and Windows Server Active Directory
• Microsoft Learn: Windows LAPS in Microsoft Entra ID
• Microsoft Learn: Intune support for Windows LAPS

Related NHI Mgmt Group resources: Local Administrator Password Solution (LAPS) Guide · LAPS vs PAM Vaulting · Active Directory and Entra ID Hardening Guide · Credential Dumping Guide