Windows
View all Worklets
WindowsWindows

Disconnect Mapped Drives

Disconnect stale mapped network drives from every user profile on Windows endpoints

Worklet Details

What the mapped drive disconnection Worklet does

This Automox Worklet™ disconnects targeted mapped network drives from every user profile on a Windows endpoint by editing the per-user Network registry key under HKEY_USERS. Mapped drives are persistent network connections that appear as drive letters in File Explorer and survive reboots through entries written to each user's ntuser.dat hive. When a file server is decommissioned, an internal share is relocated, or a vendor relationship ends, those persistent mappings stay attached to every profile that ever touched the share and keep attempting reconnection on each logon.

The Worklet uses Get-CimInstance against Win32_UserAccount to enumerate local and cached domain users, mounts HKEY_USERS as a PSDrive, and uses reg load to attach each user's ntuser.dat into HKU under their SID. It scans the Network subkey for any drive letters listed in the $removeDrives array and removes the matching registry keys directly. The approach reaches profiles that are not currently signed in, which net use * /delete /yes cannot do because net use only operates on the calling user's session.

You set the drive letters to clear by editing the $removeDrives = @("Y","Z") line at the top of both evaluation.ps1 and remediation.ps1; the default value is @("") and the two arrays must match for the policy to behave consistently. Evaluation gates on Windows 8 or later by checking [System.Environment]::OSVersion.Version.Major and exiting 0 on older releases. Both scripts skip profiles where C:\Users\<name>\ntuser.dat is absent, which avoids loading service and system accounts. Remediation writes a per-drive Write-Output line in the form "User: <name>, drive <letter> disconnected." so policy logs show exactly which user and which letter was cleared.

Why clear stale mapped drives at fleet scale

Persistent mapped drives are a credential and access vector. Every cached mapping is a reconnect attempt against the listed UNC path on the next logon, and stale mappings to decommissioned servers can be redirected by an attacker who claims the abandoned hostname or DNS record. Persistent connections also slow logon as Explorer waits on reconnect timeouts to shares that no longer answer, generate noisy event log entries on every session, and confuse end users into emailing the help desk about drives that should not be there.

CIS Benchmarks for Windows recommend removing unused network shares as part of baseline hardening, and the principle of least privilege requires that revoked share access actually disappear from the endpoint. Group Policy preferences can map drives at logon, but unmapping them at scale across both signed-in and offline profiles is exactly the last-mile remediation that GPO does not handle cleanly. Scheduling this Worklet against a Windows endpoint group lets you sweep every workstation in the fleet on the same evaluation cycle, including endpoints whose primary user is offline at the time of policy execution.

How mapped drive removal works

  1. Evaluation phase: The Worklet enumerates user accounts with Get-CimInstance -ClassName Win32_UserAccount, mounts HKEY_USERS as the HKU PSDrive, and iterates each profile. For every account where C:\Users\<name>\ntuser.dat exists, it runs reg load HKU\<sid> to attach the hive, then reads HKU:\<sid>\Network and compares the child key names against $removeDrives. The script exits 1 the moment it finds a single matching drive letter on any profile, which keeps evaluation fast on endpoints with many users and triggers remediation. It exits 0 if no profile contains a matching mapping.

  2. Remediation phase: The remediation script repeats the enumeration but does not exit early. For each matching profile it runs Remove-Item HKU:\<sid>\Network\<letter> for every drive letter in $removeDrives that is present, wrapped in a try/catch so a locked registry key on one profile does not abort the others. Each removal writes "User: <name>, drive <letter> disconnected." to the activity log so the policy run produces a per-user, per-letter audit trail. The script finishes by running Remove-PSDrive -Name HKU to release the HKU mount.

Mapped drive disconnection requirements

  • Windows 8 or later, including Windows 10, Windows 11, and Windows Server 2012 R2 and above

  • PowerShell 3.0 or later (the Automox agent already runs as 64-bit elevated PowerShell)

  • Local administrator privileges to mount HKEY_USERS, run reg load, and delete keys under another user's hive

  • Set $removeDrives at the top of both evaluation.ps1 and remediation.ps1, for example $removeDrives = @("Y","Z"); the two arrays must match

  • Target users must have a writable ntuser.dat under C:\Users\<name>\; roaming profiles redirected to a network path are skipped if the hive is not present locally at evaluation time

Expected endpoint state after disconnection

Registry changes apply immediately. The Network subkey under each affected user's hive no longer contains the cleared drive letters, and the next interactive logon for that user will not attempt to reconnect the share. The visible drive letter in File Explorer for the currently signed-in user may persist with a red X until the user signs out and back in or the endpoint reboots, because Explorer caches the mapped-drive view for the active session. Get-PSDrive -PSProvider FileSystem in a fresh PowerShell session reflects the cleared state without a reboot.

On the next scheduled evaluation, the endpoint reports compliant because the Network subkey no longer contains a child matching $removeDrives. If a user re-creates the same mapping through net use, the Map Network Drive wizard, or a logon script, the Worklet detects and removes it again on the following run, which is the intended enforcement loop. To validate, sign in as one of the affected users after a reboot and confirm the drive letter is absent from File Explorer and from Get-PSDrive output. From an admin shell, run reg load HKU\Validate C:\Users\<name>\ntuser.dat and inspect HKU:\Validate\Network to confirm the cleared letters are not present as subkeys, then release the hive with reg unload HKU\Validate. Cross-reference the policy activity log Write-Output lines against the targeted user list to confirm every active profile was processed.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets