Good day, Cloud Gurus.
And welcome back for this lesson
where we're going to take a look
at configuring PowerShell remoting.
Let's take a look at what we're going to cover.
First up, we'll do a bit of an introduction
to PowerShell remoting.
And then we'll take a look
at the types of PowerShell remoting that you can use.
We'll take a look at session types.
We'll also take a look
at how you can configure PowerShell remoting.
And then we'll wrap up with a fairly decent demo
of PowerShell remoting.
I'm really looking forward to taking you through this.
So let's jump in.
Throughout this course we've been using PowerShell
to complete a range of administrative tasks,
but all the tasks we've completed so far
have been run against the local computer
that we're logged onto.
The advantage of Powershell remoting
is that you can execute commands against computers
without having to directly log onto those computers.
Now, this might not seem like much.
Only having saved a few seconds
that it would normally take to log on.
The process of connecting to one computer remotely
is known as one-to-one remoting.
But with PowerShell remoting,
you can target multiple computers with your commands.
And this is known as fan-out remoting,
or one-to-many remoting.
And you can also have multiple administrators
run commands against a single computer
without the administrators stepping on each other's toes.
And this is known as fan-in remoting
or many-to-one remoting.
And you can also use what's known as PowerShell Direct.
While not exactly the same as PowerShell remoting,
PowerShell Direct allows you to execute PowerShell commands
on VM guest operating systems from Hyper-V hosts.
But we won't cover PowerShell Direct in this section.
Instead, we'll take a look at PowerShell Direct
in a later section where we take a look at Hyper-V.
And PowerShell remoting is a fundamental building block
of modern Microsoft management tools,
like Windows Admin Center,
which will also cover later in this section.
When you execute PowerShell commands,
they are typically executed against the local computer.
But the computer name parameter
is available with many PowerShell cmdlets.
And that allows you to specify a remote computer
or multiple remote computers.
In most cases, when you execute cmdlets
using the computer name parameter,
it uses a mix of technologies,
including Windows Management Instrumentation
to query the remote computer and return the result.
Using most cmdlets with the computer name parameter
doesn't require any special configuration.
With this configuration, PowerShell is only executed
on the local computer,
but the queries and actions are sent to the remote computer.
cmdlets that use this method
are cmdlets like, Restart-Computer, Test-Connection
and Get-Service.
But this is not true for all cmdlets.
In-store Windows feature, for example,
accepts a computer name parameter,
but it actually uses PowerShell Remoting
to install a Windows feature.
Now this can get confusing.
You can use the Get-Help command
to determine if a cmdlet needs PowerShell remoting
when using the computer name parameter.
Now, when you use PowerShell remoting,
it works a little differently.
You have a PowerShell session on your local computer
and you create a PowerShell session on the remote computer.
PowerShell remoting sends the command
to the remote computer.
It is executed on the remote computer
in the remote PowerShell session.
And then the result is sent back to your local computer.
Typically in the form of an object
or a collection of objects.
And objects might seem like a programming term for us,
but it just means things and their attributes.
An example of an object would be a user account,
and the attributes of that user might be their username,
their first name, and their last name.
This type of PowerShell remoting
is referred to as Windows Remote Management or WinRM.
And how the data is transported back and forth
between the 2 computers
is done using Web Server Management or WSMan.
Now, the reason I mentioned both WinRM and WSMan
is because you'll see those terms pop up
as we configure and use PowerShell remoting
later on in this lesson.
And PowerShell remoting communication occurs over TCP
using HTTPS port 5986,
or HTTP port 5985.
Now with PowerShell remoting,
you have a few options available
for the types of session you can use.
The first is an interactive session
where you create and connect directly
to an interactive remote PowerShell session
using the Enter-PSSession cmdlet.
And then you can exit the session when you are done.
This is great for one-on-one remote.
You can also create a non-persistent session
that exists only to run the command you specify
with the Invoke-Command cmdlet.
This is great for one-to-many remoting
because you can specify multiple computers
with a computer name parameter,
and the results from all the computers
are sent back to your local PowerShell session.
And finally, you can create a session
that persists over multiple commands.
This is useful when you need to perform
multiple independent steps
and keep information between those steps.
And we'll take a look at each
of these PowerShell remote session types in the demo.
Now to use PowerShell remoting,
there are a few prerequisites
and most of these won't be a problem
on a modern version of Windows Server.
But let's take a look.
Firstly, you need to have Windows PowerShell 2
or later on the source and target computer.
And you'll also need the Microsoft .NET Framework
on both the source and the target computer.
And you need to have Windows Remote Management
that matches the version of PowerShell
that you have installed
and this again needs to be on both computers.
And by default, you will also need administrative privileges
on the remote computer.
But this is configurable, and we'll take a look
at how you can do this in a later lesson.
And if you want to configure WSMan,
you also need to be an administrator on the local computer.
To configure PowerShell remoting,
you can use the Enable-PSRemoting PowerShell cmdlet
on the target computer.
And you can also use Group Policy for this.
And I'll provide a link for how this can be done.
You'll also need to configure the Windows Defender Firewall
to allow access.
And finally, if you want to connect to a remote computer
that is in a work group using the IP address,
you'll need to configure a listener on the remote computer
to use HTTPS and connect using a DNS name.
But this requires installing a certificate
and adding it to the HTTPS listener.
And because we don't want to spend the remainder
of this lesson configuring certificates
and because we're in a lab environment,
we can configure the TrustedHost setting
on the source computer.
But this is not recommended in a production environment
because it's less secure.
Let's take a look at a demo of PowerShell remoting.
We'll complete this demo
from our administrative server, CORP-BNE-ADM01.
Now the first computer we want to connect to
using PowerShell remoting is not domain joined.
And the second computer, CORP-BNE-DC01,
is in the same domain as our administrative server.
In this demo, we will configure the 2 computers
for PowerShell remoting
and we will test interactive, persistent,
and non-persistent PowerShell remoting.
Let's take a look at the demo.
All right, let's first configure our work group computer
which is VM1.
First, we'll use PowerShell to enable PowerShell remoting.
So I'll just right-click the Start button
and select Windows PowerShell.
And then we can enable PowerShell remoting
with the Enable-PSRemoting command.
And I'm going to provide the force parameter
to suppress any prompts related
to enabling PowerShell remoting.
And then we can go ahead and run that.
All right, and now we just need to confirm
that our Windows Defender Firewall
is configured to allow remote management.
So we'll just go ahead and launch Administrative Tools
and I'll scroll down and select Windows Defender Firewall.
And then we'll select Inbound Rules.
And then we'll scroll all the way down to the bottom
and we can see there's a Windows Remote Management HTTP-In.
And I'll just drag this center pane out a little bit.
And then I'll just drag the profile out a little bit
and we can see that Windows Remote Management
is enabled for the public profile
and the domain and private profiles.
All right, now let's configure our domain PC.
So we'll jump over to CORP-BNE-DC01.
And we'll run the Enable-PSRemoting cmdlet here as well.
All right, now we also need to make sure
that the Windows Firewall Network Profile
is set to DomainAuthenticated.
And we're going to use the Get-NetConnectionProfile command
to check that.
So we'll go ahead and run Get-NetConnectionProfile
and we can see it set to DomainAuthenticated.
Now, the reason we need to check this is, by default,
the Windows Defender Firewall
is configured to only allow PowerShell remoting
from the same subnet if the network profile is set to public
but because the firewall profile is set to domain,
it will allow PowerShell remoting from the entire network.
So if you go to configure PowerShell remoting,
and your firewall profile is not set to DomainAuthenticated,
check your DNS configuration
and make sure you have a domain controller available
and then check your profile again.
All right, now let's log on to our administrative server
and test PowerShell remoting.
So here we are on our administrative server, CORP-BNE-ADM01.
And because VM1 is not in the same domain
as our administrative server,
and we want to connect without configuring HTTPS.
We need to configure the WSMan TrustedHost settings
on this computer.
So we're going to go ahead
and run a couple of PowerShell cmdlets
to check and set the WSMan TrustedHost configuration.
So we'll go ahead and launch PowerShell.
And the first command we need to run
is to confirm the current TrustedHost settings.
So we're going to run the Get-Item cmdlet
and we're going to specify WSMan:\localhost
\Client\TrustedHosts.
All right, and we can see here,
we currently have no TrustedHost configured.
We're going to need to have VM1 specified here.
So I'm going to go ahead and add the IP address
for VM1 as a TrustedHost.
And to do that, we'll use the Set-Item PowerShell cmdlet
and we'll provide the value, which is the IP address for VM1
which is 10.1.11.15.
We can go ahead and run that command.
And it's just confirming that we want to add
this computer as a TrustedHost.
We're going to go ahead and select Yes.
All right, now let's rerun Get-Item
to confirm that the TrustedHost has been added successfully.
So I'll just press Up on the keyboard twice
and then press Enter to run that command.
And we can see, we now have the IP address for VM1
configured as a TrustedHost.
Now let's test interactive, one-to-one remoting
using Enter-PSSession.
Firstly, we'll do this on the work group PC.
So I'll just clear the screen here.
And then we'll run Enter-PSSession.
We'll provide the computer name using the IP address for VM1
and then we'll specify our credential, AdminUser,
and it'll prompt for our password.
I'll provide the password for the AdminUser account.
All right, and we're now logged on
using PowerShell remoting to VM1.
Let's go ahead and run a command
to create a new local user on VM1.
So to do that, we'll use the New-LocalUser PowerShell cmdlet
and then we'll provide a name for the user
and then it'll prompt for a password.
We'll go ahead and provide a password
for this new local user.
All right, and we've now successfully
used PowerShell remoting to create a new local user account
on that remote computer, VM1.
Let's go ahead and exit this PSSession.
All right, let's go ahead and clear the screen again.
Now let's test one-to-one PowerShell remoting
using the domain PC.
We're going to run Enter-PSSession again.
And we're going to provide the computer name,
which is our domain controller's computer name.
And we don't need to provide credentials here
because it's going to use my current domain credentials,
which is nice and secure.
All right, now let's run Get-LocalUser
against our corporate domain controller.
And we can see here, it's actually pulling in
the domain user accounts,
including the computer accounts
and that's because CORP-BNE-DC01 is a domain controller
and it doesn't have local user accounts.
So instead, it's pulling in those active directory accounts.
All right, let's exit this PSSession.
And we'll clear the screen again.
All right, now let's execute a command
using a non-persistent session.
To do that, we're going to use
the Invoke-Command PowerShell cmdlet
and we'll execute it against our domain controller.
And to specify the command
that we're going to execute against the remote computer,
we'll use the ScriptBlock parameter
and we'll include that inside curly braces
and we're going to use the Get-TimeZone PowerShell cmdlet
on the remote computer.
All right, and we'll receive back the results
of that PowerShell cmdlet from CORP-BNE-DC01.
Now finally, let's create a session
and invoke a couple of commands against that session.
I'll go ahead and clear the screen again.
And then we'll create a session
with the New-PSSession PowerShell cmdlet.
And I'm storing this session in the session variable.
So we'll go ahead and run that command.
Then let's go ahead and run a command against that session.
So we'll use Invoke-Command again
by the session that we want to execute the command against.
And then we'll specify this ScriptBlock
that we want to execute.
And what I'm doing here in the ScriptBlock
is I'm setting a variable named $persistent
to a value of true.
And this variable will only contain that value of true
if the session remains running
after I finish executing the command using Invoke-Command.
So we'll go ahead and run this command.
Now let's run Invoke-Command again
and we'll check the value of the $persistent variable.
All right, and we can see here that that session
has remained running throughout multiple Invoke-Commands
and it's still running on that remote computer
and we can see it's returned the value of true.
All right, that concludes this demo.
Let's go and wrap up with a bit of a summary
of what we've covered in this lesson.
PowerShell remoting enables you to execute
PowerShell commands against remote computers
using WinRM and WSMan
over ports 5985 and 5986.
And you can enable PowerShell remoting
using the Enable-PSRemoting cmdlet.
You can enter an interactive PowerShell session
using the Enter-PSSession cmdlet.
And you can also create a remote PowerShell session
with the New-PSSession cmdlet.
And you can also use Invoke-Command
to execute commands against remote computers
with or without a persistent session.
All right, thanks for being with me in this lesson
and I hope you found it useful,
and I look forward to seeing you on the next lesson.