Dépannage de la demande automatique de certificat (auto-enrollment) via RPC/DCOM (MS-WCCE)

Auteur Uwe GradeneggerPublié le Catégories Test de fonctionnement, DépannageÉtiquettes , , , , , , , , , , ,

Supposons le scénario suivant :

  • Es ist eine Zertifikatvorlage für die automatische Beantragung von Zertifikaten konfiguriert (Autoenrollment).
  • Die Zertifikatvorlage ist auf einer ins Active Directory integrierten Zertifizierungsstelle (Enterprise Certification Authority) veröffentlicht.
  • Die für die automatische Zertifikatbeantragung konfigurierten Benutzer oder Computer beantragen allerdings nicht wie vorgesehen Zertifikate.

Nachfolgend eine Anleitung zur Fehlersuche.

Dieser Artikel beschreibt die Fehlersuche von Autoenrollment über RPC/DCOM. Viele der Aussagen lassen sich auch auf die Zertifikatbeantragung über WSTEP (CEP/CES) übertragen.

Eingrenzen des Problembereiches

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Zunächst muss geklärt werden, in welchem Kontext der Fehler auftritt.

  • Tritt er für Zertifikate eines Benutzers auf?
  • Tritt er für Zertifikate eines Computers auf?

Für die Fehlersuche bei der Beantragung von Benutzer-Zertifikaten ist es meist erforderlich, sich mit dem betreffenden Benutzer gemeinsam in dessen Sitzung einzuklinken. Tritt der Fehler im Kontext eines Computers auf, ist es oft möglich, ohne den Benutzer auf dem System mit einer administrativen Kennung zu arbeiten.

Möglichkeiten zur Remote-Fehlersuche

Folgende Methoden des Zugriffs auf das betreffende System ergeben sich somit für die Fehlersuche:

  • Bildschirmfreigabe (Screen Sharing, zusammen mit und im Kontext des Endbenutzers)
  • Administrativ / Interaktive Anmeldung (Konsole/Remote Desktop)
  • Administrativ / per Remote-Konsole über PSExec Remoting (nicht empfehlenswert)
  • Administrativ / per Remote-Konsole über PowerShell Remoting

Es wird im Allgemeinen nicht empfohlen, sich mit einem administrativen Domänenkonto an einem Clientsystem anzumelden, da hier die Gefahr eines Credential-Diebstahls sehr hoch ist.

Da der kleinste gemeinsame Nenner oft die Kommandozeile ist, wird die Fehlersuche nachfolgend auch mit dieser vorgenommen.

Einordnung des Fehlerbildes

Grundsätzlich kann man Autoenrollment Fehler in folgende Bereiche einteilen, die nachfolgend näher beschrieben werden:

  • Die Zertifikatanforderung wird nicht gestellt
  • Die Zertifikatanforderung wird gestellt, kommt aber nicht an der Zertifizierungsstelle an
  • Die Zertifikatanforderung wird gestellt, kommt auch an der Zertifizierungsstelle an, wird dort allerdings abgelehnt

Die Zertifikatanforderung wird nicht gestellt

Wird die Zertifikatanforderung überhaupt nicht gestellt, sollten folgende Punkte beleuchtet werden:

  • Ist bereits ein Zertifikat der betreffenden Zertifikatvorlage vorhanden?
  • Ist Autoenrollment auf dem Client aktiviert?
  • Wird der Autoenrollment Prozess ausgelöst?
  • Ist das betreffende Konto zur Zertifikatbeantragung berechtigt?
  • Kann der Client die Vertrauenskette zur Zertifizierungsstelle herstellen?
  • Kann der Client ein Schlüsselpaar erzeugen?

Details: Ist bereits ein Zertifikat der betreffenden Zertifikatvorlage vorhanden?

Pour le contexte de l'utilisateur :

certutil -user -store my

Pour le contexte informatique :

certutil -store my

Mit diesem Befehl werden auch archivierte Zertifikate angezeigt. Daher ist es übersichtlicher, die Windows PowerShell zu verwenden.

Pour le contexte de l'utilisateur :

Get-ChildItem -Path Cert:\CurrentUser\My

Pour le contexte informatique :

Get-ChildItem -Path Cert:\LocalMachine\My

Details: Ist Autoenrollment auf dem Client aktiviert?

Wenn Autoenrollment auf dem Client nicht aktiviert ist, äußert sich dies üblicherweise dadurch, dass trotz der eindeutigen Trigger keine Zertifikatbeantragung stattfindet.

Die Konfiguration für Autoenrollment wird üblicherweise per Gruppenrichtlinie festgelegt. Nur weil eine Gruppenrichtlinie vorhanden, konfiguriert und verlinkt ist, heißt es aber nicht, dass diese auch beim Client angekommen ist.

Eine Mögliche Ursache kann z.B. fehlende Domänenkonnektivität sein oder eine Filterung anhand einer Sicherheitsgruppe oder eines anderen Kriteriums.

Bitte auch beachten, dass bei Ausführung eines Prozesses via RunAs keine Gruppenrichtlinien angewendet werden und dementsprechend unter Umständen (z.B. bei Erstanmeldung via RunAs) auch kein AutoEnrollment erfolgt.

  • Die Aktivierung des Autoenrollment Prozesses („Configuration model“) bewirkt zunächst, dass ein Replikat des „Public Key Services“ Objektes aus der Konfigurationspartition des Active Directory geladen wird. Sie muss mindestens aktiviert sein, damit die weiteren Optionen verwendet werden können.
  • Die Einstellung „Renouveler les certificats expirés, mettre à jour les certificats en attente et révoquer les certificats révoqués“ bewirkt, dass abgelaufene Zertifikate automatisch erneuert werden, sofern sie von einer Active Directory integrierten Zertifizierungsstelle ausgestellt wurden. Außerdem werden genehmigte Zertifikatanforderungen von Zertifizierungsstellen abgeholt, sofern diese vorliegen. Widerrufene Zertifikate werden archiviert.
  • Die Einstellung „Update certificates that use certificate templates“ bewirkt, dass Zertifikate automatisch beantragt werden, welche für den Antragsteller für Autoenrollment freigegeben sind. Sie muss also auf dem Client aktiviert sein, damit Zertifikate automatisch beantragt werden können.

Die Autoenrollment Konfiguration wird lokal in der Registrierung gespeichert:

Pour le contexte de l'utilisateur :

HKCU\Software\Policies\Microsoft\Cryptography\AutoEnrollment\AEPolicy

Pour le contexte informatique :

HKLM\Software\Policies\Microsoft\Cryptography\AutoEnrollment\AEPolicy

Im folgenden werden die einzelnen Konfigurationsoptionen für „AEPolicy“ beschrieben.

ValeurDescriptionRésultat
0x00000000 ou non disponibleLe processus d'auto-enrôlement est active
„Mise à jour des certificats qui utilisent des modèles de certificats" est désactivé		pas de demande automatique de certificats
pas de renouvellement automatique des certificats expirés
pas de collecte automatique des demandes de certificats approuvées
pas de archivage automatique des certificats révoqués
0x00000001Le processus d'auto-enrôlement est active
„Mise à jour des certificats qui utilisent des modèles de certificats" est active
„Renouveler les certificats expirés, mettre à jour les certificats en attente et révoquer les certificats révoqués" est désactivé		demande automatique de certificats
pas de renouvellement automatique des certificats expirés
pas de collecte automatique des demandes de certificats approuvées
pas de archivage automatique des certificats révoqués
0x00000006Le processus d'auto-enrôlement est active
„Mise à jour des certificats qui utilisent des modèles de certificats" est désactivé
„Renouveler les certificats expirés, mettre à jour les certificats en attente et révoquer les certificats révoqués" est active		pas de demande automatique de certificats
renouvellement automatique des certificats expirés
collecte automatique des demandes de certificats approuvées
archivage automatique des certificats révoqués
0x00000007Le processus d'auto-enrôlement est active
„Mise à jour des certificats qui utilisent des modèles de certificats" est active
„Renouveler les certificats expirés, mettre à jour les certificats en attente et révoquer les certificats révoqués" est active		demande automatique de certificats
renouvellement automatique des certificats expirés
collecte automatique des demandes de certificats approuvées
archivage automatique des certificats révoqués
0x00008000AutoEnrollment est désactivépas de demande automatique de certificats
pas de renouvellement automatique des certificats expirés
pas de collecte automatique des demandes de certificats approuvées
pas de archivage automatique des certificats révoqués

Damit die automatische Zertifikatbeantragung erfolgt, muss „AEPolicy“ somit den Wert 0x1 oder besser den Wert 0x7 aufweisen. Der Wert kann mit den folgenden Kommandozeilenbefehlen abgefragt werden.

Pour le contexte de l'utilisateur :

certutil -v -user -getreg -GroupPolicy enroll\AEPolicy

Alternativ kann der Schlüssel aus der Registrierung direkt ausgelesen werden:

reg query HKCU\Software\Policies\Microsoft\Cryptography\AutoEnrollment /v AEPolicy

Für den Maschinenkontext:

certutil -v -getreg -GroupPolicy enroll\AEPolicy

Alternativ kann der Schlüssel aus der Registrierung direkt ausgelesen werden:

reg query HKLM\Software\Policies\Microsoft\Cryptography\AutoEnrollment /v AEPolicy

Der Wert kann auch über die Windows PowerShell aus der Registry abgefragt werden.

Pour le contexte de l'utilisateur :

(Get-ItemProperty -Path HKCU:\Software\Policies\Microsoft\Cryptography\AutoEnrollment).AEPolicy

Für den Maschinenkontext:

(Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Cryptography\AutoEnrollment).AEPolicy

Angelegt können die Einstellungen auch ohne Gruppenrichtlinie mit folgenden Befehlen. Der Wert aus dem Beispielcode ist gegebenenfalls anhand der obenstehenden Tabelle anzupassen.

Pour le contexte de l'utilisateur :

New-Item -Path HKCU:\Software\Policies\Microsoft\Cryptography\AutoEnrollment
Set-ItemProperty -Path HKCU:\Software\Policies\Microsoft\Cryptography\AutoEnrollment -Name AEPolicy -Value 0x7 -Force

Für den Maschinenkontext:

New-Item -Path HKLM:\Software\Policies\Microsoft\Cryptography\AutoEnrollment
Set-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Cryptography\AutoEnrollment -Name AEPolicy -Value 0x7 -Force

Details: Wird der Autoenrollment Prozess ausgelöst?

Les déclencheurs de l'exécution du processus d'auto-enrollment sur les membres du domaine sont

  • à l'ouverture de session de l'utilisateur (sur les ordinateurs, lorsque le compte de l'ordinateur se connecte, c'est-à-dire au démarrage du système)
  • Par minuterie toutes les 8 heures.
  • Lors d'une mise à jour de la stratégie de groupe, à condition qu'il y ait eu un changement.

Im Aufgabenplaner befinden sich entsprechende Aufgaben unter „Microsoft“ – „Windows“ – „CertificateServicesClient“.

Es ist also durchaus möglich, dass noch kein Trigger für die Zertifikatbeantragung ausgelöst wurde (siehe hierzu auch Artikel „Es wird kein Zertifikat per Autoenrollment beantragt, wenn ein Benutzer per Virtual Private Network (VPN) verbunden ist„).

Manuell kann der Prozess mit folgenden Befehlen ausgelöst werden.

Pour le contexte de l'utilisateur :

certutil -pulse -user

Pour le contexte informatique :

certutil -pulse

Ob der Prozess ausgelöst wurde, kann man anhand des Status der Aufgaben im Aufgabenplaner ermitteln. Dies kann auch per Windows PowerShell erfolgen:

Pour le contexte de l'utilisateur :

Get-ScheduledTask `
-TaskPath \Microsoft\Windows\CertificateServicesClient\ `
-TaskName UserTask | Select-Object -Property State

Pour le contexte informatique :

Get-ScheduledTask `
-TaskPath \Microsoft\Windows\CertificateServicesClient\ `
-TaskName SystemTask | Select-Object -Property State

Bitte beachten: Es kann auch sein, dass der Prozess dauerhaft läuft und nie beendet wird. Dies ist beispielsweise dann der Fall, wenn ein manuelles Eingreifen des Benutzers notwendig ist, der Benutzer diese Interaktion allerdings nicht durchführt.

Die letzte Ausführungszeit und das Ergebnis des Task kann ebenfalls per Windows PowerShell eingesehen werden.

Pour le contexte de l'utilisateur :

Get-ScheduledTaskInfo `
-TaskPath \Microsoft\Windows\CertificateServicesClient\ `
-TaskName UserTask

Pour le contexte informatique :

Get-ScheduledTaskInfo `
-TaskPath \Microsoft\Windows\CertificateServicesClient\ `
-TaskName SystemTask

Details: Ist das betreffende Konto zur Zertifikatbeantragung berechtigt?

Damit eine Zertifikatbeantragung erfolgen kann, muss der Benutzer bzw. der Computer an zwei Stellen berechtigt sein:

  • In den Sicherheitsberechtigungen der betreffenden Zertifikatvorlage
  • In den Sicherheitseinstellungen der Zertifizierungsstelle, welche die Zertifikatvorlage anbietet

Beide Informationen sind im Active Directory hinterlegt. Ist der Benutzer nicht berechtigt, erfolgt keine Zertifikatbeantragung.

Vorsicht bei Verwendung von Sicherheitsgruppen für die Erteilung der Berechtigungen: Nur weil der Benutzer bzw. der Computer im Active Directory Mitglied einer Sicherheitsgruppe ist, heißt das noch nicht, dass diese auch bereits im Kerberos Ticket angewendet wurde. Hat sich der Benutzer seit Hinzufügen zur Gruppe noch nicht neu angemeldet bzw. wurde der Computer noch nicht neu gestartet, wurde die Gruppenmitgliedschaft auch noch nicht angewendet.

Der Autoenrollment Client inspiziert nicht das lokale Kerberos-Ticket, sondern die Zugriffsberechtigungen im Active Directory. Daher würde hier das Phänomen auftreten, dass zwar eine Zertifikatbeantragung ausgelöst wird, die Zertifikatbeantragung jedoch mangels Berechtigung von der Zertifizierungsstelle abgelehnt würde (Événement n° 53 mit Fehlercode CERTSRV_E_TEMPLATE_DENIED auf der Zertifizierungsstelle).

Ob die Gruppenmitgliedschaft lokal bereits abgebildet wurde, kann mit folgenden Kommandozeilenbefehlen überprüft werden.

Pour le contexte de l'utilisateur :

gpresult /R /Scope:User

Pour le contexte informatique :

gpresult /R /Scope:Computer

Die Berechtigungen für die Zertifikatbeantragung können auch mit folgendem Kommandozeilenbefehl überprüft werden:

certutil -config "Hostname-der-CA\Common-Name-der-CA" -catemplates

Die Berechtigung zur Beantragung von Zertifikaten auf der Zertifizierungsstelle wird in der Standardeinstellung über einen entsprechenden Eintrag für „Authenticated Users“ sichergestellt.

Diese Information wird ins Active Directory synchronisiert. Entsprechend können sich Clients bereits vor Antragstellung über ihre Berechtigungen informieren. Sind sie nicht berechtigt, wird auch kein Zertifikatantrag gestellt.

Typische Ursachen für fehlende Berechtigungen auf der Zertifizierungsstelle sind in folgenden Artikeln beschrieben:

Details: Kann der Client die Vertrauenskette zur Zertifizierungsstelle herstellen?

Versucht man, das Zertifikat über die Microsoft Management Konsole zu beantragen (certmgr.msc für den Benutzerkontext sowie certlm.msc für den Computerkontext), und die Zertifikatvorlage wird zwar angezeigt, aber ist nicht auswählbar mit der Fehlermeldung „A valid certification authority (CA) configured to issue certificates based on this template cannot be located, or the CA does not support this operation, or the CA is not trusted.“, ist es möglich, dass der Client die entsprechende ausstellende Zertifizierungsstelle nicht kennt, d.h. die Vertrauenskette nicht herstellen kann.

Dans ce cas, il convient de vérifier les points suivants :

  • L'autorité de certification racine (angl. "Root CA") est-elle enregistrée dans le magasin d'autorités de certification racine de confiance correspondant ?
  • Toutes les autorités de certification intermédiaires (si elles existent) sont-elles stockées dans la liste des certificats d'autorités de certification intermédiaires ? (Cette liste est automatiquement remplie sur les clients de domaine à partir de l'objet "AIA" du Public Key Services Container dans l'Active Directory. Il convient donc de vérifier si les certificats y sont également déposés).

Voir aussi à ce sujet

Details: Kann der Client ein Schlüsselpaar erzeugen?

Das Schlüsselpaar kann nicht erzeugt werden, z.B. weil der Cryptographic Service Provider bzw. Key Storage Provider nicht vorhanden ist oder nicht funktioniert (würde auf dem Client das Événement n° 57 déclencher).

Ob ein bestimmter Key Storage Provider auf dem Client benutzbar ist, kann mit folgendem Befehl überprüft werden.

certutil -csp "Microsoft Platform Crypto Provider" -csptest

Im Erfolgsfall würde folgende Meldung generiert:

CertUtil: -csptest-Befehl wurde erfolgreich ausgeführt.

Im Fehlerfall würde eine mit folgener vergleichbare Meldung generiert:

CertUtil: -csptest command FAILED: 0x80090030 (-2146893776 NTE_DEVICE_NOT_READY)
CertUtil: The device that is required by this cryptographic provider is not ready for use.

Es ist auch möglich, mit der Windows PowerShell ein selbstsigniertes Zertifikat unter Verwendung des entsprechenden Key Storage Provider zu erzeugen:

New-SelfSignedCertificate `
-Provider "Microsoft Platform Crypto Provider" `
-KeyLength 2048 `
-Subject "CN=Test" `
-CertStoreLocation Cert:\CurrentUser\My

Siehe auch Artikel „Die Beantragung eines Zertifikats ist nicht möglich, da die Zertifikatvorlage nicht angezeigt wird. Die Fehlermeldung lautet „Can not find a valid CSP in the local machine.“„ .

Die Zertifikatanforderung wird gestellt, kommt aber nicht an der Zertifizierungsstelle an

Wird die Zertifikatanforderung zwar gestellt, kommt aber nicht bei der Zertifizierungsstelle an, sollten folgende Punkte beleuchtet werden:

  • Ist die Zertifizierungsstelle erreichbar und kann sich an dieser authentifiziert weden?
  • Kann ein Zertifikat von der betreffenden Zertifikatvorlage manuell angefordert werden?

Ist die Zertifizierungsstelle erreichbar und kann sich an dieser authentifiziert werden?

Fehler, die aufgrund eines Problems mit der Netzwerkverbindung oder der Authentifizierung an der RPC/DCOM Schnittstelle auftreten können, verursachen den Fehlercode RPC_S_SERVER_UNAVAILABLE.

Voir à ce sujet l'article „La demande de certificat échoue avec le message d'erreur "The certificate request could not be submitted to the certification authority. Error : The RPC server is unavailable. 0x800706ba (WIN32 : 1722 RPC_S_SERVER_UNAVAILABLE)"„ .

Beim Zertifikatregistrierungs-Webdienst (CES) gibt der Client den gleichen Fehlercode aus, wenn der Serverdienst läuft, aber keine Verbindung zur Zertifizierungsstelle herstellen kann. Kann der Serverdienst jedoch erst gar nicht starten, weil die Zertifizierungsstelle zu diesem Zeitpunkt nicht erreichbar ist, wird der Fehlercode WS_E_ENDPOINT_FAILURE sein, der sich aber wiederum in den meisten Fällen im Backend auf RPC_S_SERVER_UNAVAILABLE herunterbrechen lässt.

Mit der folgenden Befehlsabfolge in der Windows PowerShell kann einfach die gesamte Kette bis zur Zertifizierungsstelle (über RPC/DCOM) validiert werden.

$ConfigString = "{Hostname-der-Zertifizierungsstelle}\{Common-Name-der-Zertifizierungsstelle}"
$CertRequest = New-Object -ComObject CertificateAuthority.Request
$CertRequest.GetCAProperty($ConfigString, 0x6, 0, 4, 0)

Der Befehl sollte bei Erfolg den Common Name der Zertifizierungsstelle zurückmelden.

Für den Computerkontext muss zunächst in den diesen gewechselt werden (NT-AUTHORITY\SYSTEM). Dies kann beispielsweise per psexec erfolgen:

psexec -s -i powershell.exe

Anschließend kann der vorige Befehl im Kontext des Computerkontos ausgeführt werden.

Details: Kann ein Zertifikat von der betreffenden Zertifikatvorlage manuell angefordert werden?

Die Zertifikatbeantragung für eine bestimmte Zertifikatvorlage kann mit folgendem Befehl manuell (also ohne Autoenrollment) ausgelöst werden.

Pour le contexte de l'utilisateur :

certreq -q -enroll "Name-der-Zertifikatvorlage"

Pour le contexte informatique :

certreq -q -machine -enroll "Name-der-Zertifikatvorlage"

Ein Aufruf des Befehls ohne den -q Parameter öffnet einen GUI Dialog. In einer Remote-Shell-Verbindung führt dies dazu, dass der Prozess stehen bleibt.

Schlägt die Zertifikatbeantragung mit Fehlercode „CERTSRV_E_UNSUPPORTED_CERT_TYPE“ fehl, siehe Artikel „La demande de certificat échoue avec le message d'erreur „The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)“.“„ .

Weitere mögliche Ursachen

Die Zertifikatanforderung wird gestellt, kommt auch an der Zertifizierungsstelle an, wird dort allerdings abgelehnt

Kommt die Zertifikatanforderung an der Zertifizierungsstelle an, wird dort allerdings abgelehnt, wird diese das Ereignis Nr. 53 protokollieren. Mögliche Ursachen und deren Lösung sind im entsprechenden Artikel beschrieben.

Protokollierungsebene für Autoenrollment auf dem Client erhöhen

Um ein Problem weiter einzugrenzen, kann es hilfreich sein, die Protokollierungsebene für Autoenrollment auf dem Client zu erhöhen (siehe hierzu auch Artikel „Activer la journalisation pour la demande automatique de certificat (auto-enrollment)„).

Mit folgendem Kommandozeilenbefehl kann die Protokollierung für den Benutzer- als auch den Systemkontext aktiviert werden (Es werden alle Ereignisse der Typen „Error“, „Warning“ und „Information“ ausgegeben):

certutil –setreg Enroll\LogLevel 4

Die Änderungen werden direkt ohne Neuanmeldung bzw. Neustart aktiv.

Anschließend kann eine Zertifikatbeantragung ausgelöst werden. Entsprechende Ereignisse sollten sich nun im Anwendungs-Ereignisprotokoll finden.

Aufbau einer üblichen Ereignis-Sequenz

Eine übliche Sequenz sieht wie folgt aus:

QuelleNummerTexte de l'événement
Microsoft-Windows-CertificateServicesClient-AutoEnrollment2Automatic certificate enrollment for %1 started.
Microsoft-Windows-CertificateServicesClient-AutoEnrollment4Automatic certificate enrollment for %1 invoked the enrollment API.
Microsoft-Windows-CertificateServicesClient1Certificate Services Client has been started successfully.
Microsoft-Windows-CertificateServicesClient3Certificate Services Client has detected network connectivity.
Microsoft-Windows-CertificateServicesClient-CertEnroll65Certificate enrollment for %1 is successfully authenticated by policy server %2 using authentication mechanism %5 (Credential: %4). Policy Id: %3
Microsoft-Windows-CertificateServicesClient-CertEnroll64Certificate enrollment for %1 successfully load policy from policy server %2
(ggfs. weitere)
Microsoft-Windows-CertificateServicesClient-AutoEnrollment5Automatic certificate enrollment for %1 returned from the enrollment API.
Microsoft-Windows-CertificateServicesClient-AutoEnrollment3Automatic certificate enrollment for %1 completed.
Microsoft-Windows-CertificateServicesClient2Certificate Services Client has been stopped.

Abfrage der Ereignisse

Mit folgendem Windows PowerShell Befehl können die Ereignisse ausgelesen werden:

Get-WinEvent -FilterHashtable @{
Logname='Application'
ProviderName=@('Microsoft-Windows-CertificateServicesClient-AutoEnrollment','Microsoft-Windows-CertificateServicesClient','Microsoft-Windows-CertificateServicesClient-CertEnroll')
StartTime=(Get-Date -Hour 0 -Minute 0 -Second 0)
} | Sort-Object -Property TimeCreated -Descending

Hierbei werden folgende Kriterien angewendet:

  • Quelle: Ereignisse der betreffenden drei Kategorien
  • Zeitraum: Die Ereignisse des heutigen Tages
  • Sortierung: Absteigend nach Datum

Ereignisse in eine Datei speichern

Die Ereignisse können auch einfach im CSV-Format abgespeichert werden, um die Analyse abseits des fehlerhaften Systems vorzunehmen:

... | Select-Object -Property TimeCreated,Id,LevelDisplayName,Message | Export-Csv -Path .\$($env:Computername)_ClientEvents.csv -Encoding Unicode -NoTypeInformation

Ein Export in eine .evt oder .evtx Datei ist nach Filterung nicht mehr möglich.

Liens complémentaires :

Sources externes

Les commentaires sont fermés.

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais