Windows client/server operations: release channels, PowerShell context, services, updates, permissions, WSL boundaries, and evidence-based recovery.

Apache-2.0 Requires access to the target Windows system through its supported shell or management tools.

Instructions

Overview

Use for Windows administration, diagnostics, and automation. Determine the target and management authority; local tools do not establish remote capabilities.

Mental model

Windows behavior depends on edition, channel, identity, and execution context. A successful command or running process does not prove service health.

Release and execution gate

Verified 2026-09-05: Windows 11 25H2 is the general feature-update baseline. Released 26H1 serves specific new hardware and is not an in-place upgrade from 24H2/25H2. Windows Server 2025 is the current LTSC release. Recheck release health and edition-specific lifecycle dates before prescribing an upgrade; Insider and optional preview updates are different channels.

Identify client versus Server, edition, display version, full build/revision, architecture, and installation type. Server Core, desktop clients, Enterprise LTSC, and IoT Enterprise LTSC have different component availability and support terms.
Windows 10 22H2 standard support ended in October 2025; verify ESU enrollment where applicable. Don't apply that lifecycle blindly to Windows 10 LTSC products.
Distinguish native architecture from process bitness/emulation. A 32-bit shell on 64-bit Windows can see redirected filesystem/registry locations; ARM64 machines may run emulated x64 tools.
Windows PowerShell 5.1 uses powershell.exe; PowerShell 7 uses pwsh.exe and installs alongside it. PowerShell 7.6 is current LTS; 7.7 is preview. Check $PSVersionTable, module compatibility, and remoting endpoint rather than assuming Terminal selects PowerShell 7.
Preserve argument boundaries with PowerShell arrays and -LiteralPath where appropriate. Explicitly use sc.exe for the service utility: sc can resolve to a PowerShell alias.

Services and scheduled work

Inspect Service Control Manager configuration before changing it: service name, account, binary arguments, dependencies, start mode, recovery actions, and current state. A display name is not a stable service identifier.
Keep long-lived services under their service manager; use Task Scheduler for scheduled jobs with explicit user, logon requirements, working directory, overlap policy, and exit handling. Interactive success does not prove unattended success.
A stopped demand-start service may be normal. Before restarting, inspect scoped event logs and dependency failures; don't turn every service to Automatic or loop restarts against a persistent configuration error.
For an authorized restart, bound waiting, observe the final state, and check the actual endpoint/workload. Record pending reboot or partial failure instead of reporting success from command acceptance alone.

Packages and update lifecycle

Use the host's existing management channel. WinGet supports modern Windows clients and Server 2025, but availability depends on App Installer and context; don't bootstrap a second manager just because the command is absent.
Resolve exact package ID, source, publisher, architecture, version, and user/machine scope before installation. Preserve installer exit codes and restart requirements; a PATH change may require a new process.
Respect Intune/Group Policy/WSUS controls and update rings. Check known issues, safeguard holds, reboot windows, and recovery options before feature updates; don't bypass a managed deferral by manually installing another channel.
OS servicing, Store apps, WinGet applications, and PowerShell have separate update lifecycles. Verify the changed component after reboot; an empty query or pending installation is not proof of compliance.

Privilege, WSL, and failure handling

Use the least-privileged identity that can perform the operation. Elevation, service-account rights, NTFS/share permissions, and remote authorization are separate; diagnose the denied boundary instead of granting broad Full Control.
Execution policy is a scripting guardrail, not a security boundary. Don't disable Defender, firewall, UAC, application control, or certificate validation to make an unexplained failure disappear.
Record WSL distribution, WSL version, and WSL 1/2 mode separately from Windows. WSL 2 has a Linux kernel in a managed VM; networking, service lifetime, and mounted Windows-file permissions differ from a standalone Linux server.
-ErrorAction Stop promotes cmdlet errors for handling; native utilities need exit-code checks under the selected PowerShell behavior. Some tools define nonzero success/status codes: interpret their contract rather than treating every nonzero value identically.
Capture the failing operation, timestamp, target, and relevant event IDs before changing state. Use bounded, targeted diagnostics; don't dump credentials or entire event stores. Retry only identified transient failures; preserve prior configuration for recovery.

Example

Read-only target inventory, compatible with Windows PowerShell 5.1 and PowerShell 7:

powershell

$PSVersionTable
Get-CimInstance Win32_OperatingSystem -ErrorAction Stop |
    Select-Object Caption, Version, BuildNumber, OSArchitecture
Get-CimInstance Win32_Processor -ErrorAction Stop |
    Select-Object Name, Architecture
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -ErrorAction Stop |
    Select-Object EditionID, DisplayVersion, CurrentBuildNumber, UBR

Processor architecture codes include 9 for x64 and 12 for ARM64. Run in the intended target session; these values alone do not prove patch support or service health.

Checklist

Target, edition/channel, build, architecture, identity, and shell are known.
Service/package/update ownership and reboot consequences are explicit.
Failures remain visible; retries and recovery have stopping conditions.
Post-change evidence verifies the requested behavior, not just command exit.
Executed checks and remaining unknowns are reported separately.

References

View on GitHub