Managing Network Drive Mappings with Intune

One of the current challenges when moving from group policy to MDM with Intune is the lack of support for group policy preferences (GPP).  Apart from the ability to configure preferences which the user can override/customise it also has some other useful features such as network drive mappings.  There isn’t any native support for doing this within Intune today although there are some great alternative solutions already documented by some MVPs and members of the MEM community.  These solutions typically use a combination of PowerShell, Scheduled Tasks, etc. to map the drives at windows sign-in.

In this post, I am going to share another way of mapping drives on Intune-managed Windows 10 devices without using anything other than MDM policy.  Yes… network drive mappings without PowerShell 😊.  The main requirements I had when I developed this solution were:

  • Configure the drive mappings directly in Intune
  • Control assignment of drive mappings via Azure AD groups
  • Easily change/remove mappings without having to edit/re-deploy scripts
  • Create mapped network drives without requiring network connectivity to the remote path
  • Ensure mapped drives switch from “offline” to “online” when connectivity to the remote path is available

About Network Drive Mappings

When a network drive mapping is marked as persistent the configuration is stored in the registry. This is so that the drive mappings can be rebuilt at each user sign-in. It is possible to configure network drive mappings by simply creating the required registry keys/values.  Understanding this then opens up other mechanisms to configure the mapped drives without any dependency on network connectivity to the remote path.  This is particularly useful in a scenario where users will enrol devices on the internet without any connectivity to the on-premises network or with a VPN connection which may not be available immediately after enrolment.

Network drive mappings are stored in the HKCU\Network registry hive.  There is a subkey for each mapped drive with a number of registry values within each key.

Patch My PC
Managing Network Drive Mappings with Intune 1
Registry settings for network drive mappings
Value NameTypeDescriptionDefault Value
Connection TypeREG_DWORDThe type of connection – for drive redirection the value will be 1 and if it is print redirection the value will be 2.
DeferFlagsREG_DWORDIndicates whether the drive needs to be connected immediately at sign-in. If the mapped drive credential is the same as that of the logged on user or the credentials have been saved the value will be 4. If it is an alternative credential and the password has not been saved the value will be 1.4
ProviderNameREG_SZThe name of the network provider being used to connect to the network drive.Microsoft Windows Network
ProviderTypeREG_DWORDWhat type of Provider is used. For the Microsoft LanMan Provider the value will be 0x002000.0x002000 (8192)
RemotePathREG_SZUNC path to the share.
UserNameREG_SZThe username used to connect to the share. If the current user credentials are used then the value will be blank.

All but one of registry keys are the same for each mapped drive.  The RemotePath value needs to be set to the correct remote path (UNC) for each drive.

If you are happy using PowerShell to manage the drive mappings then you could just create the appropriate registry keys and values using PowerShell.  Using this method you could deploy a PowerShell script via Intune (user context) without having to worry about whether the user will have network connectivity to the on-premises network at the time when the script is executed on the client.

ADMX-Backed Policy

However, there is also a way of creating the required registry keys and values via MDM policy thanks to ADMX backed policy support 😊.  I won’t go into the full details of ADMX-backed policy, if you want more insights into this then there is some great documentation on docs.microsoft.com:

1E Nomad

Understanding ADMX-backed policies – Windows Client Management | Microsoft Docs

The ADMX-backed policy is the underlying mechanism used by the Administrative Templates configuration profile template in Intune.  In addition to the settings available natively via Administrative Templates you can also configure other settings via custom policy in Intune.  The complete list of ADMX-backed policies supported by Policy CSP are documented here:

ADMX-backed policies in Policy CSP – Windows Client Management | Microsoft Docs

It is also possible to ingest your own ADMX templates via Intune policy to configure settings for 3rd party apps such as Google Chrome, Adobe Acrobat, etc.  Both the ingestion of the ADMX template and configuration of the required settings has to be done using custom policy.  In fact, prior to the Administrative Templates feature shipping this is exactly how I used to configure hundreds of settings for Office 365 Pro Plus.  As indicated by @MikeDanoski (Device Configuration Policy PM, MSFT) recently on Twitter the engineering team is working on a better way to manage any ADMX template via the UX.

In addition to 3rd party ADMX templates provided by ISVs you can also author your own templates to configure apps or other settings in the operating system.  However you cannot update all parts of the registry with ADMX-backed policy.  Some registry keys are blocked (by Microsoft) due to security concerns (\System, \Software\Microsoft etc.).  A complete list of those keys are detailed in this article:

Support Tip: Ingesting Office ADMX-Backed policies using Microsoft Intune – Microsoft Tech Community

Managing network drive mappings via ADMX-backed policy

In this scenario we only need to update HKCU\Network and as that isn’t on the blacklist we can use ADMX-backed policy to create the required registry keys.  There are two steps to deploy the ADMX-backed policy via Intune:

  1. Ingest the ADMX XML template (required for settings which are not native to the OS)
  2. Configure settings from the template

I have authored an ADMX template for network drive mappings, you can download a .zip file containing the ADMX and ADML files here.  If you want to quickly test this outside of Intune just copy the ADMX file to C:\Windows\PolicyDefintions and the corresponding ADML file to C:\Windows\PolicyDefinitions\en-US. After coping the files run gpedit.msc to launch the local group policy editor.  You will find the settings under User Configuration\Administrative Templates\Network Drive Mappings:

Managing Network Drive Mappings with Intune without PowerShell
Local group policy editor (gpedit.msc) showing Network Drive Mappings settings

Just double-click one of the settings to enable the policy and specify the remote path.  The other registry values required to configure the network drive mapping are hard-coded into the ADMX template and will get created when the policy applies to the client.

You can test with any UNC path, it doesn’t have to be anything valid which you can connect to.  In this example, I am mapping drive Q: to \\MyFileServer\MyFileShare.

Managing Network Drive Mappings with Intune without PowerShell
Use the local group policy editor to configure a network drive mapping

After saving the policy you will not see the drive in Windows Explorer immediately, you will need to sign-out and back into Windows or restart the explorer.exe process via task manager. 

After doing that you will see the mapped drive.  If it is not a valid network path or the signed-in user cannot authenticate to it then you will see the drive in a disconnected state:

Managing Network Drive Mappings with Intune without PowerShell
Disconnected/Offline network drive

There is an additional setting at the bottom of the drive list called “Display a notification if a mapped drive fails to re-connect”.  By setting this to “disabled” it prevents a pop-up notification from appearing when the user does not have network connectivity to the target remote path.  I will detail more about this later in this post.

As we are writing registry keys outside of the \Software\Policies and Software\Microsoft\Windows\CurrentVersion\Policies registry hives the settings are “tattooed” to the registry and will not be removed by simply changing the policy from “enabled” to “not configured”.  The policy will need to be set to “disabled” to remove the mapped network drive from the client.  Again you can test this via gpedit.msc, changing the policy to “disabled” and restarting explorer.exe or signing out and back in will remove the mapped network drive.

How to manage network drive mappings via Intune configuration policy

Here is a step by step guide on how to configure network drive mappings via Intune.

I recommend keeping your ADMX ingested templates in a separate profile to the associated settings, it just makes it easier to re-use the same template across multiple settings profiles.

  1. Download the ADMX template files from here.
  2. Extract the files somewhere onto your local drive (only the admx file is needed for ingesting via a custom profile).
  3. Create a custom configuration profile in Intune as detailed below:

Configuration Profile

PlatformWindows 10 and later
Profile TypeCustom
Profile NameADMX Ingestion

OMA-URI Setting

NameDriveMapping.admx
DescriptionADMX template for Network Drive Mappings
OMA-URI./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/DriveMapping/Policy/DriveMappingAdmx
Data TypeString
Value{copy and paste the XML from DriveMapping.admx}
  1. Save the profile and assign it to a device group containing your Windows 10 devices.
  2. Perform an MDM policy sync on a client to ensure that the new ADMX template is ingested correctly.
  3. You can check this on the client in the registry:

HKLM\Software\Microsoft\PolicyManager\AdmxInstalled\{GUID}\DriveMapping\Policy\DriveMappingAdmx

Managing Network Drive Mappings with Intune 2
Policy manager registry values showing ingested ADMX template

HKLM\Software\Microsoft\PolicyManager\AdmxDefault\{GUID}\DriveMapping~Policy~DriveMapping

Managing Network Drive Mappings with Intune 3
Policy manager registry keys showing the settings from the ingested ADMX template
  1. Once the ADMX template is successfully ingested on the client create another Intune custom profile to configure a network drive mapping.  I have included an example below, just adjust the text in red to specify the drive letter and target remote path.

Configuration Profile

PlatformWindows 10 and later
Profile TypeCustom
Profile NameNetwork Drive Mappings
NameDrive Q
DescriptionMaps Q Drive to a network share
OMA-URI./user/Vendor/MSFT/Policy/Config/DriveMapping~Policy~DriveMapping/Drive_Q
Data TypeString
Value<enabled/>
<data id=”Drive_Q_RemotePath” value=”\\MyFileServer\MyFileShare“/>

OMA-URI Setting

  1. You can add multiple OMA-URI settings to the same profile for additional drive mappings if you wish.  For example you could create all of the drive mappings for the Marketing dept. in a single profile and then assign that to a group containing the Marketing dept. users.
  2. Update 20/03/21 – It is also possible to include an environment variable as a subfolder to the share in the remote path. For example \\MyFileServer\Users\%Username%. Thanks to Stuart Hoaen for finding the fix to the ADMX template to make this work (see comments section below). I have updated the ADMX template linked to this post.
  3. Assign the profile to a group containing the users who require the network drive mappings.
  4. Again perform an MDM policy sync on the client and monitor the registry to see if the settings are deployed successfully:

HKLM\SOFTWARE\Microsoft\PolicyManager\current\{SID}\DriveMapping~Policy~DriveMapping

Managing Network Drive Mappings with Intune 4
Policy manager registry keys showing the configured network drive mapping
  1. Once the policy has applied successfully sign out and back in on the client (or restart the explorer.exe process) and the drive mapping will appear.

If the target remote path is not available immediately at sign in then the drive will appear in an offline state.  However simply double-clicking the drive to open it in explorer will switch it to online as long as the network path is reachable and the user can authenticate to the remote file server.

Disabling the user notification for drive connection failures

If your users are remote and connecting over a VPN (that applies to many us at the moment!) then by default Windows will likely display a notification that the persistent mapped drive cannot be reconnected during sign-in.  This can be quite annoying for end users but can be disabled using the additional setting I have included in the ADMX template.  Just configure the following setting in a custom profile.  I would recommend configuring this in a single profile which is assigned to all users rather than configuring it within each of your network drive mapping profiles:

OMA-URI Setting

NameReconnectNetworkDrivesWarning
DescriptionCustom
OMA-URI./user/Vendor/MSFT/Policy/Config/DriveMapping~Policy~DriveMapping/ReconnectNetworkDrivesWarning
Data TypeString
Value<disabled/>

In my experience of testing this I have seen the notification appear even when this setting is disabled, it does not appear to be that consistent.  I have found that also setting the following system registry key seems to resolve the issue:

Registry KeyHKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider
Registry Value TypeDWORD
Registry Value NameRestoreConnection
Registry Value0

As discussed earlier in this post it is not possible to configure registry values within HKLM\System via ADMX-backed policy as it is blocked by Microsoft.  Therefore I usually configure this setting via PSH, you can deploy a single line script to achieve this:

New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\NetworkProvider -Name RestoreConnection -PropertyType DWord -Value 0 -Force

Editing and removing network drive mappings via ADMX-backed policy

If you want to change the target remote path for a network drive mapping you simply need to edit the UNC path in the OMA-URI setting.  The change will then apply to all existing clients where the profile has been targeted.

However as I mentioned earlier in this post as the settings are “tattooed” to the registry it is necessary to explicitly disable the policy setting for any network drive mappings you wish to delete.  Simply un-assigning the profile or deleting the OMA-URI settings will not remove the mapped drive from the client.

To delete a network drive mapping simply change the value of the OMA-URI setting to <disabled/>. 

NameDrive Q
DescriptionMaps Q Drive to a network share
OMA-URI./user/Vendor/MSFT/Policy/Config/DriveMapping~Policy~DriveMapping/Drive_Q
Data TypeString
Value<disabled/>

Once this has applied to all existing clients you can delete the setting from your Intune profile.

I did discover some issues with deleting the registry keys/values when setting the policy to disabled.  Whilst it worked perfectly via local group policy it did not work via ADMX-backed policy.  Therefore the ADMX template just sets the registry values to NULL strings or 0 rather than deleting them.  The mapped drives will disappear from Windows Explorer so the end-user experience isn’t impacted.  Changing the policy back to enabled and specifying the remote path will re-apply the correct registry values so there are no issues with deleting a mapped drive and then re-adding it at a later date.

Happy network drive mapping 😊

Resources