PowerShell

Routine Active Directory work does not require an RDP session or an interactive console sign-in on a domain controller. A separate, managed administration workstation is a better place to run the AD tools, inspect objects, make a narrow change, and keep a record of who performed it. That separation matters. Domain controllers hold directory credentials, Kerberos keys, DNS data, and the tools that change the forest. Browsing the web, opening email, or running a general-purpose admin desktop workflow on a DC increases the chance that a workstation-style problem becomes a directory-wide incident. ...

Go and PowerShell work well together on Windows. PowerShell is convenient for orchestration, object filtering, scheduled tasks, and Windows management APIs. Go is useful when a small tool needs a single compiled executable, predictable startup behavior, or easy distribution to machines that do not have a PowerShell module installed. The useful split is simple: use PowerShell to prepare inputs, call the Go program, inspect its output, and react to its exit code. Let the Go program own the focused task it was written for. Do not make PowerShell scrape a human-oriented console screen when the Go command can return structured JSON or a clear exit code instead. ...

Go is a good place to coordinate a Windows utility that needs a compiled executable, HTTP service, queue worker, or structured application logic. PowerShell is still useful for the Windows task itself: calling a mature module, querying local configuration, or using an administrative command that already exists as a script. The reliable boundary is a PowerShell script file with named parameters, predictable standard output, useful standard error, and an explicit exit code. Let Go launch that file as a process. Do not build one large PowerShell command string from user input and hand it to -Command; nested quoting becomes fragile and command injection becomes easy to introduce. ...

Upgrading Go in WSL or Linux is usually one archive extraction, but it is easy to hide an old compiler behind PATH or accidentally accept a dependency-file rewrite while testing it. The compiler installation and the module files are separate concerns. Treat them that way and the upgrade is straightforward to test and easy to roll back. I first select the new compiler, run an existing project’s tests and build, and inspect go.mod and go.sum before deciding whether either file should change. A compiler upgrade does not, by itself, require a new module language version or a dependency cleanup. ...

Upgrading Go on a Windows workstation should be a small change, but it can become confusing when two things change at once. The installed Go compiler changes first. Then a command such as go mod tidy may propose changes to go.mod and go.sum. Those are related, but they are not the same job. I keep the first upgrade test deliberately narrow: install or select the new compiler, run the existing project’s tests and build, and inspect the module files before accepting any change. That gives a useful answer when a project fails: is this a compiler/toolchain problem, or did the dependency graph change? ...

I received error 1618 when installing 7-Zip with winget. The package was found, the installer hash was verified, and the installation started, but Windows reported that another installation was already in progress. This error is normally related to Windows Installer, also known as MSI. Windows Installer allows only one MSI installation transaction at a time. If another operation is running, waiting for input, or stuck after an earlier failure, a second package installation returns error 1618. ...

I manage two different types of remote computers every week: Windows hosts that I access through Remote Desktop Protocol (RDP), and Linux hosts that I access through Secure Shell (SSH). Instead of putting every connection into one large application, I use two focused tools: Microsoft Sysinternals RDCMan for Windows RDP connections and Tabby for Linux SSH connections. This arrangement keeps the connection type visible. When I need a Windows desktop, I open RDCMan. When I need a Linux shell, I open Tabby. Both applications are lightweight enough to leave available during the day, and both let me organize a growing list of hosts into named groups. ...

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 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. ...