Sektion 33: Detection Methods: Registry vs. File vs. Custom Scripts

Einleitung

In der Welt von Microsoft Intune ist die Installation einer Software oder die Ausführung eines Konfigurationsskripts nur die halbe Miete. Die eigentliche Herausforderung – und die häufigste Fehlerquelle in produktiven Umgebungen – ist die sogenannte Detection Method (Erkennungsmethode). Ohne eine präzise definierte Erkennungslogik weiß Intune nicht, ob eine App erfolgreich installiert wurde, ob sie fehlt oder ob ein Installationsversuch fehlgeschlagen ist.

Wenn die Detection Method falsch konfiguriert ist, landet man in einem der gefürchteten Szenarien: Die App wird in einer Endlosschleife immer wieder installiert, obwohl sie bereits vorhanden ist, oder sie wird als „installiert“ gemeldet, obwohl der Client in Wahrheit abstürzt. In dieser Masterclass-Sektion analysieren wir die drei Säulen der Erkennung: den Registry-Check, die Dateisystem-Prüfung und die mächtigen Custom Detection Scripts. Wir lernen, wie man diese Methoden kombiniert, um eine „Industrial Precision“ in der Softwareverteilung zu erreichen.

Grundkonzepte: Warum Detection überhaupt existiert

Intune arbeitet nach dem Prinzip des Desired State Configuration (DSC). Das bedeutet, du definierst nicht nur, was passieren soll (Installation), sondern auch, wie es aussieht, wenn es fertig ist (Detection). Der Intune Management Extension (IME) Agent auf dem Client führt folgenden Logik-Zyklus aus:

• Prüfung: Der Agent führt die Detection Method aus.
• Ergebnis „Gefunden“: Die App gilt als installiert. Es passiert nichts weiter.
• Ergebnis „Nicht gefunden“: Die App gilt als fehlend. Der Installationsbefehl wird ausgeführt.
• Nachprüfung: Nach der Installation wird die Detection Method erneut ausgeführt. Ist sie nun „Gefunden“, ist der Status „Erfolgreich“. Bleibt sie „Nicht gefunden“, wird die Installation als „Fehlgeschlagen“ markiert.

Ein kritischer Punkt hierbei ist die Unterscheidung zwischen dem System-Kontext und dem Benutzer-Kontext. Eine Registry-Key-Abfrage unter HKEY_LOCAL_MACHINE (HKLM) erfordert Systemrechte, während HKEY_CURRENT_USER (HKCU) nur funktioniert, wenn die App im Benutzerkontext installiert wurde. Ein häufiger Fehler ist die Suche nach einer Datei im Benutzerprofil, während die App als System installiert wurde – das Ergebnis ist fast immer ein Fehlschlag.

Praxis-Implementierung: Die drei Methoden im Detail

1. Die Registry-Erkennung (The Gold Standard)

Die Registry ist oft der zuverlässigste Weg, um Software zu erkennen, da fast jeder Windows-Installer (MSI, EXE) dort Einträge hinterlässt. Besonders bei MSI-Paketen ist der ProductCode (ein GUID) die absolut präziseste Methode.

Wann man sie einsetzt: Wenn die Software einen eindeutigen Registry-Key erstellt, der nur bei einer erfolgreichen Installation existiert.

Konfiguration in Intune:

• Rule Type: Registry
• Key Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{PRODUCT-GUID}
• Value Name: (leer lassen, wenn nur die Existenz des Keys geprüft werden soll)
• Detection Method: Key exists

Pro-Tipp für 64-Bit vs. 32-Bit: Achtung bei der Registry-Umleitung! Wenn du eine 32-Bit App auf einem 64-Bit System suchst, landet der Key oft in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\.... Intune bietet hier die Option „Associated with a 32-bit app on 64-bit clients“. Aktiviere diese Option, wenn du nicht sicher bist, wo der Key landet, oder gib den Pfad zum WOW6432Node explizit an.

2. Die Dateisystem-Erkennung (The Simple Way)

Die Dateierkennung ist die intuitivste Methode: „Wenn die Datei program.exe im Ordner C:\Program Files\App liegt, ist die App da.“

Wann man sie einsetzt: Bei portable Software, einfachen Skript-Installationen oder wenn die Registry-Einträge unzuverlässig sind.

Konfiguration in Intune:

• Rule Type: File
• Path: C:\Program Files\MyCompany\MyApp
• File or Folder: MyApp.exe
• Detection Method: File or folder exists

Erweiterte Prüfung (Versionierung): Die bloße Existenz einer Datei reicht oft nicht aus. Was passiert bei einem Update? Wenn du Version 1.0 installiert hast und Version 2.0 verteilst, erkennt Intune die Datei MyApp.exe immer noch und meldet „Installiert“, obwohl die Version veraltet ist. Nutze daher die Option „String (version)“. Hier gibst du die exakte Versionsnummer an (z. B. 2.1.0.5). Intune prüft dann die Dateieigenschaften der EXE oder DLL und erkennt, dass ein Update nötig ist.

3. Custom Detection Scripts (The Power User Way)

Manchmal reicht ein einfacher Key oder eine Datei nicht aus. Vielleicht muss geprüft werden, ob ein bestimmter Datenbank-Eintrag existiert, ob ein Dienst läuft oder ob eine Kombination aus drei verschiedenen Dateien vorhanden ist. Hier kommen PowerShell-Skripte ins Spiel.

Die goldene Regel der Custom Detection: Intune bewertet das Ergebnis eines Skripts ausschließlich anhand des Exit Code und des STDOUT (Standard-Ausgabe).

• App installiert: Das Skript muss einen Exit Code von 0 zurückgeben UND (idealerweise) einen Text in die Konsole schreiben (z. B. Write-Output "Installed").
• App NICHT installiert: Das Skript muss einen Exit Code ungleich 0 zurückgeben (z. B. exit 1) ODER gar nichts ausgeben.

Beispiel: Komplexe Prüfung einer App (Datei + Registry + Version)

# Custom Detection Script für 'EnterpriseTool'
$Path = "C:\Program Files\EnterpriseTool\Tool.exe"
$RegKey = "HKLM:\SOFTWARE\EnterpriseTool"
$MinVersion = [version]"2.5.0"

if (Test-Path $Path) {
    $FileVersion = [version](Get-ItemProperty $Path).Version
    if ($FileVersion -ge $MinVersion) {
        if (Test-Path $RegKey) {
            Write-Output "Detected: Version $FileVersion is installed and Registry key exists."
            exit 0
        }
    }
}

# Wenn eine der Bedingungen nicht erfüllt ist, geben wir keinen Erfolg zurück
exit 1

Best Practices für die Architektur der Erkennung

Um in einer Enterprise-Umgebung mit tausenden Clients stabil zu arbeiten, solltest du dich an folgende Prinzipien halten:

1. Das Prinzip der Minimalen Spezifität

Suche nach dem spezifischsten Merkmal. Ein Ordner namens C:\Temp ist kein Beweis für eine Installation. Eine Datei namens app.exe ist besser, aber eine Registry-GUID ist perfekt. Die Hierarchie der Zuverlässigkeit ist: MSI GUID > Spezifischer Registry-Key > Dateiversion > Dateiexistenz.

2. Vermeidung von „Race Conditions“

Manche Installer erstellen die Datei app.exe sofort beim Start, aber die eigentliche Konfiguration dauert noch 5 Minuten. Wenn Intune die Detection sofort nach dem Start des Installationsbefehls ausführt und die Datei findet, markiert er die App als „installiert“, obwohl der Installer im Hintergrund vielleicht gerade abstürzt. Lösung: Suche nach einem Artefakt, das erst ganz am Ende des Installationsprozesses erstellt wird (z. B. ein Log-Eintrag oder ein finaler Registry-Key).

3. Kontext-Matching

Wenn die App im User-Kontext installiert wird, MUSS die Detection auch im User-Kontext laufen. Ein System-Agent kann nicht in HKEY_CURRENT_USER schauen, da er nicht weiß, welcher Benutzer gerade angemeldet ist. Prüfe in den App-Einstellungen in Intune immer: Install behavior: User $\rightarrow$ Detection: User Context.

Troubleshooting: Wenn die Detection „lügt“

Wenn eine App in Intune als „Fehlgeschlagen“ markiert wird, obwohl du auf dem PC siehst, dass sie installiert ist, liegt es zu 99 % an der Detection Method. So debuggst du das systematisch:

Schritt 1: Den Intune Management Extension (IME) Log analysieren

Die wichtigste Datei auf dem Client ist die IntuneManagementExtension.log. Du findest sie unter: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Nutze das Tool CMTrace oder den Support Tool von Intune, um die Logs zu lesen.

Suche nach Begriffen wie [Win32App] Checking detection. Dort steht genau, welchen Pfad Intune geprüft hat und welchen Exit Code das Skript zurückgegeben hat.

Schritt 2: Manuelles Testen des Detection-Skripts

Wenn du ein Custom Script nutzt, führe es lokal in einer erhöhten PowerShell-Konsole aus. Aber Achtung: Teste es exakt so, wie Intune es tut. Wenn die App im User-Kontext läuft, darfst du die Konsole nicht als Administrator starten, da du sonst HKLM statt HKCU prüfst.

# Test-Kommando in der PowerShell:
.\MyDetectionScript.ps1
echo $LASTEXITCODE

Wenn $LASTEXITCODE nicht 0 ist, wird Intune die App als „nicht installiert“ werten.

Schritt 3: Die Registry-Falle (64-bit vs 32-bit)

Prüfe mit dem Registry-Editor (regedit), ob dein Key wirklich dort liegt, wo du ihn in Intune eingetragen hast. Wenn du im Editor HKEY_LOCAL_MACHINE\SOFTWARE\MyApp siehst, aber Intune ihn nicht findet, schau nach, ob er eigentlich in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MyApp liegt. Das ist der klassische Fehler bei 32-Bit Applikationen auf 64-Bit Windows.

Zusammenfassung und Fazit

Die Detection Method ist das Gehirn der Softwareverteilung in Intune. Sie entscheidet darüber, ob dein Deployment ein Erfolg ist oder in einem Chaos aus Fehlermeldungen und unnötigen Neuinstallationen endet.

Die Key-Takeaways für deine Praxis:

• Registry: Nutze sie für MSI-Pakete (GUID) und Enterprise-Software. Beachte den WOW6432Node.
• Files: Nutze sie für einfache Tools, aber immer in Kombination mit einer Versionsprüfung, um Updates zu ermöglichen.
• Scripts: Nutze sie für komplexe Logik. Achte penibel auf den Exit Code 0 (Erfolg) und einen nicht-leeren STDOUT.
• Kontext: System-Installationen $\rightarrow$ HKLM/Program Files. User-Installationen $\rightarrow$ HKCU/AppData.

Wenn du diese Regeln befolgst, baust du eine Infrastruktur auf, die wartungsarm ist und eine extrem hohe Zuverlässigkeit bietet. In der nächsten Sektion werden wir uns ansehen, wie wir diese Erkenntnisse nutzen, um komplexe App-Abhängigkeiten (Dependencies) zu steuern, damit App B erst installiert wird, wenn die Detection von App A erfolgreich war.