Resolving PowerShell Credential Test Failures on ServiceNow MID Servers!

Selva Arun · Friday

Resolving PowerShell Credential Test Failures on ServiceNow MID Servers

Article Type: Real-World Troubleshooting Experience

Difficulty Level: Low

Estimated Resolution Time: 2-5 minutes

Related KB: KB0956823, KB0749654

Last Updated: October 2025

📋 About This Article

My Real-World Experience: This article documents an actual troubleshooting scenario I encountered in our production ServiceNow environment where our DEV MID servers suddenly started failing Windows credential tests with empty PowerShell results.

Not a Duplicate: While investigating, I reviewed existing ServiceNow KB articles (KB0956823, KB0749654) and community posts. However, none provided a clear, comprehensive walkthrough of this specific symptom with the surprisingly simple solution. This article fills that gap by sharing my complete troubleshooting journey and the resolution that worked.

The Surprise: After I spent hours investigating - ruling out JRE issues, permissions, execution policies, and configuration differences between environments - the fix turned out to be remarkably simple: just restart the MID Server service! Sometimes the simplest solution is the right one.

My Experience: The Issue

In our ServiceNow environment, Windows credential testing suddenly began failing on our DEV MID servers with the following error message:

Error encountered when invoking PowerShell, the result from running 
'"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -noninteractive 
-nologo -noprofile -command "$ver = if (Test-Path Variable:\PSVersionTable) 
{ $PSVersionTable.PSVersion } else { (get-host).Version }; 'full_version:' + 
$ver.ToString() + ', major_version:' + $ver.Major"' is

The PowerShell command returned completely empty results, causing all credential validation to fail. What made this particularly frustrating was that the same credential worked perfectly on our PROD, TEST, and QA environments - only DEV was affected.

My Troubleshooting Journey

What I Learned: I spent considerable time investigating various potential causes before discovering the simple solution. Here's what I ruled out during my investigation:

✓ Not a 32-bit JRE issue - I verified all DEV MID servers had 64-bit JRE (KB0749654)
✓ Not multiple PowerShell versions - I confirmed only PowerShell 5.1 was installed
✓ Not an execution policy issue - I checked and execution policy was set to Unrestricted
✓ Not a MID server parameter issue - I verified mid.powershell.path was not set (using default) on any environment
✓ Not a version mismatch - I compared all environments and they had properly configured MID servers

My Key Finding: The issue had been working previously but recently stopped, pointing to stuck PowerShell processes rather than a configuration problem.

Symptoms I Observed

Windows credential testing fails in Discovery > Credentials
MID Server Issues show "PowerShellInitialization" errors
Credential test returns no output (empty result)
Error appears intermittently or persistently
May have been working previously but recently stopped
Discovery operations requiring PowerShell fail

Why I'm Sharing This

Saving You Time: When I searched for solutions, I found several KB articles and community posts about PowerShell and credential issues, but none clearly documented this specific scenario where:

The error shows "empty result" (not authentication failed or access denied)
The same credential works in other environments
It was working before but suddenly stopped
All the usual suspects (JRE, execution policy, versions) are ruled out

Hours of My Time, Minutes to Fix: I spent several hours troubleshooting this issue, diving deep into service accounts, permissions, and configuration comparisons. The actual fix took 2 minutes. I'm documenting this to save you from the same time-consuming investigation I went through.

Sometimes the Simplest Answer is Right: In IT, we're often conditioned to look for complex solutions. This was a good reminder that sometimes "Have you tried turning it off and on again?" is actually the correct answer!

My Environment Details

For context, here's what my setup looked like:

Environment	MID Version	Credential Test Status
PROD (6 servers)	Xanadu	✓ Working
TEST (2 servers)	Xanadu	✓ Working
QA (6 servers)	Yokohama	✓ Working
DEV (2 servers)	Yokohama	✗ FAILING

Key Observation: The version difference initially made me suspect a version-specific issue, but QA (same version as DEV) was working fine. This pointed to a transient issue rather than a configuration problem.

Technical Details

Stuck PowerShell processes on the MID server host prevent new PowerShell commands from executing properly.

Over time, PowerShell processes can accumulate and become unresponsive, causing the MID server to be unable to:

Test Windows credentials
Initialize PowerShell capabilities
Execute discovery operations requiring PowerShell

This issue can occur due to:

Long-running or hung PowerShell commands from discovery operations
Multiple concurrent PowerShell executions
Insufficient system resources
PowerShell process memory leaks

Investigation Steps

1Verify the Error in MID Server Issues

Navigate to: MID Server > Servers
Open the affected MID server
Click Related Lists > MID Server Issues
Look for errors with:
- Source: PowerShellInitialization
- Message: Contains "Error encountered when invoking PowerShell"

2Test the Credential

Navigate to: Discovery > Credentials > Windows Credentials
Open the failing credential
Click "Test Credential"
Enter a target IP address
Observe if test fails with empty PowerShell result

3Gather MID Server Information

Run this background script to collect environment details:

// Check MID server details
var midName = 'YOUR_MID_SERVER_NAME'; // Replace with actual name

var gr = new GlideRecord('ecc_agent');
gr.addQuery('name', midName);
gr.query();

if (gr.next()) {
    gs.print('=== MID Server Information ===');
    gs.print('Name: ' + gr.getValue('name'));
    gs.print('Version: ' + gr.getValue('version'));
    gs.print('Status: ' + gr.getValue('status'));
    gs.print('Validated: ' + gr.getValue('validated'));
    
    // Check for PowerShell errors
    var issue = new GlideRecord('ecc_agent_issue');
    issue.addQuery('agent', gr.sys_id);
    issue.addQuery('source', 'PowerShellInitialization');
    issue.addQuery('state', '!=', 'resolved');
    issue.orderByDesc('sys_created_on');
    issue.query();
    
    if (issue.next()) {
        gs.print('\n=== PowerShell Error Found ===');
        gs.print('Created: ' + issue.getValue('sys_created_on'));
        gs.print('Message: ' + issue.getValue('message'));
        gs.print('Count: ' + issue.getValue('count'));
    }
}

4Rule Out Other Common Causes

A. Verify this is NOT a 32-bit JRE issue (KB0749654):

On the MID server host, check Java version:

cd "D:\Path\To\MID Server\agent\jre\bin"
.\java.exe -version

Look for "64-Bit Server VM" in the output. If it says 32-bit, see KB0749654.

B. Verify this is NOT multiple PowerShell versions (KB0956823):

$PSVersionTable
DISM /online /get-features /format:table | findstr "PowerShell"

Should show only one PowerShell version (typically 5.1).

C. Check PowerShell execution policy:

Get-ExecutionPolicy -List

Should show Unrestricted or RemoteSigned for LocalMachine.

The Solution: Surprisingly Simple!

✅ Resolution: Just Restart the MID Server Service

Yes, it really is that simple! After all our investigation, the solution was to simply restart the MID Server service. This cleared the stuck PowerShell processes and immediately resolved all credential testing failures.

My Result: Within 2-3 minutes of restarting the service, the Windows credential test that had been failing for hours suddenly worked perfectly. No configuration changes, no parameter adjustments - just a service restart.

Why This Works: The restart clears accumulated PowerShell processes that had become stuck or unresponsive, allowing the MID server to execute PowerShell commands normally again.

Option 1: Restart via PowerShell (What I Used)

This is what I ran on the MID server host. Open PowerShell as Administrator and run:

# Restart the MID Server service
Restart-Service "snc_mid_YOUR_MID_SERVER_NAME"

# Verify service is running
Get-Service "snc_mid_YOUR_MID_SERVER_NAME" | Select-Object Name, Status

Option 2: Restart via ServiceNow UI

Navigate to: MID Server > Servers
Open the affected MID server
In Related Links, click "Restart MID"
Wait for status to return to "Up"

Option 3: Restart via Services GUI

On the MID server host, press Windows Key + R
Type services.msc and press Enter
Find "ServiceNow MID Server_[NAME]"
Right-click and select "Restart"

Verification Steps

1Verify MID Server Status

Navigate to: MID Server > Servers
Confirm Status = "Up"
Check that "Last Refreshed" timestamp is recent

2Verify PowerShell Initialization is Fixed

// Verify no PowerShell errors remain
var midName = 'YOUR_MID_SERVER_NAME';

var gr = new GlideRecord('ecc_agent');
gr.addQuery('name', midName);
gr.query();

if (gr.next()) {
    var issue = new GlideRecord('ecc_agent_issue');
    issue.addQuery('agent', gr.sys_id);
    issue.addQuery('source', 'PowerShellInitialization');
    issue.addQuery('state', '!=', 'resolved');
    issue.query();
    
    if (!issue.hasNext()) {
        gs.print('✓ No PowerShell errors found - Issue resolved!');
    } else {
        gs.print('⚠ PowerShell errors still present');
    }
}

3Test Windows Credential

Navigate to: Discovery > Credentials > Windows Credentials
Open the previously failing credential
Click "Test Credential"
Enter target IP address
Expected Result: Test succeeds with green checkmark

4Run Test Discovery (Optional)

Create a simple discovery schedule targeting a known Windows device
Use the MID server and credential that were failing
Verify discovery completes successfully

Prevention and Long-Term Recommendations

1. Monitor MID Server Issues Regularly

Set up notifications for PowerShellInitialization errors:

Create a filter on ecc_agent_issue table
Source = "PowerShellInitialization"
State != "resolved"

2. Implement Regular MID Server Restarts

Consider scheduling periodic MID server restarts during maintenance windows to prevent PowerShell process accumulation. See KB0692080 for scheduling options.

3. Monitor MID Server Resources

On the MID server host, monitor:

CPU usage during peak discovery times
Memory consumption
Number of PowerShell processes: Get-Process powershell | Measure-Object

4. Keep MID Servers Updated

Newer MID server versions may have improvements to PowerShell process management. Ensure all environments are on consistent, current versions.

5. Optimize Discovery Schedules

Avoid overlapping discovery schedules that create concurrent PowerShell load
Stagger discovery times across multiple MID servers
Review and optimize PowerShell-based discovery patterns

Additional Troubleshooting

If restarting the MID server does NOT resolve the issue, investigate:

A. Service Account Permissions

Check which account the MID server service is running as:

Get-WmiObject Win32_Service | Where-Object {$_.Name -like "*snc_mid*"} | 
    Select-Object Name, StartName, State

Compare with working environments - different service accounts may have different permissions.

B. Security Software Blocking PowerShell

Check for restrictions from:

AppLocker policies
Attack Surface Reduction (ASR) rules
Group Policy restrictions on PowerShell
Endpoint security software (EDR/antivirus)

C. Set Explicit PowerShell Path (KB0956823)

If default PowerShell discovery fails, set explicit path:

// Set mid.powershell.path parameter
var gr = new GlideRecord('ecc_agent');
gr.addQuery('name', 'YOUR_MID_SERVER_NAME');
gr.query();

if (gr.next()) {
    var prop = new GlideRecord('ecc_agent_property');
    prop.initialize();
    prop.agent = gr.sys_id;
    prop.name = 'mid.powershell.path';
    prop.value = 'C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe';
    prop.insert();
    
    gs.print('PowerShell path set. Restart MID server to apply.');
}

Quick Reference Summary

Issue	PowerShell credential test returns empty result
Root Cause	Stuck PowerShell processes on MID server host
Quick Fix	Restart the MID Server service
Resolution Time	2-5 minutes
Prevention	Regular MID server restarts, monitor MID Server Issues
Difficulty	Low