We're going to pick up on this demo where we left off on the previous one.
To set the stage for you again, I'm on my host here, ARC2,
and I just completed installing a virtual machine called server1,
this is what you're looking at in the internal machine, and I now
want to demonstrate PowerShell Direct versus PowerShell remoting
from the Hyper‑V host to the guest.
So what I'm going to do is bring up my VS Code, and as
you can see in my terminal output,
I ran hostname to verify that I am on ARC2. First of all, to
demonstrate PowerShell Direct, we can on line 14 do an
Enter‑PSSession, and notice that I'm using the VMName parameter.
Let me run this selection, and I'm going to authenticate with an
account on that virtual machine. And I haven't yet renamed the local
administrator account, which is why I'm providing it here. So now we
can see I'm connected to server1.
If I do a host name,
it's server1. It's kind of weird that it echoes the host name twice in
the remoting session. I'm not exactly sure why it's doing that. But
that's a good demonstration of PowerShell Direct.
Let me Exit‑PSSession,
clear the screen, and the other way to do remoting is Invoke‑Command. And
here again we're using the VMName parameter, and I'm going to get the
status of the WinRM service on that machine. Again,
I have to authenticate, but let me provide that, and then we get the results
back from that server. Okay. We can also create a persistent session object,
like you see here, and then do a Copy‑Item.
So we could say, first of all, authenticate to server1 as a local
administrator and then copy an item from the local path,
C:\scripts\new‑user.ps1 to the destination in the guest VM C:\scripts.
And I'd probably want to create a saved credential rather than have
to interactively put in my credentials each time.
That's super annoying.
But this should be the last time I do it.
And now let's right‑click this guy and run that copy session, and I can
verify that by going to the File Explorer on the virtual machine, and
there's the new user script, copy it into C:\scripts.
Okay. Same idea. Now, with PowerShell remoting, again,
it's literally the same thing, only instead of VMName,
we're using ComputerName.
So we could do the same thing as far as entering a
PSSession or doing an Invoke‑Command.
That's what I'm going to do here. Let me change the WinRM to a different
service, but other than that, I'll do it the same way, and I'll do again
Credential (Get‑Credential). Clear the screen, and let's try this. Now
this assumes that server1 is already enabled for PowerShell remoting,
which I've mentioned a few times is the case by default on Windows Server.
On Windows Client, you would need to enable PS remoting. In other words,
you would need a command like you see here, this ScriptBlock section on 24 to
enable PS remoting on a machine. To finish up, let me verify that this
internal server1 is able to get out onto the internet.
I'm going to do an IPv4 ping against the Syracuse University domain,
and this is just a verification that it works. When I enabled the MAC
address spoofing, this is absolutely critical to configure on the
Hyper‑V host because you've got two layers of virtual switches going
on. So you're going to have MAC addresses flying all over the place at
different levels.
Let's finish up by taking a brief look in Hyper‑V Manager in the VM
Settings. Let me right‑click server1 and go to Settings from the
shortcut menu. A little bit more about RAM,
given that dynamic memory is mentioned specifically on the AZ‑800
certification objectives. Notice you can adjust the amount of RAM,
the startup RAM, while the machine is running.
We certainly can change it after the fact, but notice that we can adjust if
we've got dynamic memory turned on the minimum and maximum RAM allocation, as
well as the percentage of memory that Hyper‑V should try to reserve as a
buffer. And then here's that weight property where we can prioritize the
availability of memory for this VM compared to other VMs on the machine. And
there's a warning that if you set this too low, the VM might not start. If you
set it too high,
you may be robbing other VMs and preventing them from running optimally or
maybe even starting up. Lastly, in order to make sure that you've got as many
of those enhanced session configurations available,
you'll want to make sure that you've enabled all of the
integration services. So as you can see here,
I've got all of them, including guest services, enabled for this virtual
machine, and then I'll click OK to commit my change.
We can see down in the Hyper‑V Manager, if we want to quickly get a check on
what the TCP/IP configuration of the virtual machine is, we can head on over
to Networking and verify the IP address, as well as the IPv6 addresses that
may be in use on that machine, and we also see in the first column the MAC
address that the virtual adapter is using. And actually, that's one more thing
I forgot to show. If I go back to Settings and we go to Network Adapter down
here, this is where you can verify the virtual switch that you're connected to.
We also under Advanced Features can set either a dynamic or a
static MAC address per VM and enable MAC address spoofing here. It
says that MAC address spoofing allows virtual machines to change
the source MAC address and outgoing packets to one that's not
assigned to them. And again,
that's going to be necessary when you're passing through two layers of virtual switches to reach your physical network.