How to Map Network Drives in Microsoft Intune Using Custom ADMX Files
Deploy mapped network drives to Entra-joined Windows devices with a community drive-mapping ADMX imported into Intune, with a clear-eyed look at the authentication prerequisites and support caveats most guides skip.
- Difficulty
- Advanced
- Time required
- 30-45 minutes to configure; drives appear at the next user sign-in after policy sync
- Steps
- 8
- Platform
- Intune
Table of contents
Quick Answer
Go to the stepsImport windows.admx + windows.adml into Intune (Devices > Configuration > Import ADMX), then import a community DriveMapping.admx + .adml (windows.admx must be first, or you get a NamespaceMissing error). Create a Templates > Imported Administrative Templates (Preview) profile, go to User Configuration > Network Drive Mapping, enable a drive letter and set its UNC path, then assign the profile to a user group. The drive appears at the user's next sign-in, provided the device can authenticate to the share.
- Confirm the device can authenticate to the share (Entra Kerberos / Hybrid / PHS + line of sight)
- Import windows.admx and windows.adml into Intune first
- Import a reviewed community DriveMapping.admx and .adml
- Create an Imported Administrative Templates (Preview) profile and set the drive letter + UNC path
- Assign to a user group and verify in File Explorer on a target device
Microsoft Intune admin center > Devices > Configuration > Import ADMX → then Devices > Windows > Configuration > Create > New policy > Templates > Imported Administrative Templates (Preview)Expected result: Assigned users see the configured drive letter and share appear in File Explorer after signing in, as long as authentication to the file server is in place.
Key takeaways
- You will import the Windows base ADMX and a community drive-mapping ADMX into Intune, build an Imported Administrative Templates profile that maps a drive letter to a UNC path, assign it to users, and verify it on a device - while understanding the authentication prerequisites that decide whether it actually works.
- Entra-joined (cloud-only) devices have no Group Policy and Intune has no native drive-mapping feature. The ADMX method gives you a clean, GPO-like configuration visible in the Intune UI instead of a maintenance-heavy logon script.
- The ADMX drive-mapping method works and is admin-friendly, but it relies on a third-party template and, above all, on the device being able to authenticate to the share - solve authentication first, then the mapping is easy.
Introduction
On domain-joined PCs, mapped drives came free with Group Policy Preferences. On Entra-joined, cloud-only devices there are no GPOs, and Intune ships no native drive-mapping setting - so admins reach for one of three approaches: a PowerShell logon script, a Win32 app, or importing a custom drive-mapping ADMX into Intune's Import ADMX feature. This tutorial covers the ADMX method, which many admins prefer because the result is visible and editable in the Intune UI, much like the old GPO interface. Two honest caveats up front, because they decide success or failure: the drive-mapping ADMX is a third-party community template, not a Microsoft-provided or Microsoft-referenced file; and mapping a drive is only half the job - the device must be able to authenticate to the file server, which on cloud-only devices requires Microsoft Entra Kerberos, Hybrid Join, or password hash sync plus network line of sight. Get the authentication right and this method is clean and reliable; skip it and the drives simply never connect.
Who this is for: IT admins and MSPs managing Entra-joined or hybrid Windows 10/11 devices that still need access to on-premises SMB file shares.
Before you start
- Access
- Access to the Microsoft Intune admin center with the Intune Administrator or Policy and Profile Manager role, plus the UNC paths and drive letters you intend to deploy and read access to an up-to-date Windows PC to source the Windows ADMX files.
- Required roles
- Intune Administrator or Policy and Profile Manager
- Intune Administrator, or the built-in Policy and Profile Manager role
- Required licenses
- Microsoft Intune (any plan)
- Environment
- Entra-joined or Hybrid-joined Windows 10/11. On-premises SMB file server reachable from the device (LAN or VPN). Working authentication path to the share: Microsoft Entra Kerberos (Windows 10 1903+/11), Hybrid Azure AD Join, or password hash synchronization - Entra-joined devices do not get on-prem Kerberos tickets automatically.
- Vendor
- Microsoft
- Tested environment
- Documented against the Microsoft Intune admin center and Microsoft Learn, July 2026. Not validated in a live tenant - pilot before production.
- Administrator permissions required
Steps documented against Microsoft Learn and the current Intune admin center (July 2026); validate in a pilot before wide rollout.
About 30-45 minutes to configure; drives mount at the user's next sign-in after the policy syncs.
Warning: Authentication is the real prerequisite
Mapping the drive letter is easy; authenticating to the share is the hard part. On cloud-only devices without Entra Kerberos, Hybrid Join, or password hash sync, users get repeated credential prompts or the drive never connects. Confirm your auth path before deploying anything.
Warning: The drive-mapping ADMX is third-party, not Microsoft's
There is no Microsoft-provided or Microsoft-referenced drive-mapping ADMX. The templates come from the community (for example Rudy Ooms / call4cloud). ADMX/ADML are plain XML - open and review them before importing, since importing an ADMX is deploying code to your fleet.
Warning: Not an officially supported use of ADMX import
Microsoft states custom ADMX may only target specific registry locations, and drive mappings under HKCU\Network fall outside that documented set. It works in practice and is widely used, but if you need a fully supported path, use a PowerShell script or Win32 app instead. Keep that fallback in mind.
1Confirm authentication and gather your mapping details
Make sure devices can actually authenticate to the share, and collect what you'll enter into the policy.
Decide and verify your authentication path to the on-premises file server: Microsoft Entra Kerberos, Hybrid Azure AD Join, or password hash synchronization. Confirm target devices have network line of sight to the server (same LAN or an always-on/device-tunnel VPN). Then list each drive letter, its UNC path in \\server\share\optional-folder form (use the FQDN, not NetBIOS), and the user group that should receive it.
Expected result: You can browse the UNC path manually from a signed-in test device without a credential prompt, and you have a table of drive letter, UNC path, and target group.
Note
If you can't reach the UNC path manually, fix authentication and connectivity first - no drive-mapping policy will succeed until this works.
2Obtain the Windows base ADMX files
Get the prerequisite windows.admx and windows.adml that the drive-mapping ADMX depends on.
On an up-to-date Windows 10/11 Pro/Enterprise PC, copy windows.admx from C:\Windows\PolicyDefinitions and windows.adml from C:\Windows\PolicyDefinitions\en-US. Alternatively, download the current Administrative Templates MSI for your Windows version from the Microsoft Download Center and extract them. Keep both files in a working folder.
Copy-Item C:\Windows\PolicyDefinitions\windows.admx, C:\Windows\PolicyDefinitions\en-US\windows.adml -Destination C:\ADMXExpected result: You have windows.admx and its en-US windows.adml ready to upload.
Note
Windows Home editions may lack these files - use a Pro/Enterprise machine or the Download Center MSI. Only the en-US ADML is supported by Intune.
3Obtain and review the community drive-mapping ADMX
Get a working DriveMapping.admx/.adml and confirm it's safe and compliant before import.
Download a community drive-mapping template (for example Rudy Ooms' DriveMapping ADMX on call4cloud, or a comparable one). Open both files in a text editor: the .admx should declare its own namespace and reference Microsoft.Policies.Windows, and its policies should target HKCU\Network\<drive>-style keys with a class="User". Confirm the file is under 1 MB and has a single en-US ADML.
Expected result: You have a reviewed DriveMapping.admx and matching en-US .adml that you understand and trust.
Note
Reviewing is not optional: you're deploying this to every targeted device. If a template uses an unsupported registry area, Intune may accept the upload but fail to apply it on devices.
4Import the ADMX files in the correct order
Upload the templates so Intune exposes their settings, respecting the dependency.
Devices > Configuration > Import ADMX > ImportIn the Intune admin center, go to Devices > Configuration > Import ADMX (or Devices > Windows > Manage devices > Configuration > Import ADMX). Click Import, upload windows.admx with its windows.adml, and wait for the status to show Available. Then click Import again and upload DriveMapping.admx with its .adml.
Expected result: Both templates appear on the Import ADMX tab with an Available status.
Note
Order matters. If you upload DriveMapping.admx first you get: 'ADMX file referenced not found. NamespaceMissing:Microsoft.Policies.Windows. Please upload it first.' Import limits: 20 ADMX files total, 1 MB each, one en-US ADML per ADMX.
5Create an Imported Administrative Templates profile
Start the configuration profile that will carry the drive-mapping settings.
Devices > Windows > Configuration > Create > New policy > Templates > Imported Administrative templates (Preview)Go to Devices > Windows > Configuration > Create > New policy. Set Platform to Windows 10 and later and Profile type to Templates, then choose Imported Administrative templates (Preview) and click Create. On Basics, name the profile so its purpose is obvious - include the drive letter and target group, e.g. Drive H: - Marketing Share - and click Next.
Expected result: You reach the Configuration settings tab showing the imported drive-mapping category.
Note
Create one profile per drive. Unlike GPO Preferences, these policies have no item-level targeting, so per-drive profiles let you assign each drive to the right group.
6Configure the drive letter and UNC path
Set the actual mapping using the imported template.
Configuration settings > User Configuration > Network Drive Mapping > (drive letter) > EnabledOn Configuration settings, switch to User Configuration and expand the drive-mapping category (often Network Drive Mapping). Select the drive letter you want and set it to Enabled, then enter the UNC path exactly, using the FQDN. If your template exposes options like reconnect/persistent or a DFS/ProviderFlags toggle, set them as needed. Click Next.
Expected result: The chosen drive letter shows Enabled with your UNC path configured.
Note
The mapped drive's display name comes from the share's own folder name, so name your SMB shares the way you want users to see them. Escape special characters in paths (& and ') if the template requires it.
7Assign the profile to a user group
Target the right users - this is a user-scoped policy.
Assignments > Add groupsOn Assignments, add the Microsoft Entra security group of users who should get this drive (ideally the same group that has permission to the share). Start with a small pilot group. Continue through Scope tags (optional) and Review + create, then click Create.
Expected result: The profile is created and begins deploying to the assigned users.
Note
Because the settings are User class, assign to user groups. Matching the assignment group to the share-permission group keeps access and mapping in sync.
8Verify the mapping on a target device
Confirm the policy applied and the drive actually mounts.
On a target device, force a sync (Settings > Accounts > Access work or school > Info > Sync, or from Intune) and have the user sign out and back in. Open File Explorer to see the drive. To confirm the mechanics: imported templates register under HKLM\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled and AdmxDefault, and the live mappings appear under HKCU\Network\<drive>. net use lists the connections.
net useExpected result: The drive letter and share appear in File Explorer and in net use output, and the HKCU\Network key exists for the drive.
Note
Allow for policy sync timing (often 15-30 minutes, up to a few hours). If the profile shows success in Intune but no drive appears, jump to Troubleshooting - it's almost always authentication.
How to Confirm the Drive Mapping Is Actually Working
Confirm configuration
A working deployment shows three things: in Intune, the profile's per-user check-in reports Succeeded; on the device, the drive appears in File Explorer and in net use, backed by an HKCU\Network\<drive> registry key; and the imported templates are present under HKLM\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled. The most important thing to internalize is that Intune reporting 'Succeeded' only means the policy reached the device - not that the drive connected. Authentication happens on the client at sign-in, so a green status in Intune with no drive on the device is the classic signature of a missing Entra Kerberos / Hybrid / PHS path or no line of sight to the server, not a policy failure. Test with a real user account, after a full sign-out and sign-in, on a device that can reach the share.
Normal result: Profile 'Succeeded' in Intune, drive visible in File Explorer and net use, HKCU\Network\<drive> present, no credential prompt.
Abnormal result: Profile 'Succeeded' but no drive, a credential prompt at every logon, or 'The local device name is already in use' after reboot - all point to authentication or reconnect handling rather than the policy itself.
HKCU\Network\H
Live mapping present
Confirms the drive was actually mounted for the user, not just that the ADMX was installed.
net use
Drive listed as OK
A 'Disconnected' or missing entry usually means an authentication or connectivity failure.
Troubleshooting
Upload fails: NamespaceMissing:Microsoft.Policies.Windows
Warning
Cause: The drive-mapping ADMX depends on the Windows namespace, and windows.admx wasn't imported first.
Delete the failed upload, import windows.admx and windows.adml, wait for Available, then import the DriveMapping ADMX and its ADML.
ADMX uploads but the drive never maps on devices
Warning
Cause: The template targets a registry area outside Intune's supported ADMX ingestion locations, or the ADMX is malformed.
Try a known-good community template; if it still fails, switch to a PowerShell script or Win32 app for the mapping, which don't have the registry-location restriction.
Users are prompted for credentials at every sign-in, or the drive won't connect
Warning
Cause: The cloud-only device has no way to authenticate to the on-prem share - no Entra Kerberos, no Hybrid Join, no password hash sync, or no line of sight to the server.
Implement Microsoft Entra Kerberos (or Hybrid Join / PHS) and ensure LAN/VPN connectivity to the file server; verify you can browse the UNC path manually before blaming the policy.
'The local device name is already in use. The connection has not been restored' after reboot
Note
Cause: A known reconnect-handling issue with ADMX-mapped drives on cloud-joined devices.
Ensure reconnect/persistent (ProviderFlags) is set in the template, and if it persists, deploy a small remediation that re-establishes the mapping at logon.
DFS namespace shares don't map on Entra-joined devices
Note
Cause: Entra-joined devices can't resolve DFS namespaces the way domain-joined devices do.
Map directly to the target server and share instead of the DFS path, or use a template that sets ProviderFlags=1 for DFS handling.
Policy shows 'Not Applicable' on Azure Virtual Desktop / multi-session
Note
Cause: User-scoped imported ADMX has limited applicability in multi-session environments.
Use a PowerShell logon script for multi-session hosts; keep the ADMX method for single-user physical devices.
Frequently asked questions
Is mapping drives with custom ADMX officially supported by Microsoft?
The ADMX import feature is official, but drive mapping through it is not a Microsoft-supported scenario: custom ADMX may only target certain registry areas, and HKCU\Network drive mappings fall outside them. It works in practice and is widely used, but keep a PowerShell or Win32 fallback if you need a supported path.
Where does the DriveMapping ADMX come from?
From the community - most notably Rudy Ooms (call4cloud), with variants from other authors. It is not provided or referenced by Microsoft. Because you're deploying it fleet-wide, open and review the XML before importing.
Why must windows.admx be imported before the drive-mapping ADMX?
The drive-mapping ADMX references the Microsoft.Policies.Windows namespace defined by windows.admx. Import it first, or the upload fails with 'NamespaceMissing:Microsoft.Policies.Windows.'
Should I assign the profile to user groups or device groups?
User groups. The drive-mapping settings are User class, so assign to Entra security groups of users - ideally the same group that has permission to the share.
Why do the drives fail on pure Entra-joined devices?
Almost always authentication. Entra-joined devices don't automatically get Kerberos tickets for on-prem servers, so without Entra Kerberos, Hybrid Join, or password hash sync (plus network reach), the share can't authenticate and the drive won't mount.
Can I map DFS namespace shares this way?
Not straightforwardly on Entra-joined devices, which don't resolve DFS namespaces like domain-joined ones. Map directly to the server and share, or use a template that sets ProviderFlags for DFS.
Conclusion
You imported windows.admx first, then a reviewed community DriveMapping ADMX, built an Imported Administrative Templates (Preview) profile that enables a drive letter and UNC path under User Configuration, and assigned it to a user group. The result is a clean, GPO-like drive mapping visible in the Intune UI. The deciding factor isn't the policy - it's authentication: with Entra Kerberos, Hybrid Join, or password hash sync and line of sight to the server, the drives mount at sign-in; without it, they never will. Treat this as a bridge while you plan a move of the data to SharePoint or OneDrive.
The ADMX drive-mapping method works and is admin-friendly, but it relies on a third-party template and, above all, on the device being able to authenticate to the share - solve authentication first, then the mapping is easy.
Devices > Configuration > Import ADMX → Devices > Windows > Configuration > New policy > Templates > Imported Administrative Templates (Preview) > User Configuration > Network Drive MappingSources5
