DiagnosticLog-Konfigurationsdienstanbieter
Die folgende Liste enthält die Knoten des DiagnosticLog-Konfigurationsdienstanbieters:
- ./Vendor/MSFT/DiagnosticLog
DeviceStateData
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/DeviceStateData
Stammknoten aller Arten von Gerätezustandsdaten, die von CSP verfügbar gemacht werden.
Die DeviceStateData-Funktion im DiagnosticLog-CSP stellt zusätzliche Geräteinformationen bereit.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
DeviceStateData/MdmConfiguration
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1607 [10.0.14393] und höher |
./Vendor/MSFT/DiagnosticLog/DeviceStateData/MdmConfiguration
Dieser Knoten soll das Andocken der Geräteverwaltung Zustandsdaten mit "SNAP" auslösen.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format |
chr (Zeichenfolge) |
Zugriffstyp | Exec, Get |
Beispiel:
<?xml version="1.0"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Exec>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/DiagnosticLog/DeviceStateData/MdmConfiguration</LocURI>
</Target>
<Meta>
<Format xmlns="syncml:metinf">chr</Format>
</Meta>
<Data>SNAP</Data>
</Item>
</Exec>
<Final/>
</SyncBody>
</SyncML>
DiagnosticArchive
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1903 [10.0.18362] und höher |
./Vendor/MSFT/DiagnosticLog/DiagnosticArchive
Stammknoten für Die Archivdefinition und -sammlung.
Die DiagnosticArchive-Funktion innerhalb des DiagnosticLog-CSP wird verwendet, um Geräte dazu zu veranlassen, Problembehandlungsdaten in einer ZIP-Archivdatei zu sammeln und dieses Archiv in den Cloudspeicher hochzuladen.
DiagnosticArchive ist für Ad-hoc-Problembehandlungsszenarien konzipiert, z. B. ein IT-Administrator, der einen App-Installationsfehler mithilfe einer Sammlung von Ereignisprotokollereignissen, Registrierungswerten und App- oder Betriebssystemprotokolldateien untersucht.
Hinweis
DiagnosticArchive ist eine "Break Glass"-Backstop-Option für die Problembehandlung von Geräten. Diagnosedaten wie Protokolldateien können auf viele Gigabyte anwachsen. Das Sammeln, Übertragen und Speichern großer Datenmengen kann das Gerät des Benutzers, das Netzwerk und den Cloudspeicher belasten. Verwaltungsserver, die DiagnosticArchive aufrufen, müssen darauf achten, die Häufigkeit und den Umfang der Datenerfassung zu minimieren.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
DiagnosticArchive/ArchiveDefinition
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1903 [10.0.18362] und höher |
./Vendor/MSFT/DiagnosticLog/DiagnosticArchive/ArchiveDefinition
Die Aktion "Ausführen" für diesen Knoten akzeptiert einen Collection
XML-Codeausschnitt (als Zeichenfolge), der beschreibt, welche Daten gesammelt und wohin sie hochgeladen werden sollen. Die Ergebnisse werden gezippt und in die angegebene SasUrl hochgeladen. Das Zip-Dateinamenformat ist DiagLogs-{ComputerName}-YYYYMMDDTHHMMSSZ.zip
.
Mit Windows 10 KB5011543 und Windows 11 KB5011563 gibt es zusätzliche Unterstützung für ein zusätzliches Element, das bestimmt, ob die vom CSP generierte Ausgabedatei eine vereinfachte Ordnerstruktur ist, anstatt einzelne Ordner für jede Anweisung im XML-Code zu haben. Das folgende Beispiel zeigt einen XML-Code Collection
:
<Collection>
<!--NOTE: The value shown here is an example only, for more information see the ID documentation which follows the example -->
<ID>f1e20cb4-9789-4f6b-8f6a-766989764c6d</ID>
<!--NOTE: The value shown here is an example only, for more information see the SasUrl documentation which follows the example -->
<SasUrl><![CDATA[https://myaccount.blob.core.windows.net/mycontainer?sp=aw&st=2020-07-01T23:02:07Z&se=2020-07-02T23:02:07Z&sv=2019-10-10&sr=c&sig=wx9%2FhwrczAI0nZL7zl%2BhfZVfOBvboTAnrGYfjlO%2FRFA%3D]]></SasUrl>
<RegistryKey>HKLM\Software\Policies</RegistryKey>
<FoldersFiles>%ProgramData%\Microsoft\DiagnosticLogCSP\Collectors\*.etl</FoldersFiles>
<Command>%windir%\system32\ipconfig.exe /all</Command>
<Command>%windir%\system32\mdmdiagnosticstool.exe -out %ProgramData%\temp\</Command>
<FoldersFiles>%ProgramData%\temp\*.*</FoldersFiles>
<Events>Application</Events>
<OutputFileFormat>Flattened</OutputFileFormat>
</Collection>
Der XML-Code sollte die folgenden Elemente im Collection
-Element enthalten:
- ID: Der ID-Wert identifiziert diese Datensammlungsanforderung eindeutig. Um eine versehentliche Wiederholung der Datensammlung zu vermeiden, ignoriert der CSP nachfolgende Set- oder Execute-Aufrufe mit demselben ID-Wert. Der CSP erwartet, dass der Wert beim Empfang der Anforderung aufgefüllt wird, sodass er vom IT-Administrator oder vom Verwaltungsserver generiert werden muss.
-
SasUrl: Der SasUrl-Wert ist der Ziel-URI, in den der CSP die ZIP-Datei mit den gesammelten Daten hochlädt. Es liegt in der Verantwortung des Verwaltungsservers, Speicher so bereitzustellen, dass der Speicherserver die HTTP-PUT-Adresse des Geräts an diese URL akzeptiert. Der Geräteverwaltungsdienst könnte beispielsweise:
- Bereitstellen von Cloudspeicher, der für das Zielgerät erreichbar ist, z. B. einen Microsoft Azure Blob Storage-Container
- Generieren einer Shared Access Signature-URL, die dem Besitzer (dem Zielgerät) zeitlich begrenzten Schreibzugriff auf den Speichercontainer gewährt
- Übergeben Sie diesen Wert über den XML-Code als Wert an den CSP auf dem
SasUrl
ZielgerätCollection
.
Darüber hinaus kann der XML-Code eine oder mehrere Datensammlungsdirektiven enthalten, die eine der folgenden Enthalten können:
RegistryKey: Exportiert alle Schlüsselnamen und -werte unter einem angegebenen Pfad (rekursiv).
- Erwarteter Eingabewert: Registrierungspfad wie "HKLM\Software\Policies".
- Ausgabeformat: Erstellt eine .reg-Datei, ähnlich der Ausgabe reg.exe EXPORT-Befehls.
- Datenschutzrichtlinien: Um die Erfassung von Diagnoseprotokollen zu aktivieren und gleichzeitig das Risiko zu verringern, dass ein IT-Administrator versehentlich vom Benutzer generierte Dokumente erfasst, sind Registrierungspfade auf die Pfade beschränkt, die unter HKLM und HKCR liegen.
Ereignisse: Exportiert alle Ereignisse aus dem benannten Windows-Ereignisprotokoll.
- Erwarteter Eingabewert: Ein benannter Ereignisprotokollkanal wie "Application" oder "Microsoft-Windows-DeviceGuard/Operational".
- Ausgabeformat: Erstellt eine EVTX-Datei.
Befehle: Dieser Direktiventyp ermöglicht die Ausführung bestimmter Befehle, z. B. ipconfig.exe. Beachten Sie, dass DiagnosticArchive und die Commands-Direktiven keine allgemeine Skriptplattform sind. Diese Befehle sind im DiagnosticArchive-Kontext zulässig, um Fälle zu behandeln, in denen wichtige Geräteinformationen möglicherweise nicht über vorhandene Protokolldateien verfügbar sind.
- Erwarteter Eingabewert: Die vollständige Befehlszeile einschließlich pfad und allen Argumenten, z
%windir%\\system32\\ipconfig.exe /all
. B. . - Ausgabeformat: Die Konsolentextausgabe des Befehls wird in einer Textdatei erfasst und im gesamten Ausgabearchiv enthalten. Bei Befehlen, die anstelle einer Konsolenausgabe eine Dateiausgabe generieren können, wird eine nachfolgende FolderFiles-Direktive verwendet, um diese Ausgabe zu erfassen. Im obigen XML-Beispiel wird dieses Muster mit dem Parameter -out von mdmdiagnosticstool.exe veranschaulicht.
- Datenschutzrichtlinien: Um die Erfassung von Diagnosedaten zu aktivieren und gleichzeitig das Risiko zu verringern, dass ein IT-Administrator versehentlich vom Benutzer generierte Dokumente erfasst, sind nur die folgenden Befehle zulässig:
- %windir%\system32\certutil.exe
- %windir%\system32\dxdiag.exe
- %windir%\system32\gpresult.exe
- %windir%\system32\msinfo32.exe
- %windir%\system32\netsh.exe
- %windir%\system32\nltest.exe
- %windir%\system32\ping.exe
- %windir%\system32\powercfg.exe
- %windir%\system32\w32tm.exe
- %windir%\system32\wpr.exe
- %windir%\system32\dsregcmd.exe
- %windir%\system32\dispdiag.exe
- %windir%\system32\ipconfig.exe
- %windir%\system32\logman.exe
- %windir%\system32\tracelog.exe
- %programfiles%\windows defender\mpcmdrun.exe
- %windir%\system32\MdmDiagnosticsTool.exe
- %windir%\system32\pnputil.exe
- Erwarteter Eingabewert: Die vollständige Befehlszeile einschließlich pfad und allen Argumenten, z
FoldersFiles: Erfasst Protokolldateien aus einem bestimmten Pfad (ohne Rekursion).
- Erwarteter Eingabewert: Dateipfad mit oder ohne Wildcards, z. B. "%windir%\System32" oder "%programfiles%\*.log".
- Datenschutzrichtlinien: Um die Erfassung von Diagnoseprotokollen zu aktivieren und gleichzeitig das Risiko zu verringern, dass ein IT-Administrator versehentlich benutzergenerierte Dokumente erfasst, sind nur Pfade unter den folgenden Stammdaten zulässig:
- %PROGRAMFILES%
- %PROGRAMDATA%
- %PUBLIC%
- %WINDIR%
- %TEMP%
- %TMP%
- Darüber hinaus werden nur Dateien mit den folgenden Erweiterungen erfasst:
- .Protokoll
- .txt
- .Dmp
- CAB
- .zip
- .xml
- .html
- .evtx
- .Etl
OutputFileFormat: Vereinfacht die Ordnerstruktur, anstatt einzelne Ordner für jede Anweisung im XML-Code zu verwenden.
- Der Wert "Flattened" ist der einzige unterstützte Wert für OutputFileFormat. Wenn das OutputFileFormat im XML-Code fehlt oder explizit auf etwas anderes als "Vereinfacht" festgelegt ist, wird die Dateistruktur in der alten Struktur beibehalten.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format |
chr (Zeichenfolge) |
Zugriffstyp | Exec, Get, Replace |
DiagnosticArchive/ArchiveResults
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1903 [10.0.18362] und höher |
./Vendor/MSFT/DiagnosticLog/DiagnosticArchive/ArchiveResults
Rufen Sie die Ergebnisse der letzten Archivausführung auf.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format |
chr (Zeichenfolge) |
Zugriffstyp | „Abrufen“ |
Beispiel:
Ein Get to the above URI gibt die Ergebnisse der Datensammlung für die letzte Diagnose Anforderung zurück. Zum Beispiel:
<SyncML>
<SyncHdr/>
<SyncBody>
<Status>
<CmdID>1</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>0</CmdRef>
<Cmd>SyncHdr</Cmd>
<Data>200</Data>
</Status>
<Status>
<CmdID>2</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>1</CmdRef>
<Cmd>Get</Cmd>
<Data>200</Data>
</Status>
<Results>
<CmdID>3</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>1</CmdRef>
<Item>
<Source>
<LocURI>./Vendor/MSFT/DiagnosticLog/DiagnosticArchive/ArchiveResults</LocURI>
</Source>
<Data>
<Collection HRESULT="0">
<ID>f1e20cb4-9789-4f6b-8f6a-766989764c6d</ID>
<RegistryKey HRESULT="0">HKLM\Software\Policies</RegistryKey>
<FoldersFiles HRESULT="0">C:\ProgramData\Microsoft\DiagnosticLogCSP\Collectors\*.etl</FoldersFiles>
<Command HRESULT="0">%windir%\system32\ipconfig.exe /all</Command>
<Command HRESULT="-2147024637">%windir%\system32\mdmdiagnosticstool.exe -out c:\ProgramData\temp\</Command>
<FoldersFiles HRESULT="0">c:\ProgramData\temp\*.*</FoldersFiles>
<Events HRESULT="0">Application</Events>
</Collection>
</Data>
</Item>
</Results>
<Final/>
</SyncBody>
</SyncML>
Informationen zum Lesen der resultierenden Daten finden Sie unter Überprüfen von ArchiveResults.
EtwLog
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog
Stammknoten aller Arten von Ereignisprotokollierungsknoten, die von CSP verwaltet werden.
Das ETW-Protokollfeature (Ereignisablaufverfolgung für Windows) des DiagnosticLog-CSP wird verwendet, um die folgenden Arten der Ereignisablaufverfolgung zu steuern:
Das ETW-Protokollfeature ist für die erweiterte Verwendung konzipiert und setzt voraus, dass Entwickler mit ETW vertraut sind. Weitere Informationen finden Sie unter Informationen zur Ereignisablaufverfolgung.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
EtwLog/Channels
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Channels
Stammknoten registrierter Kanalknoten.
Der Typ der Ereignisablaufverfolgung exportiert Ereignisdaten aus einem bestimmten Kanal. Benutzer können einen Kanalknoten mit dem vollständigen Namen hinzufügen oder löschen, z. B. Microsoft-Windows-AppModel-Runtime/Admin.
Der DiagnosticLog-CSP verwaltet eine Protokolldatei für jeden Kanalknoten, und die Protokolldatei wird überschrieben, wenn auf demselben Kanalknoten erneut ein Startbefehl ausgelöst wird.
Für jeden Kanalknoten hat der Benutzer folgende Möglichkeiten:
- Exportieren von Kanalereignisdaten in eine Protokolldatei (.evtx).
- Aktivieren oder deaktivieren Sie den Kanal des Ereignisprotokolldiensts, um das Schreiben von Ereignisdaten in den Kanal zuzulassen oder zu verbieten.
- Geben Sie eine XPath-Abfrage an, um Ereignisse beim Exportieren der Kanalereignisdaten zu filtern.
Weitere Informationen zur Verwendung von DiagnosticLog zum Remoteerfassung von Protokollen von einem PC oder mobilen Gerät finden Sie unter Sammeln von MDM-Protokollen.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
EtwLog/Channels/{ChannelName}
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Channels/{ChannelName}
Jeder dynamische Knoten stellt einen registrierten Kanalknoten dar. Der Knotenname muss ein gültiger Windows-Ereignisprotokollkanalname sein, z. B. "Microsoft-Client-Licensing-Platform%2FAdmin". Wenn Sie den Namen im LocURI angeben, muss er url-codiert sein, andernfalls wird er unerwartet in einen anderen URI übersetzt.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | Hinzufügen, Löschen, Abrufen |
Dynamische Knotenbenennung | UniqueName: Der Knotenname muss ein gültiger Windows-Ereignisprotokollkanalname sein, z. B. "Microsoft-Client-Licensing-Platform%2FAdmin" |
Beispiele:
Hinzufügen eines Kanals
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Add> <CmdID>1</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Channels/Microsoft-Client-Licensing-Platform%2FAdmin</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">node</Format> </Meta> </Item> </Add> <Final/> </SyncBody> </SyncML>
Löschen eines Kanals
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Delete> <CmdID>1</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Channels/Microsoft-Client-Licensing-Platform%2FAdmin</LocURI> </Target> </Item> </Delete> <Final/> </SyncBody> </SyncML>
EtwLog/Channels/{ChannelName}/Export
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Channels/{ChannelName}/Export
Dieser Knoten soll das Exportieren von Ereignissen in eine Protokolldatei aus dem zugeordneten Windows-Ereigniskanal dieses Knotens auslösen. Die Erweiterung der Protokolldatei ist .evtx, die Standarderweiterung des Windows-Ereigniskanalprotokolls. Der Befehl "Get" gibt den Namen dieses Knotens zurück.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | null |
Zugriffstyp | Exec, Get |
Beispiel:
<?xml version="1.0"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Exec>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Channels/Microsoft-Client-Licensing-Platform%2FAdmin/Export</LocURI>
</Target>
</Item>
</Exec>
<Final/>
</SyncBody>
</SyncML>
EtwLog/Channels/{ChannelName}/Filter
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Channels/{ChannelName}/Filter
Dieser Knoten wird zum Festlegen oder Abrufen der xpath-Abfragezeichenfolge verwendet, um die Ereignisse beim Exportieren der Protokolldatei aus dem Kanal zu filtern. Der Standardwert ist eine leere Zeichenfolge.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format |
chr (Zeichenfolge) |
Zugriffstyp | Abrufen, Ersetzen |
Standardwert | "" |
Beispiel:
<?xml version="1.0"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Get>
<CmdID>1</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Channels/Microsoft-Client-Licensing-Platform%2FAdmin/Filter</LocURI>
</Target>
</Item>
</Get>
<Final/>
</SyncBody>
</SyncML>
EtwLog/Channels/{ChannelName}/State
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Channels/{ChannelName}/State
Dieser Knoten wird zum Festlegen oder Abrufen des Status "Aktiviert" des zugeordneten Windows-Ereigniskanals dieses Knotens im System verwendet. Wenn sie auf "TRUE" festgelegt wird, wird der Kanal aktiviert. Wenn sie auf "FALSE" festgelegt wird, wird der Kanal deaktiviert.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | bool |
Zugriffstyp | Abrufen, Ersetzen |
Zulässige Werte:
Wert | Beschreibung |
---|---|
true | Kanal ist aktiviert. |
false | Kanal ist deaktiviert. |
Beispiele:
Kanalstatus abrufen:
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Get> <CmdID>1</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Channels/Microsoft-Client-Licensing-Platform%2FAdmin/State</LocURI> </Target> </Item> </Get> <Final/> </SyncBody> </SyncML>
Kanalstatus festlegen:
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Replace> <CmdID>2</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Channels/Microsoft-Client-Licensing-Platform%2FAdmin/State</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">bool</Format> </Meta> <Data>false</Data> </Item> </Replace> <Final/> </SyncBody> </SyncML>
EtwLog/Collectors
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors
Stammknoten registrierter "Collector"-Knoten.
Diese Art der Ereignisablaufverfolgung sammelt Ereignisdaten aus einer Sammlung registrierter ETW-Anbieter. Ein Ereignissammler ist ein Container registrierter ETW-Anbieter. Benutzer können einen Collectorknoten hinzufügen oder löschen und die Registrierung mehrerer Anbieter in diesem Collector registrieren oder aufheben.
Muss {CollectorName}
innerhalb des CSP eindeutig sein und darf kein gültiger Ereigniskanalname oder eine Anbieter-GUID sein.
Der DiagnosticLog-CSP verwaltet eine Protokolldatei für jeden Collectorknoten, und die Protokolldatei wird überschrieben, wenn auf demselben Collectorknoten erneut ein Startbefehl ausgelöst wird.
Für jeden Collectorknoten hat der Benutzer folgende Möglichkeiten:
- Starten oder beenden Sie die Sitzung mit allen registrierten und aktivierten Anbietern.
- Abfragesitzung status.
- Ändern des Protokolldateimodus der Ablaufverfolgung.
- Ändern der Größe von Protokolldateien der Ablaufverfolgung.
Die Konfigurationen für den Protokolldateimodus und die Größe der Protokolldateien werden nicht wirksam, während die Ablaufverfolgungssitzung ausgeführt wird. Diese Attribute werden angewendet, wenn der Benutzer die aktuelle Sitzung beendet und dann für diesen Collector erneut startet.
Für jeden registrierten Anbieter in diesem Collector hat der Benutzer folgende Möglichkeiten:
- Geben Sie Schlüsselwörter an, um Ereignisse von diesem Anbieter zu filtern.
- Ändern Sie die Ablaufverfolgungsebene, um Ereignisse von diesem Anbieter zu filtern.
- Aktivieren oder deaktivieren Sie den Anbieter in der Ablaufverfolgungssitzung.
Die Änderungen an State, Keywords und TraceLevel werden sofort wirksam, während die Ablaufverfolgungssitzung ausgeführt wird.
Hinweis
Microsoft-WindowsPhone-Enterprise-Diagnostics-Provider (GUID - 3da494e4-0fe2-415C-b895-fb5265c5c83b) verfügt über die erforderlichen Debugressourcendateien, die in Windows integriert sind, wodurch die Protokolldateien auf dem Remotecomputer decodiert werden können. Alle anderen Protokolle verfügen möglicherweise nicht über die Debugressourcen, die zum Decodieren erforderlich sind.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
Beispiel:
So erfassen Sie Diagnose mithilfe dieses CSP:
- Geben Sie einen CollectorName für den Container der ETW-Zielanbieter an.
- (Optional) Legen Sie Protokollierungs- und Protokolldateiparameter mithilfe der folgenden Optionen fest:
- Geben Sie einen oder mehrere ETW-Zielanbieter an, indem Sie dessen ProviderGUID für den Add-Vorgang von EtwLog/Collectors/CollectorName/Providers/ProviderGUID angeben.
- (Optional) Legen Sie Protokollierungs- und Protokolldateiparameter mithilfe der folgenden Optionen fest:
- Starten Sie die Protokollierung mit dem TraceControl EXECUTE-Befehl "START".
- Führen Sie Aktionen auf dem Zielgerät aus, die Aktivitäten in den Protokolldateien generieren.
- Beenden Sie die Protokollierung mit dem TraceControl EXECUTE-Befehl "STOP".
- Sammeln Sie die Protokolldatei, die
%temp%
sich im Ordner befindet, mithilfe der methode Lesen einer Protokolldatei , die unter DateiDownload beschrieben wird.
EtwLog/Collectors/{CollectorName}
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/{CollectorName}
Jeder dynamische Knoten stellt einen registrierten "Collector"-Knoten dar. CSP verwaltet eine ETW-Ablaufverfolgungssitzung für diesen Collector, dessen Name als eindeutiger Bezeichner verwendet wird. In einem Collector kann ein gültiger ETW-Anbieter registriert und die Registrierung aufgehoben werden. Die zugeordnete Ablaufverfolgungssitzung des Collectors aktiviert die darin registrierten Anbieter, wenn der Status des Anbieters "Aktiviert" lautet. Der Status, die Ablaufverfolgungsebene und die Schlüsselwörter jedes Anbieters können separat gesteuert werden. Der Name dieses Knotens darf kein gültiger Windows-Ereigniskanalname sein. Es kann sich um eine ETW-Anbieter-GUID handeln, solange sie nicht mit einem bereits registrierten Knotennamen "Provider" übereinstimmt.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | Hinzufügen, Löschen, Abrufen |
Dynamische Knotenbenennung | ServerGeneratedUniqueIdentifier |
Beispiele:
Hinzufügen eines Collectors
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Add> <CmdID>1</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/DeviceManagement</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">node</Format> </Meta> </Item> </Add> <Final/> </SyncBody> </SyncML>
Löschen eines Collectors
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Delete> <CmdID>1</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/DeviceManagement</LocURI> </Target> </Item> </Delete> <Final/> </SyncBody> </SyncML>
EtwLog/Collectors/{CollectorName}/LogFileSizeLimitMB
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/{CollectorName}/LogFileSizeLimitMB
Dieser Knoten wird zum Festlegen oder Abrufen der Größe der Ablaufverfolgungsprotokolldatei (in Megabyte) der zugeordneten Ablaufverfolgungssitzung dieses Collectorknotens verwendet. Der Wertbereich liegt zwischen 1 und 2048. Der Standardwert ist 4.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | int |
Zugriffstyp | Abrufen, Ersetzen |
Zulässige Werte | Bereich: [1-2048] |
Standardwert | 4 |
EtwLog/Collectors/{CollectorName}/Providers
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/{CollectorName}/Providers
Stammknoten aller Anbieter, die in diesem Collectorknoten registriert sind.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
EtwLog/Collectors/{CollectorName}/Providers/{ProviderGuid}
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/{CollectorName}/Providers/{ProviderGuid}
Jeder dynamische Knoten stellt einen ETW-Anbieter dar, der in diesem Collectorknoten registriert ist. Der Knotenname muss eine gültige Anbieter-GUID sein.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | Hinzufügen, Löschen, Abrufen |
Dynamische Knotenbenennung | UniqueName: Der Knotenname muss eine gültige Anbieter-GUID sein. |
Beispiele:
Hinzufügen eines Anbieters:
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Add> <CmdID>1</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/DeviceManagement/Providers/3da494e4-0fe2-415C-b895-fb5265c5c83b</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">node</Format> </Meta> </Item> </Add> <Final/> </SyncBody> </SyncML>
Löschen eines Anbieters:
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Delete> <CmdID>1</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/DeviceManagement/Providers/3da494e4-0fe2-415C-b895-fb5265c5c83b</LocURI> </Target> </Item> </Delete> <Final/> </SyncBody> </SyncML>
EtwLog/Collectors/{CollectorName}/Providers/{ProviderGuid}/Keywords
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/{CollectorName}/Providers/{ProviderGuid}/Keywords
Dieser Knoten wird zum Festlegen oder Abrufen der Schlüsselwörter des Ereignisanbieters in der zugeordneten Ablaufverfolgungssitzung dieses Collectorknotens verwendet. Die Zeichenfolge ist in Form von Hexadezimalziffern und 16 Zeichen breit. Es wird intern in den ULONGLONG-Datentyp im CSP konvertiert. Der Standardwert ist "0", was bedeutet, dass alle Ereignisse dieses Anbieters enthalten sind. Wenn die zugeordnete Ablaufverfolgungssitzung ausgeführt wird, wird die einstellung neue Schlüsselwörter sofort angewendet. Wenn dies nicht der Fall ist, wird sie beim nächsten Start dieser Sitzung angewendet.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format |
chr (Zeichenfolge) |
Zugriffstyp | Abrufen, Ersetzen |
Standardwert | "0" |
Beispiele:
Abrufen von Anbieterschlüsselwörtern:
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Get> <CmdID>1</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/DeviceManagement/Providers/3da494e4-0fe2-415C-b895-fb5265c5c83b/Keywords </LocURI> </Target> </Item> </Get> <Final/> </SyncBody> </SyncML>
Festlegen von Anbieterschlüsselwörtern:
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Replace> <CmdID>4</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/DeviceManagement/Providers/3da494e4-0fe2-415C-b895-fb5265c5c83b/Keywords </LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">chr</Format> <Type>text/plain</Type> </Meta> <Data>12345678FFFFFFFF</Data> </Item> </Replace> <Final/> </SyncBody> </SyncML>
EtwLog/Collectors/{CollectorName}/Providers/{ProviderGuid}/State
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/{CollectorName}/Providers/{ProviderGuid}/State
Dieser Knoten wird zum Festlegen oder Abrufen des Zustands des Ereignisanbieters in der zugeordneten Ablaufverfolgungssitzung dieses Collectorknotens verwendet. Wenn die Ablaufverfolgungssitzung nicht gestartet wird, steuert das Ändern des Werts, ob der Anbieter aktiviert werden soll oder nicht, wenn die Sitzung gestartet wird. Wenn die Ablaufverfolgungssitzung bereits gestartet wurde, führt eine Änderung des Werts dazu, dass der Anbieter in der Liveablaufverfolgungssitzung aktiviert oder deaktiviert wird. Der Standardwert ist true.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | bool |
Zugriffstyp | Abrufen, Ersetzen |
Standardwert | true |
Zulässige Werte:
Wert | Beschreibung |
---|---|
true (Standard) | Der Anbieter ist in der Ablaufverfolgungssitzung aktiviert. Dies ist die Standardeinstellung. |
false | Der Anbieter ist in der Ablaufverfolgungssitzung deaktiviert. |
Beispiel:
Anbieterstatus festlegen:
<?xml version="1.0"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/DeviceManagement/Providers/3da494e4-0fe2-415C-b895-fb5265c5c83b/State</LocURI>
</Target>
<Meta>
<Format xmlns="syncml:metinf">bool</Format>
</Meta>
<Data>false</Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
EtwLog/Collectors/{CollectorName}/Providers/{ProviderGuid}/TraceLevel
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/{CollectorName}/Providers/{ProviderGuid}/TraceLevel
Dieser Knoten wird zum Festlegen oder Abrufen der Ablaufverfolgungsebene dieses Ereignisanbieters in der zugeordneten Ablaufverfolgungssitzung dieses Collectorknotens verwendet. Der Standardwert ist 5, was TRACE_LEVEL_VERBOSE ist. Wenn die zugeordnete Ablaufverfolgungssitzung ausgeführt wird, wird sofort eine neue Einstellung auf Ablaufverfolgungsebene angewendet. Wenn dies nicht der Fall ist, wird sie beim nächsten Start dieser Sitzung angewendet.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | int |
Zugriffstyp | Abrufen, Ersetzen |
Standardwert | 5 |
Zulässige Werte:
Wert | Beschreibung |
---|---|
1 | TRACE_LEVEL_CRITICAL: Ungewöhnliche Beendigungs- oder Beendigungsereignisse. |
2 | TRACE_LEVEL_ERROR: Schwerwiegende Fehlerereignisse. |
3 | TRACE_LEVEL_WARNING: Warnungsereignisse wie Zuordnungsfehler. |
4 | TRACE_LEVEL_INFORMATION: Nicht-Fehlerereignisse, z. B. Ein- oder Ausstiegsereignisse. |
5 (Standard) | TRACE_LEVEL_VERBOSE : Ausführliche Informationen. |
Beispiel:
Festlegen des TraceLevel-Anbieters:
<?xml version="1.0"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/DeviceManagement/Providers/3da494e4-0fe2-415C-b895-fb5265c5c83b/TraceLevel</LocURI>
</Target>
<Meta>
<Format xmlns="syncml:metinf">int</Format>
</Meta>
<Data>1</Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
EtwLog/Collectors/{CollectorName}/TraceControl
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/{CollectorName}/TraceControl
Dieser Knoten soll "start" und "stop" der zugeordneten Ablaufverfolgungssitzung dieses Collectorknotens auslösen. "Get" gibt den Namen dieses Knotens zurück.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format |
chr (Zeichenfolge) |
Zugriffstyp | Exec, Get |
Zulässige Werte:
Wert | Beschreibung |
---|---|
Start | Protokollablaufverfolgung starten. |
BEENDEN | Beenden sie die Protokollablaufverfolgung. |
Beispiele:
Nachdem Sie eine Protokollierungsaufgabe hinzugefügt haben, können Sie eine Ablaufverfolgung starten/beenden, indem Sie einen Befehl Ausführen auf diesem Knoten ausführen.
Starten sie die Ablaufverfolgungsprotokollierung des Collectors:
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Exec> <CmdID>2</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/DeviceManagement/TraceControl</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">chr</Format> </Meta> <Data>START</Data> </Item> </Exec> <Final/> </SyncBody> </SyncML>
Beenden der Protokollierung der Collector-Ablaufverfolgung:
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Exec> <CmdID>2</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/DeviceManagement/TraceControl</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">chr</Format> </Meta> <Data>STOP</Data> </Item> </Exec> <Final/> </SyncBody> </SyncML>
EtwLog/Collectors/{CollectorName}/TraceLogFileMode
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/{CollectorName}/TraceLogFileMode
Dieser Knoten wird zum Festlegen oder Abrufen des Ablaufverfolgungsprotokolldateimodus der zugeordneten Ablaufverfolgungssitzung dieses Collectorknotens verwendet. Die einzigen beiden zulässigen Werte sind 1 und 2, die EVENT_TRACE_FILE_MODE_SEQUENTIAL und EVENT_TRACE_FILE_MODE_CIRCULAR sind. Der Standardwert ist 1.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | int |
Zugriffstyp | Abrufen, Ersetzen |
Standardwert | 1 |
Zulässige Werte:
Wert | Beschreibung |
---|---|
1 (Standard) | EVENT_TRACE_FILE_MODE_SEQUENTIAL-Writes Ereignisse sequenziell in eine Protokolldatei ein. Sie wird beendet, wenn die Datei ihre maximale Größe erreicht. |
2 | EVENT_TRACE_FILE_MODE_CIRCULAR-Writes Ereignisse in einer Protokolldatei. Nachdem die Datei die maximale Größe erreicht hat, werden die ältesten Ereignisse durch eingehende Ereignisse ersetzt. |
EtwLog/Collectors/{CollectorName}/TraceStatus
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/EtwLog/Collectors/{CollectorName}/TraceStatus
Dieser Knoten wird verwendet, um die status der zugeordneten Ablaufverfolgungssitzung dieses Collectorknotens zu erhalten. 1 bedeutet "in Bearbeitung"; 0 bedeutet "nicht gestartet oder beendet".
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | int |
Zugriffstyp | „Abrufen“ |
DateiHerunterladen
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/FileDownload
Stammknoten aller CSP-Knoten, die sich auf das Herunterladen der Protokolldatei in csp beziehen.
Das FileDownload-Feature des DiagnosticLog-CSP ermöglicht es einem Verwaltungsserver, Daten direkt vom Gerät zu pullen. Im FileDownload-Kontext werden die Client- und Serverrollen konzeptionell umgekehrt, wobei der Verwaltungsserver als Client fungiert, um die Daten vom verwalteten Gerät herunterzuladen.
Lesen einer Protokolldatei:
- Listen Sie die Protokolldatei unter ./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel auf.
- Wählen Sie im Ergebnis Enumeration eine Protokolldatei aus.
- Legen Sie blockSizeKB pro DM-Servernutzlasteinschränkung fest.
- Rufen Sie BlockCount ab, um die Gesamtanzahl der Leseanforderung zu bestimmen.
- Legen Sie BlockIndexToRead fest, um den Lesestartpunkt zu initialisieren.
- Rufen Sie BlockData für den Protokollblockupload ab.
- Erhöhen Sie BlockIndexToRead.
- Wiederholen Sie die Schritte 5 bis 7 bis BlockIndexToRead == (BlockIndexToRead – 1).
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
FileDownload/DMChannel
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel
Stammknoten aller CSP-Knoten, die zum Steuern des Dateidownloads für die zugehörige Protokolldatei verwendet werden, die durch die Protokollierung von CSP-Knoten generiert wird.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
FileDownload/DMChannel/{FileContext}
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/{FileContext}
Jeder dynamische Knoten stellt einen FileContext-Knoten dar, der einer Protokolldatei entspricht, die von einem der Protokollierungs-CSP-Knoten (unterhalb des Knotens "EtwLog") generiert wird. Der Knotenname muss der Name eines registrierten Knotens "Provider", "Collector" oder "Channel" sein. Die Protokolldatei und deren Speicherort werden vom CSP basierend auf dem Knotennamen bestimmt. Der Dateidownload erfolgt durch Unterteilen der Protokolldatei in mehrere Blöcke mit konfigurierter Blockgröße und anschließendes Senden der Blöcke, wie vom MDM-Server angefordert.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
Dynamische Knotenbenennung | UniqueName: Der Knotenname muss der Name eines registrierten Knotens "Provider", "Collector" oder "Channel" sein. |
FileDownload/DMChannel/{FileContext}/BlockCount
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/{FileContext}/BlockCount
Dieser Knoten wird verwendet, um die Gesamtzahl der Blöcke für die zugeordnete Protokolldatei zu erhalten. Wenn die Protokolldatei noch nicht generiert wurde, ist der zurückgegebene Wert -1; Wenn die Ablaufverfolgungssitzung ausgeführt wird, ist der zurückgegebene Wert -2.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | int |
Zugriffstyp | „Abrufen“ |
Beispiel:
<?xml version="1.0"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Get>
<CmdID>1</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/DeviceManagement/BlockCount</LocURI>
</Target>
</Item>
</Get>
<Final/>
</SyncBody>
</SyncML>
FileDownload/DMChannel/{FileContext}/BlockData
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/{FileContext}/BlockData
Dieser Knoten wird verwendet, um die Binärdaten des Blocks abzurufen, auf den der Knoten "BlockIndexToRead" verweist.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | b64 |
Zugriffstyp | „Abrufen“ |
Beispiel:
<?xml version="1.0"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Get>
<CmdID>1</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/DeviceManagement/BlockData</LocURI>
</Target>
</Item>
</Get>
<Final/>
</SyncBody>
</SyncML>
FileDownload/DMChannel/{FileContext}/BlockIndexToRead
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/{FileContext}/BlockIndexToRead
Dieser Knoten wird zum Festlegen und Abrufen des Blockindexes verwendet, der auf den Datenblock für den BlockData-Knoten verweist. Der Wertbereich ist 0~(BlockCount-1).
Beispiel:
Legen Sie BlockIndexToRead auf 0 fest:
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Replace> <CmdID>1</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/DeviceManagement/BlockIndexToRead</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">int</Format> </Meta> <Data>0</Data> </Item> </Replace> <Final/> </SyncBody> </SyncML>
Legen Sie BlockIndexToRead auf 1 fest:
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Replace> <CmdID>1</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/DeviceManagement/BlockIndexToRead</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">int</Format> </Meta> <Data>1</Data> </Item> </Replace> <Final/> </SyncBody> </SyncML>
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | int |
Zugriffstyp | Abrufen, Ersetzen |
FileDownload/DMChannel/{FileContext}/BlockSizeKB
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/{FileContext}/BlockSizeKB
Dieser Knoten wird zum Festlegen oder Abrufen der Blockgröße (in Kilobyte) für den Download der assoicierten Protokolldatei verwendet. Der Wertbereich ist 1 bis 16. Der Standardwert ist 4.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | int |
Zugriffstyp | Abrufen, Ersetzen |
Zulässige Werte | Bereich: [1-16] |
Standardwert | 4 |
Beispiele:
Legen Sie BlockSizeKB fest:
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Replace> <CmdID>1</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/DeviceManagement/BlockSizeKB</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">int</Format> </Meta> <Data>1</Data> </Item> </Replace> <Final/> </SyncBody> </SyncML>
Abrufen von BlockSizeKB:
<?xml version="1.0"?> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Get> <CmdID>1</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/DeviceManagement/BlockSizeKB</LocURI> </Target> </Item> </Get> <Final/> </SyncBody> </SyncML>
FileDownload/DMChannel/{FileContext}/DataBlocks
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/{FileContext}/DataBlocks
Stammknoten aller BlockNumber-Knoten für die zugeordnete Protokolldatei. Die Anzahl der untergeordneten Elemente sollte die Gesamtblockanzahl der Protokolldatei sein. Es sind keine untergeordneten Knoten vorhanden, wenn der Wert des Knotens "BlockCount" kleiner als 0 ist.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
FileDownload/DMChannel/{FileContext}/DataBlocks/{BlockNumber}
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1511 [10.0.10586] und höher |
./Vendor/MSFT/DiagnosticLog/FileDownload/DMChannel/{FileContext}/DataBlocks/{BlockNumber}
Jeder dynamische Knoten stellt einen BlockNumber-Knoten dar. Der Knotenname ist eine ganze Zahl, die dem Index des Blocks entspricht, für den dieser Knoten steht. Daher sollte der Knotenname zwischen 0 und (BlockCount -1) reichen. Er gibt die Binärdaten des Blocks zurück, auf den dieser Knoten verweist.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | b64 |
Zugriffstyp | „Abrufen“ |
Dynamische Knotenbenennung | ClientInventory |
Richtlinie
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1903 [10.0.18362] und höher |
./Vendor/MSFT/DiagnosticLog/Policy
Enthält eine Richtlinie für Diagnoseeinstellungen.
Dies kann verwendet werden, um Windows-Ereignisprotokollrichtlinien zu konfigurieren, z. B. die maximale Protokollgröße.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
Richtlinie/Kanäle
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1903 [10.0.18362] und höher |
./Vendor/MSFT/DiagnosticLog/Policy/Channels
Enthält die Richtlinie für Ereignisprotokollkanaleinstellungen.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | „Abrufen“ |
Richtlinie/Kanäle/{ChannelName}
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1903 [10.0.18362] und höher |
./Vendor/MSFT/DiagnosticLog/Policy/Channels/{ChannelName}
Jeder dynamische Knoten stellt einen registrierten Kanalknoten dar. Der Knotenname muss ein gültiger Windows-Ereignisprotokollkanalname sein, z. B. "Microsoft-Client-Licensing-Platform%2FAdmin". Wenn Sie den Namen im LocURI angeben, muss er url-codiert sein, andernfalls wird er unerwartet in einen anderen URI übersetzt.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | node |
Zugriffstyp | Hinzufügen, Löschen, Abrufen |
Dynamische Knotenbenennung | UniqueName: Der Knotenname muss ein gültiger Windows-Ereignisprotokollkanalname sein, z. B. Microsoft-Client-Licensing-Platform%2FAdmin. Wenn Sie den Namen im LocURI angeben, muss er URL-codiert sein. Andernfalls kann er unerwartet in einen anderen URI übersetzt werden. |
Beispiele:
Kanal hinzufügen
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Add> <CmdID>2</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName </LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">node</Format> <Type></Type> </Meta> </Item> </Add> <Final/> </SyncBody> </SyncML>
Kanal löschen
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Delete> <CmdID>3</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName </LocURI> </Target> </Item> </Delete> <Final/> </SyncBody> </SyncML>
Kanal abrufen
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Get> <CmdID>4</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName </LocURI> </Target> </Item> </Get> <Final/> </SyncBody> </SyncML>
Policy/Channels/{ChannelName}/ActionWhenFull
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1903 [10.0.18362] und höher |
./Vendor/MSFT/DiagnosticLog/Policy/Channels/{ChannelName}/ActionWhenFull
Aktion, die ausgeführt werden soll, wenn die Protokolldatei die maximale Größe erreicht. "Truncate", "Overwrite", "Archive".
Wenn Sie diese Richtlinieneinstellung deaktivieren oder nicht konfigurieren, wird der lokal konfigurierte Wert als Standard verwendet. Jeder installierte Kanal, egal ob posteingang oder von ISVs, ist für die Definition seiner eigenen lokalen Konfiguration verantwortlich, und diese Konfiguration kann von jedem Administrator geändert werden. Werte, die über diese Richtlinie festgelegt werden, überschreiben, ersetzen jedoch nicht die lokale Konfiguration.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format |
chr (Zeichenfolge) |
Zugriffstyp | Hinzufügen, Löschen, Abrufen, Ersetzen |
Zulässige Werte:
Wert | Beschreibung |
---|---|
Abschneiden | Wenn die Protokolldatei die maximale Dateigröße erreicht, werden keine neuen Ereignisse in das Protokoll geschrieben und gehen verloren. |
Überschreiben | Wenn die Protokolldatei die maximale Dateigröße erreicht, überschreiben neue Ereignisse alte Ereignisse. |
Archiv | Wenn die Protokolldatei ihre maximale Größe erreicht, wird die Protokolldatei an dem Speicherort gespeichert, der durch die Richtlinieneinstellung "Archivspeicherort" angegeben wird. Wenn der Wert des Archivspeicherorts nicht festgelegt ist, wird die neue Datei im selben Verzeichnis wie die aktuelle Protokolldatei gespeichert. |
Beispiele:
Aktion hinzufügenWhenFull hinzufügen
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Add> <CmdID>14</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/ActionWhenFull </LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">chr</Format> <Type>text/plain</Type> </Meta> <Data>Archive</Data> </Item> </Add> <Final/> </SyncBody> </SyncML>
Delete ActionWhenFull
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Delete> <CmdID>15</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/ActionWhenFull </LocURI> </Target> </Item> </Delete> <Final/> </SyncBody> </SyncML>
Get ActionWhenFull
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Get> <CmdID>13</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/ActionWhenFull </LocURI> </Target> </Item> </Get> <Final/> </SyncBody> </SyncML>
Aktion ersetzenWhenFull
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Replace> <CmdID>16</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/ActionWhenFull </LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">chr</Format> <Type>text/plain</Type> </Meta> <Data>Truncate</Data> </Item> </Replace> <Final/> </SyncBody> </SyncML>
Richtlinie/Channels/{ChannelName}/Enabled
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1903 [10.0.18362] und höher |
./Vendor/MSFT/DiagnosticLog/Policy/Channels/{ChannelName}/Enabled
Diese Richtlinieneinstellung gibt an, ob der Kanal aktiviert oder deaktiviert werden soll. Legen Sie den Wert auf TRUE fest, um zu aktivieren und AUF FALSE zu deaktivieren.
Wenn Sie diese Richtlinieneinstellung deaktivieren oder nicht konfigurieren, wird der lokal konfigurierte Wert als Standard verwendet.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | bool |
Zugriffstyp | Hinzufügen, Löschen, Abrufen, Ersetzen |
Zulässige Werte:
Wert | Beschreibung |
---|---|
true | Aktiviert den Kanal. |
false | Deaktiviert den Kanal. |
Beispiele:
Hinzufügen aktiviert
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Add> <CmdID>18</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/Enabled </LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">bool</Format> <Type>text/plain</Type> </Meta> <Data>TRUE</Data> </Item> </Add> <Final/> </SyncBody> </SyncML>
Delete Enabled
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Delete> <CmdID>19</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/Enabled </LocURI> </Target> </Item> </Delete> <Final/> </SyncBody> </SyncML>
Get Enabled
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Get> <CmdID>17</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/Enabled </LocURI> </Target> </Item> </Get> <Final/> </SyncBody> </SyncML>
Ersetzen aktiviert
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Replace> <CmdID>20</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/Enabled </LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">bool</Format> <Type>text/plain</Type> </Meta> <Data>FALSE</Data> </Item> </Replace> <Final/> </SyncBody> </SyncML>
Policy/Channels/{ChannelName}/MaximumFileSize
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1903 [10.0.18362] und höher |
./Vendor/MSFT/DiagnosticLog/Policy/Channels/{ChannelName}/MaximumFileSize
Maximale Größe der Kanalprotokolldatei in MB.
- Wenn Sie diese Richtlinieneinstellung aktivieren, können Sie die maximale Protokolldateigröße auf 1 Megabyte bis 2 Terabyte in Megabyte-Schritten konfigurieren.
- Wenn Sie diese Richtlinieneinstellung deaktivieren oder nicht konfigurieren, wird die maximale Größe der Protokolldatei auf den lokal konfigurierten Wert festgelegt. Dieser Wert kann vom lokalen Administrator mithilfe des Dialogfelds Protokolleigenschaften geändert werden und ist standardmäßig auf 1 Megabyte festgelegt.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format | int |
Zugriffstyp | Hinzufügen, Löschen, Abrufen, Ersetzen |
Zulässige Werte | Bereich: [1-2000000] |
Standardwert | 1 |
Beispiele:
Hinzufügen von MaximumFileSize
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Add> <CmdID>6</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/MaximumFileSize </LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">int</Format> <Type>text/plain</Type> </Meta> <Data>3</Data> </Item> </Add> <Final/> </SyncBody> </SyncML>
MaximumFileSize löschen
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Delete> <CmdID>7</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/MaximumFileSize </LocURI> </Target> </Item> </Delete> <Final/> </SyncBody> </SyncML>
Abrufen von MaximumFileSize
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Get> <CmdID>5</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/MaximumFileSize </LocURI> </Target> </Item> </Get> <Final/> </SyncBody> </SyncML>
Ersetzen von MaximumFileSize
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Replace> <CmdID>8</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/MaximumFileSize </LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">int</Format> <Type>text/plain</Type> </Meta> <Data>5</Data> </Item> </Replace> <Final/> </SyncBody> </SyncML>
Richtlinie/Kanäle/{ChannelName}/SDDL
Bereich | Editionen | Anwendbares Betriebssystem |
---|---|---|
✅ Gerät ❌ Benutzer |
✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC |
✅Windows 10, Version 1903 [10.0.18362] und höher |
./Vendor/MSFT/DiagnosticLog/Policy/Channels/{ChannelName}/SDDL
SDDL-Zeichenfolge, die den Zugriff auf den Kanal steuert. Weitere Informationen finden Sie unter Komplexer ChannelType-Typ.
Eigenschaften des Beschreibungsframeworks:
Eigenschaftenname | Eigenschaftenwert |
---|---|
Format |
chr (Zeichenfolge) |
Zugriffstyp | Hinzufügen, Löschen, Abrufen, Ersetzen |
Groß-/Kleinschreibung beachten | Wahr |
Beispiele:
Hinzufügen von SDDL
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Add> <CmdID>10</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/SDDL </LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">chr</Format> <Type>text/plain</Type> </Meta> <Data>YourSDDL</Data> </Item> </Add> <Final/> </SyncBody> </SyncML>
SDDL löschen
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Delete> <CmdID>11</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/SDDL </LocURI> </Target> </Item> </Delete> <Final/> </SyncBody> </SyncML>
SDDL abrufen
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Get> <CmdID>9</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/SDDL </LocURI> </Target> </Item> </Get> <Final/> </SyncBody> </SyncML>
Ersetzen von SDDL
<SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Replace> <CmdID>12</CmdID> <Item> <Target> <LocURI> ./Vendor/MSFT/DiagnosticLog/Policy/Channels/ChannelName/SDDL </LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">chr</Format> <Type>text/plain</Type> </Meta> <Data>YourNewSDDL</Data> </Item> </Replace> <Final/> </SyncBody> </SyncML>
Vergleich von FileDownload und DiagnosticArchive
Sowohl die Features FileDownload als auch DiagnosticArchive können verwendet werden, um Daten vom Gerät an den Verwaltungsserver zu übertragen, sie sind jedoch für verschiedene Workflows optimiert.
- FileDownload ermöglicht es dem Verwaltungsserver, Ablaufverfolgungsdaten auf Byteebene direkt vom verwalteten Gerät zu pullen. Die Datenübertragung erfolgt über den vorhandenen OMA-DM/SyncML-Kontext. Es wird zusammen mit dem EtwLogs-Feature als Teil eines erweiterten Überwachungs- oder Diagnoseflows verwendet. FileDownlod erfordert eine präzise Orchestrierung durch den Verwaltungsserver, vermeidet jedoch dedizierten Cloudspeicher.
- DiagnosticArchive ermöglicht es dem Verwaltungsserver, dem CSP einen vollständigen Satz von Anweisungen als einzelner Befehl zu erteilen. Basierend auf diesen Anweisungen orchestriert der CSP die clientseitige Arbeit, um die angeforderten Diagnosedateien in ein ZIP-Archiv zu packen und dieses Archiv in den Cloudspeicher hochzuladen. Die Datenübertragung erfolgt außerhalb der OMA-DM-Sitzung über einen HTTP-PUT.
Überprüfen von ArchiveResults
Das ZIP-Archiv, das von ArchiveResults erstellt und hochgeladen wird, enthält eine Ordnerstruktur wie im folgenden Beispiel:
PS C:\> dir C:\DiagArchiveExamples\DiagLogs-MYDEVICE-20201202T182748Z
Directory: C:\DiagArchiveExamples\DiagLogs-MYDEVICE-20201202T182748Z
Mode LastWriteTime Length Name
---- ------------- ------ ----
la--- 1/4/2021 2:45 PM 1
la--- 1/4/2021 2:45 PM 2
la--- 12/2/2020 6:27 PM 2701 results.xml
Jede Datensammlungsdirektive aus dem ursprünglichen Collection
XML-Code entspricht einem Ordner in der Ausgabe. Die erste Direktive lautete beispielsweise:
<Collection HRESULT="0">
<RegistryKey HRESULT="0">HKLM\Software\Policies</RegistryKey>
</Collection>
Anschließend enthält der Ordner 1
die entsprechende export.reg
Datei.
Die results.xml
Datei ist die autoritative Zuordnung zur Ausgabe. Sie enthält einen status Code für jede Direktive. Die Reihenfolge der Direktiven in der Datei entspricht der Reihenfolge der Ausgabeordner. Mithilfe results.xml
des Administrators können Sie sehen, welche Daten gesammelt wurden, welche Fehler möglicherweise aufgetreten sind und welche Ordner welche Ausgabe enthalten. Der folgende results.xml
Inhalt gibt beispielsweise an, dass der Registrierungsexport von HKLM\Software\Policies erfolgreich war und die Daten im Ordner 1
zu finden sind. Es gibt auch an, dass der netsh.exe wlan show profiles
Befehl fehlgeschlagen ist.
<Collection HRESULT="0">
<ID>268b3056-8c15-47c6-a1bd-4bc257aef7b2</ID>
<RegistryKey HRESULT="0">HKLM\Software\Policies</RegistryKey>
<Command HRESULT="-2147024895">%windir%\system32\netsh.exe wlan show profiles</Command>
</Collection>
Administratoren können die Automatisierung auf "results.xml" anwenden, um ihre eigenen bevorzugten Ansichten der Daten zu erstellen. Der folgende PowerShell-Einzeiler extrahiert beispielsweise aus dem XML eine sortierte Liste der Direktiven mit status Code und Details.
Select-XML -Path results.xml -XPath '//RegistryKey | //Command | //Events | //FoldersFiles' | Foreach-Object -Begin {$i=1} -Process { [pscustomobject]@{DirectiveNumber=$i; DirectiveHRESULT=$_.Node.HRESULT; DirectiveInput=$_.Node.('#text')} ; $i++}
In diesem Beispiel wird eine Ausgabe ähnlich der folgenden generiert:
DirectiveNumber DirectiveHRESULT DirectiveInput
--------------- ---------------- --------------
1 0 HKLM\Software\Policies
2 0 HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
3 0 HKLM\Software\Microsoft\IntuneManagementExtension
4 0 HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
5 0 %windir%\system32\ipconfig.exe /all
6 0 %windir%\system32\netsh.exe advfirewall show allprofiles
7 0 %windir%\system32\netsh.exe advfirewall show global
8 -2147024895 %windir%\system32\netsh.exe wlan show profiles
Im nächsten Beispiel wird das ZIP-Archiv in eine angepasste vereinfachte Dateistruktur extrahiert. Jeder Dateiname enthält die Direktivennummer, HRESULT usw. Dieses Beispiel könnte angepasst werden, um unterschiedliche Entscheidungen darüber zu treffen, welche Informationen in die Dateinamen eingeschlossen werden sollen und welche Formatierungsoptionen für Sonderzeichen zu treffen sind.
param( $DiagnosticArchiveZipPath = "C:\DiagArchiveExamples\DiagLogs-MYDEVICE-20201202T182748Z.zip" )
#region Formatting Choices
$flatFileNameTemplate = '({0:D2}) ({3}) (0x{2:X8})'
$maxLengthForInputTextPassedToOutput = 80
#endregion
#region Create Output Folders and Expand Zip
$diagnosticArchiveTempUnzippedPath = $DiagnosticArchiveZipPath + "_expanded"
if(-not (Test-Path $diagnosticArchiveTempUnzippedPath)){mkdir $diagnosticArchiveTempUnzippedPath}
$reformattedArchivePath = $DiagnosticArchiveZipPath + "_formatted"
if(-not (Test-Path $reformattedArchivePath)){mkdir $reformattedArchivePath}
Expand-Archive -Path $DiagnosticArchiveZipPath -DestinationPath $diagnosticArchiveTempUnzippedPath
#endregion
#region Discover and Move/rename Files
$resultElements = ([xml](Get-Content -Path (Join-Path -Path $diagnosticArchiveTempUnzippedPath -ChildPath "results.xml"))).Collection.ChildNodes | Foreach-Object{ $_ }
$n = 0
foreach( $element in $resultElements )
{
$directiveNumber = $n
$n++
if($element.Name -eq 'ID'){ continue }
$directiveType = $element.Name
$directiveStatus = [int]$element.Attributes.ItemOf('HRESULT').psbase.Value
$directiveUserInputRaw = $element.InnerText
$directiveUserInputFileNameCompatible = $directiveUserInputRaw -replace '[\\|/\[\]<>\:"\?\*%\.\s]','_'
$directiveUserInputTrimmed = $directiveUserInputFileNameCompatible.substring(0, [System.Math]::Min($maxLengthForInputTextPassedToOutput, $directiveUserInputFileNameCompatible.Length))
$directiveSummaryString = $flatFileNameTemplate -f $directiveNumber,$directiveType,$directiveStatus,$directiveUserInputTrimmed
$directiveOutputFolder = Join-Path -Path $diagnosticArchiveTempUnzippedPath -ChildPath $directiveNumber
$directiveOutputFiles = Get-ChildItem -Path $directiveOutputFolder -File
foreach( $file in $directiveOutputFiles)
{
$leafSummaryString = $directiveSummaryString,$file.Name -join ' '
Copy-Item $file.FullName -Destination (Join-Path -Path $reformattedArchivePath -ChildPath $leafSummaryString)
}
}
#endregion
Remove-Item -Path $diagnosticArchiveTempUnzippedPath -Force -Recurse
Dieses Beispielskript erzeugt eine Reihe von Dateien, die dem folgenden Satz von Dateien ähneln. Dies kann eine nützliche Ansicht für einen Administrator sein, der interaktiv die Ergebnisse durchsucht, ohne in Unterordnern navigieren oder wiederholt darauf verweisen zu results.xml
müssen:
PS C:\> dir C:\DiagArchiveExamples\DiagLogs-MYDEVICE-20201202T182748Z.zip_formatted | format-table Length,Name
Length Name
------ ----
46640 (01) (HKLM_Software_Policies) (0x00000000) export.reg
203792 (02) (HKLM_Software_Microsoft_Windows_CurrentVersion_Uninstall) (0x00000000) export.reg
214902 (03) (HKLM_Software_Microsoft_IntuneManagementExtension) (0x00000000) export.reg
212278 (04) (HKLM_SOFTWARE_WOW6432Node_Microsoft_Windows_CurrentVersion_Uninstall) (0x00000000) export.reg
2400 (05) (_windir__system32_ipconfig_exe__all) (0x00000000) output.log
2147 (06) (_windir__system32_netsh_exe_advfirewall_show_allprofiles) (0x00000000) output.log
1043 (07) (_windir__system32_netsh_exe_advfirewall_show_global) (0x00000000) output.log
59 (08) (_windir__system32_netsh_exe_wlan_show_profiles) (0x80070001) output.log
1591 (09) (_windir__system32_ping_exe_-n_50_localhost) (0x00000000) output.log
5192 (10) (_windir__system32_Dsregcmd_exe__status) (0x00000000) output.log