Desplegar Outsystems sobre Windows Server 2022 puede ahorrar costes de licenciamiento si se entiende cuándo se requieren las Client Access Licenses (CALs) y cuándo no. A continuación se detalla la lógica de Microsoft, los escenarios habituales y las mejores prácticas para mantener la conformidad sin pagar de más.

Contexto

Outsystems es una plataforma low‑code que se instala en Windows Server, IIS y SQL Server (local o PaaS). Una vez publicada la aplicación, los usuarios finales interactúan con la capa web —no con el sistema operativo—, lo que plantea la duda sobre la necesidad de adquirir CALs adicionales.

Fundamentos de licenciamiento en Windows Server 2022

¿Qué es una CAL?

La licencia de Windows Server cubre únicamente el derecho a instalar y ejecutar la instancia del sistema operativo en el hardware o la máquina virtual. Toda persona o dispositivo que “consuma o utilice” directamente servicios del SO necesita, además, una CAL (de usuario o de dispositivo). Esta regla se aplica tanto a empleados como a contratistas o colaboradores internos.

Tipos de CAL

• User CAL: ligada a una persona con múltiples dispositivos.
• Device CAL: ligada a un equipo compartido por varias personas.

La elección depende de la movilidad y de la cantidad de usuarios frente a dispositivos.

External Connector

Para audiencias externas masivas (clientes, partners, ciudadanos) Microsoft ofrece la licencia External Connector, que habilita accesos ilimitados desde Internet sin comprar una CAL por cada usuario externo.

Otras licencias complementarias

• RDS CALs: obligatorias si se ofrece Escritorio Remoto o RemoteApp.
• SQL CALs/Core: cubren el motor de base de datos si se instala localmente.
• SPLA: alternativa de pago por uso mensual para proveedores de servicios.

Escenarios típicos al alojar Outsystems

Escenario	¿Se requieren CALs?	Justificación
Solo Outsystems accede a Windows Server (los usuarios consumen únicamente la aplicación web y no se autentican contra el SO).	No.	Microsoft exige una CAL por cada usuario o dispositivo que utilice directa o indirectamente funcionalidades de Windows Server. Si la única “persona” que interactúa con el SO es la propia plataforma Outsystems y no se exponen servicios nativos (SMB, RDP, Windows Auth), no hay obligación de adquirir CALs.
La solución expone servicios del SO (Windows Auth, carpetas compartidas, RDP, etc.).	Sí.	Al aprovechar cualquier servicio nativo del sistema, cada usuario o dispositivo que lo utilice necesita su correspondiente CAL (User CAL o Device CAL).
Usuarios externos anónimos o clientes que se conectan vía Internet.	Sin CAL o con External Connector (según volumen).	La licencia External Connector cubre accesos ilimitados de usuarios externos sin adquirir una CAL por persona.

Análisis a fondo del escenario “solo Outsystems”

En la arquitectura recomendada, Outsystems se instala sobre IIS dentro de la máquina virtual. La autenticación de los usuarios ocurre en la capa de la aplicación (por ejemplo, autenticación propia, OAuth o Azure AD vía APIs), no en el SO. El tráfico HTTP/HTTPS llega a IIS, la plataforma genera las páginas y responde al cliente. Bajo esta circunstancia:

• No se habilita Escritorio Remoto para usuarios finales.
• No se comparte el sistema de archivos por SMB.
• No se emplea Windows Authentication en la cadena de petición.
• No hay llamadas API que requieran tokens del dominio de Windows.

Por lo tanto, aunque existan «muchos» usuarios finales, todos interactúan únicamente con el worker process de IIS que ejecuta Outsystems; técnicamente ninguno “accede” al sistema operativo según la definición de uso de Microsoft y, en consecuencia, no se precisan CALs adicionales.

Riesgos de acceso indirecto y cómo evitarlos

Aunque el diseño inicial no requiera CALs, es habitual que la solución evolucione y, sin darse cuenta, introduzca un acceso indirecto. Ejemplos:

1. Integración con carpetas de red: si el equipo de desarrollo decide exportar logs o informes CSV a una carpeta compartida vía SMB para que los analistas los descarguen, cada dispositivo que abra esa carpeta necesitará una CAL.
2. Autenticación Windows integrada: para unificar credenciales, se puede habilitar Windows Integrated Auth en IIS. En ese caso, todas las cuentas que se autentiquen contra el DC y el SO requerirán CAL.
3. Operaciones administrativas por RDP: dar acceso de solo lectura a desarrolladores para inspeccionar eventos vía Escritorio Remoto implica RDS CAL + Windows CAL para cada usuario.
4. APIs de automatización PowerShell: si un portal Outsystems invoca scripts remotos sobre WinRM usando credenciales de usuarios, estas cuentas consumen servicios del SO.

La clave es documentar y vigilar cualquier nuevo requisito funcional que toque servicios nativos de Windows.

Buenas prácticas

• Revisar los términos del canal de licenciamiento: los contratos Open Value, CSP, OEM o SPLA pueden variar en matices. Las notas técnicas de Microsoft indican que la interpretación es “por acceso a funcionalidad del SO”, pero siempre prevalece lo firmado.
• Implementar separación de preocupaciones: mantén los archivos compartidos y terminales de administración en un servidor distinto o usa servicios PaaS (Blob, S3, Azure Files) para evitar depender de SMB.
• Habilitar registros de auditoría: configura Logon/Logoff en el visor de sucesos o integra con Azure Log Analytics para demostrar quién inicia realmente sesión.
• Programar auditorías semestrales: valida que ningún cambio de código añada dependencias de Windows Auth.
• Formar al equipo de desarrollo: los programadores deben conocer las implicaciones de usar APIs como System.DirectoryServices.
• Consultar a un Partner autorizado: ante dudas, la confirmación por escrito de Microsoft o de un LSP (“Licensing Solution Partner”) mitiga riesgos frente a auditorías.

Procedimiento para documentar la conformidad

1. Diagrama de alto nivel: representa el flujo de peticiones desde el navegador hasta Outsystems.
2. Inventario de servicios activos: IIS (HTTP/HTTPS) marcado como el único puerto expuesto.
3. Declaración de autenticación: Detalla que la validación de usuario se gestiona en la base de datos de Outsystems o un IdP externo, no con Windows Auth.
4. Registro de accesos administrativos: Lista de cuentas con RDP y justificación.
5. Revisión legal: Archiva la guía “Licensing Windows Server 2022” de Microsoft con la sección sobre CALs resaltada.

Preguntas frecuentes (FAQ)

¿Necesito CALs si solo un usuario administrador entra por RDP? No para la sesión de consola incluida, pero sí si habilitas múltiples sesiones o RDS. ¿El load balancer cuenta como dispositivo que necesita CAL? No; los dispositivos de red que redirigen tráfico sin autenticarse ante el SO están exentos. ¿Outsystems Integration Studio o Service Center requieren CAL? No; son herramientas web. El ingeniero que use RDP para tareas avanzadas sí consumirá una CAL. ¿Se pueden mezclar User CAL y Device CAL? Sí, siempre que administres inventario y no excedas la cobertura. ¿Qué ocurre si migro la VM a Azure? La licencia “Azure Hybrid Benefit” cubre Windows Server, pero las CAL siguen siendo necesarias si se exponen servicios del SO. ¿SQL Server requiere CAL aparte? Solo si licencias SQL por Server + CAL; con licenciamiento por núcleo no se necesitan CAL.

Conclusión

Mientras los usuarios finales interactúen exclusivamente con la aplicación web de Outsystems sobre IIS y no con servicios nativos de Windows Server 2022, basta con la licencia del sistema operativo para la máquina virtual. Solo incorpora CALs —o la licencia External Connector— si algún cambio funcional introduce accesos directos o indirectos al SO. Documentar la arquitectura, revisar los términos de licenciamiento y auditar periódicamente el uso real son las mejores defensas contra costes inesperados y sanciones en auditorías.