Map network drives on cloud-managed Windows devices

A few weeks ago I wrote an article on managing printer mappings on cloud-managed Windows devices. It’s one of the frequently heard challenges when companies move from a traditionally managed Windows device (controlled with GPOs and Configuration Managed) to a Microsoft Entra joined (Azure AD joined) Intune-managed Windows device (Modern Windows workplace).

Another challenge in this journey is how we need to manage network drive mappings on these cloud-managed devices. Because while we are moving more and more things to the cloud, a lot of companies still have a lot of files stored on on-premises file servers. The file shares can be reached from Entra joined devices without any issue (as long as they are connected to the same network), but how do we automatically connect the network drives? And make sure these are connected when a domain connection is available?

Like with managing printers mappings, we also need to be creative when we manage network mappings. There are multiple options to manage printers, I’ll share an example which is using scripting and Microsoft Intune.

The Solution

The solution I use is a PowerShell script which is triggered via a scheduled task. Every time a network change happens, several events are written under Microsoft-Windows-NetworkProfile (under operational). On event id 10000, the task is triggered.

The scheduled starts a VBS script. The only thing the VBS script does is start another (PowerShell) script. This is to avoid any user-facing pop-ups because the scheduled task runs under Users.

The PowerShell script that is eventually triggered, checks if the domain connection is available, and if that is the case, it connects the network drive mappings.

A third script is involved in the solution. This script copies the other two scripts to a local folder on the device and creates the scheduled task.
To deploy this solution, I wrapped these as WIN32 package and deployed the package with Microsoft Intune.

The scripts can be found un my GitHub repo.

The scripts

Let’s have a closer look at the three scripts.

The script whose name ends on CreateScheduledTask, creates the scheduled task as the name already shows.

In the functions region, we define a CleanUpAndExit function, which is also used for Intune detection when wrapped as a win32 package.

Next, we handle copying the other two scripts to a local folder. The location is defined in the variables. In my case, the location is C:\Program Files\Common Files\CompanyName\DriveMappings.

In the last part, the script creates the Scheduled task.
The trigger is configured to run when event id 10000 is detected under Microsoft-Windows-NetworkProfile\Operational.
It executes wscript.exe with an argument of the vbs script.
I used the SID S-1-5-32-545 instead of a group name, to make sure the script not only runs correct on a device running an English OS.

This article provides some more information on configuring a scheduled task trigger using an event id.

Then we have the vbs script whose name ends on ScriptRunFromTaskScheduler.vbs.

As said, it only triggers the initial PowerShell script that does the actual drive mapping.

And last we have the script whose name ends with ScriptRunFromTaskScheduler.ps1.

First, the CleanUpAndExit function is defined. Second, a function to check the connection to the domain is defined, followed by two functions to check if the drive mapping already exists.

In the second part, the Test-DCConnection function is used to test domain connectivity. If the connection is not available, it stops and the status is written to a log file.
If there is a domain connection, the script tries to connect the network drive mappings, if these are not already connected.

In the last part, a final check is done to check the end state network drive mappings.

And that’s all to make the drive mappings available to your end users on Entra joined devices.

In case something goes wrong in connecting the drive mapping(s), the log file can be found in %programdata%\Microsoft\IntuneManagementExtension\Logs. I chose this location so it is part of the Device Diagnostics zip folder you can retrieve remotely from your Intune managed devices. Makes troubleshooting a little easier.

This is just an example of how we can make the drive mappings available. I hope it is useful to get you started in connecting the drive mappings.

Below is a short video to show that on-premises resources are available, although some people still think this is not possible.