DNS resolution

Start with the exact symptom and identify the dependency that must work for the operation to succeed. Capture the server name, source system and the exact error before making changes.

TCP 135 connectivity

Test the relevant dependency directly. Use a focused connectivity or configuration check instead of relying on a generic ping or a single management tool.

RPC services

Review the Windows, virtualization or cloud configuration that controls the failing operation. Compare the expected configuration with the actual state.

Windows Firewall

Check security controls such as Windows Firewall, network security rules, authentication and permissions. Confirm the rule applies to the correct network profile, interface or identity.

WMI validation

Validate the result after each change. Record what changed and whether the original symptom is resolved before moving to the next step.

Repeatable troubleshooting workflow

Turn the final checks into a repeatable runbook or scheduled report so the same issue can be diagnosed faster next time.

Useful commands

Run these checks from an elevated PowerShell session where appropriate. Replace example names with your environment.

PowerShell checks

Resolve-DnsName SERVER01
Test-NetConnection SERVER01 -Port 135
Get-Service RpcSs,RpcEptMapper

Firewall check

Get-NetFirewallRule -DisplayGroup 'Windows Management Instrumentation (WMI)' | Select DisplayName,Enabled,Profile

Quick troubleshooting path

Use this sequence to isolate the failing dependency before changing production configuration.

Troubleshooting decision path for windows server rpc server unavailable

What good troubleshooting looks like

Good infrastructure troubleshooting is evidence-driven. Capture the original state, test the dependency that can prove or disprove your hypothesis, make the smallest safe change and repeat the original test.

Example workflow
Symptom → hypothesis → direct test → result → controlled change → validation → documentation

Frequently asked questions

What should I check first?

Start with the exact symptom and validate the dependency closest to the failure, such as DNS, a port, a service, storage or an authentication path.

Should I change production configuration immediately?

No. Capture the current state first, test the suspected dependency and make one controlled change at a time.

How should I document the fix?

Record the symptom, commands used, result, configuration change and validation result so the procedure can be repeated.

Related TechRunbook guides

WinRM Troubleshooting: Windows Server Remote Management Checklist →Windows Server DNS Troubleshooting: Complete Checklist →
TechRunbook approach: Test one dependency at a time, record the result and only then change the configuration.

Need more infrastructure resources?

Browse free TechRunbook guides, checklists and scripts.

Browse free IT resources →