Building an IT Toolkit

As a support technician my goal is simple: solve problems quickly, efficiently, and with documentation. Loose scripts weren’t enough. I needed a cohesive, professional system. This is the technical breakdown of how I built IT-Support-Scripts from scratch.

Core Philosophy: Modularity and Professional Reports

From the start I set two non-negotiable pillars for the project’s architecture:

1. Absolute Modularity: Each script had to be an autonomous, specialized tool. A diagnostico_red.ps1 for networking, an inventario_hw_sw.ps1 for hardware. This lets you run only what’s needed and makes maintenance and expansion easy.

2. The Report Is the Final Product: Console output is for me, but the HTML report is for the client (or my future self). That’s why HTMLTemplate.ps1 became the central component. Its role is to decouple diagnostic logic from presentation, ensuring every script produces a standardized, professional, and—above all—useful output.

Key Architecture Decisions

The Orchestrator: master_script.ps1

I didn’t want a simple collection of files; I wanted an integrated system. master_script.ps1 serves as the main orchestrator.

• Single Entry Point: It offers an interactive menu that acts like a human API for the whole toolkit. This removes the need to memorize filenames and parameters.
• Environment Management: It handles critical configuration, like adjusting PowerShell execution policy (Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass), a common obstacle in client environments.
• Dependency Checks: Before showing the menu it validates that all required scripts exist, preventing runtime failures.

Robust Error Handling: ErrorHandler.ps1

A failing script that fails silently is useless. I implemented a central error handler in ErrorHandler.ps1 to guarantee system resilience.

• Invoke-SafeExecution: This is the core of error handling. It’s a wrapper function that runs code blocks inside a try/catch. If an operation (like a WMI query) fails, the error is captured, logged to a global log, and the main script continues instead of stopping.
• Severity Classification: Errors are categorized as Info, Warning, Error, or Critical. This is crucial to prioritize issues in the final HTML report, allowing the technician to focus immediately on what’s most important.

The Final Product: Dynamic HTML Reports

The goal was simple: a technician runs a script and gets a diagnostico_completo_2025-08-17_21-35-30.html report ready to analyze or send.

• Unified CSS: All styling lives in the template. That means I can change the design of every report by editing a single file.
• Visual Summaries: The top of each report shows counters for issues (goodCount, warningCount, criticalCount). These are filled by a small JavaScript block injected at the end of the HTML, offering an immediate visual summary of the system state.
• Color-Coded Classification: CSS classes .good, .warning, and .critical are applied dynamically to rows and sections of the report, translating technical data into an intuitive visual alert system.

Future Vision: A Universal Toolkit

PowerShell on Windows was the starting point, but the goal is more ambitious. The ROADMAP.md is clear: evolve toward a truly cross-platform, portable solution.

The strategy involves moving the core logic to Node.js and WebAssembly, packaged with Electron.js. This will allow running the same toolkit from a USB on Windows, macOS, or Linux, without dependencies or installation.

This project materializes my philosophy as a technician: tools must be not only functional, but fast, reliable, and professional.