Kapitel 2: Bestandsaufnahme — Wo steht Ihre Flotte?

Jede Härtungsmaßnahme der folgenden Kapitel setzt voraus, dass Sie wissen, wo Ihre Flotte heute steht. „Wir setzen BitLocker ein" und „99 % unserer Geräte sind BitLocker-verschlüsselt mit Pre-Boot-PIN, UEFI CA 2023 und aktuellem DBX-Stand" sind zwei vollkommen unterschiedliche Aussagen, und nur die zweite erlaubt eine belastbare Risikoaussage. Dieses Kapitel liefert die Inventarschemata und die konkreten PowerShell- und Intune-Bausteine, mit denen Sie diese zweite Aussage herbeiführen.

In der Praxis stoßen Inventur-Skripte häufig auf zwei Probleme: Geräte sind offline, wenn das Skript laufen soll, und nicht jede Datenquelle ist über jeden Verwaltungsweg gleich gut erreichbar. Wir adressieren beides — über einen Mix aus Intune-Reporting, Custom Compliance Discovery und einem PowerShell-Modul, das auch in ConfigMgr- oder reinen AD-Umgebungen läuft.

Welche Daten Sie pro Gerät brauchen

Die folgenden Datenpunkte bilden das Minimal-Inventar, das wir in Assessments für die Risikobewertung erheben. Ohne diese Werte können Sie weder die Pilotgruppe für Kapitel 3 sinnvoll bilden noch im Compliance-Bericht aus Kapitel 6 belastbar berichten.

Wir empfehlen, diese Daten in einer einzigen Tabelle pro Gerät zu konsolidieren — ob in Intune-Reports, Power BI oder einem ConfigMgr-Datawarehouse ist sekundär. Wichtig ist, dass Sie sich später durch eine Geräteliste filtern lassen wie „Notebooks, TPM 2.0, BitLocker TPM-only, UEFICA2023Status = nicht migriert, Recovery-Key nicht in Entra escrowt" — die genaue Pilotgruppe für Kapitel 3 und 4.

PowerShell für die Flottenabfrage

Der folgende Schnipsel deckt die zentralen lokalen Datenpunkte ab und ist als Baustein für ein Intune-Proactive-Remediation- oder ein ConfigMgr-CI-Skript gedacht. Er gibt eine CSV-Zeile pro Gerät aus, die anschließend zentral aggregiert werden kann.

# Boot-Chain-Inventar je Gerät — Output als PSObject (CSV-tauglich)
$systemDrive = $env:SystemDrive
$bl = Get-BitLockerVolume -MountPoint $systemDrive
$keyProtectors = ($bl.KeyProtector | ForEach-Object { $_.KeyProtectorType }) -join ";"
 
$secureBoot = try { Confirm-SecureBootUEFI } catch { $false }
 
$tpm = Get-Tpm
$tpmVersion = (Get-CimInstance -Namespace "Root\CIMV2\Security\MicrosoftTpm" `
    -ClassName Win32_Tpm).SpecVersion
 
$servicingPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing"
$capable   = (Get-ItemProperty -Path $servicingPath -Name WindowsUEFICA2023Capable `
    -ErrorAction SilentlyContinue).WindowsUEFICA2023Capable
$caStatus  = (Get-ItemProperty -Path $servicingPath -Name UEFICA2023Status `
    -ErrorAction SilentlyContinue).UEFICA2023Status
$available = (Get-ItemProperty -Path "$servicingPath\CurrentBoot" `
    -Name AvailableUpdates -ErrorAction SilentlyContinue).AvailableUpdates
 
$bios = Get-CimInstance Win32_BIOS
$cs   = Get-CimInstance Win32_ComputerSystem
 
[PSCustomObject]@{
    HostName              = $env:COMPUTERNAME
    OSBuild               = (Get-ComputerInfo).OsBuildNumber
    Manufacturer          = $cs.Manufacturer
    Model                 = $cs.Model
    FirmwareVersion       = $bios.SMBIOSBIOSVersion
    SecureBoot            = $secureBoot
    TpmVersion            = $tpmVersion
    TpmReady              = $tpm.TpmReady
    BitLockerVolumeStatus = $bl.VolumeStatus
    KeyProtectors         = $keyProtectors
    EncryptionPercentage  = $bl.EncryptionPercentage
    UEFICA2023Capable     = $capable
    UEFICA2023Status      = "0x{0:X}" -f [int]$caStatus
    AvailableUpdates      = "0x{0:X}" -f [int]$available
} | Export-Csv -Path "C:\ProgramData\itx2\boot-inventory.csv" -NoTypeInformation -Append

Der Skript-Ausgabepfad ist bewusst flach gehalten; in der Praxis schreiben wir die CSV in den Intune-Management-Extension-Output oder direkt in einen Log-Analytics-Workspace. Wer ConfigMgr nutzt, kann das Skript als CI-Discovery-Skript einbinden und den Output über Hardware Inventory einsammeln. Für reine AD-Umgebungen ohne Endpoint-Management funktioniert das Skript auch über Invoke-Command gegen Get-ADComputer-Listen, allerdings ohne den Komfort der Online-Bereinigung.

Der KeyProtectors-Wert ist der entscheidende Filter: Geräte, deren Liste keine Pin enthält, laufen im TPM-only-Modus (oder TPM+ExternalKey ohne PIN) und stehen in Kapitel 4 ganz oben auf der Rollout-Liste. Eine typische TPM-only-Zeile hat KeyProtectors = "Tpm;RecoveryPassword", während ein vollständig gehärtetes Gerät Tpm;TpmPin;RecoveryPassword zeigt.

Registry-Datenpunkte interpretieren

Microsoft dokumentiert den UEFI-CA-2023-Rollout über Registry-Werte unterhalb von HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing. Drei Werte sind operativ relevant:

• WindowsUEFICA2023Capable zeigt, ob das Gerät die Migration grundsätzlich technisch kann (kompatible Firmware, ausreichend Platz im NV-Store). Geräte, die hier 0 zurückgeben, brauchen in der Regel ein OEM-Firmware-Update, bevor sie überhaupt migriert werden können.
• UEFICA2023Status enthält den aktuellen Migrationsstand als Bitmask. 0x4000 steht für „vollständig migriert" (Boot Manager mit neuem Zertifikat signiert, KEK/DB aktualisiert). Werte dazwischen markieren teilweise abgeschlossene Schritte.
• AvailableUpdates unter …\Servicing\CurrentBoot ist der Hebel, mit dem Sie Microsoft mitteilen, welche Migrationsschritte ausgerollt werden sollen. Details dazu folgen in Kapitel 3.

Beim Auslesen sollten Sie die Hex-Darstellung beibehalten — die Bitmask ist nur in dieser Form sinnvoll lesbar. Sie können sich bei Bedarf eine kleine Tabelle anlegen, die die Bits in Klartext übersetzt, etwa „Bit 0x0040 = KEK 2023 hinzugefügt", „Bit 0x4000 = Boot Manager 2023 aktiv".

Intune Custom Compliance Discovery

Für eine reine Intune-Flotte ist Custom Compliance der pragmatischste Weg, das Inventar in den Compliance-Bericht zu heben. Sie erstellen ein PowerShell-Discovery-Skript, das die relevanten Werte ausgibt, und eine JSON-Policy, die Schwellwerte definiert.

# Custom-Compliance-Discovery — nur JSON auf STDOUT, keine sonstige Ausgabe
$bl = Get-BitLockerVolume -MountPoint $env:SystemDrive
$hasPin = $bl.KeyProtector.KeyProtectorType -contains "TpmPin"
$secureBoot = try { Confirm-SecureBootUEFI } catch { $false }
$caStatus = (Get-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" `
    -Name UEFICA2023Status -ErrorAction SilentlyContinue).UEFICA2023Status
 
$result = @{
    BitLockerPinActive = [bool]$hasPin
    SecureBootActive   = [bool]$secureBoot
    UEFICA2023Status   = [int]$caStatus
} | ConvertTo-Json -Compress
 
Write-Output $result

Die zugehörige JSON-Compliance-Definition prüft die drei Werte gegen die Soll-Werte. Ein einfaches Schema für die Regel „PIN aktiv und Secure Boot aktiv und UEFI CA 2023 vollständig migriert" sieht so aus:

{
  "Rules": [
    {
      "SettingName": "BitLockerPinActive",
      "Operator": "IsEquals",
      "DataType": "Boolean",
      "Operand": true,
      "MoreInfoUrl": "https://intranet/leitfaden/boot-chain"
    },
    {
      "SettingName": "SecureBootActive",
      "Operator": "IsEquals",
      "DataType": "Boolean",
      "Operand": true
    },
    {
      "SettingName": "UEFICA2023Status",
      "Operator": "GreaterEquals",
      "DataType": "Int64",
      "Operand": 16384
    }
  ]
}

16384 ist die Dezimalentsprechung von 0x4000 — der Schwellwert, ab dem ein Gerät als vollständig migriert gilt. Custom Compliance setzt das Gerät bei Verstoß auf „non-compliant" und ist über Conditional Access mit der Bedingung „Require device to be marked as compliant" verknüpfbar (Details dazu in Kapitel 6).

Segmentierung nach Risikoklasse

Nicht jedes Gerät trägt dasselbe Risiko, und nicht jede Härtungsmaßnahme passt zu jedem Gerätetyp. Wir segmentieren das Inventar nach sechs Klassen, die jeweils eigene Anforderungen mitbringen.

Tier-0-Server sind der heikelste Fall: Pre-Boot-PIN ist hier nicht praktikabel, weil sie einen menschlichen Faktor in den Reboot-Pfad einbringt. Die Härtung läuft daher über andere Mechanismen — physische Zugangskontrolle zum Rechenzentrum, dedizierter Recovery-Key-Workflow, Defender Device Health Attestation. Notebooks am anderen Ende der Skala sind der Hauptanwendungsfall der Pre-Boot-PIN, weil sie die einzige Geräteklasse sind, die regelmäßig physisch verloren geht.

OT-Geräte fordern in der Regel einen unbeaufsichtigten Reboot-Pfad. Hier ist der pragmatische Standard TPM+USB-Startup-Key oder TPM+Network-Unlock (mit signiertem WDS-Server in einem getrennten Boot-VLAN), nicht Pre-Boot-PIN.

Dokumentation und Übergabe

Der Output dieses Kapitels ist nicht „ein gefüllter Excel-Sheet", sondern ein lebender Datensatz, der ab Kapitel 3 zur Steuerung des Rollouts dient. Wir empfehlen drei Artefakte: erstens das pro-Gerät-Inventar in Intune oder ConfigMgr, das mit jedem Geräte-Check-in aktualisiert wird; zweitens eine aggregierte Geräteklassen-Übersicht (Anzahl Geräte je Risikoklasse × aktueller Härtungsstand), die monatlich als Stand-Bericht in den IT-Lenkungsausschuss geht; drittens eine priorisierte Rollout-Liste, sortiert nach Risikoklasse und Härtungsstand, die in den nächsten Kapiteln abgearbeitet wird.

Wenn Sie zur Bestandsaufnahme externe Unterstützung benötigen, deckt unsere Systemhärtung genau diesen ersten Schritt ab — inklusive Skripten, Auswertung und priorisiertem Maßnahmenplan.

Nächster Schritt

Mit dem vollständigen Inventar wissen Sie, welche Geräte für die UEFI-CA-2023-Migration und den Pre-Boot-PIN-Rollout in Frage kommen. In Kapitel 3 beginnt die operative Migration: Pilotgruppe, Registry-Bitmask, Intune- vs. GPO-Steuerung — und die wichtige Trennung zwischen dem automatischen Rollout auf Windows Client und dem manuellen Playbook auf Windows Server.