SUP-01 — Automating Windows support and diagnostics with PowerShell

Summary

SUP-01 turns Windows support and administration activities I carried out at the Québec Ministry of Cybersecurity and Digital Technology and La Poste du Burkina Faso into a PowerShell demonstration toolkit: silent application installs, application version checks, software inventory, patch application and remediation scripting. The toolkit automates N2/N3 first-line checks — connectivity, services, logs, SCCM/MECM and Windows Update — and returns structured results in an HTML report. It is deliberately read-only: it diagnoses and recommends, but never applies a correction without human validation.

Business and technical context

In a Windows estate managed through Active Directory and SCCM/MECM, an endpoint incident is rarely one question. An application may not deploy because the endpoint is unreachable, WinRM is closed, a service has stopped, the SCCM client has no management point, the update source cannot be reached, or the application version is non-compliant.

The N2/N3 support problem is therefore not a lack of commands: it is their fragmentation and the lack of a consistent record. SUP-01 runs checks in diagnostic order, returns one result format for every check and produces a report that can be attached to an incident.

Automation objectives

• Turn repeated manual checks into a readable, repeatable sequence.
• Distinguish an unreachable endpoint from a check that genuinely failed, using Ignore.
• Verify access prerequisites before querying a remote endpoint.
• Inventory software and compare versions against a required minimum.
• Diagnose conditions preventing an SCCM/MECM client from receiving policy or deployments.
• Produce useful support output without disclosing passwords or running destructive remediation.

Documented responsibilities

• Silent application installation.
• Application version checks.
• Software inventory.
• Patch application.
• Development of remediation scripts.

These activities are the professional foundation of SUP-01. The toolkit does not claim to be a production script used by either organization; it makes the method visible: prerequisites, controlled collection, readable results, recommendations and traceability.

Logical architecture

Access conditions and security

1. The operator opens an elevated PowerShell session with an authorized account.
2. Active Directory authenticates that account; no password is written into code or logs.
3. The account must be a local administrator on the target endpoint, preferably through a dedicated AD group.
4. WinRM / PowerShell Remoting must be enabled and permitted by firewall. Port 5985 is typical inside a trusted network; port 5986 is preferred where HTTPS is required.
5. The toolkit reads information only; it changes no service, policy or firewall rule.

Diagnostic process

Technical demonstration: Windows-Support-Toolkit

The local repository is ready for publication: C:\Users\Utilisateur\Documents\Windows-Support-Toolkit.

GitHub link to complete after publication: Windows-Support-Toolkit

# Interactive menu, local computer
.\Invoke-SupportToolkit.ps1

# Targeted diagnostic linked to an incident
.\Invoke-SupportToolkit.ps1 -ComputerName PC-0042 `
  -Check Connectivite,Services,SCCM `
  -Context 'INC0012345'

Example report

The report is generated from fictional laboratory data only: PC-0042, PC-0043, LABO domain and 192.0.2.0/24, a documentation-only address range. No real endpoint, account or address is published.

Technical accomplishments in the demonstration

• PowerShell 5.1 and 7 compatible module, without external dependency.
• Ten documented functions, one per file.
• Prerequisite verification; an inaccessible endpoint returns an actionable state rather than a raw exception.
• Common Wst.Resultat object: endpoint, check, status, summary, details, recommendations and timestamp.
• Registry-based software inventory — never Win32_Product, which can trigger MSI reconfiguration.
• Self-contained HTML report with encoded content.
• Operation logging with no password or real demonstration data in the repository.
• Real local validation: module import, all ten functions, fictional report generation and reproducibility check.

Demonstrated skills

Verifiable results

• Independent local Git repository created: Windows-Support-Toolkit.
• 10 PowerShell functions exported; every script parsed successfully by the PowerShell parser.
• Read-only controls executed locally in a lab: connectivity, services, logs, inventory, SCCM client, SCCM logs, Windows Update and version comparison.
• Fictional HTML report generated twice with identical SHA-256 hash: reproducible result.
• No quantified productivity claim: it would depend on estate size, permissions, SCCM maturity and support process.

Documentation and publication

Diagrams, README and the example HTML report are the demonstration documentation. Before GitHub publication, replace [TO-COMPLETE] with your GitHub identifier; never add organization data to the repository.