New-PSDrive not visible to other shells contrary to MS documentation

I've been trying al sorts of varieties of the following, trying to mount a network share in such a way it can be visible for both other shells and in File Explorer. According to the MS documentation of the related commands, saying one can use -Persistent and -Scope Global to make them "immediately visible to other shells", it just doesn't work.

$mDL       = 'Z'        # Mount to this Drive Letter
$dDesc     = 'ML-DATA'  # Description of PSDrive
$NLRoot    = "\\somepath.windows.net\xxx"
$UserName  = "localhost\someuser"

$cred = Get-Credential -Credential $UserName

New-PSDrive -Name $mDL -PSProvider "FileSystem" -Root $NLRoot -Credential $cred -Description $dDesc -Persist -Scope Global

The data container is in Azure, and everything seem to work apart from being visible from other parts in my system (Win10).

How can I make this drive visible from other PowerShell instances and File Explorer?

UPDATE: 2022-07-06

My bad, the text was from the ss64 docs for New-SmbMapping, where it was stated:

When a drive mapping is created with New-SmbMapping the new drive will not be visible to any currently running processes (including Windows Explorer) until that process is restarted (or the machine is rebooted). The one exception to this is the PowerShell console, all PowerShell sessions on the machine will immediately get the new drive mappings.

It may also be that the MS documentation is not easily understood by non-specialists, because in the New-PSDrive docs, the following is stated in 2 places.

In Example-4:
The mapped drive can be viewed on the local computer in PowerShell sessions, File Explorer, and with tools such as net use.
In the Paramters list under -Persist:
Mapped network drives are saved in Windows on the local computer. They're persistent, not session-specific, and can be viewed and managed in File Explorer and other tools.

So how can I make this share user and session type agnostic, in such a way that Z: is visible "everywhere" and for "everyone" in both in File Explorer and whatever powershell/cmd they want to use?

Useful References:

Solution

I'm not sure if Azure-specific considerations apply, but, generally speaking:

tl;dr

"Immediately visible to all other shells" with respect to newly established persistent drive mappings applies to:

By default: Shell processes (such as PowerShell and cmd.exe sessions) - more generally, (native) processes in general - that were created:
- by the same user and
- have the same session type: non-elevated vs. elevated (run as admin).
Optionally, if your system is configured accordingly (see below): Processes that were created:
- by the same user
- irrespective of session type.

Note:

All the information in this answer also applies to non-persistently mapped drives, assuming they are established with system-level features, such as net.exe use or File Explorer.
- By contrast, PowerShell does not allow you to create such mappings: if you omit -Persist in a New-PSDrive call, you'll get an (always non-persistent, session-specific and possibly scope-specific) PowerShell-only drive.

Persistently mapped network drives are user-specific:

Update:
- Windows 11 / Windows Server 2022 now come with the New-SmbGlobalMapping cmdlet, which allows establishing drive mappings globally, i.e. for all users, but note that its "primary use is for Windows Containers" and that such mappings "support standalone and failover cluster SMB shares", but do "not support DFS Namespace folder shares."
As is to be expected, other users won't see a given user's persistently mapped drives.
Surprisingly, even in the context of the same user, trying to establish a persistent drive from an elevated session (run as administrator) does not work: the request to make the mapping persistent is quietly ignored (that is, the mapping is quietly only established for the current session and only visible to other elevated sessions of the same user).
By default, elevated vs. non-elevated sessions do not share drive mappings, so that no drive mappings initially exist in an elevated session.
- However, with extra configuration you can make both types of sessions for a given user share mappings, which does allow you to establish (both persistent and non-persistent) mappings from an elevated session that are visible to the same user's non-elevated sessions too - see Mapped drives are not available from an elevated prompt when UAC is configured to Prompt for credentials.
- In short: From an elevated PowerShell session, modify the registry as follows and then reboot to make the change take effect:
```
#requires -RunAsAdministrator
# Reboot required afterwards
Set-ItemProperty 'registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' EnableLinkedConnections 1
```

As an aside:

Your New-PSDrive command shows the use of both -Persist and -Scope Global, which is indeed required to successfully establish a persistent drive from a script (from a scope other than the global one, i.e. other than directly from the interactive prompt).

If you use -Persist alone, it is quietly ignored: that is, a non-persistent, scope-local PowerShell-only drive is established.

Given that establishing a persistent drive mapping is unrelated to PowerShell's scopes, and that a successfully established persistent drive (or a non-persistent one established with net use or from File Explorer) is by definition visible in all PowerShell scopes, there should be no need to also specify -Scope Global - unfortunately, it was decided not to fix this usability problem: see GitHub issue #15752.