RPC Error Message when running a PowerShell script

Question

RPC Error Message when running a PowerShell script

Kaplan, Andrew H 226

Hello.

Several PowerShell scripts have been deployed to monitor remote Windows 11 Pro systems in our environment. One of the scripts is designed to monitor active users. This script is failing with the following error message appearing on-screen:

Failed to query mghroswl3. Details: Error 0x000006BA enumerating sessionnames Error [1722]:The RPC server is unavailable. System.Management.Automation.RemoteException

I confirmed the following on the target system:

The RPC service is running, and it is set to Automatic.
Remote Desktop and Remote Assistance are enabled on the firewall. The Remote Assistance is enabled for Private and Domain networks, but for Public networks.
The system is configured for a Normal startup.
File and Print Sharing along with IPv6 TCP/IP are enabled on the system.
The RemoteRegistry service is running.
The TCP/IP NetBIOS Helper service is running.

What other steps can I take to correct this issue?

0 comments

5 answers

Your answer

Answer 1

Kaplan, Andrew H 226

Hello.

Thank-you for your responses. As requested the text of the script is the following:

<#

.SYNOPSIS

Gets the number of active user sessions on a remote computer.

.DESCRIPTION

Uses the built-in 'quser' command to query remote sessions.

Filters only sessions with the "Active" state.

Includes error handling for offline or inaccessible computers.

.PARAMETER ComputerName

The remote computer name or IP address.

.EXAMPLE

.\Get-ActiveUserCount.ps1 -ComputerName "Server01"

#>

param (

[Parameter(Mandatory = $true)]

[string]$ComputerName

)

try {

# Run quser remotely and capture output

$output = quser /server:$ComputerName 2>&1

# Check if the command failed

if ($LASTEXITCODE -ne 0) {

Write-Error "Failed to query $ComputerName. Details: $output"

exit 1

}

# Filter lines containing 'Active' (case-insensitive)

$activeUsers = $output | Where-Object { $_ -match '\sActive\s' }

# Count active sessions

$count = $activeUsers.Count

Write-Output "Computer: $ComputerName"

Write-Output "Active user sessions: $count"

}

catch {

Write-Error "Error querying ${ComputerName}: $_"

}

VPHAN 32,870 Reputation points Independent Advisor

2025-12-29T14:48:32.1133333+00:00

Thanks for sharing the script. This code clarifies why our previous WMI troubleshooting. while revealing a valid repository issue (0x8004100e), did not resolve the script error. Your script relies on quser.exe, a legacy command-line tool that functions independently of WMI. It communicates directly with the Remote Desktop Services (TermService) via a specific RPC interface. The error 0x6BA (RPC Server Unavailable) in this context specifically means the Remote Desktop Services service is either unreachable, stopped, or explicitly configured to reject remote query requests (WinStationEnumerate), even if RDP connections are allowed.

To fix this for quser, you must enforce a specific registry configuration on the target machine (mghroswl3) that permits remote RPC queries against the terminal server subsystem. Open an elevated Command Prompt on the target and run the command reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v AllowRemoteRPC /t REG_DWORD /d 1 /f.

After adding the registry key, ensure the service itself is active by running sc config TermService start= auto followed by net start TermService. Unlike WMI, quser requires the Remote Desktop Services service to be in the "Running" state to respond to queries. Once the registry key is set and the service is confirmed running, retry your script from the source machine.
Kaplan, Andrew H 226 Reputation points

2025-12-29T15:25:35.5533333+00:00

Hello.

I completed the steps outlined in your response, and the error message has continued to appear.
VPHAN 32,870 Reputation points Independent Advisor

2025-12-29T15:29:30.2433333+00:00

Hm, there might be a missing firewall exception for legacy service management. The quser command utilizes RPC over Named Pipes or dynamic ports that are governed by the remote service management firewall group, which is distinct from the "Remote Desktop" or "WMI" groups you have already enabled.

Please explicitly enable the Remote Service Management rules on the target system (mghroswl3). Run the following command in an elevated PowerShell window:

Enable-NetFirewallRule -DisplayGroup "Remote Service Management"

After that, I strongly recommend performing a full reboot of the target machine. The AllowRemoteRPC registry key you added earlier often requires a system restart to correctly register the Remote Desktop Services interface with the RPC Endpoint Mapper. Once the system is back online, retry the script.

VP

Answer 2

VPHAN 32,870 Independent Advisor

Hello Kaplan, Andrew H,

I'm following up to see if the winmgmt /resetrepository command successfully resolved the 0x8004100e "Invalid namespace" error on the target system (mghroswl3). As detailed in the previous response, this error confirms that network connectivity is healthy but isolates the root cause to a corrupted WMI repository on the local machine. Rebuilding the repository and restarting the Windows Management Instrumentation service (Restart-Service Winmgmt -Force) is the standard and necessary procedure to restore the namespace functionality required for your monitoring scripts.

If the issue has been successfully resolved, please consider accepting the answer as it helps other people sharing the same question benefit too. Thank you!

VP

Kaplan, Andrew H 226 Reputation points

2025-12-24T15:26:35.5+00:00

Hello VP.

I ran the winmgmt /verifyrepository on the target system, and the output message is 'WMI repository is consistent'. The error message at the start of this thread continues to occur.
VPHAN 32,870 Reputation points Independent Advisor

2025-12-24T15:31:11.6333333+00:00

The "Consistent" result from winmgmt /verifyrepository only confirms that the WMI database file structure is intact; it does not verify that the standard namespaces (like root\cimv2) are correctly registered or populated. The 0x8004100e (Invalid Namespace) error you received in wbemtest is the definitive diagnostic here: it proves the WMI service is running (RPC is working) but cannot find the standard class definitions required by your monitoring script. This logical corruption is what eventually causes the script to time out or fail, incorrectly reporting the generic "RPC Server Unavailable" (0x6BA) error.

You must force a repository reset to regenerate the missing namespace definitions. Please proceed with the following steps on the target system (mghroswl3):

Open an Administrator Command Prompt.

Stop the WMI service and its dependencies: net stop winmgmt /y

Execute the repository reset (ignoring the previous "consistent" status): winmgmt /resetrepository

Restart the computer to ensure all providers re-register correctly.

After the reboot, test again with wbemtest. Once the "Invalid Namespace" error is cleared there, your PowerShell script should function correctly.
MotoX80 37,686 Reputation points

2025-12-24T15:36:32.1133333+00:00

What statement in the script is failing?

Can you share enough of the code so we can see what it's doing and run tests on our own machines?

Have you checked the system and security eventlogs for errors on the target machine?

Have you temporarily disabled the firewall on the target machine and tested?
Kaplan, Andrew H 226 Reputation points

2025-12-29T14:40:34.5366667+00:00

Hello.

Thank-you for your responses. As requested the text of the script is the following:

<#

.SYNOPSIS

Gets the number of active user sessions on a remote computer.

.DESCRIPTION

Uses the built-in 'quser' command to query remote sessions.

Filters only sessions with the "Active" state.

Includes error handling for offline or inaccessible computers.

.PARAMETER ComputerName

The remote computer name or IP address.

.EXAMPLE

.\Get-ActiveUserCount.ps1 -ComputerName "Server01"

#>

param (

[Parameter(Mandatory = $true)]

[string]$ComputerName

)

try {

# Run quser remotely and capture output

$output = quser /server:$ComputerName 2>&1

# Check if the command failed

if ($LASTEXITCODE -ne 0) {

Write-Error "Failed to query $ComputerName. Details: $output"

exit 1

}

# Filter lines containing 'Active' (case-insensitive)

$activeUsers = $output | Where-Object { $_ -match '\sActive\s' }

# Count active sessions

$count = $activeUsers.Count

Write-Output "Computer: $ComputerName"

Write-Output "Active user sessions: $count"

}

catch {

Write-Error "Error querying ${ComputerName}: $_"

}

Answer 3

Hello,

The shift from an RPC unavailable error to 0x8004100e is significant progress. It confirms that network connectivity and firewall traversal are now successful, but the WMI service on the target machine (mghroswl3) can't locate the requested namespace (likely root\cimv2). This specific error almost invariably indicates a corrupted WMI repository on the target system.

To resolve this, access the target machine directly via an elevated Command Prompt or PowerShell. First, check the repository status by running winmgmt /verifyrepository. If the output states "WMI repository is inconsistent," run winmgmt /salvagerepository to attempt a repair that preserves existing data. If that fails or if the repository claims to be consistent yet still throws the error, you must force a rebuild by running winmgmt /resetrepository. Once the command completes, restart the WMI service using Restart-Service Winmgmt -Force (or net stop winmgmt /y && net start winmgmt) and attempt the connection via wbemtest again.

If the issue has been successfully resolved, please consider accepting the answer as it helps other people sharing the same question benefit too. Thank you!

VP

Answer 4

VPHAN 32,870 Independent Advisor

Hello Kaplan, Andrew H,

The error 0x000006BA (RPC_S_SERVER_UNAVAILABLE) usually indicates that the initial handshake on TCP port 135 failed or the subsequent dynamic port allocation was blocked. While you have confirmed that File and Print Sharing is enabled, that specific group primarily covers SMB ports (445/139). Remote PowerShell scripts that utilize WMI or CIM queries often require the "Windows Management Instrumentation (WMI)" firewall group to be explicitly allowed, which is distinct from Remote Assistance or File Sharing. Furthermore, on Windows 11, if the network adapter has identified the connection as "Public" rather than "Private" or "Domain," the standard firewall exceptions you enabled will not apply.

To resolve this, first verify the target system's network profile using the PowerShell command Get-NetConnectionProfile on the target machine. If the NetworkCategory is set to Public, you must change it to Private or DomainAuthenticated using Set-NetConnectionProfile -Name "NetworkName" -NetworkCategory Private. If the profile is correct, you then need to explicitly enable the WMI traffic. Run the following command on the target system (mghroswl3) in an elevated PowerShell prompt: Enable-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)".

After adjusting the firewall, verify connectivity from your source machine by running Test-NetConnection -ComputerName mghroswl3 -Port 135. If this returns "TcpTestSucceeded: True," retry your monitoring script. If the port test fails despite the firewall changes, ensure there are no hardware firewalls or VLAN ACLs dropping traffic on TCP port 135 between the two subnets.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP

Kaplan, Andrew H 226 Reputation points

2025-12-23T14:32:40.82+00:00

Hello VP.

Thank-you for your response. I went through the suggested steps, and I have confirmed all are present and true. Regrettably, the error condition continues to be present.
VPHAN 32,870 Reputation points Independent Advisor

2025-12-23T14:36:19.0433333+00:00

Since the network profile and firewall configurations have been validated, the persistence of error 0x000006BA (RPC_S_SERVER_UNAVAILABLE) suggests a breakdown in Name Resolution (DNS) or the specific service handling the session enumeration. The error "enumerating sessionnames" probably indicates the script is querying the Remote Desktop Services subsystem, which requires more than just the basic RPC service to be active.

First, verify that the Remote Desktop Services (TermService) service is currently in the "Running" state on the target machine (mghroswl3). Even if the firewall allows the traffic, if this specific service is stopped or hung, the RPC call to enumerate sessions will fail with 0x6BA. Next, confirm DNS Resolution is accurate by running nslookup mghroswl3 on your source machine. If the resolved IP does not match the target's actual IP (common with stale IPv6 records), the RPC packet is being sent to the wrong destination. Finally, isolate the issue by running wbemtest on the source machine. Launch it, click Connect, enter \\mghroswl3\root\cimv2, and attempt to connect with admin credentials. If wbemtest connects successfully, the underlying WMI/RPC infrastructure is healthy, and the issue lies specifically with the script's method of querying terminal sessions.
Kaplan, Andrew H 226 Reputation points

2025-12-23T14:44:09.76+00:00

Hello VP.

I did the suggested checks, and the wbemtest utility was able to connect successfully.

Answer 5

AI answer

To resolve the RPC server unavailable error (0x000006BA) when running your PowerShell script, consider the following troubleshooting steps:

Check Network Connectivity: Ensure that the target system (mghroswl3) is reachable over the network. You can use the ping command to verify connectivity.
Firewall Settings: Although you mentioned that Remote Desktop and Remote Assistance are enabled, ensure that the firewall is not blocking the dynamic ports used by RPC. The default RPC communication uses TCP port 135 and a range of dynamic ports (49152-65535 by default in Windows). Ensure these ports are open in the firewall settings.
Service Dependencies: Verify that all necessary services for RPC are running. In addition to the RPC service, ensure that the following services are also running:
- DCOM Server Process Launcher
- RPC Endpoint Mapper
Check for Network Issues: Use tools like tracert to check for any network issues that may be preventing communication between the systems. Look for any devices that may be dropping packets.
Review Event Logs: Check the Event Viewer on both the source and target systems for any related errors or warnings that might provide more context about the issue.
Dynamic Port Configuration: If your environment has specific configurations for dynamic ports, ensure that they are correctly set up. You can refer to the registry settings related to RPC to confirm this.
Test with Other Scripts: Try running other PowerShell scripts that utilize RPC to determine if the issue is specific to the active users monitoring script or if it is a broader RPC issue.

By following these steps, you should be able to identify and resolve the underlying cause of the RPC server unavailable error.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

Share via

RPC Error Message when running a PowerShell script

5 answers

Your answer