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

Sometimes Windows leaves strange folder names directly under C:\. They often look like random hexadecimal strings, for example 2b5da985a5f78e4b5d0c3b89, feba7..., or another long mix of numbers and letters. I usually see this after installing or repairing Microsoft Visual C++ Redistributable packages, .NET components, drivers, or other Windows installer packages. Most of the time these folders are temporary extraction folders. The installer should clean them up when it finishes. When an installer crashes, is interrupted, runs under a different security context, or leaves files locked until reboot, the folder can remain on the root of the system drive. ...

If a Windows event log is cleared on a server, the first question is usually simple: can I get it back? The honest answer is uncomfortable: sometimes yes, but only if the events were copied somewhere else before the clearing happened. If the only copy lived inside the local .evtx file and that log was cleared, normal administration tools will not magically rebuild the missing history. You may still find evidence in backups, forwarded events, EDR telemetry, domain controller logs, firewall logs, or application logs, but the local event log itself should be treated as damaged evidence. ...

Windows event logs are often treated like the final record of what happened on a server. That is useful, but it can also create a false sense of safety. A local administrator has a lot of power. If that account is abused, compromised, or used carelessly, the same privilege that can fix a server can also damage the evidence that explains what happened. This post is written for defensive education. It does not publish a step-by-step anti-forensic procedure. The point is simpler and more important: administrators should assume local logs can be altered or destroyed, then design audit controls that do not depend on one machine telling the whole truth. ...

Logging is one of those parts of a PowerShell script that feels optional until the first production failure happens at 2 AM. When a script is run manually, you can watch the console and fix problems as they appear. When the same script runs from Task Scheduler, a deployment tool, a service account, or a remote session, the console is gone. The log becomes the only witness. For small one-off scripts, Write-Host might be enough. For production scripts, I want a log that answers a few basic questions quickly: ...

These are Windows troubleshooting notes I keep coming back to: SMB errors that block file shares, WSL refusing to start, Windows 11 complaining about TPM in VMware, and disk space disappearing after background downloads. The common thread is simple: start with the error, isolate the layer that is failing, and fix that layer before changing everything around it. Quick answer For Windows troubleshooting, start by proving which layer is broken before changing settings. For SMB share errors, test port 445, credentials, and SMB signing. For WSL crashes, restart WSL, check the distribution state, and confirm virtualization is healthy. For VMware Windows 11 install problems, verify TPM and Secure Boot settings. For disk space issues, find the folder consuming space before deleting files. ...

Office deployment and Active Directory maintenance often land on the same admin desk. This post collects the PowerShell workflows I use for silent Office installs, Office activation firewall rules, Get-ADUser reporting, and domain rejoin cleanup when a Windows device has stale identity state. Quick answer Use PowerShell to make Office and Active Directory work repeatable: deploy Office with the Office Deployment Tool and a checked configuration.xml, open only the firewall rules needed for activation, export AD user data with Get-ADUser, and fix stale device identity by checking domain join, Azure AD join, and dsregcmd output before rejoining the computer. ...