Solved Pssession- computername vs vmname for Enter-pssession

---

I guess I'm thonking if the hyper-v server is aware of the vm's why wouldn't either cmdlet work?

@John-DeWilde ,

When you first create a VM, there is no operating system. You still have to call the VM something. Lets say you call it demoVM. This is the VM name. Only the Hyper-V server that you created the VM on knows this name.

Now you install Windows in the VM. As part of the installation, Windows generates a random name, something like desktop-egjdsd. This is the computer name. This is what the network sees. This is the name that gets registered with DNS so other machines on the network can find it. Most people will change this name to something more meaningful. Like myLaptop, or client01. This is the name you set in system preferences.

But this doesn't change the VM name. It is still listed in the Hyper-V console as demoVM. You can change them to match, but they are independent, and changing one doesn't change the other.

Now when you want to create a PSSession, the name you use to identify the VM you want to connect to depends on where you are connecting from.

If you are connecting to the VM from the Hyper-V host that the VM is running on, you must use the -VMName parameter.

If you are connecting to the VM from anywhere else, you must use the -ComputerName parameter.

@John-DeWilde said in Pssession- computername vs vmname for Enter-pssession:

I guess I'm thonking if the hyper-v server is aware of the vm's why wouldn't either cmdlet work?

That's just the way it was designed. There is an inherit trust between the Hyper-V host and the VMs on that host. When you use the -VMName parameter, the VM does not need to be listed in your TrustedHosts. The Hyper-V server can connect to the VMs that are running on it anyways. This makes it easier to manage the VMs.

@Mike-Rodrick said in Pssession- computername vs vmname for Enter-pssession:

@John-DeWilde ,

When you first create a VM, there is no operating system. You still have to call the VM something. Lets say you call it demoVM. This is the VM name. Only the Hyper-V server that you created the VM on knows this name.

Now you install Windows in the VM. As part of the installation, Windows generates a random name, something like desktop-egjdsd. This is the computer name. This is what the network sees. This is the name that gets registered with DNS so other machines on the network can find it. Most people will change this name to something more meaningful. Like myLaptop, or client01. This is the name you set in system preferences.

But this doesn't change the VM name. It is still listed in the Hyper-V console as demoVM. You can change them to match, but they are independent, and changing one doesn't change the other.

Now when you want to create a PSSession, the name you use to identify the VM you want to connect to depends on where you are connecting from.

If you are connecting to the VM from the Hyper-V host that the VM is running on, you must use the -VMName parameter.

If you are connecting to the VM from anywhere else, you must use the -ComputerName parameter.

I still don't understand that. If the hyper-v host can see it wouldn't the dns server also see it? It would have to if you can connect to it by name using computername.

@John-DeWilde ,

Nope. The VMName is not a DNS name. Think of it more like a folder name. Remember, in the end, a VM is a collection of files. The VM name in the Hyper-V console can be descriptive, and helps manage the VMs.

For example, I might have a VM named svr01. It belongs to the domain itpro.tv. The hostname for this machine is svr01. The FQDN for this machine is svr01.itpro.tv. The FQDN is what is registered with DNS. This is the name that other machines on the network see.

The name of the VM in the Hyper-V console is completely separate. It has nothing to do with the hostname of the server or the FQDN. It isn't registered anywhere. It is only used in the Hyper-V console to name the VM. You could name it the same as the hostname, SVR01. But this name doesn't tell you much about the VM. Lets say another admin opened the Hyper-V console. They see the VM named svr01. They wouldn't know what the OS was, what roles were installed, etc. They would have to start the machine and log in to find out. Now, if we named the VM something like WS16-DB-itprotv, we could tell from the name that the vm was running Windows Server 2016, was a database server, in the domain ITProTV.

When you only have a couple of VMs, this might not seem all that important. You know what your machines are and do. But in an enterprise environment, you might have 100's or 1000's of VMs to manage. There might be several administrators, and many machines that you didn't create. Having a good VM naming convention becomes extremely important.

I know in my shows I use simple names like laptop01, but in a production environment, this wouldn't work for long.

If you want some examples, check out this blog. He has a really well thought out naming convention.

https://www.hansmichiels.com/2016/05/08/a-naming-convention-for-virtual-machines-and-home-networks-windows-user-series/

Ok, I get the difference between the vm name vs computer name. The computer name is what I'm referring too. The one in system preferences. Not the one in hyper-v mgr. In my case I just made them the same.

If the running vm with the computer named the same as the vmname can see dns shouldn't either cmdlet work? Do they need to be named separately in order to use either cmdlet?

@John-DeWilde ,

Either will work, but the requirements aren't the same.

When you use Enter-PSSession -VMName, you are actually using PowerShell Direct.

PowerShell Direct allows Windows PowerShell management inside a virtual machine regardless of the network configuration or remote management settings on either the Hyper-V host or the virtual machine. This makes it easier for Hyper-V Administrators to automate and script virtual machine management and configuration.

This makes managing VMs using PowerShell a lot easier. If you can log on to the Hyper-V host, you can use PowerShell commands to manage the VMs on that host, even if the VM is not on the same network, is not part of the same domain, is not in your trusted hosts list. Without any additional configuration, you can manage the VMs running in Hyper-V, as long as you are a Hyper-V admin and have valid credentials on the VM.

When you use Enter-PSSession -ComputerName, you need to meet certain requirements and have everything configured to support remote PSSessions. This is why it works when you use -VMName from the Hyper-V host and fails when you try to use -ComputerName.

In order to use -ComputerName, the Hyper-V host needs to be configured properly:

Has remote management been configured on the VM? (Enable-PSRemoting)

It must be able to resolve the DNS name (NOT the VMName). Can you ping the VM by name from the Hyper-V host?

There must be network connectivity.

• Is the VM connected to a network?
• Have a valid IP address?
• Is the Hyper-V host also connected to this network (directly or routed)?
• Is the network the VM is connected to is a private? The Hyper-V host cannot connect to this network.

Is the VM in the same domain as the Hyper-V host? If not, is the VM listed in the TrustedHosts list?

So there is a lot of configuration that has to happen before you can remotely administer a VM. This is where PowerShell Direct comes to the rescue. There are much fewer requirements to allow PowerShell Direct.

Configuration requirements for PowerShell Direct:

• The virtual machine must be running locally on the host.
• The virtual machine must be turned on and running with at least one configured user profile.
• You must be logged into the host computer as a Hyper-V administrator.
• You must supply valid user credentials for the virtual machine.

Make note of that first bullet. PowerShell Direct (-VMName) is only available from the Hyper-V host.

https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/powershell-direct
https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-windows-virtual-machines-with-powershell-direct

@John-DeWilde ,

The reason -VMName works for you is because it doesn't need any additional configuration.

If you configure it properly -ComputerName will work as well.

@Mike-Rodrick @Mike-Rodrick A million thank you's for all of your assistance and expertise. I thought I had configured everything for computername access, but I'll go through the set up again. Powershell for me is squeezing square peg into a round hole. Do you know where in the menu I can find the solved option?

@John-DeWilde ,

You're welcome, glad I could help!

Let me know if have more questions later, it can be tricky when dealing with a workgroup environment.