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
Patch My PC
Advt

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.

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:

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.

1E Nomad
Advt

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

Sharing is caring!

28 thoughts on “Managing Network Drive Mappings with Intune”

  1. OMA-URI Setting

    Name Drive Q
    Description Maps Q Drive to a network share
    Data Type String
    Value

    Hello

    There is no OMA-URI string in this part but there is in all the other examples. I cannot get this to work

    Reply
    • Hi Adrian, thanks for testing this out and spotting the issue in the blog post. I have fixed that for you now :-).

      Reply
      • Hi Mark,

        It fails when mapping the drives as per the blog

        ERROR CODE
        0x87d1fde8
        ERROR DETAILS
        Remediation failed

        Any ideas

  2. Hi Adrian

    I think it might be the text formatting due to copying and pasting the setting value from the blog post. I will try to fix that but in the meantime just paste the value into Notepad and then overtype the double quote characters (“). Then copy that text from notepad into the setting in the MEM console.

    Mark.

    Reply
    • Hi Anders,

      Unfortunately no it’s not possible to do that via ADMX backed policy. The display name is stored in a different part of the registry (which is updatable via ADMX) but the reg key name is based on the UNC path. To the best of my knowledge it’s not possible to dynamically adjust the reg key the policy will write to based on the remote path value you entered.

      I haven’t tried this but I believe it is possible to achieve the same thing by placing a desktop.ini file in the root of the file share. That will work if you are happy with all users connected to the same share having the same display name. The file needs to have either system or read-only attributes applied – I would use attrib +S +H +R to make it system, hidden and read-only.

      I am not sure of the structure of the desktop.ini file, I will try and look into it a bit more and see if I can get it working. If you manage to do that yourself let me know :-).

      Reply
  3. Thank you so much, Thomas! This is exactly what I have been looking for. I’ve tried numerous powershell solutions for this, but it’s been a nightmare to edit drives later.

    Reply
  4. Thanks for this – worked brilliantly for me.

    Follow up question (can’t find any answer anywhere) we have private areas for staff and these were traditionally mapped by “\\Server\%username%”. This works in the sense that the drive will appear mapped to the correct letter in File Explorer, but it throws back an error “Network resource or device is no longer available. This connection has not been restored”

    Should the %username% work dynamically in this? Or am I on to a loser here..

    Thanks

    Reply
    • Thanks for the feedback Steven, great to hear it worked for you. I am not sure that variables such as %username% would work in this scenario, although I have never tried it. I assume that when mapping the drive through the normal windows process it resolves the variable to the value and then the drive is mapped using that e.g \\server\steven.

      Reply
      • Hi. Thanks very much for this valuable resource. I had the same question as Steven McAuley above about using variables in paths. Like Steven I found it doesn’t work.

        However, I’ve found this is possible by amending the ADMX file as follows….

        Find the section within each and change the item to include an expandable=”true” flag. For example…..

        After doing this, variables in drive map paths are resolved.

      • Hi. Thanks very much for this valuable resource. I had the same question as Steven McAuley above about using variables in paths. Like Steven I found it doesn’t work.

        However, I’ve found this is possible by doing the following….

        Find the element section within each policy section and change the text item to include an expandable=”true” flag. For example…..

        text id=”Drive_Q_RemotePath” valueName=”RemotePath” expandable=”true”

        After doing this, variables in drive map paths are resolved.

  5. Thanks for the feedback Stuart! Yes that is correct it does seem that the expandable flag enables environment variables to be expanded to their real value. I will test this out and update the ADMX template and blog post. All kudos to you of course .

    Reply
  6. Hi Mark,

    Any ideas why after I push the “Configuration Profile” to enable the mapped drive of my choice the “HKLM\SOFTWARE\Microsoft\PolicyManager\current\{SID}\DriveMapping~Policy~DriveMapping” path does not appear? I was able to push the ADMX policy itself easily and confirm it’s entry in my registry.

    Also when I load your ADMX file on my machine I receive the following error after opening the local GP editor, “Invalid value ‘True’ for attribute expandable. File C:\Windows\PolicyDefinitions\DriveMapping.admx, line 79, column 81.”

    Thanks for the help.

    Reply
    • Hi Calvin, I think there are two separate issues. I recently updated the ADMX template to add support for using variables and forgot to check that it worked via the local group policy editor :-). I have now fixed that issue so if you re-download the .zip file and use that .ADMX you will find that it does now load in GPEdit.msc. However even with the previous version your configuration profile should have still worked. Did you spot the comment above regarding the double quote characters? If you have copied the text from the blog post and pasted that directly into Intune then that might be the issue. Paste the text into Notepad first and overtype the double quote (“) characters – then copy that text from Notepad into the Intune console. It’s just a formatting issue from the blog post. Let me know if that helps.

      Reply
    • Hi Jan, yes they should be double quotes. The issue is caused by copying and pasting the text from the blog post. I have just added a .txt file to the .zip file which includes the correct settings. If you download the .zip again and check the “example settings.txt” file you can copy and paste the values directly from there (changing the drive letter as necessary). That will avoid the formatting issue when copying from the blog post. Clear your cached images and files from your browser cache before re-downloading the .zip just to make sure you get the latest one.

      Reply
  7. Very helpful.
    After seeing the item:
    Find the element section within each policy section and change the text item to include an expandable=”true” flag.

    I wondered why it worked, then I remembered that in the registry there is data type of
    REG_EXPAND_SZ which was engineered expressly to resolve %variables%, I suspect that changing expandable=”true” changes the reg data type written to the registry to REG_EXPAND_SZ

    RegKey data types
    [ REG_SZ | REG_MULTI_SZ | REG_EXPAND_SZ |
    REG_DWORD | REG_QWORD | REG_BINARY | REG_NONE ]

    Reply
    • Hi John,

      Thanks for the feedback. Yes that is correct, setting the expandable property switches the registry value from REG_SZ to REG_EXPAND_SZ.

      Mark.

      Reply
  8. Hi Mark,

    Thank for your work.

    Probably i found a problem with the username variables

    First login after deploy the policy with your step by step it works fine.
    But the second login the mapped drives with uservariables not work anymore.

    In the network registry node there is: \\share\%username%\ but in the explorer appears \\share\SYSTEM

    My idea is, that the policy is running with the system user and not with the login user. Then it will remap the mapped drive.

    Have you an idea to solve this?

    Reply
    • Hi Daniel,

      Oh… that’s not good! I can’t be 100% sure how many times I logged on / rebooted when I tested this out but I don’t recall seeing that issue. I will test this scenario again and see if I can reproduce the problem. It might take me a few days due to other work commitments but I will get back to you.

      Mark.

      Reply
    • Hi Daniel,

      Sorry for the delay in getting back to you. I have now re-tested this and the use of %username% as detailed in the blog post does work OK, it does not seem to revert to SYSTEM. I have rebooted several times, sync’d with Intune etc and all seems OK. However I notice you are using \\Server\%UserName%. I did not have that much success with that in my own testing and recommend using the variable as a subfolder of the share. For example \\Server\Users\%UserName%. Also are you assigning the ADMX ingestion profile to a group containing devices and the drive mapping profile to a group containing users? The drive mapping policy is per-user and I would recommend assigning that to a user group.

      Hope that helps.

      Mark.

      Reply
  9. Hi Mark,
    a very basic question by a newbie:
    I would like to use your method connecting a folder on a server as a network drive. The server is not part of a domain, so I have simply created a local user account with a password, which has the rights to access the folder.
    My question is: how is it possible to add username and password with your method? Can I somehow add it with the UNC?

    Thanks for your help.

    Markus

    Reply
    • Hi Markus,

      Whilst it is possible to specify a username in the registry settings my current ADMX template doesn’t allow you to configure that (it’s hardcoded to a null value). However it’s not possible to specify the password via the registry, users would have to enter the password and this is then stored in the Windows Credential Manager. So even if I updated the ADMX to cater for the username you would have to tell all of the users the password and they would need to enter it.

      To be honest what you are looking to do isn’t a very secure solution and best avoided. If you are setting up something new and don’t currently have any on-premises AD infrastructure I would suggest using a cloud based storage solution such as Azure Files.

      Mark.

      Reply
  10. Thank you for all the work you put into it. Once I resolved the self-induced syntax error (dammit UTF-8), it worked flawlessly.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.