Skip to main content
Version: Next

Task 01: Enable WinRM for Remote Management

Runbook Azure Dell

DOCUMENT CATEGORY: Runbook SCOPE: Remote management enablement PURPOSE: Bootstrap PowerShell remoting on all cluster nodes so subsequent Phase 03 tasks can run remotely from the management server MASTER REFERENCE: Phase 03: OS Configuration

Status: Active

Overview​

Enable WinRM on each Azure Local node. This task must run directly on each node via iDRAC Virtual Console — WinRM cannot be enabled remotely because it does not exist yet on a fresh OS installation.

Once complete on all nodes, all subsequent Phase 03 tasks can be executed remotely from the management server.

Prerequisites​

RequirementDescriptionSource
Phase 02 CompleteAzure Stack HCI OS installed and verified on all nodesPhase 02
iDRAC console accessVirtual Console accessible for each nodevariables.yml: nodes.<name>.idrac_ip
Administrator credentialsLocal admin password set during OS installationKey Vault: node-<hostname>-local-admin

Variables from variables.yml​

PathTypeDescription
nodes.<name>.idrac_ipstringiDRAC IP for console access if WinRM fails
nodes.<name>.management_ipstringManagement IP for TrustedHosts configuration
network.management_subnetstringManagement subnet for TrustedHosts wildcard pattern

TrustedHosts Configuration​

TrustedHosts controls which remote computers are allowed to connect to the node via WinRM. Before running the script, identify all networks from which you will be managing these nodes and combine them into a comma-separated value.

Update TrustedHosts Before Running

The script defaults to 10.245.64.* as a placeholder. You must update this to match your environment before running. An incorrect or missing TrustedHosts entry will prevent remote management from working and is a common source of "Access denied" failures.

Networks to Include​

NetworkSourceExample
Management server subnetvariables.yml: network.management_subnet10.245.64.*
Point-to-site VPN client poolvariables.yml: p2s_client_address_pool172.16.0.0/24
Delivery engineer working networkLaptop/jumpbox subnet during the engagement192.168.1.*

Include all networks from which you or the management server will connect to the nodes. If you are working from a P2S VPN connection, your VPN-assigned address will come from the p2s_client_address_pool range — this must be in TrustedHosts or your remote sessions will be rejected.

Combining Multiple Networks​

TrustedHosts accepts a comma-separated list of hostnames, IP addresses, or wildcards:

# Example combining management subnet, P2S VPN pool, and delivery engineer network
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "192.168.211.*,172.16.0.*,192.168.1.*,10.250.*" -Force

To append to an existing TrustedHosts list without overwriting:

$current = (Get-Item WSMan:\localhost\Client\TrustedHosts).Value
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "$current,172.16.0.*" -Force
Use a Subnet Wildcard

Using a wildcard per subnet (e.g., 10.245.64.*) is more practical than listing individual IPs and covers the entire subnet for the duration of the engagement.

Execution​

Run on each node via iDRAC Virtual Console. Repeat for every node before proceeding.

  1. Open https://<idrac-ip> → Virtual Console → Launch
  2. Log in as Administrator
  3. Update the TrustedHosts value to match your environment (see TrustedHosts Configuration above)
  4. Run the following:
# Enable WinRM
winrm quickconfig -q

# Set network profile to Private (required for WinRM)
Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private

# Enable WinRM firewall rules
Enable-NetFirewallRule -DisplayGroup "Windows Remote Management"

# Configure TrustedHosts — update to include all networks you will manage from
# Include: management subnet, P2S VPN client pool, delivery engineer working network
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "10.245.64.*,172.16.0.*" -Force

# Verify
Get-Service WinRM | Select-Object Name, Status, StartType
Test-WSMan -ComputerName localhost

Validation Checklist​

  • TrustedHosts updated to include all required networks before running
  • Script completed on all nodes via iDRAC Virtual Console
  • WinRM service Running and StartType: Automatic on all nodes
  • Test-WSMan -ComputerName localhost returns schema version without error on all nodes
  • PSRemoting session can be established from management server to each node

Troubleshooting​

IssueCauseResolution
winrm quickconfig failsWinRM service disabledStart-Service WinRM; Set-Service WinRM -StartupType Automatic
Test-WSMan fails locallyNetwork profile still PublicGet-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private
Management server cannot connectTrustedHosts not set on management serverRun Set-Item WSMan:\localhost\Client\TrustedHosts -Value "10.245.64.*" -Force on the management server
P2S VPN session rejectedP2S client pool not in TrustedHostsAdd p2s_client_address_pool range to TrustedHosts on each node
"Access denied" from management serverWrong credentialsVerify local Administrator password from Key Vault
← Phase 03 Overview↑ Phase 03: OS ConfigurationTask 02: Enable RDP →

Version Control​

VersionDateAuthorChanges
1.02026-01-31Azure Local Cloud Azure Local CloudnologyInitial document
1.12026-03-04Azure Local Cloud Azure Local CloudnologyRemove tabs, flat prose version
1.22026-03-04Azure Local Cloud Azure Local CloudnologyIncorrect orchestrated tab removed
1.32026-03-04Azure Local Cloud Azure Local CloudnologyDirect (On Node) + Standalone tabs
1.42026-03-04Azure Local Cloud Azure Local CloudnologyIncorrectly replaced with single orchestrated tab
1.52026-03-04Azure Local Cloud Azure Local CloudnologySingle Direct Script (On Node) tab with correct bootstrap script
1.62026-03-04Azure Local Cloud Azure Local CloudnologyAdd TrustedHosts Configuration section covering management subnet, P2S VPN pool, and delivery engineer network