One of the networking cards has it's network type set to public. Firewall exceptions do not work with public network type connections (since there are no exceptions for public network). Change the network connection type to eitehr Domain or Private and try again.

Add-VMNIC only adds the virtual hardware. The public/private setting is in Windows itself, and as far as I know can't currently be configured with PowerShell (not easily in any event). So you'll need to set it within the VM. It isn't a Hyper-V setting.

The first error is the important one. The second command didn't work because the New-PSSession command failed.

It's telling you that it was unable to authenticate. Your screen shot doesn't include the entire error message, but it appears as if your machine was unable to contact an authentication server - in a domain environment, that would be an Active Directory domain controller. If you're trying to authenticate to a local machine, then you have to enable an authentication protocol other than Kerberos in WinRM. Read the "about_remote_troubleshooting" help file for information about authenticating WinRM in a non-domain scenario.

I have read that document, but I still have a problem with the credentials. Below is a sample topology of my servers. I have permission to run the script only from MainHost. the MainHost server has a HyperV Manager, so I can see all VMs that belongs to Hyperv54 and HyperV56. Also, I can control that VMs without facing any problem (For example, adding NICs and other operations). But... by trying to control the VM remotely from MainHost using the following script, I get the error message (I attached it in previous post):

First, create a new credential using Get-Credential, not New-Object. Dunno where you dug up that syntax, but it's unnecessary.

You don't "reference the required host." New-PSSession has no knowledge of virtualization, and it doesn't care. You provide the computer name of the machine you want to establish a session to. New-PSSession will use DNS and Active Directory to locate the machine specified and open a session to it - there's no need to provide its Hyper-V host machine's name.

In order for Remoting to work using the default settings, both MainHost and tempDC1 must be in the same Active Directory domain. This is because Remoting needs to establish mutual authentication and a secured session. If they are in different domains, then you need to read the "HOW TO ENABLE REMOTING FOR ADMINISTRATORS IN OTHER DOMAINS" section in about_remote_troubleshooting.

The error you're getting is indicating that PowerShell can't establish an authentication for TEMPDC1\Administrators. That's likely because MainHost is in a different domain, or in no domain at all, and PowerShell can't locate a domain controller for the TEMPDC1 domain, or TEMPDC1 server. I'm assuming TEMPDC1 is a machine name; if it isn't a domain controller, then TEMPDC1\Administrators is the correct credentials, but you need to read the "HOW TO CONNECT REMOTELY FROM A WORKGROUP-BASED COMPUTER" section of the about_remote_troubleshooting file.

This is purely a question of authentication. MainHost must be able to contact a logon server for whatever credential you provide, and it's telling you that it cannot do so.

1) I have read the HOW TO ADD A COMPUTER TO THE TRUSTED HOSTS LIST section, but I still don't understand how should I refere to the required host and to the required VM, I mean, I need to add a VM called 'tempDC1' which belongs to the hyperv56 host to TRUSTED HOSTS LIST.

On tempDC1, run Enable-PSRemoting and ensure the command runs without error.

On your client computer, where you added tempDC1 to the rusted hosts list, run:

Invoke-command -computer tempdc1 -script { whatever }

"whatever" can be any command or script that is present on tempdc1. Any command or function located in a module must be loaded into memory (eg. Import-Module) first.

The fact that tempdc1 is a virtual machine is not relavent. You do not need hyperv56 involved in any way.

On the front page of PowerShell.com, in the side banners, is advertised a free ebook on PowerShell Remoting. If you haven't read that, consider doing so. It's a very good resource, and it's completely free.

First, create a new credential using Get-Credential, not New-Object. Dunno where you dug up that syntax, but it's unnecessary.

The original syntax uses a simple hack to create a credential object without needing to prompt the user. It's a common approach used in testing, etc. In my classroom(s), "P@ssw0rd" is a commonly used password - so why bother to prompt for it when I can just create credential objects.

Now if you are going to make the point that Get-Credential approach is more secure - well yes there is that. But sometimes convenience and ease of use make security less important.