New-SMBMapping not showing in Explorer until Explorer process is closed/restarted

Occasional Contributor

I'm writing a script to remap drives to new paths (file server migration), and I had everything working.  I'm using Remove-SMBMapping and New-SMBMapping.

 

While it was working there was a strange bug where it would only work if I pasted the code directly into powershell.  But if I called the .ps1 script file, the drive mappings would change (as verified by NET USE from the command line), Explorer continued to show and use the old drive mappings.  If I end process for Explorer.exe and re-run it, then it would show and use the new mappings.  I just ignored this at the time.

 

Well now I'm doing some more testing, now no matter what I do, when using New-SMBMapping in any way, Explorer refuses to see the drive (even new mappings) while the system does see the correct drives via cmdline.  

 

I'm at a complete loss as to why this is an issue.  It occurs in both Powershell 7 as well as Windows Powershell 5.1.  

 

Does anyone have a clue as to what is happening here?

 

FWIW I know that drives mapped in the standard UAC user context are not visible to admin contexts and vice versa.  That is not the issue here.  This is all under the same user context.  No elevated admin sessions are at play.  In fact, if it were this, restarting Explorer would have no affect.

Also this is an issue whether -persistent $true is used or not.

Finally, if I just simply use native Windows cmd prompt command "Net Use" to map the drive, even within the Powershell console, everything works as expected.  This is only an issue using the powershell specific cmdlet to map the drive.

11 Replies
You could try using the New-PSDrive cmdlet. i.e.

New-PSDrive -Name X -Root \\Fileserver\Share -PSProvider FileSystem

This creates a mapping which is visible in Windows Explorer straight away, you can use the -Persist parameter to make it permanent. The New-SMBMapping is for the PowerShell session itself until it closes?
No change. Anything I do within Powershell with drive letters is not reflected in the Explorer process.

Note: I am using Windows 11.

Further, I remember running into this problem a few months back but it only surfaced if I ever launched the script via the PS file from Explorer. If I launched it directly in Powershell, or simply manually typed the commands in Powershell it worked as expected. Now, all of a sudden, no matter what I do, if it's done in Powershell, Explorer will not see the change until it is restarted.
I'm also using Windows 11, I typed the command in a Windows Terminal and.. Now it doesn't work for me also.. PowerShell 5 and 7 in Windows Terminal, but also from a script file... Which it did yesterday...I don't get it :)
I'm seeing some weird back and forth now. I am using Terminal too (as well as VSCode), where both were broken, so I decided to try regular Windows Powershell outside of Terminal. New-PSDrive works there, but only if I add the -Persist option. It also works with the raw NET USE command.

But after doing the, now New-PSDrive is working in Terminal\Powershell and Terminal\Windows Powershell again. I'm confused.

But New-SMBMapping still is broken everywhere (where it used to work).
Adding persist does map it instant, remove-psdrive -Name X doesnt but net use x: /d does... But not running it from a script... It could work as a loginscript before the computer desktop is shown to the user I guess?
Unfortunately this is a script users will trigger manually from SCCM Software Center.

Here's an even more interesting one for ya.

In WPSH, I did a New-SMBMapping. In Terminal PoSH, a Get-PSDrive sees that new mapping, yet when trying to run Remove-PSDrive, it says there is no such mapping to remove. But I can run same Remove-PSDrive command from the original WPSH and it unmaps that connection fine.

I guess this is going to have to be one for the Windows dev team to figure out. Clearly something is wrong.
Any luck in figuring out another solution?
I ended up just going with the native NET USE commands in my script.
Net use still going strong after all those years...
You know... I might be crazy, but I vaguely recall having issues with NET USE as well in certain cases (likely in Terminal instances) as I ended up including a disclaimer with my script that users should log of/reboot to ensure the mapping is in place.