Okay, so now that we've added trusted host entries,
we've also got the credentials,
our next task is to look at creating and removing PowerShell sessions,
which is really the objective here,
is how do we connect and create sessions for management?
So to create PowerShell sessions,
we can use what's referred to as the ‑ComputerName parameter.
Now, not every cmdlet in PowerShell provides this, but some of them do.
So we can actually go in and say execute this command,
blah blah blah, ‑ComputerName and then pass the name of the
computer we want to execute the command on.
And what that will do is, as long as remoting is enabled,
it will then send the commands directly over to that machine and
then execute them and return any information back.
The second option is to utilize what's called Invoke‑Command. Invoke‑Command
allows me to say this is the machine or set of machines,
invoke the command on those machines,
and it will do the same thing as using the ‑ComputerName.
We also have what's called using Interactive PowerShell sessions.
Now an interactive PowerShell session is effectively that.
It's as if you are on the other machine writing commands,
and they are executing.
So how do we create a session using the Invoke‑Command?
Well,
you can see from here the Invoke‑Command also takes a ‑ComputerName property.
So in this instance, I'm going to say invoke this command on this computer,
so 10.0.0.5, so probably our Active Directory Server,
and then the ScriptBlock is what I want to execute,
so in this instance it's going to be another PowerShell command.
So what you can expect from here is I want to get the computer
information from the Globomantics Active Directory Server.
I'm going to execute this command.
It's going to run Get‑ComputerInfo over there,
and then return the values back to me.
Now, of course,
what happens if you don't want to run an existing PowerShell command,
but you want to run a PowerShell script that you've already
written or saved or copied somewhere?
In that instance, the syntax is the same,
except we don't use ScriptBlock this time; we use FilePath,
and the FilePath is to a location where that PowerShell script belongs.
We can also then create what's referred to as
persistent connections and execute commands.
Now what that means is, we're actually going to create the session first,
a persistent session,
which means it's not going to go away until we kind of close it down.
So that would dictate that when we use an
Invoke‑Command or use the ‑ComputerName,
it's only for a short space of time, which is correct.
So if we want to retain that session for later use,
to be able to drop in and out of the session,
then we first use New‑PSSession, so new PowerShell session,
to the remote computer,
and then once we have that we can then use Invoke‑Command
but instead of passing the ‑ComputerName,
we pass the session that we already created and then
whatever commands we wish to execute.
So fairly straightforward to be able to do that.
So a couple of different ways I've been able to send commands and
PowerShell scripts to remote machines and have them execute.
Now we did talk about using interactive sessions.
Now,
an interactive session requires us to use something called
Enter‑PSSession or maybe New‑PSSession.
If I choose Enter‑PSSession,
this will connect to a PowerShell session on that remote computer.
And basically, it means that my commands in my session are those ones.
That's exactly how things would work if you are,
again, connecting to some of the Microsoft services in the cloud,
for example, like Exchange Online, you'll connect into a PowerShell session,
and then you're able to execute commands.
Now, if we use the New‑PSSession,
we can create a brand‑new PowerShell session that we can of course re‑utilize,
which means, again, we can utilize the persistent option.
So persistent just means that we create a new PowerShell session,
put it into a variable, and it becomes usable to us later.
We can also connect to a PowerShell session on a specific computer by using
different credentials, or even the port can be different.
Now of course, this needs to be configured,
but you can simply say, well, when I connect to this machine,
I want to pass this credential versus this credential.
Now remember the combination of things that we need here.
So,
if you're trying to connect to the Globomantics File Server but the
workstation that you're on is not on the domain,
then you're going to be passing in credentials that
are not part of the workstation, but you'll also need to be a trusted host.
Now of course, finally, we can also remove PowerShell sessions,
so Remove‑PSSession will basically remove a session that exists,
but, of course, we need to know what those are.
So to retrieve any of the PowerShell sessions that might exist,
we can choose Get‑PSSession.
That will list them all out with a unique identifier,
and then we can either enter them, remove them,
or just retrieve details about the sessions.
Okay, so let's talk about Globomantics sessions.
So, we're back to our diagram here, so we have Active Directory Server,
we have File Server, and then we have an admin workstation.
We know that the ones on the left are all connected to the domain,
and, of course,
we can create Session 1 and Session 2 because they are different machines.
So in the right‑hand side here,
you'll see that I'm going to create some variables,
so $s1 equals the IP address of Active Directory Server,
and $s2 is the variable for the File Server IP address.
Now to connect to them,
I can simply say Enter‑PSSession and tell it that the session I wish to
connect to is the IP address of the Active Directory Server and then have it
go and execute that command, such as Get‑ComputerInfo.
I could then in the same console do Enter‑PSSession and this time connect to
the separate session and, obviously, run that same command.
So you can see from a PowerShell perspective,
we're able to kind of drop in and out as we need to and connect to not
just one machine but multiple machines at the same time.
Now from a PowerShell session management, we have some core capabilities.
The first one is the ability to get an existing session or
list of sessions, and once you have a session, then we can
enter back into that session.
We can also create new or remove sessions as needed,
so New‑PSSession or Remove‑PSSession.
We also have the ability to exit from a session if we need to.
We can also then reconnect into a session, as well as
importing and exporting in and out of a session, and then
we can enter a session as well.
Now, when we create the sessions, it's not just a every
connection is the same. It can be different.
So we have the ability of modifying the session properties that
would be utilized for a specific session.
This is done by utilizing what's called the New‑PSSessionOption command.
This allows me to set specific properties such as compression,
access properties, certificate settings,
encryption capabilities, language, application arguments,
as well as any of the timeouts.
So we can define a new PowerShell session option,
and when we initiate the session, let's say,
from our admin workstation to the Active Directory Server in the domain,
I can set various properties to ensure that it connects in a certain way.
Now to create session options,
we can set a default one by just using New‑PSSessionOption.
What we can do instead is we can define specific
session options for what we're using.
So for example, here I'm creating a new PowerShell session option.
I'm then setting the timeout for open connection, I'm turning off encryption,
and I'm using the UICulture or the language to be, the current language culture
that's used there. To utilize this in a connection, we can then choose
New‑PSSession ‑ComputerName, as we did before,
and then you'll notice a new property called ‑SessionOption that
allows me to pass the options into that connection.
Now what that means is that the connection will
adhere to the various properties,
but it also means that when we retrieve any of the sessions, so Get‑PSSession, you'll see some of those extra properties listed in there.