I needed to take apart my blog about SSO from Azure Ad Joined devices to your on-premise old school legacy file server because there was too much information to tell.
So I decided to remove the Drive letter parts and dedicate a special blog to it.. So both of these blogs could the attention they need…
I will divide this blog into multiple parts
- Drive Letter Mappings
- Solving the Red cross and disconnection warning!
- Making the driveletters more beautiful
- Mapping a drive letter to sharepoint
How are we going to mount drive letters to our on-premise file servers when we have not yet migrated the data to SharePoint?
Are we going to map some old-fashioned drive letters with the use of PowerShell? I guess everyone has deployed Adminless and Applocker and of course you made sure your Applocker policy will block PowerShell for the regular users. What to do now?
In some older blogs I showed you the possibility to ingest some ADMX templates to configure some additional settings, so why not do the same for the drive mappings?
The only thing you will need is the drive mapping ADMX file which you will find here:
First, we need to configure the CSP for the admx
OMA-URI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/DriveMapping/Policy/DriveMappingAdmx Data Type: String Value: content of the drivemapping.admx file
And of course, a separate CSP for the drive mappings and itself
OMA-URI: ./user/Vendor/MSFT/Policy/Config/DriveMapping~Policy~DriveMapping/Drive_H Data Type: String Value: <enabled/> <data id="Drive_H_RemotePath" value="fileserverfileshare"/>
While waiting for the custom-made policy to apply, look at the registry to check if you already can find the ADMX policy.
As shown above, the admx drive mapping admx is installed without any problems and within a few minutes, the drive mapping itself started showing up.
After logging off and logging on again, the drive mappings popped up and were ready for use.
Okay, we have our drive mappings, but what about the disconnection warnings and the red crosses? Let’s fix it.
Please make sure you also add this CSP to make sure you don’t get any reconnection warning
OMA URI: ./user/Vendor/MSFT/Policy/Config/DriveMapping~Policy~DriveMapping/ReconnectNetworkDrivesWarning
And to be 100% sure create and deploy a PowerShell script to the devices with this content
New-ItemProperty -Path HKLM:SYSTEMCurrentControlSetControlNetworkProvider -Name RestoreConnection -PropertyType DWord -Value 0 -Force
2. Solving the Red Cross/Disconnection issue
Sometimes you could end up with this red cross error. It looks like you can’t open the drive letter.
To solve this issue, you need to make sure the Network Drive ProviderFlags is set to 1. You will need to configure this key because the Registry Key ProviderFlags controls the recovery of network shares they use Server Message Block (SMB) version 1 when they are stored in the registry.
REG ADD “HKCUNetworkP” /v “ProviderFlags” /t REG_DWORD /d “1” /f
(change the P to one of the drive letters you are experiencing the issue with)
Totally forgot to mention this part. Looking at the drive label names… it doesn’t really look that nice does it?
If you want to specify a nice name to it, we need to open the registry first and browse to:
You will notice, all of your Drive Letters show up here.
I decided to export them first
I opened the export reg file and add the _LabelFromReg with a nice name to each Mountpoint.
When you are blocking PowerShell you can deploy this reg file to your device by using this trick, you could even create proactive remediation to be sure the drive letters are always having a nice description.https://call4cloud.nl/2020/03/how-to-deploy-hkcu-changes-while-blocking-powershell/
If you don’t block PowerShell, it’s a lot easier of course. Just create a PowerShell script that is deployed to the user context
reg add “HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerMountPoints2##servername#sharename” /f /v “_LabelFromReg” /t REG_SZ /d “NewLabel”
You will need to change the server name and share name to the value you have seen in the registry key
I did some tests if it would also work when you want to map a drive letter for a SharePoint site, but unfortunately, it doesn’t (yet?) map the drive letters with the web protocol. Next week a new deep-dive I guess
When going full cloud, there is still a possibility you will need to make sure your users could access the old school file servers. Like I showed in the deliver us from hybrid blog, you can do so with SSO. But why not provide your users a nice drive letter until you can move all the data to OneDrive/SharePoint?