We'll start with creating PSDrive in FileSystem provider.
In the first example,
I'll create a temporary PSDrive which will map to a folder on my local machine.
I'll take an example of Downloads folder path.
So what we will be doing is we will create a new PSDrive that
will map to the current user's Downloads folder.
First, I'll enter the command New‑PSDrive.
I'll then use Name parameter to provide this drive a unique name.
Since we are creating this drive to map it to Downloads folder,
it makes sense to set the name as Downloads.
Next, in the Root parameter,
I'll enter the complete folder path where I want this drive to be mapped.
In this case, I'll map to current user's Downloads folder.
I'll then specify the PSProvider where I want this drive to get created.
Since it's a folder that I'm creating on my logical drive,
it will be FileSystem provider.
As soon as I hit Enter, we can see that the new PSDrive got created.
This will also list some of the properties of this newly created PSDrive.
We can see Name, Provider, Root property,
along with Used and Free space of the drive.
Now when I run Get‑PSDrive command, this newly created drive will be listed.
I will then use Set‑Location command and enter the name of
this PSDrive to enter into this drive.
I can then run any of the management commands that we saw earlier in
this module to manage files and folders in this drive.
Just to demonstrate,
I'll run Get‑ChildItem command that will list all the
files and folders in this path.
I'll quickly open another PowerShell session. To
differentiate between the two PowerShell consoles,
I have used different text color in this window. I'll now run Get‑PSDrive
command. Here we can see that the Downloads PSDrive that we created in
another PowerShell session does not appear.
This is because temporary PSDrives are sessions specific.
They will be available to use only in the session they are
created. In the next example,
I'll create a persistent PSDrive and map Shared folder on a network.
I have already created a Shared folder on DC server,
which we will be using in this example.
Remember a few rules of persistent drives. Persistent drives
require a drive letter to be assigned instead of a name. Persistent
drives cannot be mapped to a local folder.
Persistent drives are available across PowerShell sessions.
I'll run New‑PSDrive command. At first, just to see what
happens, I will intentionally enter the name instead of a
drive letter in the name parameter.
I'll enter SharedPSDrive. I'll then enter local path instead of network path
in the Root parameter. I'll enter local folder path C:/Users. I'll enter
FileSystem in PSProvider parameter, and to make this drive as a persistent
drive, I'll add Persist parameter at the end.
When I execute this command, we get an error.
The error says when you use the Persist parameter the root must be
a file system location on a remote computer.
This proves that a persistent drive cannot be mapped to a local folder.
I'll now replace the path with the Shared folder that I created. I'll enter
DC\Shared. Again, when I run the command we get an error.
The error basically says that a drive letter should be used to map folder.
This proves that a persistent drive can be mapped only to a drive letter.
Now I'll replace the value in the name parameter with K drive. You can use any
available drive letter here. When I hit Enter, the command succeeds and the
drive gets created. When I run Get‑PSDrive command,
we can see that K drive is created. We can also see Downloads PSDrive
that we created earlier in this PowerShell session.
Now, when I switch to another PowerShell session and run Get‑PSDrive command,
we can see that unlike temporary drives, K drive,
which is a persistent drive, is available to us.
We can also enter into this drive using Set‑Location command. This is what
persistent drives are meant for. You can create it in one PowerShell session and
can use it in some other PowerShell session as well.
This persistent drive, however, will not be available
to us when the system restarts.
However,
we have a workaround if you want to retain the
drive in every PowerShell session,
even if the system restarts. You might have heard about PowerShell
profiles. If you're not aware about PowerShell profiles,
just remember that it's a PowerShell script that runs
whenever PowerShell starts. You can customize your
PowerShell environment by adding commands,
functions, variables, modules,
and PowerShell drives and PowerShell profiles, so that
whenever a new PowerShell session is launched,
all the configured settings in PowerShell profile will get loaded. Now
there are different types of PowerShell profiles that you can
configure, but we won't discuss about these types in this course, as
this is beyond the scope of this course. You can learn more about
PowerShell profiles from this link.
For this demo,
I'll create PowerShell profile for all users and all
hosts. You will see profile.ps1 file inside Program
Files\PowerShell\7 folder. By default,
it is not present, and in that case you can create a new one. I'll quickly
open this file and copy the command that will create a new persistent
PSDrive and map it to the DC server's Shared folder.
Note that I am mapping this folder to S drive. I'll quickly
restart my system, and once the system restarts,
we will see whether the PSDrive got created. The system is now
rebooted. I'll now open PowerShell. We can see a message that
says PowerShell profile has been loaded.
This profile has added the PSDrive.
When I run Get‑PSDrive command,
we can see that the new PSDrive has been added that
maps to a Shared folder on DC server.
This is how you can deal with persistent PSDrives that you want to retain even after the system reboots.