Can't connect to target host via WinRM service, and this MID server is set to connect via WinRM.

RobertB1
Tera Expert

‎02-22-2024 11:10 PM

Hi all, 

 

We have a few issues with our WinRM/JEA discovery, I must say, I'm not a fan, seems very fragile. One of the issue we are working with Microsoft to fix. The other we have no lead on yet. 

 

We have also followed all the steps to confirm the mid servers are configured correctly. However, we still getting this error 'Can't connect to target host via WinRM service, and this MID server is set to connect via WinRM.'. 

But! Only from mid server within a certain location cluster. 

I've included the disco log, and error from the mid server

 

Thanks as always for any help

Preview file
60 KB
Preview file
18 KB
0 Helpfuls
  • 1,885 Views
5 REPLIES 5

VinodPaulF
Tera Contributor

‎01-30-2025 03:06 AM

The error "classification payload is empty. Stopping classification" in ServiceNow Discovery using JEA typically occurs due to one of the following reasons:

Possible Causes & Fixes

1. JEA Session Configuration Issues

  • Cause: The MID Server is unable to establish a PowerShell JEA session due to missing permissions or an incorrect JEA configuration.
  • Fix:

    1. Verify that the JEA endpoint is correctly registered:

      Get-PSSessionConfiguration -Name SNOW_Discovery

      If missing, re-register using:

      Register-PSSessionConfiguration -Name SNOW_Discovery -Path "C:\Program Files\WindowsPowerShell\Modules\JEA\SNOW_Discovery.pssc"

    2. Check if JEA allows PowerShell commands required for classification:

      Get-PSSessionCapability -ConfigurationName SNOW_Discovery -Username <MID Server User>

      Ensure commands like Get-WmiObject, Get-Service, and Get-Process are included in the JEA role configuration.

2. Missing or Incorrect Discovery Credentials

  • Cause: The MID Server is not using the correct credentials or they are not mapped properly.
  • Fix:
    1. Navigate to Discovery > Credentials.
    2. Verify that the correct Windows Credential is created for the JEA session.
    3. Check Discovery > Credential Affinity and ensure the correct credential is linked to Windows classification.

3. WinRM & PowerShell Remoting Issues

  • Cause: PowerShell Remoting (WinRM) is not properly configured on the target machine.
  • Fix:
    1. Run the following on the target Windows machine:
      winrm quickconfig
    2. Test the WinRM connection:
      Test-WSMan <MID Server IP>
    3. Check if JEA is accessible:
      Enter-PSSession -ComputerName <TargetMachine> -ConfigurationName SNOW_Discovery -Credential <JEA_User>

4. Discovery MID Server Configuration

  • Cause: The MID Server is not configured to use JEA properly.
  • Fix:
    1. Navigate to MID Server > Properties.
    2. Ensure the following parameters are set correctly:
      • mid.windows.management_protocol = WinRM
      • mid.powershell.jea.endpoint = SNOW_Discovery
    3. Restart the MID Server:
      Restart-Service MIDServer

5. Debugging & Logs

If the issue persists, enable debugging logs in ServiceNow:

  • Set System Property: glide.discovery.log_debug_info = true
  • Check logs under Discovery > Discovery Log for specific errors.

Final Steps

  1. Restart the MID Server and target Windows Machine.
  2. Test connectivity using:
    Test-NetConnection <MID Server IP> -Port 5985
  3. Re-run Discovery and check logs.

 

You need to run the PowerShell scripts on the target Windows machine(s) that ServiceNow Discovery is trying to classify. These are the machines where JEA is configured to limit administrative access.

Where to Run the PowerShell Commands?

1. On the Target Windows Machine (where JEA is configured)

Run these commands locally on each Windows server where JEA is configured to verify its setup.

2. From the MID Server (to test remote JEA connection)

After configuring JEA, run commands from the MID Server to check if it can connect to the target machine using the JEA session.

Step-by-Step Execution

Step 1: Verify JEA Endpoint Exists (Run on the Target Windows Machine)

Get-PSSessionConfiguration -Name JEA_DISCO_V2
  • If the session exists, it will return details about the JEA_DISCO_V2 configuration.
  • If it does not exist, re-register it:
    Register-PSSessionConfiguration -Name JEA_DISCO_V2 -Path "C:\Program Files\WindowsPowerShell\Modules\JEA\JEA_DISCO_V2.pssc"

Step 2: Test JEA Session Locally (Run on the Target Windows Machine)

Enter-PSSession -ConfigurationName JEA_DISCO_V2 -Credential <JEA_User>
  • If this succeeds, your JEA session is configured correctly.
  • If it fails, check the role capability file (.psrc) and session configuration file (.pssc) for missing permissions.

Step 3: Test MID Server Connection to JEA (Run on the MID Server)

Enter-PSSession -ComputerName <Target_Windows_Machine> -ConfigurationName JEA_DISCO_V2 -Credential <JEA_User>
  • If this works, the MID Server can authenticate via JEA.
  • If it fails, check:
    • Firewall rules (ensure WinRM (TCP 5985/5986) is open).
    • Whether the MID Server's credentials have permission to use JEA.

Step 4: Validate Allowed Commands (Run on the Target Windows Machine)

Get-PSSessionCapability -ConfigurationName JEA_DISCO_V2 -Username <MID_Server_User>
  • This command shows which cmdlets the MID Server is allowed to execute.

Where to Run Each Command?

Command Run on Target Windows Machine Run on MID Server

Get-PSSessionConfiguration -Name JEA_DISCO_V2✅❌
Enter-PSSession -ConfigurationName JEA_DISCO_V2 -Credential <JEA_User>✅❌
Enter-PSSession -ComputerName <Target_Windows_Machine> -ConfigurationName JEA_DISCO_V2 -Credential <JEA_User>❌✅
Get-PSSessionCapability -ConfigurationName JEA_DISCO_V2 -Username <MID_Server_User>✅❌

 

0 Helpfuls