PowerShell 7 to allow displayed existing mapped drives

[MaximoTrinidad]

Summary of the new feature/enhancement

Just a feature request to allow the cmdlet Get-PSdrive to also list existing mapped network drive(s).
In the scenario where I'm using trying to assign a letter in New-PSDrive and I want to make sure is available without opening the file explorer. SO, I'm eliminating an extra step to find out if the it already exist.

It would be nice!

Proposed technical implementation details (optional)

[doctordns]

I am not quite sure - but this seems to work here. If I create a new mapped drive, like this

net use z: \\cookham24\d$\builds

and then look ag Get-PSDrive, I see the drive fine. See here

Or am I misunderstanding your use case?

[MaximoTrinidad]

@doctordns

Try to first manually create map a network drive using the "File Explorer", not PowerShell, not using "net use ...". At the same time, I'm trying to access my existing Z: drive from within PowerShell session, but it's not possible.

The Get-PSDrive cmdlet won't display already existing mapped drives.

That's what I'm trying to show in the screenshot.

:)

[mklement0]

@MaximoTrinidad, you're seeing an OS limitation, not one of PowerShell.

Get-PSDrive does list the mapped drives that the current user sees.

However, the same account running as administrator (elevated, as your screen shot suggests) does not see the same mappings as its non-elevated incarnation.

Essentially, non-elevated and elevated processes started by a given user account behave like different accounts with respect to net use / File Explorer drive mappings: neither sees the other's, and they must be managed independently.

The only (simple) way to make a drive show up in both contexts is to define it via $PROFILE.

[MaximoTrinidad]

Ah! That's the reason I created this feature request.

Many companies possibly will have mapped some network drives during the login process. So, why should I map again the drives in PowerShell?

Of course, knowing this limitation makes you creative. Right!

I think it would be a nice feature to have if it's possible!
:)

[mklement0]

I agree that the behavior is surprising and inconvenient, but I don't think it's PowerShell's job to change it (which couldn't be done safely / predictably, given that this separation has always existed and users may have adjusted by explicitly managing separate mappings for elevated processes).

Your best bet is to put net use statements into your $PROFILE.

[MaximoTrinidad]

@mklement0

I understand! We can always change the way to map drives at login time.
:)

[SteveL-MSFT]

If the drives are mapped under a different account (and elevated vs non-elevated is considered different), then the OS prevents the other user context from seeing it (you can verify this with net use to show the mapped drives). There isn't anything PowerShell can do differently here.

[mklement0]

@MaximoTrinidad: https://github.com/gerardog/gsudo (a sudo implementation for Windows) has a --copyns switch that tries to recreate the drive mappings in an elevated session.

GitHub

gerardog/gsudo

A Sudo for Windows - run elevated without spanning a new Console Host Window - gerardog/gsudo