Last time we played with PowerShell Drives. In this part we dedicate ourselves to the structure of PowerShell, especially the PowerShell Module structure. But first, let’s look at the exercise from the last part.

All parts of the series can be found here: PowerShell for Beginners (Series)

Review (Part 11)

In Part 11 I ask for this:

Discovering
Find out how to show the Computername with the PS Drive env.

Creating
Create a new persistent PowerShell Drive that refers to a shared folder on a remote computer. Find out how to make this drive persistent. (Use the Online Help, the Local Help or whatever)

Let’s do the first more easy part. To find out the computer name we have to browse the env: directory. There we’ll find the computer name environment variable, stored in a PowerShell Drive.

cd env:

dir *computer*

But most of all it’s called that way:

$env:computername

The second task asks for creating a persistent PowerShell Drive which refers to a shared folder. For mapping a network drive to a shared folder “Data” on Client01 for the drive letter F, the command looks like this:

New-PSDrive -Name F -PSProvider FileSystem -Root \\Client01\Data -Persist

A quick glance in the Windows Explorer shows that the drive is correctly mapped:

That’s it. Let’s move on with PowerShell Modules.

Summary

A Windows PowerShell drive is a data store location that you can access like a file system drive in Windows PowerShell.

What are PowerShell Modules?

Some may think knowledge about Modules is not a topic for beginners. I don’t think so, because you have to understand why some commands are available on a Windows Server, for example on a Domain Controller, but not on a Client operating system. All these procedures are controlled by PowerShell Modules. Let’s take a look at the original description by the PowerShell team:

A module is a set of related Windows PowerShell functionalities, grouped together as a convenient unit (usually saved in a single directory). By defining a set of related script files, assemblies, and related resources as a module, you can reference, load, persist, and share your code much easier than you would otherwise.

https://msdn.microsoft.com/en-us/library/dd878324(v=vs.85).aspx

So far so good. They say it’s a set of functionalities. And they are grouped together in a unit.

Summary

A module is a set of related Windows PowerShell functionalities, grouped together as a convenient unit (usually saved in a single directory). It’s usually a set of commands and codes.

Finding PowerShell Modules with PowerShell and File System

As you may suspect, there’s a command for this task.

Get-Module shows you the currently imported modules. Note that these modules are a set of commands, as mentioned above by the PowerShell team.

Get-Module

But there’s more. There’s much more! To list all modules run

Get-Module -ListAvailable

What’s the difference between ListAvailable and the three modules above? All Modules are imported automatically if you try to run one of the module’s commands. That’s an important point when it comes to scripting.

For example my little script Do-Speak which can be found here Do-Speak: Start talking with Remote Computers (System.Speech) is listed in the Module Do-Speak.

If I try to run this command the module which hast the same name than the command is loaded automatically into the current PowerShell Session.

Now after running my custom script, I can see the module loaded into the current session.

The same is true for buit-in modules by Windows Server Roles and Features. If you run any Active Directory command, then the corresponding module is loaded into the PowerShell session.

There are many ways to show all commands of a module. I’ll show you two of them.

(Get-Module ActiveDirectory).ExportedCommands

Or, in my opinion, the better choice:

Get-Command -Module ActiveDirectory

So our last question for this part is how can we find something about this modules? Where are they stored? Can I get more information? The answer is Yes.

The default folder for modules that are shipped with Windows is here:

cd $PSHome\Modules

If you write your own script place it here for all users:

cd $Env:ProgramFiles\WindowsPowerShell\Modules

Last, but not least the location for the current user:

cd $Home\Documents\WindowsPowerShell\Modules

Ok that’s it for this part.

What have we learned so far?

Get-Module lists all currently imported modules. Get-Module -ListAvailable lists all modules which are automatically imported when your run a command of these modules. Store all custom modules in C:\ProgramFiles\WindowsPowerShell\Modules.

Installing Modules (Windows Server Only)

When you install new roles or features on Windows Server then you have to take care that the associated PowerShell Module is also installed.

For example, if you promote a Windows Server to a Domain Controller make sure you provide the IncludeManagementTools parameter. This includes all Active Directory graphical tools and the Windows PowerShell Module. If you do not provide this parameter the Server will be promoted (after you run New-ADForest or New-ADDomainController) to a Domain Controller, but you have to administer the Server from a remote computer, because there are no tools available to administer the Server locally. No Active Directory Users and Computers (dsa.msc), no AD Sites (dssite.msc) … Crazy thing hu?

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

If you install new Roles and Features graphically via Server Manager make sure the right checkboxes are selected:

Otherwise there is little to say about this topic, since everything happens automatically.

Using Custom Modules

Let’s say you find a very interesting script. You download it. Then you have the code. You open it with PowerShell ISE. It’s the script above. It tests the connectivity to the Default Gateway. Best of all, you don’t even need to know the IP address of the gateway. And it works on remote computers as well.

function Test-Gateway {
param($Computer = $null,
 $Count = "1")
If ($Computer -eq $null)
{Test-Connection -Destination (Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Select-Object -ExpandProperty Nexthop) -Count $Count}
 else
 {$Route=Invoke-Command -ComputerName $Computer {Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Select-Object -ExpandProperty Nexthop}; Test-Connection -Source $Computer -Destination $Route -Count $Count}
 }

You think you’ll surely need this script very often. What’s wrong with making a module out of it? The big advantage is that the command (Test-Gateway) is then available every time you start PowerShell. That’s a good thing, hu?

Before we begin copying the file, create a “Test-Gateway” folder. Note that the file name and the folder name must match!

Then copy the code in PowerShell ISE. (To open ISE type ise).

Save the file as Test-Gateway.psm1 (psm1 is the file assocation for PowerShellModules) in your recently created folder.

Now close PowerShell. Open PowerShell again. Try to run Test-Gateway without any parameters.

From now on the command (module) is available in every PowerShell session for all users.

By the way, to view the code of the script run

 

Get-Command Test-Gateway -ShowCommandInfo

or

Get-Command Test-Gateway | Select-Object -ExpandProperty ScriptBlock

Remember that we have already learned something about Select-Object: PowerShell for Beginners (Part 8): The Power of PowerShell – Getting in Touch with Objects (Get-Member, Select-Object)

What have we learned so far?

When installing Roles and Features verify the checkbox “Include Management Tools”. Use PowerShell ISE for importing custom modules and codes. Create a folder in  C:\ProgramFiles\WindowsPowerShell\Modules and make sure the folder and the file name match. Save the code as psm1 file. PowerShell will then import the module every time you run the command.

Exercise

Here is the exercise til next part.

For this part it’s an easy, but very important task to get familiar with PowerShell modules:

Go to https://sid-500.com/2018/02/02/powershell-test-open-tcp-ports-with-test-openport-multiple-hosts-multiple-port-numbers/ and make this command (code) available to all users in all PowerShell Sessions.

See you next time at the topic: PowerShell for Beginners (Part 13): PowerShell Remoting

Patrick Gruenauer, MVP PowerShell