Windows Server 2019 : corriger (ou ignorer) les erreurs DistributedCOM 10016 — CLSID {0358B920‑0AC7‑461F‑98F4‑58E32CD89148}, APPID {3EB3C877‑1F16‑487C‑9050‑104DBCD66683}

Vous voyez des erreurs DistributedCOM 10016 qui inondent le journal Système sur Windows Server 2019 ? Voici une explication claire, des options concrètes (du simple filtrage à l’ajustement DCOM), des scripts prêts à l’emploi et des bonnes pratiques pour concilier propreté des journaux et sécurité.

Sommaire

Problème soulevé

Le journal Système de l’Observateur d’événements enregistre des dizaines d’erreurs 10016 par minute, typiquement sous la forme :

“The machine‑default permission settings do not grant Local Activation permission for the COM Server application with CLSID {0358B920‑0AC7‑461F‑98F4‑58E32CD89148} and APPID {3EB3C877‑1F16‑487C‑9050‑104DBCD66683} to the user NT AUTHORITY\NETWORK SERVICE.”

Ces événements sont fréquents sur Windows 10/11 et Windows Server 2016/2019/2022. Ils “bruitent” les journaux sans forcément indiquer un dysfonctionnement réel.

Ce qu’il faut retenir

Par conception : de nombreux 10016 sont attendus et n’ont aucun impact fonctionnel. Le composant réessaie ensuite l’activation COM avec le bon contexte et tout fonctionne.
Ignorer ou filtrer est l’approche la plus simple et la plus sûre si aucun logiciel ne tombe en panne.
N’accordez des droits DCOM manuellement que si vous avez une preuve qu’un refus DCOM casse un scénario identifié (traces ProcMon/ETW, logs applicatifs corrélés).
Documentez chaque modification de sécurité DCOM et testez avant déploiement.

Pourquoi ces événements apparaissent

DistributedCOM (DCOM) est la couche d’activation à distance de COM. Lorsqu’un processus tente d’activer un serveur COM :

Le système vérifie les Launch and Activation Permissions de l’AppID cible (droits stockés dans le Registre).
Si le compte appelant (ex. NETWORK SERVICE) n’a pas “Lancement local”/“Activation locale”, l’accès est refusé → événement 10016.
Le même composant retente alors l’activation via une autre voie (ex. avec un service intermédiaire ou un contexte différent) et réussit.

Résultat : vous obtenez un événement 10016, mais l’application continue à fonctionner normalement. Ce pattern est particulièrement courant avec des composants système modernes.

Identifier l’application concernée

Avant de décider quoi faire, identifiez précisément le composant visé :

Ouvrez Observateur d’événements → Journaux Windows → Système → filtrez sur ID = 10016.
Ouvrez un événement et copiez CLSID, APPID et le compte concerné (ici : NT AUTHORITY\NETWORK SERVICE).
Dans Regedit :
- Vérifiez l’AppID lié au CLSID :
  HKCR\CLSID\{0358B920‑0AC7‑461F‑98F4‑58E32CD89148}\AppID
- Ouvrez la clé AppID correspondante pour voir le nom du composant :
  HKCR\AppID\{3EB3C877‑1F16‑487C‑9050‑104DBCD66683}

Vérifier l’absence d’impact réel

Si vous suspectez un lien avec une panne :

Corrélez les horodatages 10016 avec des erreurs applicatives tangibles.
Capturez une trace ProcMon (filtre Result = ACCESS DENIED) ou un provider ETW pour observer l’échec DCOM et son call stack.
Faites un test contrôlé : reproduisez l’action défaillante et voyez si le 10016 apparaît exactement au même instant.

Options de traitement

Option	Détail	Quand l’utiliser
Ne rien faire (recommandé)	Ces événements sont largement bruit et n’affectent pas le système. Les ignorer évite des modifications de sécurité hasardeuses.	Toujours, sauf preuve qu’une application échoue à cause de ce refus DCOM.
Masquer l’événement dans l’Observateur	Créez une Vue personnalisée qui supprime l’affichage des 10016. Les événements restent consignés mais n’encombrent plus la console.	Quand vous voulez des journaux lisibles sans toucher à la configuration système.
Accorder les droits DCOM (avancé)	Ajoutez le compte (ex. `NETWORK SERVICE`) avec “Lancement local” et “Activation locale” sur l’AppID ciblé via `dcomcnfg`. Souvent nécessite de prendre possession temporaire des clés Registre CLSID et AppID.	Uniquement si une application se bloque et que la corrélation est démontrée. À documenter et tester soigneusement.

Procédure : masquer les 10016 dans l’Observateur

Créer une vue personnalisée qui supprime l’affichage des 10016 (sans supprimer les événements) :

Ouvrez Observateur d’événements (eventvwr.msc).
Clic droit Vues personnalisées → Créer une vue personnalisée….
Onglet XML → cochez Modifier la requête manuellement.
Collez la requête suivante :

&lt;QueryList&gt;
  &lt;Query Id="0" Path="System"&gt;
    &lt;Suppress Path="System"&gt;*[System[(EventID=10016)]]&lt;/Suppress&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;

Cette vue affiche le journal Système sans les 10016. Les événements restent consultables dans le journal d’origine si nécessaire.

Filtrer sur un CLSID/APPID précis

Vous pouvez masquer uniquement le couple de l’exemple (CLSID {0358B920‑…} + APPID {3EB3C877‑…}) :

&lt;QueryList&gt;
  &lt;Query Id="0" Path="System"&gt;
    &lt;Suppress Path="System"&gt;
      *[System[(EventID=10016)]]
      and
      *[EventData[
           (Data[@Name='Param1']='{0358B920-0AC7-461F-98F4-58E32CD89148}')
           or (Data[@Name='CLSID']='{0358B920-0AC7-461F-98F4-58E32CD89148}')
         ]]
      and
      *[EventData[
           (Data[@Name='Param2']='{3EB3C877-1F16-487C-9050-104DBCD66683}')
           or (Data[@Name='APPID']='{3EB3C877-1F16-487C-9050-104DBCD66683}')
         ]]
    &lt;/Suppress&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;

Remarque : selon la version, les nœuds d’EventData s’appellent parfois Param1/Param2 ou CLSID/APPID. La requête ci‑dessus couvre les deux cas.

Procédure : accorder des droits DCOM (avancé)

Prérequis : cette opération modifie la surface d’attaque. Ne l’effectuez que si un besoin métier l’exige et après sauvegarde.

Sauvegarde : exportez les clés Registre.

reg export "HKCR\CLSID\{0358B920-0AC7-461F-98F4-58E32CD89148}" "%USERPROFILE%\Desktop\CLSID_0358B920.reg"
reg export "HKCR\AppID\{3EB3C877-1F16-487C-9050-104DBCD66683}" "%USERPROFILE%\Desktop\APPID_3EB3C877.reg"

Ouvrir la console DCOM : dcomcnfg → Composants DCOM.
Trouver l’AppID : triez par ID d’application et ouvrez Propriétés.
Onglet Sécurité → Lancement et activation → Modifier → Ajouter NETWORK SERVICE → cochez Lancement local et Activation locale → OK.

Si les boutons sont grisés :

Prise de possession temporaire des clés suivantes sous Regedit (clic droit → Autorisations → Avancé → Propriétaire → Administrateurs) :
- HKLM\SOFTWARE\Classes\CLSID\{0358B920-0AC7-461F-98F4-58E32CD89148}
- HKLM\SOFTWARE\Classes\AppID\{3EB3C877-1F16-487C-9050-104DBCD66683}
Donnez‑vous Contrôle total temporaire, appliquez, revenez dans dcomcnfg et refaites la modification.
Restaurez ensuite le propriétaire sur NT SERVICE\TrustedInstaller et les ACL initiales (bonne pratique sécurité).

Test : relancez l’action qui posait problème et observez si l’événement disparaît. En l’absence d’amélioration tangible, revenez à la configuration précédente.

Bonnes pratiques sécurité et exploitation

Principe du moindre privilège : n’accordez que ce qui est nécessaire (évitez “Tout le monde”).
Traçabilité : consignez qui a changé quoi (journal de changement, ticket, horodatage, SDDL avant/après).
Stabilité : sachez que des mises à jour Windows peuvent rétablir des ACL par défaut. Vérifiez après patching.
Observabilité : créez une vue “propre” pour l’exploitation quotidienne et gardez la vue brute pour les enquêtes.

Automatiser le contrôle et le filtrage

Compter les 10016 sur une période

PowerShell
Get-WinEvent -FilterHashtable @{
  LogName = 'System'
  Id      = 10016
  StartTime = (Get-Date).AddHours(-24)
} | Measure-Object

Lister les derniers messages 10016

PowerShell
Get-WinEvent -FilterHashtable @{ LogName='System'; Id=10016 } |
  Select-Object -First 5 -ExpandProperty Message

Extraire le CLSID/APPID directement depuis un événement

PowerShell
Get-WinEvent -FilterHashtable @{ LogName='System'; Id=10016 } |
  Select-Object -First 1 |
  ForEach-Object {
    $_.Properties | Select-Object Index, Value
  }

Vue personnalisée exportable

Après avoir créé votre vue “Système sans DCOM 10016”, faites Exporter la vue personnalisée pour la diffuser sur vos serveurs (GPO, outillage d’administration). L’import est immédiat et réversible.

Foire aux questions

Faut‑il supprimer les événements existants ?
Ce n’est pas nécessaire. La suppression du journal ne corrige rien. Conservez l’historique pour l’audit.

Peut‑on désactiver DCOM ?
Non recommandé : de nombreux services Windows reposent sur DCOM. Le désactiver peut casser l’administration distante, WMI, certaines consoles MMC, etc.

Pourquoi voit‑on souvent NETWORK SERVICE ?
Beaucoup de services système sont hébergés sous ce compte intégré. Il n’est pas anormal qu’il apparaisse dans les refus d’activation locale.

Attribuer des droits à “Tout le monde” résout‑il le problème ?
Ça masque le symptôme mais affaiblit la sécurité. Évitez les attributions larges ; préférez le compte précis nécessaire et seulement les privilèges requis.

Un 10016 peut‑il révéler un vrai incident ?
Oui, mais c’est rare. Indices d’alerte : échecs applicatifs corrélés, répétabilité parfaite, absence de tentative d’activation “de repli”, utilisateurs affectés. Dans ce cas, appliquez l’option avancée de manière ciblée.

Checklist décisionnelle

Situation	Action recommandée	Justification
10016 fréquents, aucun symptôme	Ignorer ou masquer	Événement attendu, bruit sans impact
10016 alignés sur une erreur logicielle	Tracer, prouver la corrélation	Éviter une modification DCOM inutile
Corrélation prouvée (ProcMon/ETW)	Accorder droits DCOM ciblés	Restaure le scénario tout en limitant le risque
Contexte réglementaire exigeant	Masquage par vue personnalisée	Journaux exploitables sans altérer la sécurité

Annexe : requêtes XML utiles pour l’Observateur

Masquer tous les 10016 du journal Système

&lt;QueryList&gt;
  &lt;Query Id="0" Path="System"&gt;
    &lt;Suppress Path="System"&gt;*[System[(EventID=10016)]]&lt;/Suppress&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;

Afficher uniquement les 10016 (vue dédiée d’investigation)

&lt;QueryList&gt;
  &lt;Query Id="0" Path="System"&gt;
    &lt;Select Path="System"&gt;*[System[(EventID=10016)]]&lt;/Select&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;

Masquer 10016 pour un compte précis (ex. NETWORK SERVICE)

&lt;QueryList&gt;
  &lt;Query Id="0" Path="System"&gt;
    &lt;Suppress Path="System"&gt;
      *[System[(EventID=10016)]] and
      *[EventData[Data and (Data='NT AUTHORITY\\NETWORK SERVICE')]]
    &lt;/Suppress&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;

Annexe : points d’attention lors des changements DCOM

Backups : exportez les clés CLSID et AppID avant toute modification.
Propriétaire : remettez TrustedInstaller après l’opération.
Surface : évitez les attributions de type “Tout le monde” ou “Utilisateurs authentifiés”.
MCO : vérifiez après patch mensuel que les ACL n’ont pas été restaurées par le système.

Conclusion

Les erreurs DistributedCOM 10016 sur Windows Server 2019 sont le plus souvent des événements attendus qui n’affectent pas les charges de travail. Pour conserver des journaux exploitables, créez une vue personnalisée qui masque ces événements, tout en gardant l’historique brut pour les enquêtes. N’envisagez un ajustement des droits DCOM que si un logiciel identifié échoue et que vous avez prouvé la corrélation. Cette approche concilie hygiène opérationnelle, sécurité et conformité.

Windows Server 2019 : corriger (ou ignorer) les erreurs DistributedCOM 10016 — CLSID {0358B920‑0AC7‑461F‑98F4‑58E32CD89148}, APPID {3EB3C877‑1F16‑487C‑9050‑104DBCD66683}