Skip to content

Troubleshooting: Job Connectivity and Errors

In this troubleshooting topic, we focus specifically on resolving issues related to remote connectivity and job failures between the Horizon software and target host machines. If you are encountering errors with Job execution like "Connection time out" or "401" errors, please review this topic to troubleshoot and resolve the issues.

Connection timed out: connect

When the Horizon software is unable to establish a connection with a Windows host machine, a "Connectivity Timeout" error may occur. This can be caused by several factors related to network settings, configuration issues, or credentials. To resolve this error, follow the suggestions below:

 

Ensure WinRM is Running and Configured Properly on the Target Host

The Windows Remote Management (WinRM) service is required for establishing remote PowerShell connections to a Windows host. If WinRM is not running or is misconfigured, Horizon will not be able to establish a connection, resulting in a timeout error.

Suggestion:

  • Open a PowerShell prompt on the target host with Administrator rights.
  • Run the following command to check and configure WinRM:
winrm quickconfig

This command will ensure that WinRM is properly configured and running on the target host. If WinRM is not configured, this command will prompt you to enable and configure it.

 

Ping the Target Host from the Server Running 12Port Horizon

Network connectivity between the Horizon server and the target host is essential for remote access. If Horizon cannot reach the target host over the network, the connection attempt will fail and result in a timeout error.

Suggestion:

  • From the server where Horizon is running, open a command prompt or PowerShell window.
  • Use the ping command to check connectivity:

ping <target_host_ip_or_hostname>

If the ping is successful, the network connection between the server and the target host is working correctly. If the ping fails, you may need to troubleshoot network connectivity between the two machines, such as firewall settings, routing issues, or DNS resolution problems.

 

Use Hostname Instead of IP Address in the Asset

In some cases, using the IP address of the target host in the Asset can cause issues with DNS resolution or network routing. If you are using the IP address in the Asset and experiencing a timeout error, try switching to the hostname instead.

Suggestion:

  • Edit the Asset for the target host and replace the IP address with the target's fully qualified domain name (FQDN) or hostname.
  • Save the changes and try to execute the task again.

Using the hostname can sometimes resolve issues related to IP address misconfiguration or DNS resolution.

 

Check the Format of the Username in the Asset

Incorrect username formatting in the Asset can cause authentication issues when attempting to connect to the target host. If you are using a domain account or local account, the format of the username must be specified correctly.

Suggestion:

  • In the Asset for the target host, verify that the username is in the correct format:
    • If you are using a domain account, the format should be domain\username.
    • If you are using a local account, the format should be computername\username.
  • Update the Asset with the correct username format and try task execution again.

Ensuring the correct format of the username will help avoid authentication issues that could prevent a successful connection.

 

Ensure the Password in the Asset is Valid

An incorrect or expired password in the Asset can also result in a timeout error. Double-check that the password stored in the Asset is valid and up to date.

Suggestion:

  • Open the Asset for the target host and verify that the password is correct.
  • If necessary, update the password to the current valid password for the target host.
  • Save the changes and attempt to execute the task again.

By verifying the password is correct and up to date, you can eliminate authentication issues as the cause of the timeout error.

 

Test WinRM Connectivity between the 12Port Server and Target Host (Windows only)

WinRM is required to remotely execute PowerShell commands from the 12Port host server and all target Windows assets. Testing WinRM to ensure it is properly configured on the target asset, credentials are valid, and the account provided has the required permission to execute remote PowerShell scripts to crucial to a successful job execution.

Suggestion:

  • Open a PowerShell prompt on the target host with Administrator rights.
  • Run the following to test WinRM execution.
    • Replace remote-host with the Hostname of the target Windows asset
    • Replace domain\username with the credentials from the target Windows asset if you're using domain-based authentication. If you're using local accounts, you would specify the local computer name computername\username. If you don’t want to hardcode the username, you can also use Get-Credential to prompt for the credentials interactively: -Credential (Get-Credential).
Invoke-Command -ComputerName remote-host -Credential domain\user -ScriptBlock {dir \}

The command should complete without errors and display the directory listing of the root directory on the target host.

If the command fails, confirm WinRM connectivity is configured properly and try again.

By following these troubleshooting steps, you should be able to resolve the "Connectivity Timeout" error and restore remote connectivity between Horizon and your Windows host machine. If the issue persists after trying these steps, please contact the 12Port support team at support@12port.com for further assistance.

Response error: 401

A 401 Unauthorized error in the context of WinRM (Windows Remote Management) typically indicates that the client failed to authenticate with the remote server. This error occurs when the server receives the request but refuses to process it due to missing or invalid authentication credentials. Troubleshooting this error involves checking both authentication configuration and user access rights on both the client and target machines. To resolve this error, follow the suggestions below:

 

Ensure Credentials are Valid

The username or password from the Asset, used to authenticate with the remote server is incorrect. This could be due to typos, outdated credentials, or incorrect format.

Suggestion:

Double-check the credentials in the Asset and ensure they are entered in the correct format:

  • If you are using a domain account, the format should be domain\username.
  • If you are using a local account, the format should be computername\username.
    • Update the Asset with the correct username format and try task execution again.

Also, confirm the password entered in the Asset's Password field is correct.

 

User Lacks required Remote Access Rights

Even if the user has valid credentials, they must also be authorized for remote access. By default, only members of the local Administrators group or members of Remote Management Users group can use WinRM.

Suggestion:

  • Add this user to the Remote Management Users group on the target machine.

After this user has been added as a member of the Remote Management Users group in the target machine, as defined in the Asset's Host field, try executing the script again.

 

UAC Remote Restrictions (on Local Administrator accounts)

UAC restricts local administrator accounts from authenticating remotely over the network, unless a registry key is set to allow full token elevation.

Suggestion:

Note

Consult with your IT department before attempting this suggestion as it requires modifying the System Registry on the target machine.

On the target machine, create the LocalAccountTokenFilterPolicy registry value:

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" `
-Name "LocalAccountTokenFilterPolicy" -Value 1 -PropertyType DWord -Force

Next, restart the WinRM service:

Restart-Service winrm

Once the service is restarted, try the script execution again.

 

Confirm Account Lock Status

If the user account being used for WinRM authentication is locked out, which typically happens after multiple failed login attempts due to incorrect credentials or saved credentials being reused, this needs to be resolved before continuing.

Suggestion:

Talk to your IT department if this is a locked domain account. Otherwise, locate this account in your Active Directory (for domain accounts) or Local Users and Groups (lusrmgr.msc for target machine local accounts) and unlock it. You can do this via Active Directory Users and Computers (ADUC), PowerShell or GUI controls.

After the account is confirmed to be not locked, try the script execution again.

By following these troubleshooting steps, you should be able to resolve the "401" error and restore remote connectivity between Horizon and your Windows host machine. If the issue persists after trying these steps, please contact the 12Port support team at support@12port.com for further assistance.