Having an understanding of the core technologies that VMM depends on to work correctly is the initial step to troubleshooting VMM:

Troubleshooting is never an easy task, but VMM 2016 provides tools and ways to help you find and remediate an issue.

Following are some techniques you can use to troubleshoot:

A good starting point is to look at the event logs. Look for OS- and VMM-related errors or failures. A problem with the operating system (OS) or one of its core services could result or lead to a problem in VMM.

For example, if you are running SQL Server on the same server and it did not start, VMM management service will not start either and VMM operations will fail as a direct result of this. You can easily find this by looking for errors in the system or application logs, errors that would indicate, in this example, that the service is not running (for this example, you can also check Services.msc).

When looking for VMM errors, it is recommended that you to look at the VMM log as well. To do so, perform the following steps on the VMM running Windows Server 2016:

VMM records information about the VMM agent installation. However, if the installation logging is not sufficient to determine the cause of failure, you can enable tracing by using the VMM MPS Reports tool and then restart the installation.

Installation logs are written, by default, to the C:\ProgramData\VMMLogs hidden folder

When installing an MSI package, such as installing the VMM agent manually, you can enable logging using the following syntax:

        msiexec /I MSIPackageName.msi  /L*V path\logfilename.log

For example, using the syntax, we can come up with something like the following command:

        msiexec /I "C:\setup\vmmAgent.msi" /L*V vmmagent.log

The local agent installation information is logged in the C:\ProgramData\VMMLogs hidden folders.

Look for the logfile vmmAgent.msi_m-d-yyy_hh-mm-dss.log.

To check if WinRM has remote access, check if:

A good understanding of what a successful installation log contains from a POC or a pilot environment is important to identify possible issues, especially if it appears when deploying VMM on a production environment, as you can then compare both logs.

Run the following command on the Hyper-V host:

winrm id

This should produce an output similar to the following output:

IdentifyResponse
ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor = Microsoft Corporation
ProductVersion = OS: 10.0.14393 SP: 0.0 Stack: 3.0
SecurityProfiles
SecurityProfileName = http://schemas.dmtf.org/wbem/wsman/1/wsman/secprofile/http/spnego-kerberos

If the result shows an error, run the following command for a quick configuration of WinRM:

winrm qc

If prompted, answer Yes. You will receive a response like the following:

WinRM already is set up to receive requests on this machine.WinRM is not set up to allow remote access to this machine for management.The following changes must be made: 
Enable the WinRM firewall exceptionMake these changes [y/n]?WinRM has been updated for remote management.WinRM firewall exception enabled.WinRM can now be tested again by typing 'winrm id' as before

Now check the listener:

winrm enum winrm/config/listener

Run the following command on the VMM management server:

winrm id -r:http://HyperVHost.yourdomain.local:5985 -u:YOURDOMAIN\AdminUser

The result will be similar to the following:

IdentifyResponse
ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor = Microsoft Corporation
ProductVersion = OS: 10.0.14393 SP: 0.0 Stack: 3.0

Otherwise you will receive the following error:

Error number: -2144108526 0x80338012The Client cannot connect to the destination specified in the request

This could indicate communication issues, so check your network, host firewall, and connectivity.

Most WinRM-related events appear in the system or application event logs. The Service Control Manager often contains the error, as the WinRM service has terminated or restarted for some reason.

To avoid this scenario, conduct the following checks:

      winrm qc -q      winrm set winrm/config/service/auth @{CredSSP="True"}      winrm set winrm/config/winrs @{AllowRemoteShellAccess="True"}      winrm set winrm/config/winrs @{MaxMemoryPerShellMB="2048"}

winrm enum wmi/root/cimv2/Win32_ComputerSystem -r :http://servername:5985 [-u:YOURDOMAIN\AdminUser]

winrm enum wmi/root/virtualization/v2/msvm_computersystem   -r:http://servername:5985 [-u:YOURDOMAIN\AdminUser]

winrm invoke GetVersion wmi/root/scvmm/AgentManagement -r:servername [-u:YOURDOMAIN\AdminUser] @{}

              wmimgmt.msc

logman create trace VMMDebug -v mmddhhmm -o
$env:SystemDrive\VMMlogs\DebugTrace_$env:computername.ETL 
-cnf 01:00:00 -p Microsoft- VirtualMachineManager-Debug                           
-nb 10 250 -bs16 -max 512

logman start VMMDebug 

              logman stop VMMDebug 

              logman delete VMMDebug

      nets  trace convert C:\VMMlogs\yourfilename.etl

       Input file: C:\VMMlogs\VMMLog_VMM01_09242130.etl
       Dump file: C:\VMMlogs\VMMLog_VMM01_09242130.txt
       Dump format: TXT
       Report file: -
       Generating dump ... done

      notepad c:\VMMlogs\yourfilename.txt