Windows Server for beginners. Part 15: Managing servers from a workstation

The servers in this series run Server Core, and there is nothing on them but a console. Much of what we did in the previous parts was run from the workstation ws1: the ActiveDirectory module, Get-DnsServerZone, Install-WindowsFeature -ComputerName, Invoke-Command. In the previous part we took apart WinRM, the transport for some of these commands. Now let's assemble the whole workplace: where the role modules on a workstation come from, which protocols each of them uses to reach a server, what to do when a module is missing, and how not to turn the administrator's workstation into the weakest spot of the domain.

---

RSAT

Remote Server Administration Tools are the same management tools that get installed on a server together with a role (-IncludeManagementTools), but for Windows 10 and 11: PowerShell modules, MMC snap-ins and command-line utilities. Since Windows 10 1809 this is not a separate installer but Features on Demand: packages Windows downloads from Windows Update when they are requested. Listing and installing them needs an elevated console: without elevation Get-WindowsCapability answers "The requested operation requires elevation.". This is the list on Windows 11 24H2 before installation:

PS C:\> Get-WindowsCapability -Online -Name 'Rsat.*' | Select-Object Name, State

Name                                                          State
----                                                          -----
Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0             NotPresent
Rsat.AzureStack.HCI.Management.Tools~~~~0.0.1.0          NotPresent
Rsat.BitLocker.Recovery.Tools~~~~0.0.1.0                 NotPresent
Rsat.CertificateServices.Tools~~~~0.0.1.0                NotPresent
Rsat.DHCP.Tools~~~~0.0.1.0                               NotPresent
Rsat.Dns.Tools~~~~0.0.1.0                                NotPresent
Rsat.FailoverCluster.Management.Tools~~~~0.0.1.0         NotPresent
Rsat.FileServices.Tools~~~~0.0.1.0                       NotPresent
Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0             NotPresent
Rsat.IPAM.Client.Tools~~~~0.0.1.0                        NotPresent
Rsat.NetworkController.Tools~~~~0.0.1.0                  NotPresent
Rsat.NetworkLoadBalancing.Tools~~~~0.0.1.0               NotPresent
Rsat.RemoteAccess.Management.Tools~~~~0.0.1.0            NotPresent
Rsat.ServerManager.Tools~~~~0.0.1.0                      NotPresent
Rsat.StorageMigrationService.Management.Tools~~~~0.0.1.0 NotPresent
Rsat.StorageReplica.Tools~~~~0.0.1.0                     NotPresent
Rsat.SystemInsights.Management.Tools~~~~0.0.1.0          NotPresent
Rsat.VolumeActivation.Tools~~~~0.0.1.0                   NotPresent
Rsat.WSUS.Tools~~~~0.0.1.0                               NotPresent

PS C:\> Get-WindowsCapability -Online -Name 'Rsat.*' | Where-Object State -eq NotPresent | Add-WindowsCapability -Online

The list depends on the Windows version: the documentation also has Rsat.LLDP.Tools, Rsat.RemoteDesktop.Services.Tools and Rsat.Shielded.VM.Tools, which 24H2 doesn't offer. The last line installs everything; for this series six are enough: ActiveDirectory.DS-LDS, Dns, DHCP, GroupPolicy.Management, and later CertificateServices and ServerManager (the AD tools pull it in as a dependency anyway). One trap: on a network with WSUS, Features on Demand are looked up on WSUS by default, where they don't exist, and installation fails with 0x800f0954. The fix is the policy "Specify settings for optional component installation and component repair" (Computer Configuration → Administrative Templates → System) with the box "Download repair content and optional features directly from Windows Update instead of Windows Server Update Services (WSUS)".

What the components bring: PowerShell modules (ActiveDirectory, DnsServer, DhcpServer, GroupPolicy), snap-ins (dsa.msc, dssite.msc, domain.msc, adsiedit.msc, dnsmgmt.msc, dhcpmgmt.msc, gpmc.msc, and from CertificateServices — certsrv.msc, certtmpl.msc and pkiview.msc; it has no PowerShell module) and utilities (repadmin, dcdiag, ntdsutil, dsacls, netdom, ldp, dnscmd). Checking what appeared in PowerShell 7 comes with one caveat:

PS C:\> Get-Module -ListAvailable ActiveDirectory, DnsServer, DhcpServer, GroupPolicy | Select-Object Name, Version

Name            Version
----            -------
ActiveDirectory 1.0.1.0
DnsServer       2.0.0.0

PS C:\> Get-Module -ListAvailable DhcpServer, GroupPolicy -SkipEditionCheck | Select-Object Name, Version, CompatiblePSEditions

Name        Version CompatiblePSEditions
----        ------- --------------------
DhcpServer  2.0.0.0 {}
GroupPolicy 1.0.0.0 {}

The modules live in the Windows PowerShell 5.1 directory, and PowerShell 7 shows only those of them that declare compatibility with it (CompatiblePSEditions containing Core). DhcpServer and GroupPolicy don't, so Import-Module DhcpServer loads the module not into PowerShell 7 but through the compatibility layer — more on that in the section on implicit remoting. If a module actually works in PowerShell 7, it can be loaded directly: Import-Module DhcpServer -SkipEditionCheck; this works for DhcpServer and GroupPolicy.

The RSAT version has to match the version of the managed servers, and the module version number doesn't help here: DnsServer is 2.0.0.0 on both Windows Server 2019 and 2025, but the 2025 one has two more commands (Get- and Set-DnsServerEncryptionProtocol, DNS over HTTPS). A module from an older Windows doesn't know the commands and parameters of a newer one, and a new command sent to an old server runs into its provider:

PS C:\> Get-DnsServerEncryptionProtocol -CimSession dns2019     # a DNS server on Windows Server 2019
Get-DnsServerEncryptionProtocol: The WS-Management service cannot process the request. The class PS_DnsServerEncryptionProtocol does not exist in the root/microsoft/windows/dns namespace.

If the workstation is a Windows Server, the same tools are installed as features: Install-WindowsFeature RSAT-AD-Tools, RSAT-DNS-Server, RSAT-DHCP, GPMC.

---

Transports

RSAT modules have several different ways of reaching a server, and you need to know them to understand which port to open and why one command works while the one next to it doesn't.

Their own protocol. The ActiveDirectory module talks to ADWS on port 9389 (part 13). The GroupPolicy module uses LDAP to a controller and SMB to SYSVOL, with the -Server or -Domain parameter. These modules know what they work with, and their transport is built in.

CIM over WinRM. The DnsServer, DhcpServer, Storage, NetTCPIP, NetAdapter, NetSecurity, SmbShare, ScheduledTasks, PrintManagement, Defender modules and a few dozen more are built the same way: their commands are functions generated from CDXML (cmdlet definition XML), wrappers around WMI classes. They all share the -CimSession parameter: it accepts a ready CIM session or a computer name, in which case a session is created for one call; the transport to a remote server is WinRM with WS-Management operations on CIM:

PS C:\> Get-Command Get-DnsServerZone | Select-Object CommandType, Source, Version

CommandType Source    Version
----------- ------    -------
   Function DnsServer 2.0.0.0

PS C:\> Get-ChildItem C:\Windows\System32\WindowsPowerShell\v1.0\Modules\DnsServer\*.cdxml | Select-Object -First 3 Name

Name
----
PS_DnsServer_v1.0.0.cdxml
PS_DnsServerCache_v1.0.0.cdxml
PS_DnsServerClientSubnet_v1.0.0.cdxml

PS C:\> Get-CimClass -Namespace root/Microsoft/Windows/DNS -ClassName PS_DnsServerZone -ComputerName dc1 | Select-Object -ExpandProperty CimClassMethods | Select-Object -First 4 Name

Name
----
Export
Get
Remove
Resume

The DnsServer module has 51 CDXML files and 133 functions. Get-DnsServerZone -CimSession dc1 is a call of the static method Get of the class PS_DnsServerZone in the root/Microsoft/Windows/DNS namespace on dc1 over WinRM; the class has six methods in all (Suspend and Sync as well), and each function maps to its own: Suspend-DnsServerZone to Suspend, Remove-DnsServerZone to Remove. Creating a zone is a different class, PS_DnsServerPrimaryZone. One session for several commands and servers saves the time spent setting up connections:

PS C:\> Import-Module DhcpServer -SkipEditionCheck
PS C:\> $cim = New-CimSession -ComputerName dc1, dc2
PS C:\> Get-DnsServerZone -CimSession $cim | Where-Object IsDsIntegrated | Format-Table ZoneName, PSComputerName

ZoneName                PSComputerName
--------                --------------
_msdcs.corp.example.com dc1
1.168.192.in-addr.arpa  dc1
corp.example.com        dc1
_msdcs.corp.example.com dc2
1.168.192.in-addr.arpa  dc2
corp.example.com        dc2

PS C:\> Get-DhcpServerv4ScopeStatistics -CimSession $cim | Format-Table ScopeId, InUse, Free, PSComputerName

ScopeId     InUse Free PSComputerName
-------     ----- ---- --------------
192.168.1.0    29  152 dc1
192.168.1.0    27  154 dc2

PS C:\> Get-CimInstance Win32_OperatingSystem -CimSession $cim | Format-Table CSName, LastBootUpTime, FreePhysicalMemory

CSName LastBootUpTime         FreePhysicalMemory
------ --------------         ------------------
DC1    10/26/2026 1:40:44 PM             1539176
DC2    10/25/2026 11:47:59 AM            2626256

PS C:\> Remove-CimSession $cim

The same scope on both servers is the failover pair from part 8. The Import-Module ... -SkipEditionCheck in the first line is there for a reason: without it DhcpServer loads through the compatibility layer, and a CIM session from PowerShell 7 can't be passed there — the command answers "Cannot convert the "CimSession: dc1" value of type "Deserialized.Microsoft.Management.Infrastructure.CimSession" to type "Microsoft.Management.Infrastructure.CimSession"". Get-CimInstance does the same for any WMI class, and it replaces Get-WmiObject from Windows PowerShell 5.1, which used DCOM and doesn't exist in PowerShell 7. For servers without WinRM New-CimSession has -SessionOption (New-CimSessionOption -Protocol Dcom), but that is RPC with all its ports.

-ComputerName in DnsServer and DhcpServer is not WinRM. Commands of these two modules also have -ComputerName, and the name suggests the same one-call session. But it's an ordinary method parameter passed to the provider: the command calls the local class PS_DnsServerZone, and its provider, installed with RSAT, contacts the DNS service on dc1 over RPC itself — using the MS-DNSP protocol, the same one the DNS Manager snap-in uses; DhcpServer works the same way with MS-DHCPM. The difference shows in PSComputerName:

PS C:\> Get-CimClass -Namespace root/Microsoft/Windows/DNS -ClassName PS_DnsServerZone | Select-Object CimClassName, @{n='Provider'; e={$_.CimClassQualifiers['provider'].Value}}

CimClassName     Provider
------------     --------
PS_DnsServerZone DnsServerPSProvider

PS C:\> Get-DnsServerZone -ComputerName dc1 -Name corp.example.com | Select-Object ZoneName, ZoneType, IsDsIntegrated, PSComputerName

ZoneName         ZoneType IsDsIntegrated PSComputerName
--------         -------- -------------- --------------
corp.example.com Primary            True

PS C:\> Get-DnsServerZone -CimSession dc1 -Name corp.example.com | Select-Object ZoneName, ZoneType, IsDsIntegrated, PSComputerName

ZoneName         ZoneType IsDsIntegrated PSComputerName
--------         -------- -------------- --------------
corp.example.com Primary            True dc1

The result is the same, the path is different: with -ComputerName the command ran on the workstation, in a WmiPrvSE.exe process, and that process opened the connections to dc1 — to port 135 and to the dynamic port of the DNS service (you'll see it in "Looking with our own eyes" below). That's why -ComputerName works without WinRM on the server but needs the firewall rules "DNS Service" and "DHCP Server Management", which the role enables when it's installed.

RPC and DCOM. Windows PowerShell 5.1 cmdlets with -ComputerName — Get-Service, Get-Process, Get-EventLog — don't have this parameter in PowerShell 7 ("A parameter cannot be found that matches parameter name 'ComputerName'."). Of what remains, RPC is used by Get-WinEvent -ComputerName, CIM sessions over DCOM, the -ComputerName of the DNS and DHCP modules and most MMC snap-ins: the Endpoint Mapper on 135 and a dynamic port from part 3. On the server's firewall they need rule groups, most of which are disabled by default, and without them the answer is always the same:

PS C:\> Get-WinEvent -ComputerName dc1 -LogName System -MaxEvents 1
Get-WinEvent: The RPC server is unavailable.

PS C:\> Invoke-Command dc1, dc2 { Enable-NetFirewallRule -DisplayGroup 'Remote Event Log Management', 'Remote Service Management', 'Remote Scheduled Tasks Management', 'Windows Management Instrumentation (WMI)', 'Remote Volume Management' }

On domain controllers the "Windows Management Instrumentation (WMI)" group is already enabled, on member servers it isn't; the other four are disabled everywhere. Which snap-in uses what:

Snap-in	Transport	Firewall rule on the server
Active Directory Users and Computers, Sites and Services, ADSI Edit	LDAP 389/3268, RPC (SAMR) for some operations	always open on a controller
DNS Manager	RPC to the DNS service (MS-DNSP: 135 and a dynamic port)	"DNS Service" — enabled when the role is installed
DHCP Manager	RPC to the DHCP service (MS-DHCPM)	"DHCP Server Management" — enabled when the role is installed
Group Policy Management	LDAP and SMB (445)	open on a controller
Event Viewer, Services, Task Scheduler, Computer Management	RPC to each service separately	"Remote … Management" groups — disabled
Disk Management	RPC to the Virtual Disk service	"Remote Volume Management" — disabled, and it has to be enabled on both the server and the workstation
Server Manager	WinRM	"Windows Remote Management" — enabled

That's why Enter-PSSession dc1 works on a fresh server while Event Viewer connected to dc1 doesn't: different protocols, different rules. On a network with a firewall between the administrators' segment and the servers, dynamic RPC ports become a separate task, which WinRM on 5985 removes entirely — and that's the main practical argument for PowerShell with -CimSession and Invoke-Command over snap-ins.

---

Implicit remoting

The module is not on the workstation, or it's older than the server's, or the workstation isn't Windows at all. Part 14 had Invoke-Command, but writing every command inside a block is inconvenient. Implicit remoting imports commands from a session as local ones:

PS C:\> $s = New-PSSession -ComputerName dc1
PS C:\> Import-Module -PSSession $s -Name DhcpServer -Prefix DC1
PS C:\> Get-DC1DhcpServerv4Scope | Format-Table ScopeId, Name, State

ScopeId     Name   State
-------     ----   -----
192.168.1.0 Office Active

PS C:\> Get-Command Get-DC1DhcpServerv4Scope | Select-Object CommandType, Source

CommandType Source
----------- ------
   Function DhcpServer

PS C:\> (Get-Module DhcpServer).Path
C:\Users\alice.admin\AppData\Local\Temp\remoteIpMoProxy_DhcpServer_2.0.0.0_dc1_6f0c…\remoteIpMoProxy_DhcpServer_2.0.0.0_dc1_6f0c….psm1

A proxy module with the same name, generated in a temporary folder, appeared on the workstation, and in it functions with the DC1 prefix: calling Get-DC1DhcpServerv4Scope runs Get-DhcpServerv4Scope in the session on dc1 and returns the result. Tab completion and help work, objects arrive serialized (PowerShell restores CIM instances as CIM, everything else as Deserialized.* without methods). Without -Prefix the functions get their native names and shadow local ones, if any. The older form of the same is Import-PSSession -Session $s -Module DhcpServer; it names the proxy module tmp_<random name>. Export-PSSession saves the proxies to disk as an ordinary module that opens a session to dc1 by itself on the first call:

PS C:\> Export-PSSession -Session $s -Module DhcpServer -OutputModule DhcpFromDc1
PS C:\> Remove-PSSession $s

# in a new window
PS C:\> Import-Module DhcpFromDc1 -Prefix DC1
PS C:\> Get-DC1DhcpServerv4Scope | Format-Table ScopeId, Name, State, PSComputerName
Creating a new session for implicit remoting of "Get-DhcpServerv4Scope" command...

ScopeId     Name   State  PSComputerName
-------     ----   -----  --------------
192.168.1.0 Office Active dc1

This also solves the version problem: the DhcpServer module from a Windows Server 2025 controller knows all the 2025 commands and parameters through implicit remoting, whatever RSAT is installed on the workstation. And it's also the way to manage Windows servers from Linux or macOS with PowerShell 7 — through an SSH session from the next part.

PowerShell 7 uses the same mechanism to load modules that haven't declared compatibility with it. Import-Module DhcpServer without -SkipEditionCheck starts a local Windows PowerShell 5.1 process — the session WinPSCompatSession to localhost — and imports the module from there:

PS C:\> Import-Module DhcpServer
WARNING: Module DhcpServer is loaded in Windows PowerShell using WinPSCompatSession remoting session; please note that all input and output of commands from this module will be deserialized objects. If you want to load this module into PowerShell please use 'Import-Module -SkipEditionCheck' syntax.

PS C:\> Get-PSSession | Format-Table Id, Name, ComputerName, State

Id Name               ComputerName  State
-- ----               ------------  -----
 2 WinPSCompatSession localhost    Opened

PS C:\> Get-DhcpServerv4ScopeStatistics -ComputerName dc1 | Format-Table ScopeId, InUse, Free, PSComputerName

ScopeId     InUse Free PSComputerName
-------     ----- ---- --------------
192.168.1.0    29  152 localhost

PSComputerName here is localhost: the object came from the 5.1 process on the same machine, and that process is what contacted dc1. GroupPolicy is loaded the same way, and that's also how PowerShell 7 finds Get-WmiObject if you call it: the command works, but through the same layer and with the same deserialized objects.

---

Windows Admin Center

Windows Admin Center (WAC) is a web interface to servers: a page in a browser and behind it a gateway that reaches the servers over WinRM — PowerShell Remoting and WMI over WinRM. It's installed on a management server (wac.corp.example.com) or on a workstation; on Windows Server it listens on 443, on client Windows on 6600 and only locally. It checks gateway users through Windows (Active Directory or local groups) or through Microsoft Entra ID, Microsoft's cloud directory from the last parts of the series, and for each server shows an overview with load, events, services, processes, updates, firewall, roles, storage, network, certificates, scheduled tasks, registry and a PowerShell console in the browser; extensions add Active Directory, DNS, DHCP, Hyper-V, clusters and Azure. The current version is installed not by an MSI but by an EXE installer:

PS C:\> Start-BitsTransfer -Source https://aka.ms/WACdownload -Destination C:\Temp\WindowsAdminCenter.exe
PS C:\> Start-Process -FilePath C:\Temp\WindowsAdminCenter.exe -ArgumentList '/VERYSILENT' -Wait

Without your own certificate (/CertificateThumbprint= with a thumbprint from LocalMachine\My) the installer issues a self-signed one for 60 days — for testing, not for real work. The gateway on a server has a property familiar from part 14: it connects to servers on behalf of the user, that is, it makes a second hop, and for single sign-on without re-entering the password every managed server has to allow resource-based constrained delegation to the gateway's computer account — that's what the WAC documentation prescribes; here the delegation is done by the gateway itself, not by a PowerShell session on an intermediate server as in part 14:

PS C:\> Set-ADComputer -Identity (Get-ADComputer srv1) -PrincipalsAllowedToDelegateToAccount (Get-ADComputer wac)

For this series it's valuable for one button: every WAC tool has a PowerShell icon on its bar that shows the scripts behind the actions on that page. So any action in the UI can be turned into a command for a script. We'll refer to it but won't rely on it: everything it does is done by commands it shows itself.

---

The administrator's workstation

The workstation from which a domain administrator signs in to the controllers is the second most valuable target after the controllers themselves. The rules that follow from this don't depend on the size of the organization.

A separate account. alice reads mail and browses the web; alice.admin from part 4 does neither. On the workstation it's used only to start tools:

PS C:\> runas /user:CORP\alice.admin pwsh
PS C:\> Start-Process pwsh -Credential (Get-Credential CORP\alice.admin)
PS C:\> runas /netonly /user:CORP\alice.admin "mmc dsa.msc"     # /netonly: locally as the current user, to the network as alice.admin

A program with arguments is quoted as a whole, otherwise runas takes dsa.msc for an extra parameter.

Where the password ends up. Every interactive logon — RDP, runas without /netonly — leaves credentials in the memory of lsass on the target machine, and they can be extracted. The rule: administrative credentials are entered only on machines of the same trust level. A controller is trusted, you can sign in to it over RDP; a server with a web application that gets broken into through a vulnerability in that application is not. For RDP to such servers there's Remote Credential Guard (mstsc /remoteGuard /v:srv1): credentials stay on the workstation, the server forwards Kerberos requests back to it as needed, and neither the password nor keys end up in its memory; it works only over Kerberos, with no fallback to NTLM. The earlier variant is Restricted Admin (mstsc /restrictedAdmin /v:srv1): a logon without passing credentials at all, only for members of the server's local Administrators group, and onward network access from the server uses its computer account rather than yours — the same second hop. The server has to allow both modes: the policy "Remote host allows delegation of nonexportable credentials" (DisableRestrictedAdmin = 0 in HKLM\SYSTEM\CurrentControlSet\Control\Lsa).

Protected Users. A built-in domain group whose members the controllers forbid everything that makes credentials vulnerable: NTLM, DES and RC4 in Kerberos, delegation of any kind, a TGT longer than four hours; workstations don't cache their password or NT hash and don't allow offline sign-in. Administrative accounts are put into it after checking with events 4776 and 4769 from part 6 that they don't use NTLM and RC4 (and that they have AES keys — the password was changed after the domain moved to 2008); service and computer accounts are not put there:

PS C:\> Add-ADGroupMember -Identity 'Protected Users' -Members alice.admin

Separating tiers. In the model Microsoft used to call tiering and now calls the enterprise access model, accounts and machines are split into tiers: 0 — controllers, PKI, identity management systems and whoever manages them; 1 — servers and applications; 2 — workstations and users. A tier 0 account doesn't sign in to tier 1 and 2 machines, and vice versa. A tier 0 administrator's workstation (PAW, privileged access workstation) is a separate machine or a separate virtual machine with minimal software, no mail and no browser, owned only by the administrator. For a domain of three controllers this sounds excessive; for a domain that was broken into through an administrator's laptop it's the only thing that would have helped.

LAPS. A local administrator with the same password on every server and workstation is the second most common reason an attack spreads across a network. Windows LAPS (built into Windows since the April 2023 updates) changes the local administrator password on each machine to a random one and stores it in an attribute of the computer account in the directory — msLAPS-Password or, encrypted, msLAPS-EncryptedPassword; both are on the list of attributes an RODC from part 11 doesn't receive. It's enabled by extending the schema (Update-LapsADSchema), granting computers the right to write their own attribute (Set-LapsADComputerSelfPermission) and a group policy, and it's read with Get-LapsADPassword ws1 -AsPlainText by whoever has been delegated the right.

---

Looking with our own eyes

All transports at once. Four commands from the workstation, then the list of established connections to dc1 and the processes that own them:

PS C:\> $dc1 = (Resolve-DnsName dc1.corp.example.com).IPAddress
PS C:\> Get-ADUser alice -Server dc1 | Out-Null                    # ADWS
PS C:\> Get-DnsServerZone -CimSession dc1 | Out-Null               # CIM over WinRM
PS C:\> Get-DnsServerZone -ComputerName dc1 | Out-Null             # RPC from the local provider
PS C:\> $dcom = New-CimSession dc1 -SessionOption (New-CimSessionOption -Protocol Dcom)
PS C:\> Get-CimInstance Win32_Service -Filter "Name='DNS'" -CimSession $dcom | Out-Null    # DCOM
PS C:\> Get-NetTCPConnection -RemoteAddress $dc1 -State Established | Sort-Object RemotePort | Format-Table RemotePort, OwningProcess, @{n='Process'; e={(Get-Process -Id $_.OwningProcess).Name}}

RemotePort OwningProcess Process
---------- ------------- -------
       135          1236 svchost
       135          1236 svchost
       135          3412 WmiPrvSE
      9389          5124 pwsh
      9389          5124 pwsh
     49671          3412 WmiPrvSE
     49673          5124 pwsh

-RemoteAddress takes all of dc1's addresses: on a network with IPv6 the connections go to 2001:db8:1::10, and a filter on 192.168.1.10 alone would find nothing. Reading line by line:

• two pwsh connections to 9389 are ADWS; the ActiveDirectory module keeps them open for the next commands;
• there's no connection to 5985 any more: -CimSession dc1 with a name instead of a session created a CIM session for one call and closed it;
• WmiPrvSE to 135 and to 49671 is Get-DnsServerZone -ComputerName: the local provider asked the Endpoint Mapper for the DNS service's port and connected to it (on the server, Get-NetTCPConnection -LocalPort 49671 -State Listen shows the dns process);
• pwsh to 49673 is DCOM to the Winmgmt service on dc1, and the two svchost connections to 135 are the local RpcSs service, through which DCOM locates the object on the server.

If you want to see the same at the packet level — pktmon start --capture, the commands, pktmon stop and pktmon etl2pcap for Wireshark (capturing needs administrator rights on the workstation). A snap-in behaves like the third line: dnsmgmt.msc connected to dc1 gives the same 135 and the DNS service's dynamic port, with MS-DNSP calls such as R_DnssrvQuery2 inside. If only 5985 is open on the firewall between the workstation and the server, neither the snap-in nor Get-DnsServerZone -ComputerName dc1 will connect, while Get-DnsServerZone -CimSession dc1 will work.

And a check that the workstation doesn't hold what it shouldn't. In a window opened with runas /netonly, whoami shows corp\alice — locally the process runs as her — while klist after the first access to a server shows alice.admin's tickets: such a logon session has type 9, NewCredentials, and its credentials are used only for the network. Who is in the group:

PS C:\> Get-ADGroupMember 'Protected Users' | Select-Object Name

Name
----
Alice Admin

On a server that alice.admin connected to with Invoke-Command, her credentials aren't present — WinRM with Kerberos doesn't pass them there (part 14).

---

Sources

• Install and Manage Remote Server Administration Tools in Windows — what RSAT contains, installation on Windows Server and client Windows, administrator rights;
• Available features on demand — names of the Rsat.* components, their contents and dependencies;
• Get-WindowsCapability and Add-WindowsCapability — listing and installing Features on Demand;
• Configure a Windows Repair Source — the "Specify settings for optional component installation and component repair" policy;
• Install-WindowsFeature — RSAT features on Windows Server;
• about_Windows_PowerShell_Compatibility — the compatibility layer, WinPSCompatSession, CompatiblePSEditions and -SkipEditionCheck;
• Import-Module, Import-PSSession and Export-PSSession — implicit remoting, -PSSession, -Prefix, saving proxies to a module;
• CDXML overview — commands generated from CIM class definitions;
• New-CimSession, New-CimSessionOption and Get-CimInstance — CIM sessions over WinRM and DCOM;
• DnsServer, Get-DnsServerZone and DhcpServer — the DNS and DHCP modules, the -ComputerName and -CimSession parameters;
• MS-DNSP: Domain Name Service (DNS) Server Management Protocol and MS-DHCPM: Microsoft Dynamic Host Configuration Protocol (DHCP) Server Management Protocol — the RPC protocols for managing the DNS and DHCP services;
• GroupPolicy — the Group Policy module;
• Service overview and network port requirements for Windows — ADWS and RPC ports and the dynamic range;
• Get-WinEvent — -ComputerName without Remoting and the firewall requirement;
• Enable-NetFirewallRule — enabling rule groups by -DisplayGroup;
• Troubleshoot Disk Management — the "Remote Volume Management" rule on both sides;
• Get-NetTCPConnection and Packet Monitor (Pktmon) — connections and packet capture with built-in tools;
• What is Windows Admin Center, Install Windows Admin Center, Get started with Windows Admin Center and User access control and permissions — the gateway and its transport, installation, ports 443 and 6600, viewing PowerShell scripts, single sign-on and delegation;
• Runas — syntax and /netonly;
• Administrative tools and logon types — logon types of RDP, runas and runas /netonly and where credentials remain;
• Remote Credential Guard — Remote Credential Guard and Restricted Admin, the policy on the server;
• Protected Users Security Group — restrictions for group members and warnings;
• Enterprise access model and Privileged access devices — access tiers and PAW;
• Windows LAPS overview, Get-LapsADPassword and Update-LapsADSchema — Windows LAPS, attributes and cmdlets.

---

The road from a Windows workstation to Windows servers is built. But servers have one more door, which Linux administrators have used for twenty years, and since 2018 it has existed in Windows Server too — along with the option of making PowerShell what opens behind it.

Next — part 16: SSH on Windows Server. OpenSSH Server as a feature, sshd_config and how it differs from Linux, keys and the administrators_authorized_keys file, PowerShell as the default shell, Kerberos sign-in via GSSAPI, PowerShell Remoting over SSH instead of WinRM — including from Linux and macOS, and why the built-in Windows client and the client from Git for Windows behave differently.