Sektion 36: Deployment Types: Required vs. Available vs. Uninstall

In der Welt des modernen Endpoint Managements ist die Entscheidung, wie eine Software auf einem Gerät landet, fast so wichtig wie die Software selbst. Wer Intune professionell einsetzt, merkt schnell: Die Auswahl des Deployment-Typs ist kein bloßes „Ankreuzen“ in der GUI, sondern eine strategische Entscheidung über die User Experience (UX), die Systemstabilität und die Compliance innerhalb eines Unternehmens.

Wenn wir von Deployment-Typen in Intune sprechen, meinen wir primär die Zuweisungsarten (Assignments) von Win32-Apps. Während Store-Apps oder LOB-Apps ähnliche Logiken verfolgen, ist die Win32-App das Schweizer Taschenmesser der IT-Administration. Hier entscheiden wir, ob eine App im Hintergrund „lautlos“ installiert wird, ob der User sie selbst aus dem Company Portal wählen darf oder ob wir eine Software-Inventur durch eine forcierte Deinstallation bereinigen.

Die drei Säulen: Required, Available und Uninstall

Intune unterteilt die Zuweisung von Anwendungen in drei primäre Kategorien. Jede dieser Kategorien löst einen völlig unterschiedlichen Workflow im Intune Management Extension (IME) Agenten auf dem Endgerät aus.

1. Required (Erforderlich)

Ein „Required“-Assignment ist ein Befehl. Die Software muss auf dem Gerät installiert sein. Wenn ein Gerät einer Gruppe zugewiesen ist, die als „Required“ markiert ist, prüft der IME-Agent in regelmäßigen Abständen (oder beim Sync), ob die App vorhanden ist. Ist sie nicht da, wird die Installation sofort und ohne Interaktion des Benutzers gestartet.

• User Experience: Im Idealfall merkt der Nutzer nichts (Silent Install). Wenn die App jedoch ein Reboot erfordert oder die Installation nicht perfekt silent ist, kann dies zu unerwarteten Pop-ups oder Performance-Einbrüchen führen.
• Einsatzszenario: Sicherheitssoftware (CrowdStrike, Defender), Browser (Chrome/Edge), VPN-Clients oder firmenweite Standard-Tools wie Microsoft Teams.

2. Available (Verfügbar)

Ein „Available“-Assignment ist ein Angebot. Die Software wird nicht automatisch installiert, sondern im Company Portal (Unternehmensportal) für den Benutzer sichtbar. Der User entscheidet selbst, wann und ob er die App benötigt.

• User Experience: Maximale Autonomie. Der Nutzer klickt auf „Installieren“, und Intune übernimmt den Rest. Dies reduziert die Last auf die IT-Abteilung („Self-Service“).
• Einsatzszenario: Spezialsoftware, die nur ein Teil der Belegschaft benötigt (z.B. Adobe Acrobat Pro für das Marketing, Wireshark für die IT-Abteilung).

3. Uninstall (Deinstallieren)

Ein „Uninstall“-Assignment ist eine Bereinigung. Intune prüft, ob die App installiert ist. Wenn ja, wird der definierte Deinstallationsbefehl ausgeführt, um die Software vom Gerät zu entfernen.

• User Experience: Die Software verschwindet einfach vom System.
• Einsatzszenario: Ausphasen von veralteter Software (z.B. Wechsel von Foxit auf Adobe) oder das Entfernen von Bloatware auf neuen Geräten.

Praxis-Implementierung: Der technische Workflow

Um diese Typen effektiv zu nutzen, müssen wir die Logik des Intune Management Extension (IME) Agenten verstehen. Der IME ist der Prozess, der im Hintergrund läuft und die Win32-Apps steuert. Er arbeitet nach einem einfachen Zyklus: Detection → Action → Verification.

Der Required-Workflow im Detail

Wenn Sie eine App als „Required“ zuweisen, passiert folgendes:

1. Detection Rule Check: Der IME prüft die Detection Rule (z.B. existiert der Pfad C:\Program Files\MyApp\app.exe?).
2. Trigger: Wenn die Regel False zurückgibt (App nicht da), wird der Install-Befehl ausgeführt.
3. Verification: Nach der Installation wird die Detection Rule erneut geprüft. Gibt sie jetzt True zurück, wird der Status „Installed“ an den Intune-Tenant gemeldet.

Die Magie des „Available“-Deployments

Bei „Available“ wird die App im Company Portal gelistet. Das ist technisch gesehen ein Trigger, der die Installation erst startet, wenn der User den Button drückt. Ein wichtiger Profi-Tipp: Sie können eine App sowohl als Available für eine Gruppe als auch als Required für eine andere Gruppe zuweisen. Das ist extrem nützlich, wenn Sie eine App für die gesamte Firma „anbieten“, sie aber für die Buchhaltung „erzwingen“ wollen.

# Beispiel: Logik der Zuweisung in einer hybriden Umgebung
Gruppe A (Alle Mitarbeiter) -> Assignment: Available
Gruppe B (Marketing)       -> Assignment: Required
# Ergebnis: Marketing bekommt die App automatisch; alle anderen können sie sich holen.

Fortgeschrittene Strategien und Best Practices

In einer Enterprise-Umgebung reicht es nicht, nur zu wissen, welche Buttons man drückt. Man muss die Auswirkungen auf das System verstehen.

Die Gefahr von „Required“ bei großen Paketen

Stellen Sie sich vor, Sie weisen ein 5GB großes AutoCAD-Paket als „Required“ für 10.000 Geräte zu. Wenn diese Geräte alle gleichzeitig synchronisieren, können Ihre Netzwerkbandbreiten (vor allem in Filialen) kollabieren.
Lösung: Nutzen Sie „Available“ für große Pakete oder implementieren Sie Delivery Optimization (DO), damit Geräte die Daten untereinander austauschen (Peer-to-Peer), anstatt alle den Cloud-Speicher zu fluten.

Die „Uninstall“-Falle

Ein häufiger Fehler ist die Zuweisung von „Uninstall“ ohne eine präzise Detection Rule. Wenn die Detection Rule fehlerhaft ist, könnte Intune versuchen, eine App zu deinstallieren, die gar nicht da ist, oder schlimmer noch, eine ähnliche App zu entfernen.
Golden Rule: Testen Sie die Deinstallations-Detection-Rule immer zuerst manuell auf einem Testgerät.

Kombination von Deployment-Typen für Software-Migrationen

Wenn Sie Software A durch Software B ersetzen wollen, nutzen Sie die folgende Kette:

1. Software B: Required (Sichert die neue Version).
2. Software A: Uninstall (Entfernt die alte Version).

Dank der Supersedence-Logik (Sektion 35) kann Intune dies sogar automatisch steuern, aber die manuelle Zuweisung via Uninstall gibt Ihnen die volle Kontrolle über das Timing.

Troubleshooting: Wenn die App nicht landet

Es gibt Momente, in denen Intune meldet „Failed“, obwohl die Installation eigentlich funktioniert hat, oder die App einfach nicht startet. Hier ist der Weg zur Lösung:

1. Die Log-Dateien (Der heilige Gral)

Alle Informationen über Win32-Deployments finden Sie in den IME-Logs. Navigieren Sie auf dem Client zu:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Nutzen Sie den CMTrace oder den Support Tool for Intune, um die IntuneManagementExtension.log zu analysieren. Suchen Sie nach Keywords wie [Win32App] oder dem Namen Ihrer Anwendung.

2. Common Failures bei Required-Deployments

• Exit Code 1603: Ein generischer MSI-Fehler. Meistens bedeutet dies, dass die App bereits in einer anderen Version installiert ist oder ein Neustart aussteht.
• Detection Rule Failure: Die App wurde installiert, aber Intune findet sie nicht. Prüfen Sie, ob der Pfad oder die Registry-Key-Version exakt mit der Detection Rule übereinstimmt.
• User Context vs. System Context: Wenn Sie eine App als „Required“ installieren, läuft sie im SYSTEM-Konto. Wenn die App jedoch User-Profile anlegt oder auf HKEY_CURRENT_USER zugreift, wird die Installation fehlschlagen, sofern Sie nicht explizit „Install as User“ gewählt haben.

3. Debugging von Available-Apps

Wenn eine App nicht im Company Portal erscheint:

• Prüfen Sie, ob der User wirklich Mitglied der zugewiesenen Gruppe ist.
• Führen Sie einen manuellen Sync in den Einstellungen (Konten -> Zugriff auf Arbeit oder Schule -> Info -> Synchronisieren) durch.
• Prüfen Sie, ob die App eine Abhängigkeit (Dependency) hat, die derzeit nicht erfüllt ist.

Zusammenfassung der Entscheidungsmatrix

Um Ihnen die Entscheidung im Alltag zu erleichtern, nutzen Sie diese Matrix:

Fazit für den Masterclass-Pfad

Das Verständnis von Required, Available und Uninstall ist das Fundament für eine saubere Software-Strategie in Intune. Ein Admin, der alles auf „Required“ setzt, riskiert unzufriedene Nutzer und instabile Systeme. Ein Admin, der alles auf „Available“ setzt, riskiert eine Sicherheitslücke, weil wichtige Tools fehlen.

Die Kunst liegt in der Balance: Erzeugen Sie ein Ökosystem, in dem die kritischen Werkzeuge unsichtbar und zuverlässig im Hintergrund landen (Required), während die Nutzer durch ein gut gepflegtes Company Portal die Freiheit haben, ihre Arbeitsumgebung selbst zu gestalten (Available). Wenn Sie diese Logik mit den in den vorherigen Sektionen gelernten Abhängigkeiten und Supersedence-Regeln kombinieren, beherrschen Sie den App-Lifecycle in Microsoft Intune vollständig.