Automation Archives - InfoTech Ninja

PowerShell 7: 10 Scripts Every SysAdmin Should Have in Their Toolkit

Morris James — Tue, 07 Apr 2026 00:00:00 +0000

PowerShell 7 (built on .NET 6+) is a genuine upgrade from Windows PowerShell 5.1. It’s cross-platform, significantly faster for parallel workloads, and brings modern language features that make complex automation dramatically cleaner. If you’re still defaulting to PS 5.1 out of habit, this article will convince you to make the switch and give you scripts worth keeping.

Why PS7 Changes Everything for SysAdmins

The headline feature for infrastructure work is ForEach-Object -Parallel. In PowerShell 5.1, looping over hundreds of servers to run a command was sequential — painfully slow when each operation involves a network call. In PS7, adding -Parallel to your ForEach-Object pipeline runs iterations concurrently (up to a configurable throttle limit), collapsing a 10-minute sequential run to under a minute. Combined with the -ThrottleLimit parameter, you get controlled parallelism without overwhelming your network or target systems.

PowerShell 7 also ships with null-coalescing operators (?? and ??=), pipeline chain operators (&& and ||), ternary expressions, and significantly improved error handling. The Get-Error cmdlet provides structured, detailed error information that makes debugging complex scripts far easier. Module compatibility has improved too — most PS 5.1 modules work in PS7 via a compatibility shim, though a handful of modules that rely on Windows-only COM components remain PS5.1-only.

Bulk AD User Management

Managing Active Directory users at scale through the GUI is tedious and error-prone. PowerShell with the ActiveDirectory module makes bulk operations straightforward and auditable. Common tasks like disabling accounts for departed employees, resetting passwords, updating department attributes for an org restructure, or moving users between OUs all lend themselves to one-liners or short scripts that you can test in a non-production OU first.

The script below processes a CSV file of user updates — useful when HR sends over a spreadsheet of 200 employees who need their department and manager attributes updated after a reorg. Run it with -WhatIf first to preview changes without applying them, then remove the switch for the actual run.

# BulkUpdateADUsers.ps1 — Update AD attributes from CSV
# CSV columns: SamAccountName, Department, Manager, Title
#Requires -Modules ActiveDirectory

param(
    [Parameter(Mandatory)][string]$CsvPath,
    [switch]$WhatIf
)

$users = Import-Csv -Path $CsvPath
$results = [System.Collections.Concurrent.ConcurrentBag[object]]::new()

$users | ForEach-Object -Parallel {
    $bag = $using:results
    $whatIf = $using:WhatIf
    try {
        $params = @{
            Identity   = $_.SamAccountName
            Department = $_.Department
            Title      = $_.Title
            Manager    = (Get-ADUser $_.Manager).DistinguishedName
            WhatIf     = $whatIf.IsPresent
        }
        Set-ADUser @params
        $bag.Add([pscustomobject]@{ User=$_.SamAccountName; Status="OK" })
    } catch {
        $bag.Add([pscustomobject]@{ User=$_.SamAccountName; Status="FAIL: $_" })
    }
} -ThrottleLimit 20

$results | Export-Csv -Path ".\update-results.csv" -NoTypeInformation
Write-Host "Done. Results at .\update-results.csv"

Automated Patch Reporting

Keeping track of patch status across a fleet of Windows servers is a common pain point. WSUS gives you a dashboard, but exporting useful reports for management or auditors is clunky. A PowerShell script that queries hotfix history across multiple servers and generates a clean report is something every Windows admin should have. The script below uses PS7’s parallel foreach to query multiple servers simultaneously, dramatically reducing the time it takes to gather data.

Combine this with a scheduled task or Azure Automation runbook to generate weekly patch compliance reports automatically. Export to CSV for easy import into Excel or your ITSM tool, or format as HTML for email distribution. Adding logic to flag servers that haven’t received updates in more than 30 days gives you an actionable compliance metric for your next audit.

# Get-PatchReport.ps1 — Query hotfix status across multiple servers
param([string[]]$Servers = @("SRV01","SRV02","SRV03"))

$report = $Servers | ForEach-Object -Parallel {
    $server = $_
    try {
        $hotfixes = Get-HotFix -ComputerName $server -ErrorAction Stop |
            Sort-Object InstalledOn -Descending |
            Select-Object -First 1
        [pscustomobject]@{
            Server       = $server
            LastPatch    = $hotfixes.HotFixID
            InstalledOn  = $hotfixes.InstalledOn
            DaysSince    = (New-TimeSpan -Start $hotfixes.InstalledOn -End (Get-Date)).Days
            Status       = "Online"
        }
    } catch {
        [pscustomobject]@{ Server=$server; LastPatch="N/A"; InstalledOn="N/A"; DaysSince=999; Status="Error: $_" }
    }
} -ThrottleLimit 10

$report | Sort-Object DaysSince -Descending | Format-Table -AutoSize
$report | Export-Csv ".\patch-report-$(Get-Date -f yyyyMMdd).csv" -NoTypeInformation

Calling REST APIs from PowerShell

Invoke-RestMethod is PowerShell’s built-in REST client, and it’s surprisingly capable. It automatically deserializes JSON responses into PowerShell objects, handles common authentication schemes, and supports all HTTP methods. Combined with PS7’s improved performance and parallelism, you can build lightweight integration scripts between your on-prem tooling and cloud APIs without pulling in external dependencies or standing up middleware.

A common use case: querying your monitoring tool’s API to get a list of alerts, then correlating them with your CMDB API to enrich the data before posting to a Teams channel via the incoming webhook API. Three API calls, all handled with Invoke-RestMethod, tied together in a script that runs every 15 minutes as a scheduled task. It’s not glamorous, but it’s the kind of practical automation that saves your team hours every week.

The post PowerShell 7: 10 Scripts Every SysAdmin Should Have in Their Toolkit appeared first on InfoTech Ninja.

Getting Started with Ansible: Write Your First Playbook in 30 Minutes

Morris James — Tue, 24 Feb 2026 00:00:00 +0000

Ansible is the Swiss Army knife of infrastructure automation. No agents to install, no complex master-client architecture to manage, no proprietary DSL to learn. Just Python, SSH, and YAML. If you can write a shell script and you know your way around Linux, you can write a useful Ansible playbook today.

No Agents, No Drama: The Ansible Model

Ansible’s architecture is deliberately simple. The control node (your workstation, a bastion host, or a CI/CD runner) connects to managed nodes over SSH (or WinRM for Windows), executes tasks, and disconnects. There’s no agent process running on managed nodes consuming resources or requiring updates. The only requirement on managed nodes is Python (which is present on virtually every Linux system) and a user account with appropriate sudo privileges.

Idempotency is Ansible’s most important design principle. Every built-in module is designed so that running a task multiple times produces the same result as running it once. If nginx is already installed and running, the package and service modules report “OK” rather than reinstalling or restarting. This means you can run your playbooks safely at any time — to enforce desired state, to verify compliance, or to bring a drifted system back in line — without worrying about destructive side effects.

Your Inventory File

Ansible’s inventory defines the hosts and groups your playbooks target. The simplest format is an INI-style text file. You can also use YAML format or dynamic inventory plugins that query cloud provider APIs (AWS EC2, Azure VMs, GCP instances) to build the inventory automatically from your actual running infrastructure — no manual list maintenance required.

Groups make targeting flexible. You might have a [webservers] group, a [dbservers] group, and a [production] group containing hosts from both. Group variables (stored in group_vars/ directories) let you define different settings per group — staging might use a self-signed certificate while production uses a real one, but the same playbook handles both.

# inventory/hosts.ini — Sample inventory file
[webservers]
web01.example.com ansible_user=ubuntu
web02.example.com ansible_user=ubuntu

[dbservers]
db01.example.com ansible_user=ubuntu ansible_port=2222

[production:children]
webservers
dbservers

[production:vars]
env=production
nginx_worker_processes=4

# Test connectivity to all hosts:
# ansible all -i inventory/hosts.ini -m ping

Writing Your First Playbook

A playbook is a YAML file containing one or more plays. Each play targets a group of hosts and defines a list of tasks to execute in order. Tasks use modules — the unit of work in Ansible. There are thousands of built-in modules covering package management, file operations, service management, cloud resources, network devices, and more. The module name is self-documenting: ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd.

The playbook below installs nginx, deploys a custom configuration, and ensures the service is running and enabled. Run it with ansible-playbook -i inventory/hosts.ini playbooks/nginx.yml. Add --check for a dry run that shows what would change without making any changes.

# playbooks/nginx.yml — Install and configure nginx
---
- name: Configure web servers
  hosts: webservers
  become: true

  vars:
    nginx_port: 80
    server_name: "{{ inventory_hostname }}"

  tasks:
    - name: Ensure nginx is installed
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Deploy nginx configuration
      ansible.builtin.template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/sites-available/default
        owner: root
        group: root
        mode: "0644"
      notify: Reload nginx

    - name: Ensure nginx is started and enabled
      ansible.builtin.systemd:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Reload nginx
      ansible.builtin.systemd:
        name: nginx
        state: reloaded

Variables, Templates, and Handlers

Variables in Ansible can be defined at multiple levels — in the playbook itself, in separate variable files, in the inventory, or passed on the command line with -e. Jinja2 templates (files ending in .j2) use double-brace syntax ({{ variable_name }}) to interpolate variables into configuration files. This is how one nginx template can produce correctly configured files for dozens of different servers, each with the right hostname, port, and SSL certificate path.

Handlers are tasks that only run when notified by another task. The classic use case: a task that updates a configuration file notifies the “Reload nginx” handler. If the configuration file didn’t change (because it was already correct), the handler never fires and nginx isn’t unnecessarily reloaded. If multiple tasks in a play all notify the same handler, the handler runs only once at the end of the play. This prevents redundant service restarts and makes your playbooks more efficient.

The post Getting Started with Ansible: Write Your First Playbook in 30 Minutes appeared first on InfoTech Ninja.