MENU
  1. Inicio
  2. Windows
  3. Windows Server
  4. Windows Server 2019 Essentials: cómo corregir el apagado semanal por SILSVC (Event 1074)

Windows Server 2019 Essentials: cómo corregir el apagado semanal por SILSVC (Event 1074)

Windows Server

Si tu Windows Server 2019 Essentials se apaga cada lunes entre 8:30 y 10:30 (PST) y ves un evento 1074 con silsvc.exe como iniciador, estás ante un corte forzado por licencias. En esta guía aprenderás a diagnosticar el incumplimiento, corregir la configuración y evitar nuevas interrupciones.

Índice

Contexto y síntomas

Escenario típico: servidor HP con Windows Server 2019 Essentials que actúa como Controlador de Dominio (DC) y servidor de archivos. No aparecen errores en el registro System antes del apagado. Al reiniciar, el Visor de eventos muestra:

  • Event ID 1074 (User32): el proceso silsvc.exe inicia el apagado.
  • Mensaje: “Licensing Compliance Service caused a shutdown. Revise Microsoft > Windows > Server Infrastructure Licensing > Operational.”
IndicadorQué significaDónde verlo
Apagado semanal en la misma franjaAcción programada por el servicio de licencias al detectar incumplimientoRegistro de eventos posterior al reinicio
Evento 1074 con silsvc.exeEl servicio de licenciamiento originó el apagadoWindows Logs > System
Mensajes de “countdown” o “out of compliance”Cuenta atrás y motivo exacto del no cumplimientoApplications and Services Logs > Microsoft > Windows > Server Infrastructure Licensing > Operational

Por qué ocurre el apagado

Windows Server 2019 Essentials incluye restricciones de topología y uso que se supervisan mediante el Server Infrastructure Licensing Service (SILSVC). Cuando detecta que la instalación está fuera de cumplimiento, inicia un apagado periódico (típicamente semanal) hasta que la configuración vuelva a estar alineada con las reglas de Essentials.

En entornos donde el servidor es DC, los detonantes más comunes son:

  • Existe más de un controlador de dominio en el bosque o dominio.
  • El DC Essentials no posee los cinco roles FSMO.
  • Hay relaciones de confianza configuradas con otros dominios.
  • Uso de virtualización que excede lo permitido por la licencia Essentials (p. ej., varias instancias activas con la misma clave).

Ruta de diagnóstico paso a paso

Empieza por el canal de licenciamiento y después valida la topología de Active Directory.

Revisar el canal de licenciamiento

# Ver los últimos eventos del canal de licencias (incluye motivos y cuenta atrás)
Get-WinEvent -LogName 'Microsoft-Windows-ServerInfrastructureLicensing/Operational' -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

Busca mensajes que indiquen el motivo: presencia de otros DCs, FSMO en otro servidor, trusts, límites de instancia, etc. Si no ves nada, reinicia solo el servicio y vuelve a comprobar:

Get-Service -Name SILSVC
Restart-Service -Name SILSVC -Force

Comprobar cuántos DCs existen

# Requiere RSAT-AD (en un DC ya está)
Get-ADDomainController -Filter * | Select-Object HostName,Site,IsReadOnly,IsGlobalCatalog,IPv4Address

Debe aparecer un único DC. Si ves más (incluso uno “fantasma” que ya no existe), hay incumplimiento.

Verificar los roles FSMO

# Alternativa clásica
netdom query fsmo

Los cinco roles (Schema Master, Domain Naming Master, PDC Emulator, RID Master, Infrastructure Master) deben estar en el servidor Essentials.

Detectar relaciones de confianza

Get-ADTrust -Filter * | Format-Table Name,Direction,TrustType,TrustAttributes

Essentials no permite trusts. Si aparece alguna confianza, elimínala.

Validar uso en virtualización

  • Comprueba si estás ejecutando más de una instancia activa de Windows Server 2019 Essentials con la misma licencia (p. ej., host físico y VM) o clones/snapshots ejecutados simultáneamente.
  • Evita usar la misma clave en host y VM a la vez si no tienes derechos para múltiples instancias.

Reglas de cumplimiento que más fallan

ReglaDescripciónCómo comprobarla
Único DCEssentials como único controlador de dominio del bosque/dominioGet-ADDomainController -Filter * debe devolver 1
Todos los FSMOEl DC Essentials debe poseer los 5 roles FSMOnetdom query fsmo apunta siempre al equipo Essentials
Sin trustsNo deben existir relaciones de confianza con otros dominiosGet-ADTrust -Filter * no devuelve resultados
Instancia únicaSolo una instancia activa por licencia (física o virtual)Inventario de host/hipervisor y claves; nada duplicado en paralelo

Corrección recomendada

Aplica los pasos que correspondan a tu caso. Haz copia de seguridad del estado del sistema y valida replicación antes de tocar AD.

Eliminar DCs “fantasma” y quedarse con uno

  1. Identifica DCs no válidos con Get-ADDomainController -Filter * y “Sitios y Servicios de AD” (dssite.msc).
  2. Retira correctamente los DCs adicionales si están vivos (despromoción con dcpromo o el asistente de Servicios de AD).
  3. Haz metadata cleanup si el DC ya no existe: ntdsutil metadata cleanup connections connect to server <DC-Essentials> quit select operation target list domains select domain <número> list sites select site <número> list servers in site select server <número del DC huérfano> quit remove selected server quit quit
  4. Elimina restos en DNS (registros A/SRV) y en “Sitios y Servicios” si quedaron objetos.

Transferir o tomar control de roles FSMO

Si algún FSMO apunta a otro servidor (o a uno desaparecido), muévelos al Essentials:

# Transferencia ordenada (preferible)
Move-ADDirectoryServerOperationMasterRole -Identity $env:COMPUTERNAME `
  -OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster

Si el propietario original ya no existe, realiza un seize con ntdsutil y después limpia metadatos del DC anterior.

Quitar relaciones de confianza

# Revisar y eliminar trusts
Get-ADTrust -Filter * | ForEach-Object {
  Write-Host "Eliminando confianza $($_.Name)"
  Remove-ADTrust -Identity $_.Name -Confirm:$false
}

Verifica de nuevo que no queda ninguna confianza y que el canal de licencias deja de registrar la cuenta atrás.

Ajustar el escenario de virtualización

  • Evita instancias paralelas activas con la misma licencia.
  • Si necesitas más VMs o más DCs, migra a Windows Server Standard o Datacenter antes de ampliar la topología.
  • Si el Essentials está como VM y el host usa la misma clave, regulariza licencias para que solo haya una instancia activa por clave.

Validación posterior

Cuando acomodes la topología, valida que el servicio de licencias ya no programe apagados.

  1. Reinicia el servicio o el servidor y revisa el canal de licencias: Restart-Service -Name SILSVC -Force Get-WinEvent -LogName 'Microsoft-Windows-ServerInfrastructureLicensing/Operational' -MaxEvents 30 | Select TimeCreated, Id, Message
  2. Comprueba el siguiente lunes que no se repite el apagado en la franja 8:30–10:30 (PST).
  3. Confirma eventos “limpios” en System (desaparece el 1074 iniciado por silsvc.exe).

Estrategias si necesitas más capacidades

Si tu diseño requiere más de un DC, trusts con otros dominios, o varias instancias de Windows Server en paralelo, Essentials no es la edición adecuada. Considera:

  • Migración a Standard/Datacenter en servidor nuevo:
    • Instala un servidor Windows Server Standard/Datacenter.
    • Únelo al dominio y promuévelo como DC adicional.
    • Transfiere FSMO al nuevo DC.
    • Despromueve o retira el Essentials.
  • Cambio de edición en el mismo hardware si tu licencia lo permite: evalúa una actualización de edición o reinstalación con Standard/Datacenter y restaura funciones.

Realiza la transición en ventana de mantenimiento y con respaldo del estado del sistema y de los datos del servidor de archivos.

Errores frecuentes y cómo evitarlos

  • Deshabilitar SILSVC: no lo hagas. El servicio volverá a forzar el apagado si persiste el incumplimiento y, además, vulneras la licencia.
  • Ignorar DCs huérfanos: un DC que desapareció sin despromover deja objetos y referencias (FSMO o GC) que activan el no cumplimiento.
  • Confiar en que “System está limpio”: el motivo no aparece antes del apagado en System; está en el canal de Server Infrastructure Licensing.
  • Clonar VMs sin plan: un clon/instantánea ejecutada en paralelo puede contar como instancia adicional.

Preguntas rápidas

¿Por qué el apagado es los lunes? El servicio de licencias usa una ventana recurrente para aplicar el corte si no se corrige el estado de cumplimiento. La franja exacta puede variar, pero el patrón semanal es un síntoma clásico.

¿Puedo seguir trabajando si cierro la ventana de aviso? No. Una vez iniciado el proceso por SILSVC, el apagado se ejecutará.

¿Basta con mover los FSMO? Solo si además cumples las otras reglas (único DC, sin trusts y uso correcto de la licencia).

Checklist imprimible

  • Canal Server Infrastructure Licensing revisado y sin cuenta atrás.
  • Solo un DC en todo el bosque (Get-ADDomainController devuelve 1).
  • Los cinco FSMO residen en el Essentials (netdom query fsmo).
  • Sin relaciones de confianza (Get-ADTrust -Filter * sin resultados).
  • Una única instancia activa por licencia (física o virtual).
  • Eventos 1074 por silsvc.exe ya no se repiten el lunes siguiente.

Script de verificación

Este script recopila lo esencial para confirmar el cumplimiento. Ejecútalo en el DC Essentials con privilegios de administrador.

function Test-EssentialsCompliance {
  [CmdletBinding()]
  param()

\$result = \[ordered]@{
Timestamp     = (Get-Date)
Computer      = \$env\:COMPUTERNAME
DCCount       = \$null
DCs           = @()
FSMOOwners    = @()
Trusts        = @()
LicenseEvents = @()
Compliance    = \[ordered]@{
SingleDC      = \$null
AllFSMOHere   = \$null
NoTrusts      = \$null
LicenseErrors = \$null
}
Notes         = @()
}

try {
\$dcs = Get-ADDomainController -Filter \* | Select HostName,Site,IsReadOnly,IsGlobalCatalog,IPv4Address
\$result.DCCount = \$dcs.Count
\$result.DCs = \$dcs
\$result.Compliance.SingleDC = (\$dcs.Count -eq 1)
if(-not \$result.Compliance.SingleDC){ \$result.Notes += "Hay \$(\$dcs.Count) DCs. Debe quedar 1." }
} catch {
\$result.Notes += "Error obteniendo DCs: \$($\_.Exception.Message)"
}

try {
\$fsmoRaw = & netdom query fsmo 2>&1
\$result.FSMOOwners = \$fsmoRaw
\$allHere = (\$fsmoRaw | Select-String -NotMatch \$env\:COMPUTERNAME).Count -eq 0
\$result.Compliance.AllFSMOHere = \$allHere
if(-not \$allHere){ \$result.Notes += "Algún FSMO no está en \$env\:COMPUTERNAME." }
} catch {
\$result.Notes += "Error consultando FSMO: \$($\_.Exception.Message)"
}

try {
\$trusts = Get-ADTrust -Filter \* | Select Name,Direction,TrustType,TrustAttributes
\$result.Trusts = \$trusts
\$result.Compliance.NoTrusts = (\$trusts.Count -eq 0)
if(\$trusts.Count -gt 0){ \$result.Notes += "Existen \$(\$trusts.Count) relaciones de confianza." }
} catch {
\$result.Notes += "Error listando trusts: \$($\_.Exception.Message)"
}

try {
\$lic = Get-WinEvent -LogName 'Microsoft-Windows-ServerInfrastructureLicensing/Operational' -MaxEvents 20 |
Select TimeCreated, Id, LevelDisplayName, Message
\$result.LicenseEvents = \$lic
\$result.Compliance.LicenseErrors = (\$lic | ? { \$.Message -match 'non.\compliant|out of compliance|shutdown' }).Count -gt 0
} catch {
\$result.Notes += "Error leyendo canal de licencias: \$(\$*.Exception.Message)"
}

return \[pscustomobject]\$result
}

Uso:

\$report = Test-EssentialsCompliance
\$report | Format-List
\$report.DCs | Format-Table
\$report.Trusts | Format-Table
\$report.LicenseEvents | Format-Table -AutoSize

Resumen ejecutivo

El patrón de apagado semanal con silsvc.exe y el aviso en el canal Server Infrastructure Licensing señalan un incumplimiento de la edición Essentials. Normalmente la causa está en la topología de AD: más de un DC, FSMO fuera del Essentials o trusts. Ajusta la configuración para que Essentials sea el único DC con todos los FSMO y sin confianzas; valida que no hay instancias duplicadas en virtualización. Si tu diseño exige varios DCs, relaciones de confianza o múltiples VMs, migra a Standard/Datacenter. Tras corregir, reinicia el servicio de licencias y monitoriza el canal operativo para confirmar que ha cesado la cuenta atrás y que el lunes siguiente no hay más apagados.

Consejo final: automatiza la revisión semanal con el script de verificación, guarda capturas de los canales de eventos y documenta quién posee los FSMO. Así podrás demostrar cumplimiento y reaccionar antes de la siguiente ventana de apagado.

Windows Server
Índice