Docs
How To
DMC
Remediating Access Issues

Remediating Access Issues

Overview

When running DMC physical, Hyper-V, VMware, or Linux server scans, you may encounter access issues that prevent successful validation and scanning.
This guide provides secure, streamlined steps to troubleshoot and resolve connectivity, credential, and configuration problems.

Common Access Issues

DMC server validation typically fails due to one of these categories:

  • Network connectivity problems – Ports blocked, firewalls, network routing
  • Authentication failures – Invalid credentials, insufficient permissions
  • Service configuration issues – WinRM/SSH not enabled, services not running
  • System state problems – Servers powered off, network interfaces down

Troubleshooting Navigation

Use the cards below to navigate to specific troubleshooting areas:

Network Connectivity
Test ports, firewalls, and network routing issues
 Windows Configuration
WinRM, PowerShell, and Windows-specific settings
 Linux Configuration
SSH, firewall, and Linux-specific settings
 VMware Configuration
vCenter, ESXi, and VMware-specific requirements
 Credential Issues
Authentication, permissions, and account setup
 Single Device Scanning
Isolate problematic devices for individual testing
 Unreachable Servers
Step-by-step resolution for unreachable devices
 Error Messages
Quick reference for common error solutions

Network Connectivity Issues

Verify Network Access

Test Basic Connectivity 

ping <server-ip-or-hostname>

If ping fails, check:

  • Jumpbox network configuration
  • Target server NIC/IP settings
  • Firewall rules blocking ICMP

Test Required Ports

Windows Servers (WinRM):

Test-NetConnection -ComputerName <server-ip> -Port 5985
Test-NetConnection -ComputerName <server-ip> -Port 5986

Linux Servers (SSH):

nc -zv <server-ip> 22

VMware vCenter/ESXi:

nc -zv <vcenter-ip> 443
nc -zv <esxi-ip> 443

Check Firewall Rules

Windows Firewall (target servers):

  • Port 5985 (HTTP) – WinRM HTTP
  • Port 5986 (HTTPS) – WinRM HTTPS

Linux Firewall (target servers):

  • Port 22 – SSH

VMware Firewall (vCenter/ESXi):

  • Port 443 (HTTPS) – vSphere API communication

Windows Server Configuration

Enable WinRM and PowerShell Remoting

Run as Administrator on the target server:

Enable-PSRemoting -Force
Set-Item WSMan:\localhost\Service\Auth\Kerberos -Value $true
Set-Item WSMan:\localhost\Service\AllowUnencrypted -Value $false

This:

  • Starts WinRM
  • Opens firewall for 5985 (HTTP)
  • Enables Kerberos (default in domains)
  • Keeps traffic encrypted

HTTPS Listener (Recommended) 

New-Item -Path WSMan:\Localhost\Listener -Transport HTTPS -Address * -CertificateThumbprint <thumbprint>

Verify WinRM 

Test-WSMan -ComputerName <server-ip>
Resetting WinRM Configuration

In some environments, it may be required to reset the WinRM configuration of the DMC Jumpbox Follow these steps to perform a complete WinRM reset:

Step 1: Open an elevated PowerShell or Command Prompt

Run as Administrator.

Step 2: Stop the WinRM service (optional but clean) 

net stop winrm

Step 3: Run a full WinRM configuration reset 

winrm invoke Restore winrm/Config

This command resets the WinRM configuration store to its default state (including listeners and client settings).

Alternative: If the above fails or you need a simpler reset, use:

winrm quickconfig -force

This will:

  • Recreate the listener (http://* on port 5985 by default)
  • Set the WinRM service startup type to Automatic
  • Start the service
  • Create necessary firewall exceptions

Step 4: Clear or reapply TrustedHosts (if used)

If DMC or your remote connections rely on specific trusted hosts, re-add them:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*"    # allow all (for testing)
# or better:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "server1,server2"

You can verify the current setting:

Get-Item WSMan:\localhost\Client\TrustedHosts

Step 5: Restart the WinRM service 

net start winrm

Step 6: Test remoting 

Test-WSMan <target-server>

If it succeeds, PowerShell remoting should now work again.

Optional: Clean up the WinRM listener manually

If the listener configuration itself is corrupted, you can rebuild it:

winrm delete winrm/config/listener?Address=*+Transport=HTTP
winrm create winrm/config/listener?Address=*+Transport=HTTP

Verify AllowRemoteShellAccess 

Set-WSManInstance -ResourceURI winrm/config/winrs -ValueSet @{AllowRemoteShellAccess="true"}.

PowerShell Constrained Mode

DMC does not support PowerShell constrained mode. This feature must be disabled on Windows VMs to allow DMC to collect the required system information.

To disable PowerShell constrained mode:

Check Current Status

Run the following command to check if constrained mode is enabled:

$ExecutionContext.SessionState.LanguageMode

Disable Constrained Mode

If the output shows “ConstrainedLanguage”, run the following command to disable it:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

Check UAC Token Filtering

Run the following command to check if UAC token filtering is enabled:

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy

If the value is 0, UAC token filtering is enabled and may prevent DMC from collecting data. Set the value to 1 to disable filtering:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
PowerShell constrained mode restricts the execution of certain PowerShell commands and modules, which prevents DMC from collecting necessary system information. Ensure this mode is disabled before running DMC discovery.

Linux Server Configuration

Enable SSH Service 

sudo systemctl enable --now sshd
sudo systemctl status sshd

Secure SSH Configuration

Edit /etc/ssh/sshd_config:

Port 22
PasswordAuthentication no
PermitRootLogin prohibit-password

Restart SSH:

sudo systemctl restart sshd

Verify SSH 

ssh -i ~/.ssh/id_rsa <username>@<server-ip>

VMware Configuration

vCenter and ESXi Requirements

DMC requires network access to vCenter servers and ESXi hosts within the scope of discovery.

Verify vSphere Version Compatibility

DMC is compatible with:

  • vSphere 6.0 and above

Test vCenter Connectivity 

curl -k https://<vcenter-ip>/sdk

Test ESXi Host Connectivity 

curl -k https://<esxi-ip>/sdk

VMware Guest VM Configuration

Windows VMs in VMware Environment

For Windows VMs running on VMware, follow the same Windows Server Configuration steps outlined above, including:

  • Enabling PowerShell Remoting
  • Configuring AllowRemoteShellAccess
  • Disabling PowerShell Constrained Mode (if enabled)
  • Configuring UAC Token Filtering (if needed)

Credential Issues

VMware vCenter Credentials

Required vCenter Account Permissions:

  • Read-only access to VMs, Hosts, and Datastores
  • Guest Operations execution role
  • Access to retrieve performance metrics

Least Privilege vCenter Roles:

  • VirtualMachine.GuestOperations.Query
  • VirtualMachine.GuestOperations.Execute
  • VirtualMachine.GuestOperations.Modify
  • Read Only access to vCenter

Windows Accounts

General Windows VMs:

  • Use an account in Remote Management Users (or Local Admin if needed).
  • Domain Admin is not required unless scanning highly privileged objects.
  • Interactive Login Rights are required for the account to authenticate properly.

Windows VMs in VMware (Least Privilege Setup):

  • Remote Management Users group membership
  • Performance Monitor Users group membership
  • Performance Log Users group membership
  • CIMV2 namespace permissions for data collection
  • Interactive Login Rights are required for the account to authenticate properly

Linux Accounts

  • Use a non-root user with sudo rights.
  • Verify sudo permissions: 
    sudo -l -U <username>

Required sudo access (NOPASSWD) for Linux VMs:

# Commands needed: netstat/ss, ps, ls
sudo -l -U <username>

Sudoers file entry example:

username ALL=(ALL) NOPASSWD: /usr/bin/netstat, /usr/bin/ss, /usr/bin/ps, /usr/bin/ls

System State Issues

Check that:

  • Servers are powered on.
  • NICs are active (ipconfig /all on Windows, ip addr show on Linux).
  • Required services (WinRM, SSH) are running.

Advanced Troubleshooting

Windows 

winrm get winrm/config
Test-WSMan -ComputerName <target>

Linux 

sudo journalctl -u sshd -f
sshd -T | grep -E "(port|permitrootlogin|passwordauthentication)"

Network 

# Windows
pathping <server-ip>
# Linux
mtr <server-ip>
sudo tcpdump -i any port 22

Re-import and Configuration

Where possible, edit servers directly in the DMC UI.
If using CSV:

  1. Correct details (IP or hostname, credentials).
  2. Re-import CSV.
  3. Re-validate.

Single Device Scanning for Troubleshooting

When a machine shows issues in the troubleshooting report or fails during batch scanning, it’s recommended to scan that specific device individually to isolate the problem.

When to Use Single Device Scanning

Use this approach when:

  • A device shows as “Unreachable” in batch scans
  • A device fails validation during batch operations
  • A device appears in the troubleshooting report with errors
  • You want to test configuration changes on a specific machine

Steps for Single Device Scanning

Create Individual Device Entry

For Physical/Hyper-V/Linux servers:

  1. In the DMC UI, add the problematic device as a single entry
  2. Use the exact same credentials and configuration that failed in the batch scan
  3. Ensure the device details (IP/hostname) are correct

For VMware environments:

  1. In the VMware Scan UI, proceed through the normal configuration steps
  2. When you reach the Review Servers step, use the manual selection options
  3. Select only the problematic VM using checkboxes or search filters
  4. Ensure the same guest credentials are configured that failed in the batch scan

Validate Single Device

For Physical/Hyper-V/Linux servers:

  1. Select the single device entry
  2. Click Validate Selected to test connectivity and credentials
  3. Review any validation errors and address them

For VMware environments:

  1. The validation happens automatically during the credential validation phase
  2. Review the validation results in the guest credentials validation screen
  3. Address any credential or connectivity issues shown in the validation report

Run Single Device Scan

For Physical/Hyper-V/Linux servers:

  1. Once validation passes, run a discovery scan on the single device
  2. Monitor the scan progress and check for any errors
  3. Review the scan results to ensure data collection was successful

For VMware environments:

  1. Click Save to confirm the single VM selection
  2. Click Run Scan to execute the scan on only the selected VM
  3. Monitor the scan progress and check for any errors in the console output
  4. Review the scan summary to ensure data collection was successful

Compare Results

  1. Compare the single device scan results with the batch scan results
  2. If the single device scan succeeds, the issue may be related to:
    • Batch processing limitations
    • Resource contention during batch operations
    • Network timing issues during concurrent scans

Troubleshoot Based on Results

  • If single scan succeeds: The device configuration is correct; consider batch size or timing
  • If single scan fails: Focus on the specific error messages and apply targeted fixes
Single device scanning helps isolate whether issues are device-specific or related to batch processing. This approach often reveals configuration problems that are masked during batch operations.

Troubleshooting “Unreachable” Servers

If a server shows as Unreachable during validation (e.g., ports 5985/5986 for Windows or 22 for Linux not open), follow these steps:

Check Server Power and NIC

Ensure the server is powered on and NICs are active. From the jumpbox:

ping <server-ip>

Check Required Ports

Verify the required ports are accessible:

Windows:

Test-NetConnection -ComputerName <server-ip> -Port 5985
Test-NetConnection -ComputerName <server-ip> -Port 5986

Linux:

nc -zv <server-ip> 22

VMware vCenter/ESXi:

nc -zv <vcenter-ip> 443
nc -zv <esxi-ip> 443

Enable the Management Service

Enable the appropriate remote management service:

On Windows:

Enable-PSRemoting -Force

On Linux:

sudo systemctl enable --now sshd

For VMware vCenter/ESXi:

  • vCenter and ESXi services should be running by default
  • Verify vCenter service status in vSphere Client
  • Check ESXi host services via SSH or vSphere Client

Check Firewall Rules

Verify firewall rules allow the required traffic:

Windows:

Get-NetFirewallRule -DisplayGroup "Windows Remote Management"

Linux:

sudo iptables -L -n | grep 22

VMware vCenter/ESXi:

  • Check vCenter firewall rules in vSphere Client
  • Verify ESXi firewall rules via SSH or vSphere Client
  • Ensure port 443 is open for vSphere API communication

Verify Listeners

Check that the services are listening on the correct ports:

Windows:

winrm enumerate winrm/config/listener

Linux:

sshd -T | grep port

VMware vCenter/ESXi:

# Test vSphere API endpoint
curl -k https://<vcenter-ip>/sdk
curl -k https://<esxi-ip>/sdk

Re-validate in DMC

Return to the DMC UI, select the server, and click Validate Selected.

Common Error Messages and Solutions

Error Message Likely Cause Next Step
“Connection refused” Port closed / service not running Run Test-NetConnection/nc; enable WinRM/SSH; open firewall
“Access denied” Insufficient privileges Verify group membership, sudo rights, account lockout
“Host unreachable” Network path down Check power state, NICs, firewall, traceroute
“Authentication failed” Wrong user/password or SSH key Retry with correct credentials, check sshd_config
“Operation timeout” Latency or firewall filtering Pathping/mtr, firewall rules
“Guest operations not available” vCenter permissions insufficient Verify Guest Operations roles assigned to vCenter account
“PowerShell constrained mode” Constrained language mode enabled Disable PowerShell constrained mode on Windows VMs
“UAC filtering enabled” UAC token filtering blocking access Disable UAC token filtering or grant CIMV2 permissions

Next Steps

  1. Re-validate servers in DMC.
  2. Test with a small sample scan.
  3. Run full scan when validation succeeds.
  4. Monitor logs for new issues.