Windows Admin Scripting Little Black

Dealing with routine Windows admin tasks via script is a lot less painful than people make it sound, provided you know where the actual failure points live

Most administrators who jump into automated Windows management end up writing one-liners that work on their machine and then break somewhere between testing and production. The real issue isn't the syntax. It is environment state. Every server you touch has different patch levels, different group policy configurations, and different amounts of accumulated registry junk. A script that runs clean on a fresh domain-joined workstation will fail immediately on a server that has been around for three years and has gone through two IT teams. I built a collection of practical scripts for day-to-day Windows administration over the past several years. I call it Windows Admin Scripting Little Black because it is small, unglamorous, and does exactly what it needs to do without any presentation layer. There are no fancy menus or color-coded output. You run it, it tells you what happened, and you move on.

Windows Admin Scripting Little Black

At its core, the tool set is a set of PowerShell and batch-based utilities for common administrative tasks: service state checks, registry audits, scheduled job listing, event log filtering by severity, and basic user permission verification. Nothing revolutionary. What makes it useful is consistency across your environment and the fact that it accounts for the edge cases that trip people up. I wrote a script to pull disabled services across a fleet of Windows Server 2016 and 2019 machines. Standard approach uses Get-Service filtered to Status Disabled. That works fine until you hit machines where the Windows Management Instrumentation service is partially degraded. The query hangs. Your whole batch process stalls for twenty minutes or more waiting on a timeout that never comes. The fix is wrapping each service query in a Start-Process call with a timeout and a catch block that marks that machine as partially reachable and moves forward. It costs about thirty seconds per stalled machine instead of the default behavior of hanging your entire job queue. The download link is straightforward. You get a zip file containing the scripts organized by function. Run the README first. It explains how to set the execution policy locally for your own user context, which is enough if you are doing this on your own admin workstation. You do not need to change the global machine policy. Changing that creates more problems than it solves.

Here is a practical example of how to use it for a common task: auditing local administrator membership across multiple machines. I have a plain text file called targets.txt with one hostname per line. You point the script at that file and it outputs a CSV with MachineName, Username, MemberOf fields. The output is boring. That is the point. Boring output means you can pipe it into Excel or another audit tool without cleaning it up first. The important detail that beginners miss is that the script queries Win32_GroupUser, not just the built-in Administrators group SID. This matters when environments have renamed local groups or added custom groups with administrator privileges. If you only check the SID-based group, you will miss accounts that were added to a renamed variant. I learned this after an audit showed zero discrepancies and a follow-up security review found three unauthorized local admin accounts on machines where someone had renamed the group to something non-standard during a previous compliance project. The rename was documented but the tooling was not updated. My script catches both. Another thing nobody talks about is event log access. You can query the Security event log on remote machines without issue until the account you are using does not have SeSecurityPrivilege. That privilege is not granted to regular domain admins by default on newer builds unless explicitly configured. I ran into this when trying to pull failed login events from a batch of Windows Server 2022 machines. The script returned empty results every time. Switching to a query against System log for the same timeframe revealed nothing unusual. The logs existed. The account simply had no read access to Security log on those specific boxes. The workaround was configuring a Group Policy preference that granted the read permission to the service account used by the script, then allowing two hours for policy propagation before re-running the query.

There are limitations worth stating upfront. This tool set is not designed for hybrid cloud management. If your environment uses Azure AD joined devices or Intune policies controlling device state, these scripts will not give you a complete picture. They only cover on-premises Windows machines that are reachable via network and accessible through standard WMI or PowerShell remoting. You will also find that scripts relying on WMI perform slowly on heavily loaded servers. A single Win32_Process query on a machine under high CPU load can take several seconds longer than expected. The overhead accumulates quickly across hundreds of machines. For environments that need cloud visibility alongside on-prem tools, pairing this with a Microsoft Graph API script or a dedicated Intune reporting solution is the better path. Using both together gives you coverage without false confidence from either tool alone. The scripts are written to run under PowerShell 5.1 and later. If you are on PowerShell 7, some of the WMI-based commands will still work but you should migrate them to Get-CimInstance for better reliability. The migration is mechanical and takes about ten minutes per script. I did it on my current version and the output format changed slightly. The CSV columns remained the same so downstream tools did not need adjustment.

A final note on deployment. Do not put these scripts in a shared network folder and expect them to stay current. I watched a team maintain a shared copy for six months and then discover that ten machines were being managed with a version that had a broken event log filter. The fix was moved to individual admin workstations with a simple version check at the top of each script that alerts you if the local copy is older than thirty days. It is an annoying step to add but it prevents exactly that kind of situation.