Windows Server 2019 Essentials : arrêts du lundi par silsvc.exe — diagnostic et solution pas à pas

Votre serveur Windows Server 2019 Essentials s’éteint chaque lundi entre 08:30 et 10:30 (UTC‑8) ? Voici un guide concret pour diagnostiquer l’arrêt initié par silsvc.exe (Licensing Compliance Service) et rétablir une topologie Active Directory conforme.

Sommaire

Arrêts hebdomadaires d’un serveur Windows Server 2019 Essentials le lundi matin

Contexte et symptômes observés

Un serveur HP exécutant Windows Server 2019 Essentials (système activé) s’éteint systématiquement le lundi matin entre 08:30 et 10:30 (UTC‑8, fuseau Pacifique). Aucune tâche planifiée n’explique le comportement, la température est normale, et les journaux « classiques » ne montrent rien avant l’extinction. En revanche, un événement User32 / 1074 apparaît après coup, indiquant que C:\Windows\System32\silsvc.exe (Server Infrastructure Licensing Service) a demandé l’arrêt :

« Licensing Compliance Service caused a shutdown. Voir Microsoft > Windows > Server Infrastructure Licensing > Operational. »

Conclusion en une phrase

L’arrêt est forcé par le service de conformité de licence de l’édition Essentials à la suite d’une non‑conformité détectée dans la topologie Active Directory ou dans l’usage de l’édition.

Pourquoi le lundi ?

Le service de conformité effectue des vérifications périodiques. Dans de nombreux environnements, un cycle hebdomadaire est observé, d’où un regroupement des arrêts sur une fenêtre récurrente le lundi matin. Ce n’est pas l’heure qui importe, mais la condition de non‑conformité que le service finit par constater.

Ce que contrôle l’édition Essentials

Windows Server 2019 Essentials est conçu pour un petit domaine, avec des limitations que le service de conformité (silsvc) surveille. Les causes de non‑conformité les plus fréquentes sont :

Présence de plus d’un contrôleur de domaine (même un ancien DC restant dans l’AD).
Le serveur Essentials ne détient pas tous les rôles FSMO.
Existence de relations d’approbation (trusts) avec d’autres domaines/forêts.
Topologie multi‑domaine ou multi‑forêt.
(Plus rarement) dépassement des limites d’usage (25 utilisateurs / 50 appareils) ou configuration/licences de virtualisation inadaptées.

Important : ne désactivez pas silsvc et n’essayez pas de contourner la conformité. Outre l’aspect légal, cela n’empêchera pas forcément de nouveaux arrêts et compliquera le diagnostic.

Localiser la cause exacte dans les journaux

La clé est le journal dédié aux vérifications de licence, distinct des journaux Système/Application.

Ouvrez l’Observateur d’événements.
Accédez à Applications et services → Microsoft → Windows → Server Infrastructure Licensing → Operational.
Filtrez sur la plage du lundi 08:00–11:00 (UTC‑8) et cherchez des événements d’avertissement et d’erreur émis peu avant l’arrêt.
Lisez le message détaillé : il précise la condition de non‑conformité détectée (DC multiple, trusts, FSMO, etc.).

Vous pouvez aussi lister rapidement les derniers événements en PowerShell :

Get-WinEvent -LogName "Microsoft-Windows-Server Infrastructure Licensing/Operational" -MaxEvents 50 |
  Select TimeCreated, Id, LevelDisplayName, Message |
  Sort-Object TimeCreated -Descending

Plan d’action pas à pas

Valider la présence d’un unique contrôleur de domaine

Dans un domaine Essentials, un seul DC doit exister et être en service. Vérifiez l’OU Domain Controllers dans ADUC et nettoyez tout objet résiduel.

# Lister les contrôleurs de domaine connus
Get-ADDomainController -Filter * | Select Name, IPv4Address, Site, IsGlobalCatalog

# Compter le nombre de DCs : doit être 1

(Get-ADDomainController -Filter \*).Count

Si un ancien DC apparaît (même hors ligne) : exécutez un metadata cleanup puis supprimez les objets restants dans Sites and Services et DNS.

Contrôler et, au besoin, transférer tous les rôles FSMO

# Inventaire des rôles FSMO
netdom query fsmo

# Transférer via PowerShell (exemple : tous les rôles vers le serveur Essentials)

Move-ADDirectoryServerOperationMasterRole -Identity "NOM-SRV-ESSENTIALS" \`
-OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Éliminer toute relation d’approbation

Essentials ne supporte pas de trusts avec d’autres domaines/forêts.

# Lister les trusts
Get-ADTrust -Filter * | Select Name, Direction, TrustType

# Suppression via la MMC "Active Directory Domains and Trusts" ou via PowerShell si approprié

Confirmer une topologie domaine/forêt simple

# Les domaines retournés doivent se limiter au domaine Essentials
(Get-ADForest).Domains

Vérifications de base

Édition et activation : winver et slmgr /dlv.
Fuseau horaire exact (UTC‑8 si Pacifique) et synchronisation NTP.
Si virtualisé, cohérence des droits de licence avec l’hyperviseur et l’usage.

Tableau de contrôle de conformité Essentials

Règle	Comment la vérifier	Action corrective
Un seul contrôleur de domaine	`Get-ADDomainController -Filter *` et ADUC → OU Domain Controllers	Démotion de l’excédentaire ou metadata cleanup si disparu
Tous les rôles FSMO sur Essentials	`netdom query fsmo`	Transférer (ou saisir) les 5 rôles sur le serveur Essentials
Aucun trust inter‑domaine/forêt	`Get-ADTrust -Filter *` et MMC Domains and Trusts	Supprimer les trusts (unidirectionnels ou bidirectionnels)
Topologie à un seul domaine	`(Get-ADForest).Domains`	Revenir à un domaine unique ou migrer vers Standard
Limites 25 utilisateurs / 50 appareils	Inventaires AD : `Get-ADUser`, `Get-ADComputer` (comptes actifs)	Désactiver/archiver les comptes inactifs ou migrer vers Standard

Corrections typiques et procédures

Ancien DC détecté mais plus présent physiquement

Lancez un metadata cleanup : # PowerShell (module AD) Remove-ADDomainController -Identity "NOM-ANCIEN-DC" -MetadataCleanup -Force -Confirm:$false
Supprimez le serveur et l’objet NTDS Settings dans Active Directory Sites and Services.
Nettoyez les enregistrements DNS associés (A, SRV, CNAME) au DC supprimé.

Rôles FSMO dispersés

Transférez tous les rôles sur le serveur Essentials, puis confirmez :

Move-ADDirectoryServerOperationMasterRole -Identity "NOM-SRV-ESSENTIALS" `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

netdom query fsmo

Trusts trouvés

Essentials n’accepte aucune relation d’approbation. Supprimez toutes les entrées listées par Get-ADTrust dans la console Active Directory Domains and Trusts. Redémarrez le service Netlogon si nécessaire.

Environnement dépassant le périmètre Essentials

Si vos contraintes d’entreprise imposent plusieurs DCs, des trusts, ou plusieurs domaines, l’environnement est non compatible avec Essentials. Deux voies sûres :

Migration avec nouveau serveur Standard : joindre un Windows Server Standard au domaine, promouvoir en DC, transférer les FSMO, déplacer les rôles applicatifs/données, puis démonter et retirer le serveur Essentials.
Refonte sur Standard si vous planifiez une consolidation ou un renouvellement matériel/OS.

Remarque : l’upgrade d’édition in‑place depuis Essentials vers Standard n’est pas le scénario le plus courant et peut être limité selon les clés/contrats. La voie de migration via un nouveau serveur Standard reste la plus maîtrisée.

Contrôles post‑remédiation

Surveillez pendant 1 à 2 lundis l’absence d’événements dans Server Infrastructure Licensing / Operational.
Vérifiez qu’aucun nouvel événement User32 / 1074 n’est généré.
Exécutez une vérification de santé AD pour confirmer la stabilité.

# Santé de la réplication
repadmin /replsummary
repadmin /showrepl

# Diagnostic de base DC

dcdiag /v

Script de triage rapide

Exécutez ce bloc sur le serveur Essentials pour obtenir une vue synthétique :

# 1) Derniers événements de conformité de licence
Get-WinEvent -LogName "Microsoft-Windows-Server Infrastructure Licensing/Operational" -MaxEvents 30 |
  Select TimeCreated, Id, Message | Sort-Object TimeCreated -Descending

# 2) État AD essentiel

netdom query fsmo
Get-ADDomainController -Filter \* | Select Name, IPv4Address, Site, IsGlobalCatalog
Get-ADTrust -Filter \* | Select Name, Direction, TrustType
(Get-ADForest).Domains

Exemples de messages utiles pour le diagnostic

Journal Licensing / Operational : messages d’avertissement indiquant qu’une condition de licence sera appliquée, parfois avec un compte à rebours avant extinction.
Système → User32 / 1074 : confirmation de l’arrêt demandé par silsvc.exe avec l’argument « Licensing Compliance Service ».

Si vous voyez ces éléments de manière répétée le lundi matin, c’est un signe fort que la non‑conformité n’a pas encore été corrigée.

Checklist opérationnelle prête à l’emploi

Ouvrir le journal Server Infrastructure Licensing / Operational et relever le libellé précis de la non‑conformité.
Vérifier le nombre de DCs et la présence d’anciens objets.
Confirmer que tous les FSMO sont détenus par le serveur Essentials.
Supprimer toute relation d’approbation.
Valider que la forêt/domaine est unique.
Contrôler activation, heure/NTP, virtualisation (si applicable).
Surveiller le lundi suivant et consigner les résultats.

FAQ pratique

Est‑il possible de désactiver le service `silsvc` ?

Non. Le service fait partie du mécanisme de conformité d’Essentials. Le désactiver, le tuer, ou bloquer ses actions viole la licence et peut dégrader la stabilité. La solution durable consiste à corriger la cause (topologie/usage).

Un ancien contrôleur de domaine hors ligne peut‑il déclencher l’arrêt ?

Oui. Un objet DC résiduel ou des enregistrements DNS orphelins peuvent suffire à faire croire à la présence d’un second DC. D’où l’importance du metadata cleanup et du nettoyage DNS.

Que faire si l’entreprise a besoin de deux DCs pour la résilience ?

Ce besoin dépasse le périmètre d’Essentials. La voie recommandée est la migration vers Windows Server Standard (ou Datacenter selon les cas), avec au moins deux DCs et, si nécessaire, des trusts.

Le dépassement de 25 utilisateurs / 50 appareils provoque‑t‑il un arrêt immédiat ?

Ce cas est moins fréquent. Toutefois, si la volumétrie a évolué, vérifiez les comptes actifs et désactivez/archivez ceux qui ne sont plus utilisés, ou planifiez une migration vers Standard.

Pourquoi ne vois‑je rien d’utile dans Application ou Système juste avant l’arrêt ?

Le détail réside dans le journal Server Infrastructure Licensing / Operational, qui est distinct des journaux généraux. C’est là que le message de conformité est consigné avant l’extinction.

Annexes techniques

Comptage utilisateurs et ordinateurs actifs

# Comptes utilisateurs activés (hors comptes intégrés)
Get-ADUser -Filter {Enabled -eq $true -and ObjectClass -eq "user"} -SearchBase (Get-ADDomain).DistinguishedName |
  Where-Object { $_.Name -notmatch "^(Guest|DefaultAccount|krbtgt)$" } |
  Measure-Object

# Postes clients (ordinateurs) activés

Get-ADComputer -Filter {Enabled -eq \$true} |
Measure-Object

Vérifications temps/NTP

# Fuseau horaire
Get-TimeZone

# Source de temps

w32tm /query /status
w32tm /query /configuration

Surveillance ciblée le lundi matin

# À exécuter le lundi matin pour suivre en temps réel
$log = "Microsoft-Windows-Server Infrastructure Licensing/Operational"
Get-WinEvent -LogName $log -MaxEvents 1 | Format-Table -AutoSize
Write-Host "Suivi en temps réel - CTRL+C pour arrêter"
Get-WinEvent -LogName $log -MaxEvents 1000 -Oldest | Where-Object {
  $_.TimeCreated -gt (Get-Date).Date.AddHours(8) -and $_.TimeCreated -lt (Get-Date).Date.AddHours(12)
} | Sort-Object TimeCreated | Format-Table TimeCreated, Id, LevelDisplayName, Message -AutoSize

Arbre de décision rapide

Un seul DC ? Non → retirer l’excédentaire / nettoyer les métadonnées.
Tous les FSMO ? Non → transférer/saisir les rôles.
Trusts ? Oui → supprimer.
Plusieurs domaines/forêts ? Oui → migrer vers Standard.
Tout OK mais arrêts persistent ? Recontrôler le journal Operational et la volumétrie (25/50), puis envisager une migration.

Étude de cas synthétique

Dans un environnement client, l’arrêt survenait chaque lundi à 09:10 (UTC‑8). Le journal Operational mentionnait la détection d’un second DC résiduel (objet resté après une panne matérielle). Après metadata cleanup, suppression des enregistrements DNS, transfert des FSMO vers le serveur Essentials, et redémarrage contrôlé : plus aucun arrêt observé sur les deux lundis suivants.

En résumé

Les extinctions hebdomadaires d’un Windows Server 2019 Essentials autour du lundi matin sont presque toujours le symptôme d’une non‑conformité que le Server Infrastructure Licensing Service détecte. Le journal Server Infrastructure Licensing → Operational vous dira exactement quelle règle est violée. Ramenez la topologie dans le périmètre Essentials (un seul DC, tous les FSMO, aucun trust, un seul domaine), ou migrez vers Windows Server Standard si vos besoins dépassent ce périmètre.

Prêt à agir ? Liste d’exécution rapide

Ouvrir le journal Server Infrastructure Licensing / Operational et noter la cause.
Get-ADDomainController -Filter * : vérifier qu’un seul DC existe.
netdom query fsmo : réunir tous les rôles sur Essentials.
Get-ADTrust -Filter * : supprimer tout trust.
(Get-ADForest).Domains : confirmer le domaine unique.
Surveiller le lundi suivant : absence d’User32 / 1074 = correctif validé.

Windows Server 2019 Essentials : arrêts du lundi par silsvc.exe — diagnostic et solution pas à pas