La retirada gradual de VBScript marca un antes y un después en la administración de Windows Server. Con una hoja de ruta oficial ya publicada, los responsables de TI necesitan dimensionar el riesgo, anticipar las fases y diseñar una estrategia de migración que evite paradas operativas y mantenga la seguridad aplicativa.

¿Qué es VBScript y por qué se retira?

VBScript (Visual Basic Scripting Edition) nació a mediados de los años 90 como un subconjunto de Visual Basic 6.0 pensado para la administración de equipos Windows, la creación de scripts de inicio de sesión, la automatización de instalaciones y el motor de scripting de Classic ASP. Con la aparición de tecnologías más potentes —PowerShell para operaciones, .NET para desarrollo y JavaScript/TypeScript para la web— su uso se ha reducido, pero no ha desaparecido por completo. Microsoft ha decidido retirarlo por tres razones principales:

• Seguridad: VBScript carece de los mecanismos de endurecimiento (hardening) que sí existen en PowerShell o .NET, lo que lo convierte en objetivo habitual de malware.
• Mantenibilidad: cada biblioteca legada consume recursos de ingeniería y pruebas internas que podrían dirigirse a funcionalidades modernas.
• Coherencia de plataforma: eliminar duplicidades simplifica la pila tecnológica y anima a los usuarios a adoptar estándares actuales.

Estrategia oficial de Microsoft

Microsoft ha comunicado un plan de tres fases que afecta tanto a Windows 11 Client como a Windows Server:

1. Fase 1 (vigente desde Windows 11 24H2 y Windows Server 2025) – VBScript pasa a ser una Feature on Demand (FOD) que viene habilitada por defecto. Los administradores disponen de toda la funcionalidad tradicional mientras inventarían y migran sus scripts.
2. Fase 2 (aprox. 2027) – La FOD permanecerá en el sistema, pero aparecerá deshabilitada por defecto tras la instalación o actualización. Habrá que activarla manualmente mediante DISM, PowerShell o la GUI de “Características opcionales”.
3. Fase 3 (fecha exacta pendiente, posterior a 2027) – VBScript se eliminará definitivamente; los binarios vbscript.dll dejarán de distribuirse y cualquier proceso que intente cargarlos fallará con error.

Versiones de Windows Server afectadas

La repercusión varía según la versión:

• Legado (2008, 2008 R2, 2012, 2012 R2): solo reciben parches críticos; VBScript ya no evoluciona y seguirá presente hasta fin de soporte ampliado, aunque sin mejoras ni mitigaciones futuras.
• Soporte actual (2016, 2019, 2022): mantendrán VBScript integrado hasta llegar al ciclo FOD. El momento exacto dependerá de la rama de mantenimiento (LTSC, SAC) y de cuándo migre cada organización a Windows Server 2025 o posterior.
• Próxima generación (Server 2025): se estrena directamente en Fase 1 con VBScript empaquetado como FOD activada.

Resumen práctico

Tema	Detalles prácticos
Estrategia oficial de Microsoft	Fase 1 – VBScript como FOD habilitada (Windows 11 24H2, Server 2025). Fase 2 – FOD deshabilitada por defecto (~2027). Fase 3 – Eliminación total en versiones posteriores.
Versiones de Windows Server afectadas	2008/2008 R2/2012/2012 R2: sin nuevas funciones. 2016/2019/2022: VBScript integrado hasta migrar a modelo FOD. 2025: Fase 1 ya aplicada.
Impacto técnico inmediato	Los .vbs y Classic ASP seguirán funcionando en Fase 1. En Fase 2 fallarán salvo reinstalar la FOD. En Fase 3 no habrá binarios ni retrocompatibilidad.
Alternativas recomendadas	PowerShell, PowerShell DSC, .NET 6/8, JavaScript/TypeScript en Classic ASP, Web API o Blazor para modernización.
Pasos de mitigación	Inventariar, probar sin VBScript, reescribir código, documentar reversión mientras exista la FOD.

Profundizando en el impacto técnico

Aunque la mayoría de las cargas de trabajo corporativas ya han migrado a PowerShell, todavía perviven numerosos scripts de arranque (.vbs) y portales internos en Classic ASP.

Scripts de inicio de sesión y tareas programadas

Muchos dominios Active Directory siguen usando GPO con cscript.exe <script.vbs> para mapear unidades, aplicar claves de registro o recopilar inventario. Tras la Fase 2, el mecanismo seguirá existiendo, pero cscript.exe devolverá un error si la FOD no está habilitada.

Classic ASP

El motor asp.dll admite VBScript y JScript. Al desaparecer VBScript, las páginas <% Option Explicit %> que invoquen Response.Write en VBScript quebrarán. Migrar a JScript, TypeScript (transpilado) o a .NET Core (Minimal APIs, Razor Pages) es la vía aconsejada.

Herramientas de terceros

Instaladores, consolas de Backup y aplicaciones legacy pueden llevar sus propios .vbs como “pegamento” de automatización. Iniciar un inventario exhaustivo evita sorpresas en la Fase 2.

Alternativas recomendadas y estrategia de reemplazo

• PowerShell 7.x: dispone de un motor multiplataforma, módulos para todas las áreas de Windows Server y un ecosistema de seguridad (Just Enough Administration, políticas de ejecución, transcripción de comandos).
• .NET 6/8 (LTS): perfecto para scripts compilados o utilidades de línea de comandos de alto rendimiento.
• PowerShell DSC y Azure Automation: permiten definir estados deseados y aplicar configuración de forma declarativa.
• JavaScript/TypeScript: compatibles con Classic ASP (JScript) o, de manera más robusta, con Node.js, Deno o servicios web modernos.
• Herramientas low‑code/Power Automate: para procesos simples de orquestación.

Plan de migración paso a paso

1. Inventariar dependencias
   • Ejecuta un script crawler que busque extensiones .vbs, referencias a vbscript.dll y cadenas “VBScript” en carpetas de servidores, GPO y repositorios de código.
   • Clasifica cada hallazgo según criticidad (inicio de sesión, backup, monitorización, etc.).
2. Establecer laboratorios de prueba
   • En Windows Server 2025 Preview deshabilita la FOD con Disable-WindowsOptionalFeature -Online -FeatureName VBScript.
   • Anota qué funciones dejan de operar y documenta flujos rotos.
3. Portar o reescribir scripts prioritarios
   • Para GPO, migra a PowerShell Logon/Logoff Scripts.
   • Convierte Classic ASP a .NET Razor Pages o Minimal API; para transiciones rápidas, transpila VBScript a JavaScript mediante herramientas como vb2js.
4. Validar funcionalidad y rendimiento
   • Compara tiempos de ejecución de los nuevos scripts frente a VBScript.
   • Ejecuta pruebas de estrés si hay reemplazos en flujo crítico (facturación, ERP).
5. Desplegar en producción con reversión controlada
   • Mantén la FOD instalada pero deshabilitada mediante política, lista para reactivarse en caso de incidente.
   • Actualiza runbooks de operación para reflejar el cambio.

Buenas prácticas para la transición

• Documentación viva: integra la guía de migración en tu wiki interna; indica quién mantendrá cada script convertido.
• Automatiza las pruebas: usa pipelines CI/CD que ejecuten linting y unit tests en PowerShell y en los módulos .NET resultantes.
• Doble auditoría: revisa que nadie suba nuevos .vbs al control de versiones ni a servidores compartidos.
• Sensibiliza al equipo: organiza talleres de PowerShell avanzado; la curva de aprendizaje se reduce con buenas prácticas y módulos ideados para administradores.
• Plan de hardening: aprovecha la ocasión para firmar scripts y aplicar AppLocker/Windows Defender Application Control.

Preguntas frecuentes (FAQ)

¿Desaparece también cscript.exe? – No. cscript.exe y wscript.exe seguirán presentes para JScript/WSH, pero arrojarán error si invocan VBScript en Fase 3.

¿Las aplicaciones compiladas en Visual Basic 6.0 dejarán de funcionar? – No. La retirada afecta solo al motor de scripting; los binarios VB6 compilados se ejecutan con msvbvm60.dll, no con vbscript.dll.

¿Puedo mantener VBScript en Server 2022 indefinidamente? – Solo mientras esa versión esté en soporte. Tras la fecha de fin de ciclo (por ejemplo, octubre 2031 para LTSC 2022) ya no recibirá parches de seguridad.

¿Será opcional reinstalar la FOD en Fase 3? – No. Microsoft ha confirmado que la FOD desaparecerá; no habrá método oficial para restaurar VBScript.

¿Necesito reescribir Classic ASP a .NET inmediatamente? – Depende de tu ventana de mantenimiento. Si cuentas con modernización planificada antes de 2027, puedes convivir con la FOD. Aun así, cuanto antes reduzcas la superficie legada, menos trabajo acumulado tendrás en la Fase 2.

Conclusión

La obsolescencia de VBScript es inminente, gradual y, finalmente, irreversible. La buena noticia es que Microsoft ofrece un periodo de gracia generoso en Fase 1 y Fase 2. Quienes inicien hoy mismo la detección y migración podrán completar la transición mucho antes de que la FOD se deshabilite por defecto. Las organizaciones que ya usan PowerShell, .NET y JavaScript tienen una base sólida: basta con consolidar procesos y validar compatibilidades. Para las que aún dependen de VBScript, el momento de actuar es ahora. Detecta, prioriza, migra y valida. La recompensa será un entorno Windows Server más seguro, mantenible y alineado con las tecnologías que dominarán la próxima década.