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.
10 Comments
Hi,
are you sure you haven’t made a mistake? You probably mean this applies to HybridJoin devices! EntraID Join devices are not authorized to access local resources because their UPN is not Domain\User but AzureAD\User, unless you use Entra DS or connect the local domain via gateway to Azure.
Kind regards
Khiro
Hi Khiro,
This definitely isn’t a mistake. It is a misconception local resources are not available using Entra joined devices. When your user identities are synced from the local AD to Entra ID, resources like file shares are available as long as the device is able to reach the resources. When the device and file shares are on the same network, or for example using VPN the file shares are reachable and network drive mappings can be connected.
Regards,
Peter
Hi,
Is your technique better than those offered in the below two links?
https://github.com/nicolonsky/IntuneDriveMapping/wiki#adding-network-drive-mapping-entries
https://call4cloud.nl/2021/03/willy-wonka-and-the-drive-letter-factory/
Hi Michael,
I’m not saying one solution is better than the other. It depends on your own needs.
The benefit of this solution is that it (re-) connects the drives at every network change to avoid ending up with disconnected network drives. In our environment, we found this more stable than deploying (and running) a script once or deploying it via ADMX.
Regards,
Peter
Could you please share details with how you packaged it as an Intune app? Specifically, what to enter in the install command fields, etc.
Thank you
You need to wrap the 3 scripts with the WIN32 prep tool found on GitHub https://github.com/Microsoft/Microsoft-Win32-Content-Prep-Tool
And than use an install command like PowerShell.exe -ExecutionPolicy Bypass -file .\DriveMappingsv1.0_CreateScheduledTask.ps1
Good luck with it!
Hi Peter,
Thank you for sharing these scripts. Would you recommend against creating separate tasks for each drive mapping. E.g. instead of one task with all available drive mappings, a separate task for each drive-letter? So users only get a drive-mapping if they have access to the files?
Kind regards,
Brendan
Hi Brendan,
It doesn’t take much resources to run multiple scheduled tasks, so I don’t see a reason to not do it. Depending on your PowerShell skills you could also add some logic in one script to map a drive mapping only when the user has access. But that’s what I leave to the real PS guru’s 🙂
Hi Peter,
Thank you for your response, I’ll take that in mind.
Kind regards,
Brendan
Spent quite many hours looking for solutions to this issue. This one is easy to setup and robust, worked right away. Thank you!