Windows - Configuration - Map Network Drive via Scheduled Task

What the network drive mapping Worklet does

This Automox Worklet™ creates a Windows scheduled task that maps a network drive each time a user logs on. The Automox agent runs as NT AUTHORITY\SYSTEM, and network drives belong to the interactive user session, so the Worklet hands the mapping off to a scheduled task with a logon trigger instead of running net use directly from the agent. The task fires once per user logon and resolves the share under that user's token.

The remediation script registers a task named "Map Network Drive" with Register-ScheduledTask, attaches a logon trigger scoped to the BUILTIN\Users group, and writes a small PowerShell payload to C:\Windows\Temp\MapNetworkDrive.ps1. That payload calls New-PSDrive with the -Persist flag against the configured UNC path and drive letter, so the mapping survives reboots and appears in File Explorer under "This PC" with the standard network-drive icon.

Every run is logged to C:\ProgramData\amagent\WorkletCache\WSE-339\MapNetworkDrive.log, including the resolved UNC path, the chosen drive letter, the exit status of New-PSDrive, and any access-denied or path-not-found errors returned by the file server. The log is the first stop when a user reports that their drive is missing after a reboot.

Why map drives through a scheduled task instead of Group Policy

Group Policy Preferences and AD logon scripts are the historical answer to persistent drive mapping, and both assume an on-premises domain controller that every endpoint can reach at logon. Hybrid-joined laptops on residential Wi-Fi, Entra-only endpoints, contractor machines, and standalone field devices never see that DC at the moment they need it. The result is a fleet where some users get the H: drive automatically, others get it sporadically, and the help desk maps it manually for everyone else.

A scheduled task with a logon trigger removes the domain dependency. New-PSDrive runs locally under the user's session, the share is contacted directly over SMB, and the mapping persists because the -Persist flag writes it into the user's HKEY_USERS\<SID>\Network hive. The Worklet re-validates that registry state on each evaluation pass, so drift on a single endpoint is corrected without anyone opening a remote session.

How scheduled task drive mapping works

1. Evaluation phase: The Worklet walks HKEY_USERS and inspects each loaded user hive at Network\<DriveLetter>. For every SID, it reads the RemotePath value and compares it to the configured UNC path. The endpoint is compliant only when every interactive user already has the drive letter mapped to the exact UNC string. A missing drive letter, a different RemotePath, or a stale mapping pointing at an old file server all flag the endpoint non-compliant and trigger remediation.

2. Remediation phase: The script validates that $driveLetter is a single A–Z character, creates C:\ProgramData\amagent\WorkletCache\WSE-339\ for logging, and unregisters any prior "Map Network Drive" task with Unregister-ScheduledTask -Confirm:$false. It then writes the New-PSDrive payload to C:\Windows\Temp\MapNetworkDrive.ps1 and calls Register-ScheduledTask with a New-ScheduledTaskTrigger -AtLogOn trigger, a Users-group principal, and an action of powershell.exe -NonInteractive -WindowStyle Hidden -NoProfile -ExecutionPolicy Bypass -File against the payload. The payload itself runs Test-Path against the UNC before calling New-PSDrive -Persist, so a temporarily unreachable share is logged and skipped rather than mapped as a broken letter. The drive appears at the next interactive logon, when the task fires and the mapping is written into the user's hive.

Persistent drive mapping requirements

• Windows 10, Windows 11, Windows Server 2019, or Windows Server 2022 with the Task Scheduler service running

• Windows PowerShell 5.1 or later, with the ScheduledTasks and Microsoft.PowerShell.Management modules available (default on supported OS versions)

• Network reachability over SMB (TCP 445) from the endpoint to the file server at logon time; VPN-only shares need a pre-logon tunnel or the task will fail until connectivity is restored

• Share permissions plus NTFS permissions that grant each target user at least Read on the share – the task runs as the logged-on user, not as SYSTEM

• Set $driveLetter to a single uppercase letter (A–Z) that is not already claimed by a local volume or another mapping

• Set $uncPath to the full UNC path, including the share name (\\fileserver01.corp.local\Finance, not just \\fileserver01.corp.local)

Expected state after the scheduled task is registered

Immediately after remediation, the task "Map Network Drive" exists in the root folder of Task Scheduler with an At log on trigger, a Users-group principal, and a Ready state. The drive letter is not visible yet because no logon event has fired the task. On the next interactive logon, the task runs, New-PSDrive writes the mapping into HKEY_USERS\<SID>\Network\<DriveLetter> with the correct RemotePath, and the drive appears in File Explorer with the Persist flag set.

Validate end to end by signing out and back in, then running these checks from an admin PowerShell window: Get-ScheduledTask -TaskName 'Map Network Drive' for task state, Get-PSDrive -PSProvider FileSystem for the live mapping under the current user, net use for the legacy view, and Get-Content C:\ProgramData\amagent\WorkletCache\WSE-339\MapNetworkDrive.log for the New-PSDrive exit detail. The most common failures recorded in that log are exit code 67 (network name not found, usually a typo in $uncPath), exit code 5 (access denied, almost always a share-permission mismatch), and exit code 1219 (multiple credentials to the same server, which clears once the conflicting cached credential is removed with cmdkey /delete). Subsequent Automox evaluation runs find the mapping already present in the user hive and report the endpoint compliant without re-registering the task.