How To Fix Network Drive Issues in Elevated PowerShell SessionsHow To Fix Network Drive Issues in Elevated PowerShell Sessions

This tutorial explains how PowerShell handles drive mappings, highlighting an issue where mapped network drives are inaccessible in elevated sessions. We will show you a workaround using the “net use” command and explain how to create and manage custom PowerShell drives. By the end, you will understand how to navigate PowerShell drives efficiently and overcome common access limitations.

Subscribe to ITPro Today’s YouTube channel for PowerShell tutorials and more.

The following transcript has been edited for length and clarity.

Transcript:

Brien Posey: Hello, greetings, and welcome. I'm Brien Posey.

In this video, I want to discuss a weird topic: PowerShell drives.

At first glance, the subject of drives seems simplistic. When I first learned about computers in the 1980s, drive mappings were one of the first lessons. Back then, the lesson was that to access the B Drive, type “B:”. If you want to access the A drive, type “A:”. The C and hard drives weren't standard, but that basic concept remains the same today.

Back then, we booted into DOS, and PowerShell still uses many commands left over from the days of DOS. For example, this machine has an R drive, so I could type “R:” and access the R drive. If I want to go back to the C drive, I type “C:”. So, the same basic rules from the 1980s still apply in PowerShell today.

Related:How To Create PowerShell Progress Bars for External Tasks (Video Tutorial)

So, why am I taking the time to record a video on PowerShell drives? Well, some weird things happen when you start dealing with drive mappings in PowerShell. Microsoft has changed the rules along the way, so I want to show you something odd you may run into in PowerShell with drive mappings. I'll show you a workaround and then a handy shortcut you can use. I'm talking about something impossible to do back in the days of DOS.

Let's go ahead and get into it.

PowerShell’s Odd Behavior With Network Drives

The first thing I want to show you is the anomaly I mentioned a moment ago. It's the odd behavior you may encounter with network drives in PowerShell.

You can see the drives on this PC when we look at the File Explorer. I have a C drive, a D drive that contains a Blu-ray disc, an R drive, a W drive, a couple of mapped network drives, a Q drive, and an I drive.

Let's focus on the I drive. There's nothing special about this drive. It's a mapping to a share on a file server where I store ISO files. However, for the sake of demonstration, let's use this drive.

As you can see, the I drive is mapped on the PC. If I double-click it, we can access its contents without a problem.

Related:How To Use PowerShell for Automated Event Response

With that said, let me open PowerShell. Once again, I could access the R drive by typing “R:” and pressing enter. I could access the W drive by typing “W:” and pressing enter. I could return to the C drive by typing “C:” and pressing enter. But what about that I drive, which maps to a network location? If I type “I:” and press Enter, I get an error. The error says that a drive named “I” doesn't exist.

Why is that? As weird as it sounds, this error is related to working in an elevated PowerShell session. You won't see the error when I open a secondary non-elevated PowerShell window and try the same thing. When I try typing “I:” in a standard PowerShell session, I can access the I drive. If I type Get-ChildItem and press Enter, I see the contents of that mapped network drive.

Now, this is an interesting dilemma. If you think about it, I mentioned that this disk contains a bunch of ISO files. ISO files are often used by administrators to install a piece of software. And yet, I can't access this drive containing all my ISO files from an elevated PowerShell session.

The Workaround: An Old DOS Command

So, what can I do as a workaround to access this drive from an elevated PowerShell session? Well, at the beginning of this video, I mentioned that many commands built into PowerShell are leftovers from the days of DOS. We can use one of those commands to access a mapped network drive from an elevated PowerShell session. Let's do that.

Related:Tracking Windows Group Policy Changes With PowerShell

I will switch to my elevated session and type “net use.” Again, “net use” is an old DOS command ported into PowerShell, so we don't have to use the dash because it's not a true PowerShell cmdlet. If I were to type “Net-Use,” it would produce an error. I need to type net-space-use followed by the drive letter I want to use. I used the I drive earlier, and I will use it again, but because an elevated PowerShell session is unaware of network drive mappings, we could use any drive letter we want if it isn't a local drive. But I will use the I drive. So, I type “I:” and then the UNC path that I want to map I: to. In this case, it's \\147.100.100.151\ISO.

net use I: \\147.100.100.151\iso

When I press Enter, PowerShell prompts me to enter some credentials. After I've entered my credentials, if I type “I:” and press Enter, I can access the I drive, even though I'm in an elevated PowerShell session. If I type Get-ChildItem and press Enter, I can access the contents of the I drive.

So, use this workaround to access a mapped network drive from an elevated PowerShell session.

Access Files More Quickly

I mentioned a moment ago that Microsoft changed some of the rules for PowerShell drives and that there's a handy trick to make it easier to access some of your files. Let me show you what that trick looks like.

I will switch to my C drive. To make things interesting, I will close out my elevated PowerShell window and do everything from a standard PowerShell session.

After I switch to my C drive, I'll type “cd\” and press Enter. It drops me to the root folder. I have a folder on this machine called “Scripts.” I will type “cd scripts” to go into the Scripts folder. This folder contains a bunch of PowerShell scripts.

As I demonstrated, I had to use a few different commands to gain access to the Scripts folder. Typically, that's not a big deal. However, I use the Scripts folder all the time. We can map a drive letter to the Scripts folder to access it directly.

Before I show you how that works, I must introduce another PowerShell cmdlet: Get-PSDrive. This is a true PowerShell cmdlet, not a leftover DOS command. I'll type “Get-PSDrive” and press Enter, and it shows you all the drives that PowerShell is aware of. It shows the C, R, W drives, and even our network drive mappings. Here's the I and Q drive. Everything that was visible in File Explorer is visible here when I use Get-PSDrive.

Now, some of these items didn't show up in File Explorer. In the “Provider” column, some of these drives are mapped to the FileSystem. For example, the C drive is part of the FileSystem.

There are non-FileSystem mappings here, too. For example, we have Registry drives. Here's HKEY_LOCAL_MACHINE, and the Provider is listed as Registry. Likewise, we have HKEY_CURRENT_USER, and the provider is listed as Registry. We have drives mapped to the Registry: the HKLM drive, and the HKCU drive.

I mentioned earlier that I have a folder named Scripts and can map a drive directly to the Scripts folder to make it easier to access it. Let me show you how that works.

I will use another PowerShell cmdlet called “New-PSDrive.” This command creates new drive mappings. First, we must provide a name for the drive mapping, so I will type “-Name” and then specify what we want to call this drive. Traditionally, with the old DOS-style drive names, which Windows still uses today, we use the letters of the alphabet. The C drive is typically the boot drive. However, if you look at the output from the Get-PSDrive command, we're not restricted to using only letters. We can use words in place of drive letters. That's what I will do here: Rather than mapping a drive letter to the Scripts folder, I will call this “Scripts.”

Next, we must specify the PSProvider. I showed you the PSProvider column. It displays whether a mapping is related to the FileSystem, the Registry, a Certificate, or something else. I will type “-PSProvider” and set the PSProvider equal to “FileSystem”:

C:\scripts> New-PSDrive -Name Scripts -PSProvider FileSystem

Lastly, we provide a path for the drive mapping. I'm going to type “-Root” and specify the path. The path specification must be enclosed in quotation marks. I'll type “C:\Scripts”.

C:\scripts> New-PSDrive -Name Scripts -PSProvider FileSystem -Root “C:\Scripts”

When I press Enter, the drive mapping is completed. So now, if I type Get-PSDrive and press Enter, you can see a drive called Scripts.

When you access a PowerShell drive, you must type the drive name followed by a colon. I showed you how to access regular drives like C and R. You would type the letter of the alphabet, like R, followed by a colon, and press Enter, which takes you to the drive. But if we do that with the Scripts drive, it doesn't quite work. I get an error message.

So, how do we access the scripts drive? Well, we use the “cd” command. The cd command, which you saw earlier, is normally used to change the directory. You can use the cd command to move up and down levels within the directory structure. Normally, all that is done within the currently selected drive. You can use the cd command to switch to a different drive in PowerShell. So, if I want to access the Scripts folder, I type:

cd scripts:

The colon is important. When I press Enter, I'm now in the Scripts folder. If I type Get-ChildItem, I see the contents of the Script folder.

Now, it's worth noting that you can also remove a PowerShell drive. It’s super simple to do. Type “Remove-PSDrive” and then the drive name without the colon at the end (i.e., scripts, not scripts:). When I press Enter, I get an error message because I'm in that drive right now, but when I switch to a different drive and try the command again, the removal is successful. If I type Get-PSDrive, the Scripts drive has been removed.

That's how to work with drives and PowerShell. I'm Brien Posey. Thanks for watching.