IT-Support-Scripts por dentro

Como técnico de soporte, mi meta es resolver problemas rápido y dejar constancia de qué se hizo. Los scripts sueltos se me quedaron cortos: necesitaba un sistema que funcionara como un todo. Así construí IT-Support-Scripts desde cero.

Dos decisiones de partida

Desde el inicio fijé dos reglas para la arquitectura del proyecto:

1. Cada script es una herramienta independiente y especializada. Un diagnostico_red.ps1 para la red, un inventario_hw_sw.ps1 para el hardware. Así se ejecuta solo lo necesario, y mantener o ampliar el código es sencillo.

2. El reporte es el producto final. La salida en consola es para mí; el reporte HTML es para el cliente (o para mi yo del futuro). Por eso HTMLTemplate.ps1 es el componente central: separa la lógica de diagnóstico de la presentación y garantiza que todos los scripts generen una salida estandarizada y fácil de leer.

Cómo está armado

El orquestador: master_script.ps1

No quería una simple colección de archivos, sino un sistema integrado. master_script.ps1 es el punto de entrada:

• Ofrece un menú interactivo que funciona como una “API humana” para todo el toolkit: nadie tiene que memorizar nombres de archivos ni parámetros.
• Se encarga de la configuración crítica, como ajustar la política de ejecución de PowerShell (Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass), un obstáculo común en equipos de clientes.
• Antes de mostrar el menú, valida que todos los scripts necesarios existan, para evitar fallos a media ejecución.

Manejo de errores: ErrorHandler.ps1

Un script que falla en silencio no sirve. Centralicé el manejo de errores en ErrorHandler.ps1:

• Invoke-SafeExecution es el núcleo: una función que envuelve bloques de código en un try/catch. Si una operación falla (por ejemplo, una consulta WMI), el error se captura, se registra en un log global y el script principal sigue corriendo en lugar de detenerse.
• Los errores se clasifican como Info, Warning, Error o Critical. Eso permite priorizar en el reporte final, para que el técnico vea primero lo importante.

Los reportes HTML

La idea es simple: el técnico ejecuta un script y obtiene un diagnostico_completo_2025-08-17_21-35-30.html listo para analizar o enviar.

• Todo el estilo vive en la plantilla: cambiar el diseño de todos los reportes es editar un solo archivo.
• La parte superior muestra contadores de problemas (goodCount, warningCount, criticalCount), rellenados por un pequeño bloque de JavaScript que se inyecta al final del HTML.
• Las clases CSS .good, .warning y .critical se aplican dinámicamente a filas y secciones, para que el estado del equipo se entienda de un vistazo.

Lo que sigue

PowerShell en Windows fue el punto de partida, pero el ROADMAP apunta más lejos: una versión multiplataforma y portable. El plan es migrar la lógica a un core en Node.js y WebAssembly, empaquetado con Electron.js, para poder ejecutar el mismo toolkit desde una USB en Windows, macOS o Linux, sin dependencias ni instalación.