{"id":415,"date":"2025-01-20T16:51:33","date_gmt":"2025-01-20T15:51:33","guid":{"rendered":"https:\/\/digitalmaterial.ch\/blog\/?p=415"},"modified":"2025-01-20T16:51:35","modified_gmt":"2025-01-20T15:51:35","slug":"intune-adventures-the-curious-case-of-the-disappearing-network-drives","status":"publish","type":"post","link":"https:\/\/digitalmaterial.ch\/blog\/intune-adventures-the-curious-case-of-the-disappearing-network-drives\/","title":{"rendered":"Intune Adventures: The Curious Case of the Disappearing Network Drives"},"content":{"rendered":"\n

Recently, we experienced some issues with a Customer after removing a Network Drive from the Computers that had been mapped via Intune. And it was surely not the kind of issue we would have expected.<\/p>\n\n\n\n

But let’s begin from the start. We have been managing the Network Drives for that customer via Intune for quite a while, as described in this Blog from Call 4 Cloud: Intune Drive Mappings | Managing Drive letters with an ADMX<\/a>. We do have one Server and Azure Files being used as file shares with multiple network drives ranging from G: to Y: As we have been moving the data from drive L: to SharePoint, we wanted to disable that drive on all clients. So we unassigned to Policy from the Clients, and after a short while some users complained that they were missing multiple Network Drives. Not what we expected after just removing one drive. And when looking at the Computers we were greeted by the following view (remember that we had drives ranging from G: to Y: and we removed drive L:)<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The command net use<\/code> also showed just a part of the expected drives:<\/p>\n\n\n\n

PowerShell<\/span><\/path><\/path><\/svg><\/span>
> net use<\/span><\/span>\nStatus       Local     Remote<\/span><\/span>\n-------------------------------------------------------------------------------<\/span><\/span>\nOK           G:        \\\\serverA.intra.domain.ch\\FileShareG<\/span><\/span>\nOK           H:        \\\\serverA.intra.domain.ch\\FileShareH<\/span><\/span>\nOK           I:        \\\\serverA.intra.domain.ch\\FileShareI<\/span><\/span>\nOK           J:        \\\\serverA.intra.domain.ch\\FileShareJ<\/span><\/span>\nOK           K:        \\\\serverA.intra.domain.ch\\FileShareK<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
So on first sight, we thought that only the drives from the Server were mapped, and Azure Files were missing. But we had Maps to the Server on Drive Letters like Y: as well. So after a short while, it was clear that all drives were missing that follow after the Letter L in the Alphabet. And that was the first sign of a bug either in Intune or Windows (or both, of course).<\/p>\n\n\n\n
So we dug deep into the Intune policies, CSP, and our beloved registry. After a long search (and possibly some cursing) we stumbled upon the Registry Key HKLM:\\Software\\Microsoft\\Policymanager\\Current\\{SID}<\/code>. All the mapped drives were showing, and for drive L: there was just one Registry Item instead of the four for all the others. So we removed the remains of that network drive in the registry and tried again, but with no luck.<\/p>\n\n\n\n
So we went on with digging, searching, (and cursing) and after a while, found another leftover of our «Deleted» Drive in HKCU:\\Network<\/code>:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
So we deleted the Key and voil\u00e0, net use showed us all the drives instantly:<\/p>\n\n\n\n
PowerShell<\/span><\/path><\/path><\/svg><\/span>
> net use<\/span><\/span>\nStatus       Local     Remote<\/span><\/span>\n-------------------------------------------------------------------------------<\/span><\/span>\nOK           G:        \\\\serverA.intra.domain.ch\\FileShareG<\/span><\/span>\nOK           H:        \\\\serverA.intra.domain.ch\\FileShareH<\/span><\/span>\nOK           I:        \\\\serverA.intra.domain.ch\\FileShareI<\/span><\/span>\nOK           J:        \\\\serverA.intra.domain.ch\\FileShareJ<\/span><\/span>\nOK           K:        \\\\serverA.intra.domain.ch\\FileShareK<\/span><\/span>\nOK           M:        \\\\stdata.file.core.windows.net\\FileShareM<\/span><\/span>\nOK           N:        \\\\stdata.file.core.windows.net\\FileShareN<\/span><\/span>\nOK           O:        \\\\stdata.file.core.windows.net\\FileShareO<\/span><\/span>\nOK           P:        \\\\stdata.file.core.windows.net\\FileShareP<\/span><\/span>\nOK           Q:        \\\\serverA.intra.domain.ch\\FileShareQ<\/span><\/span>\nOK           R:        \\\\serverA.intra.domain.ch\\FileShareR<\/span><\/span>\nOK           T:        \\\\serverA.intra.domain.ch\\FileShareT<\/span><\/span>\nOK           X:        \\\\serverA.intra.domain.ch\\FileShareX<\/span><\/span>\nOK           Y:        \\\\serverA.intra.domain.ch\\FileShareY<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
Explorer needed a restart to be happy and show the drives:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
As we had the issue on multiple devices, we pushed a script via Intune with the following command, and after a reboot all the users had their drives back.<\/p>\n\n\n\n
PowerShell<\/span><\/path><\/path><\/svg><\/span>
Remove-Item<\/span> -Path <\/span>"HKCU:\\Network\\L"<\/span> -Recurse -Force<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
Finally, we had a solution for this issue, but still would expect Intune and Windows to be able to remove Network Drives without such issues. So we checked what happens, if we do not just unassign the policy or set it to Not configured but delete the drive via Intune. And the result was even worse:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
So we did not find a way to remove drives just with the Intune policy, and always needed to add a script to remove the Registry Key. Funnily, net use was also able to remove the drive and the Registry Key after the Intune Policy mishap:<\/p>\n\n\n\n
BAT (Batchfile)<\/span><\/path><\/path><\/svg><\/span>
net use<\/span> L: \/delete<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
If you thought this is weird. Well it gets even weirder. For testing we created a simple policy to remove the Drive E: from a client that did not have that drive mounted.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
We would have expected that nothing happens. If you deleted a drive that does not exist there’s nothing you have to do. But no: Intune \/ Windows created a new registry Key named E with the same content we have seen above, leading to the same issues.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
In the end, the whole issue seems to be a combination of a bug in the Intune Policy, which did not completely remove the Registry Key in Windows. And Windows to trip over the incomplete Registry Key. We were even able to reproduce that issue by just creating a key named E and no drives were showing:<\/p>\n\n\n\n
PowerShell<\/span><\/path><\/path><\/svg><\/span>
New-Item<\/span> -Path <\/span>"HKCU:\\Network\\E"<\/span><\/span>\n<\/span>\n> net use<\/span><\/span>\nThere are no entries <\/span>in<\/span> the list.<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
If you need to remove a network drive that you have mounted via Intune and an ADMX, test thoroughly to ensure if your drive (and only that drive) will be removed.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Recently, we experienced some issues with a Customer after removing a Network Drive from the Computers that had been mapped via Intune. And it was surely not the kind of issue we would have expected. But let’s begin from the start. We have been managing the Network Drives for that customer via Intune for quite […]<\/p>\n","protected":false},"author":2,"featured_media":445,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[16,45],"class_list":["post-415","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-endpoint-management","tag-intune","tag-network-drives"],"_links":{"self":[{"href":"https:\/\/digitalmaterial.ch\/blog\/wp-json\/wp\/v2\/posts\/415","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/digitalmaterial.ch\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/digitalmaterial.ch\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/digitalmaterial.ch\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/digitalmaterial.ch\/blog\/wp-json\/wp\/v2\/comments?post=415"}],"version-history":[{"count":26,"href":"https:\/\/digitalmaterial.ch\/blog\/wp-json\/wp\/v2\/posts\/415\/revisions"}],"predecessor-version":[{"id":470,"href":"https:\/\/digitalmaterial.ch\/blog\/wp-json\/wp\/v2\/posts\/415\/revisions\/470"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/digitalmaterial.ch\/blog\/wp-json\/wp\/v2\/media\/445"}],"wp:attachment":[{"href":"https:\/\/digitalmaterial.ch\/blog\/wp-json\/wp\/v2\/media?parent=415"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/digitalmaterial.ch\/blog\/wp-json\/wp\/v2\/categories?post=415"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/digitalmaterial.ch\/blog\/wp-json\/wp\/v2\/tags?post=415"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}