PowerShell for real administration

When I receive an IP address or hostname, the first question is often whether the remote host is running Windows or Linux. That determines which tools, credentials, ports, and remote-management protocols I should try next. There is no universal detection command that works against every host. A firewall can block ping, WinRM, CIM, and SSH, and a network device can answer in a way that looks like an operating system. The most reliable method is to query an operating-system-specific service after confirming that the host is reachable. ...

I installed the PowerShell Preview version on Windows, installed Tabby, and opened a new Tabby terminal. The terminal itself started normally, but running pwsh failed immediately. The error looked like this: Program 'pwsh.exe' failed to run: Access is denied At line:1 char:1 + pwsh + ~~~~ + CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException + FullyQualifiedErrorId : NativeCommandFailed This was confusing because PowerShell Preview had already been installed and pwsh worked outside Tabby. The fix was to remove the Preview package and its remaining AppX package, install the stable PowerShell package, remove Tabby, reboot Windows, and verify which pwsh.exe Windows resolved. ...

I wanted to move an existing WSL installation from Ubuntu 24.04 to Ubuntu 26.04 without creating a second distro and manually copying everything across. The important requirement was to keep the existing contents: home directories, installed packages, shell configuration, SSH keys, WSL settings, scripts, and project files. The approach in this post is an in-place release upgrade. It runs the Ubuntu release upgrade inside the existing Ubuntu-24.04 WSL instance. It is different from installing a new Ubuntu distro and importing files into it. ...

After a VS Code update, I hit a Remote WSL failure even though WSL itself still worked from the command line. The WSL terminal opened normally: wsl But VS Code could not connect to the WSL distro. The Remote WSL log showed a failed download like this: https://update.code.visualstudio.com/commit:<commit-id>/server-linux-x64/insider HTTP request sent, awaiting response... 404 Not Found ERROR: Failed to download https://update.code.visualstudio.com/commit:<commit-id>/server-linux-x64/insider to /home/<user>/.vscode-server-insiders/bin/<commit-id>-<timestamp>.tar.gz The important details are: Log detail Meaning update.code.visualstudio.com VS Code is trying to download its remote server package commit:<commit-id> The server must match the exact VS Code client build server-linux-x64 The server package is for Linux x64 inside WSL insider The VS Code client is using the Insiders update channel .vscode-server-insiders The WSL-side install folder for the Insiders server 404 Not Found That exact server package was not available at the update endpoint This is a VS Code Remote WSL server install problem, not a general WSL failure. ...

I recently had a Windows Scheduled Task fail with this kind of event in the Task Scheduler Operational log: Task Scheduler failed to start "\Folder\Example_Task" task for user "NT AUTHORITY\SYSTEM". Additional Data: Error Value: 2147750687. The important parts are the event source, the event ID, and the error value: Field Value Log Microsoft-Windows-TaskScheduler/Operational Event ID 101 Level Error OpCode Launch Failure Error Value 2147750687 Hex value 0x8004131F In plain English, this usually means Task Scheduler tried to start the task, but another instance of the same task was still running. The task did not fail because PowerShell could not start, and it did not necessarily fail because the account was wrong. It failed before the new run started because Task Scheduler blocked a second instance. ...

Sometimes the schedule belongs in Linux, but the work belongs everywhere. I hit this pattern when a small Hugo site lived in WSL, supporting scripts lived on the Windows host, and the final deployment needed to touch both sides: copy files, run PowerShell scripts, restart the Hugo development service in WSL, and restart IIS on Windows. Cron can handle the schedule cleanly. PowerShell can handle the orchestration cleanly. The useful trick is to let cron call pwsh.exe or powershell.exe, then let the PowerShell script decide what needs to happen on Windows and what needs to happen inside WSL. ...

Scheduled Tasks are one of the most useful built-in deployment tools on Windows. They are not as polished as Intune, Configuration Manager, or a real RMM platform, but they are available almost everywhere and work well for controlled admin jobs: copy a script, run a cleanup task, install an MSI, start a BAT file, or schedule a one-time maintenance command. I use scheduled tasks when I need something more reliable than “open a remote PowerShell session and hope the command keeps running.” A task can run as SYSTEM, run whether a user is logged on or not, keep its own history, and start at a specific time. That makes it useful for local work and for remote deployments to a small group of machines. ...

WSL is useful when an admin workflow lives between Windows and Linux. Sometimes I want Linux-style scheduling with cron, but the actual work still needs to happen on Windows: start a Windows Scheduled Task, run a PowerShell script, trigger a deployment task, or call a remote Windows server. This pattern is not a replacement for a real job scheduler. It is a practical bridge. WSL cron can keep a Linux-style schedule, and each cron entry can call Windows tools such as powershell.exe, schtasks.exe, or wsl.exe path-aware scripts. ...

Windows Task Scheduler and Linux cron solve the same basic problem: run something later, or run it again on a schedule. The idea is simple, but the two tools feel very different in daily administration. On Windows, Scheduled Tasks are tied deeply into the operating system. They understand users, triggers, privileges, idle state, battery state, and event-based starts. On Linux, cron is smaller and more direct. A cron job says, “run this command at this time,” and that simplicity is exactly why it has lasted for decades. ...

PowerShell error handling is easy to ignore while a script is still small. A command fails, the red text appears, and you fix the problem while looking at the console. That stops working when the same script runs from Task Scheduler, a deployment tool, a remote session, or a service account. At that point, the script needs to explain what failed without you watching it live. For production scripts, I usually want two things at the same time: a clear message on the screen when I run the script manually, and a log file that remains after the console is closed. try, catch, and finally are the basic tools for that pattern. ...