Gino Kaleb gino kaleb SYS ADMIN
/
ES / EN

Inside IT-Support-Scripts

How I organized the toolkit: standalone scripts per task, an orchestrator with a menu, central error handling, and HTML reports anyone can read.

As a support technician, my goal is to solve problems fast and leave a record of what was done. Loose scripts fell short: I needed a system that worked as a whole. That’s how I built IT-Support-Scripts from scratch.

Two starting decisions

From the beginning I set two rules for the project’s architecture:

  1. Each script is an independent, specialized tool. A diagnostico_red.ps1 for the network, an inventario_hw_sw.ps1 for hardware. That way you run only what you need, and maintaining or extending the code stays simple.

  2. The report is the final product. Console output is for me; the HTML report is for the client (or my future self). That’s why HTMLTemplate.ps1 is the central component: it separates the diagnostic logic from the presentation and guarantees every script produces a standardized, easy-to-read output.

How it’s put together

The orchestrator: master_script.ps1

I didn’t want a simple collection of files, but an integrated system. master_script.ps1 is the entry point:

  • It offers an interactive menu that works as a “human API” for the whole toolkit: nobody has to memorize file names or parameters.
  • It handles critical configuration, like adjusting PowerShell’s execution policy (Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass), a common obstacle on client machines.
  • Before showing the menu, it checks that all required scripts exist, to avoid failures mid-run.

Error handling: ErrorHandler.ps1

A script that fails silently is useless. I centralized error handling in ErrorHandler.ps1:

  • Invoke-SafeExecution is the core: a function that wraps code blocks in a try/catch. If an operation fails (say, a WMI query), the error is captured, logged to a global log, and the main script keeps running instead of stopping.
  • Errors are classified as Info, Warning, Error, or Critical. That makes it possible to prioritize in the final report, so the technician sees the important things first.

The HTML reports

The idea is simple: the technician runs a script and gets a diagnostico_completo_2025-08-17_21-35-30.html ready to analyze or send.

  • All styling lives in the template: changing the design of every report means editing a single file.
  • The top of each report shows problem counters (goodCount, warningCount, criticalCount), filled in by a small JavaScript block injected at the end of the HTML.
  • The CSS classes .good, .warning, and .critical are applied dynamically to rows and sections, so the machine’s state can be read at a glance.

What’s next

PowerShell on Windows was the starting point, but the ROADMAP aims further: a cross-platform, portable version. The plan is to move the core logic to Node.js and WebAssembly, packaged with Electron.js, so the same toolkit can run from a USB stick on Windows, macOS, or Linux, with no dependencies and no installation.