Docs
How To
DMC
Remediating Access Issues

Remediating Access Issues

Overview

When running DMC physical, Hyper-V, VMware, Linux server scans, or SQL Server assessments, 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
 SQL Server Configuration
SQL Server connectivity, authentication, and troubleshooting
 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

SQL Server Instances:

Test-NetConnection -ComputerName <server-ip> -Port 1433
Test-NetConnection -ComputerName <server-ip> -Port 1434 -Udp

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

SQL Server Firewall:

  • Port 1433 (TCP) – SQL Server default port
  • Port 1434 (UDP) – SQL Server Browser service

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)

SQL Server Configuration

DMC supports assessment of SQL Server instances for Azure migration readiness. The following sections cover SQL Server-specific troubleshooting and configuration requirements.

Test SQL Server Connectivity

Test Port Connectivity:

Test-NetConnection -ComputerName <server-ip> -Port 1433
Test-NetConnection -ComputerName <server-ip> -Port 1434 -Udp

Test SQL Server Connection:

Windows Integrated Authentication:

sqlcmd -S SERVERNAME\INSTANCENAME -E -Q "SELECT @@VERSION"

SQL Server Authentication:

sqlcmd -S SERVERNAME\INSTANCENAME -U username -P password -Q "SELECT @@VERSION"

SQL Server Prerequisites

Remote Connections must be enabled on SQL Server instances to allow DMC to connect and assess databases.

Enable Remote Connections:

  1. Open SQL Server Management Studio (SSMS)
  2. Connect to the SQL Server instance
  3. Right-click the server instance → Properties
  4. Navigate to Connections page
  5. Verify Allow remote connections to this server is checked

Enable Remote Access via T-SQL:

EXEC sp_configure 'remote access', 1;
RECONFIGURE;

Enable TCP/IP Protocol:

  1. Open SQL Server Configuration Manager
  2. Navigate to SQL Server Network Configuration → Protocols for [INSTANCE_NAME]
  3. Right-click TCP/IP → Enable
  4. Right-click TCP/IP → Properties
  5. Navigate to IP Addresses tab
  6. Ensure IPAll section has TCP Dynamic Ports or TCP Port configured
  7. Click OK
  8. Restart the SQL Server service for changes to take effect

Verify TCP/IP is Enabled:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\*\MSSQLServer\SuperSocketNetLib\Tcp" -Name Enabled

The value should be 1 if TCP/IP is enabled.

SQL Server Browser Service

The SQL Server Browser service must be running for named instance discovery and connection.

Start SQL Server Browser Service:

  1. Open Services (services.msc)
  2. Locate SQL Server Browser service
  3. Right-click → Properties
  4. Set Startup type to Automatic
  5. Click Start to start the service
  6. Click OK

Start SQL Server Browser via PowerShell:

Set-Service -Name SQLBrowser -StartupType Automatic
Start-Service -Name SQLBrowser

Verify SQL Server Browser is Running:

Get-Service -Name SQLBrowser

The Status should show Running.

Important: The SQL Server Browser service is required for connecting to named instances. Without it, DMC cannot discover or connect to SQL Server instances that use named instances (e.g., SERVER\SQLEXPRESS).

Configure Firewall Rules for SQL Server

Windows Firewall (for SQL Server on Windows):

# For Default Instance (Port 1433)
New-NetFirewallRule -DisplayName "SQL Server" -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow

# For SQL Server Browser (Port 1434)
New-NetFirewallRule -DisplayName "SQL Server Browser" -Direction Inbound -Protocol UDP -LocalPort 1434 -Action Allow

Linux Firewall (for SQL Server on Linux):

For firewalld (RHEL/CentOS/Fedora):

sudo firewall-cmd --permanent --add-port=1433/tcp
sudo firewall-cmd --permanent --add-port=1434/udp
sudo firewall-cmd --reload

For ufw (Ubuntu/Debian):

sudo ufw allow 1433/tcp
sudo ufw allow 1434/udp
sudo ufw reload

For iptables:

sudo iptables -A INPUT -p tcp --dport 1433 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 1434 -j ACCEPT

SQL Server Authentication Mode Configuration

For SQL Server Authentication:

SQL Server must be configured to allow SQL Server authentication (Mixed Mode).

  1. Open SQL Server Management Studio
  2. Connect to the SQL Server instance
  3. Right-click the server instance → Properties
  4. Navigate to Security page
  5. Under Server authentication, select SQL Server and Windows Authentication mode
  6. Click OK
  7. Restart the SQL Server service for changes to take effect

Configure Mixed Mode via T-SQL:

EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', 
    N'Software\Microsoft\MSSQLServer\MSSQLServer', 
    N'LoginMode', REG_DWORD, 2;

Then restart the SQL Server service.

Service Restart Required: Changing authentication mode requires restarting the SQL Server service. Plan for a maintenance window if changing authentication mode on production servers.

SQL Server Troubleshooting

Issue: “Remote connections not allowed”

Solution:

  1. Enable remote connections (see Enable Remote Connections above)
  2. Verify TCP/IP is enabled
  3. Check firewall rules allow port 1433 (TCP) and 1434 (UDP)
  4. Ensure SQL Server Browser service is running (for named instances)

Issue: “SQL Server Browser service is not running”

Solution:

  1. Start SQL Server Browser service (see SQL Server Browser Service above)
  2. Set startup type to Automatic
  3. Verify firewall allows UDP port 1434

Issue: “Login failed” or “Authentication failed”

For Windows Authentication:

  • Verify the Windows account exists on the machine running DMC
  • Ensure account has SQL Server permissions (sysadmin recommended)
  • Verify DMC is running as Administrator

For SQL Server Authentication:

  • Verify SQL Server is configured for Mixed Mode authentication
  • Test credentials using sqlcmd command
  • Ensure the SQL login has appropriate permissions

Issue: “Permission denied” or “Insufficient permissions”

Solution:

  1. Verify account has sysadmin role (recommended) or minimum permissions:
    • VIEW SERVER STATE
    • VIEW ANY DATABASE
    • CONNECT SQL
  2. Grant additional permissions if needed: 
    ALTER SERVER ROLE sysadmin ADD MEMBER [username];
For detailed SQL Server requirements and configuration, see the MS SQL Requirements documentation.

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

SQL Server Instances:

Test-NetConnection -ComputerName <server-ip> -Port 1433
Test-NetConnection -ComputerName <server-ip> -Port 1434 -Udp

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

For SQL Server:

  • Ensure SQL Server service is running
  • Start SQL Server Browser service (required for named instances)
  • Verify SQL Server is configured to allow remote connections

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

SQL Server:

  • Verify Windows Firewall allows port 1433 (TCP) and 1434 (UDP)
  • For SQL Server on Linux, check firewall rules using firewalld, ufw, or iptables
  • Ensure SQL Server Browser service can pass through firewall

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

SQL Server:

# Test SQL Server connection
sqlcmd -S SERVERNAME\INSTANCENAME -E -Q "SELECT @@VERSION"
# Or with SQL Server Authentication:
sqlcmd -S SERVERNAME\INSTANCENAME -U username -P password -Q "SELECT @@VERSION"

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
“Remote connections not allowed” SQL Server remote access disabled Enable remote connections in SQL Server Configuration Manager
“SQL Server Browser service is not running” SQL Server Browser service stopped Start SQL Server Browser service and set to Automatic startup
“Login failed” (SQL Server) Authentication failure Verify credentials, check Mixed Mode authentication enabled, verify account permissions
“Permission denied” (SQL Server) Insufficient SQL Server permissions Grant sysadmin role or minimum permissions (VIEW SERVER STATE, VIEW ANY DATABASE, CONNECT SQL)

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.