Recast Cloud mit Intune: Einrichtung und App-Updates

In diesem Beitrag zeige ich, wie du Recast Cloud mit Microsoft Intune verbindest, eine App-Bereitstellung vorbereitest und Updates getrennt vom ersten Installieren steuerst. Entscheidend ist für mich nicht nur, dass eine App in Intune erscheint. Sie muss auf dem vorgesehenen Gerät ankommen und danach weiterhin funktionieren.

Für die Portalprüfung habe ich 7-Zip verwendet. Das ergänzende Video zeigt den Ablauf mit Google Chrome. Beides sind Beispiele für denselben Verwaltungsprozess, aber keine identischen Testläufe.

Die Screenshots stammen aus dem Preview-Portal vom 4. Oktober 2026. Die Umgebung zeigte Ready, und die lesenden Authentifizierungsprüfungen waren erfolgreich. Der Integrationstest meldete jedoch einen Konfigurationsfehler. Deshalb habe ich in dieser Portalprüfung keinen Deployment-Prozess gespeichert oder ausgeführt. Die folgenden Schritte unterscheiden beobachtete Einstellungen, dokumentierte Abläufe und noch offene Tests.

Der passende Video-Walkthrough

Was verwaltet Recast Cloud?

Dieser Rundgang behandelt den Bereich Patching. Andere Produktbereiche im Portal werden durch eine funktionierende Intune-Verbindung nicht automatisch mitgeprüft.

Die Navigation trennt Patching → Applications, Deployment Processes, Events und Settings. Ich würde mit einer Anwendung und einer kleinen Gerätegruppe anfangen. So lassen sich Fehler einem überschaubaren Ablauf zuordnen.

Konzeptioneller Ablauf. Veröffentlichung und Geräteprüfung sind in dieser Portalprüfung noch offen.

Den breiteren Ansatz beschreibe ich in meinem Überblick zu Recast Application Management. Hier geht es um die Cloud-Patching-Einstellungen und ihre Verbindung zu Intune.

Wie verbinde ich Recast Cloud mit Intune?

Du brauchst eine passende Produktlizenz oder Testversion, einen Intune-Tenant und die Berechtigung, eine Anwendung zu registrieren und den nötigen Consent zu erteilen. Für den späteren Deployment-Test kommen ein registriertes Windows-Gerät und eine eigene Entra-Gerätegruppe hinzu.

1. Die Entra-Anwendung vorbereiten

Öffne im Microsoft Entra Admin Center App registrations → New registration. Für dieses Lab passt ein Name wie Recast Cloud Patching Lab mit der Single-Tenant-Option.

Unter API permissions ergänzt du die folgenden Microsoft-Graph-Application Permissions und lässt den Administrator-Consent erteilen:

• DeviceManagementApps.ReadWrite.All
• GroupMember.Read.All
• DeviceManagementConfiguration.Read.All
• Device.Read.All

Erzeuge unter Certificates & secrets ein Client Secret. Für die Verbindung brauchst du dessen Wert, die Application Client ID und die Directory Tenant ID. Der Secret-Wert ist nicht die Secret-ID. Die einzelnen Schritte stehen in der Entra-Einrichtungsanleitung von Recast.

Tipp: Notiere Ablaufdatum und Verantwortlichen für die Erneuerung. Der Secret-Wert gehört nicht in Screenshots, Tickets oder die Projektdokumentation.

2. Die Service Connection anlegen

Öffne in Recast Cloud Administration → Service Connections. Im geprüften Portal hiess der Verbindungstyp AzureActiveDirectory, obwohl Microsoft das Verzeichnis heute Entra ID nennt.

Trage einen verständlichen Namen sowie Tenant ID, Client ID und Client Secret ein. Bestätige Confirmed und schliesse das Formular ab. Use a Recast Proxy to connect war in dieser Cloud-Lab-Konfiguration ausgeschaltet. Ob du einen Proxy brauchst, hängt von deiner Architektur und den Verbindungsanforderungen ab.

Beschriftungen und Bedienelemente bleiben sichtbar. Private Werte sind geschwärzt; ein Secret wird nicht gezeigt.

3. Die Patching-Umgebung erstellen

Unter Patching → Settings → Add Environment wählst du die Intune-Verbindung und gehst durch den Assistenten. Im Preview-Portal verschwand nach der Intune-Auswahl das UNC-Eingabefeld. Der Schritt für eine Distribution Point Group wurde übersprungen.

Für einen kontrollierten Einstieg würde ich “No, I’ll manually start the process when I’m ready.” auswählen. Prüfe danach die Umgebungsliste. Meine Umgebung zeigte Ready, den Typ Intune und noch keinen Deployment-Prozess.

Zusätzlich habe ich lesenden App-only-Zugriff auf die Graph-Endpunkte für Geräte, Gruppen, mobile Anwendungen und Gerätekonfigurationen geprüft. Alle vier antworteten mit HTTP 200. Das belegt diese Lesezugriffe und die Authentifizierung, aber keinen Paket-Upload, keine Zuweisung und keine Installation.

Hinweis: Führe auch Test Integration aus. Der Status Ready allein reicht nicht als Abnahme einer produktiven Verbindung. Den Fehler aus meinem Lab beschreibe ich weiter unten.

Wie bereite ich die erste App-Bereitstellung vor?

Ein normaler Deployment-Prozess ist für die Installation auf Geräten gedacht, auf denen die Anwendung noch fehlen kann. Das ist ein anderer Anwendungsfall als das Aktualisieren vorhandener Installationen.

1. Anwendung und Architektur auswählen

Suche unter Patching → Applications nach 7-Zip. Im Katalog gab es getrennte Einträge für x64, ARM64 und x86. Zum Zeitpunkt der Prüfung zeigten sie Version 26.03. Prüfe bei deinem eigenen Test den dann aktuellen Katalogstand.

Wähle die Architektur passend zum Pilotgerät. Ich habe 7-Zip (x64) ausgewählt. Eine Anwendung genügt, um den Prozess zu verstehen.

2. Den Deployment-Assistenten durchgehen

Öffne Patching → Deployment Processes → Add Deployment Process. Der geprüfte Assistent hatte fünf Schritte:

1. Select Environment: Intune-Umgebung auswählen. Für eine erste Installation bleibt Create as update process auf No.
2. Select Applications: 7-Zip (x64) markieren.
3. Name the Deployment Process: Einen eindeutigen Namen wie Lab 7-Zip install vergeben.
4. Select Events: Für einen kontrollierten Test New Version Available ausschalten.
5. Select Group: Die eigene Pilotgruppe suchen und auswählen.

Das Ausschalten eines Events ist keine allgemeine Zusicherung, dass ein neu gespeicherter Prozess zunächst inaktiv bleibt. Recast dokumentiert einen ersten Lauf für neu angelegte geplante Prozesse. Prüfe Zielgruppe und Einstellungen deshalb vor dem Speichern. Quelle: Recast Events

Der Screenshot zeigt bewusst No groups selected: Er dokumentiert den Assistenten vor einer Zuweisung. Für deinen Test muss hier die vorgesehene Pilotgruppe stehen. All Devices oder All Users würde ich beim ersten Lauf nicht verwenden.

3. Installation und Benachrichtigungen prüfen

Über das Zahnrad unter Patching → Settings erreichst du die Umgebungseinstellungen. Unter Deployments → Basic waren Required und Show all as toast notifications eingestellt.

Für den Pilot würde ich Required auf der kleinen Zielgruppe verwenden und Benachrichtigungen sichtbar lassen. Prüfe sowohl geerbte Einstellungen als auch Überschreibungen im Prozess. Recast beschreibt die Optionen in der Dokumentation zu Intune Deployment Settings.

4. Speichern, ausführen und das Gerät prüfen

Erst nach einem erfolgreichen Integrationstest und geprüfter Pilotgruppe würde ich speichern. Steht der Prozess danach auf Pending run, lässt er sich über das Aktionsmenü mit Run starten. View Details zeigt den Fortschritt. Diese Schritte sind von Recast dokumentiert; in dieser Portalprüfung habe ich sie nicht ausgeführt.

Prüfe anschliessend in Intune die angelegte Anwendung, ihre Version und ihre Zuweisungen. Auf dem Gerät kontrollierst du Installation und Start der Anwendung. Ein Eintrag in Intune ist noch kein Nachweis, dass der Installer erfolgreich beendet wurde.

Wie aktualisiere ich eine bereits installierte Anwendung?

Erstelle dafür einen eigenen Prozess mit Create as update process → Yes. Laut Portalhinweis gilt eine Update-Anwendung für Geräte, auf denen bereits eine frühere Version derselben Anwendung vorhanden ist. Prozess und importierte Anwendung erhalten den Präfix Update.

Ich möchte möglicherweise 7-Zip für eine Gruppe installieren und vorhandene Installationen in einer anderen Gruppe aktualisieren. Ein Patch-Prozess soll nicht unbemerkt zur Erstinstallation für alle werden.

Wähle Umgebung und 7-Zip (x64), aktiviere den Update-Modus und benenne den Prozess eindeutig. Unter Select Events kannst du New Version Available aktivieren, wenn neue Katalogversionen den Prozess auslösen sollen. Danach prüfst du die Patch-Pilotgruppe und die abschliessenden Einstellungen.

Die Voraussetzungen beschreibt Recast unter Run a deployment process in update mode.

Diese drei Fälle würde ich in der Abnahme testen:

Das sind Abnahmekriterien, keine gemessenen Ergebnisse dieses Labs. Prüfe nach jedem Lauf Version und Programmstart.

Wie steuere ich den Update-Zeitpunkt?

Recast Cloud hat eine Events-Seite sowie die Event-Auswahl im jeweiligen Prozess. Ich habe den Dialog Add Event und die Option Patch Tuesday geprüft.

Für ein monatliches Zeitfenster öffnest du Patching → Events → Add Event, vergibst einen Namen, wählst Patch Tuesday und setzt Verzögerung und Uhrzeit. Der Preview-Dialog zeigte 0–14 Tage Verzögerung und kennzeichnete die Uhrzeit ausdrücklich als UTC.

Nicht gespeichertes Beispiel. Die angezeigte Uhrzeit ist keine Empfehlung für ein Wartungsfenster.

Speichere das korrekte Event und verknüpfe es mit dem vorgesehenen Deployment-Prozess. Aktive Events wirken zusätzlich: Ein Zeitplan ersetzt kein aktiviertes New-Version-Event. Wenn der Prozess nur nach Zeitplan laufen soll, musst du den anderen Trigger deaktivieren. Quelle: Recast Events

Tipp: Rechne UTC in dein lokales Wartungsfenster um und beachte die Zeitumstellung. Der Prozessstart bedeutet ausserdem nicht, dass jedes Gerät exakt zu dieser Uhrzeit installiert.

Für den ersten Rollout würde ich klein anfangen und nach der Prüfung manuell erweitern. Später kann eine weitere Gruppe mit Verzögerung folgen. Recast unterstützt Verzögerungen zwischen Prozessschritten, wie in Deployment Processes beschrieben. Eine Verzögerung schafft Beobachtungszeit, ersetzt aber keine menschliche Freigabe.

Wie prüfe ich Erfolg und Fehler?

Ich würde an drei Stellen prüfen: im Recast-Prozess, in der Intune-Zuweisung und auf dem Gerät.

In Recast zeigt View Details Ablauf und Anwendungsstatus. Check for Updates kann neue Versionen prüfen und den Prozess bei einem verfügbaren Update ausführen. Das ist eine Aktion, nicht nur ein Neuladen der Anzeige. Ein pausierter Prozess stoppt laut Recast keine bereits in Intune laufende Bereitstellung. Das Löschen des Prozesses entfernt auch nicht die Intune-App. Quelle: Deployment Processes

In Intune öffnest du Apps → All Apps → Anwendung → Device install status. Prüfe Status, Details und letzten Check-in. Microsoft erklärt die Felder unter Monitor app information and assignments.

Auf dem Gerät kontrollierst du die Version und startest die App. Bei Fehlern gehören Code, Zeitpunkt und Installationslog zusammen. ErrorHunter hilft beim Einordnen von Fehlercodes; mit cmtrace.dev kannst du Logs lesen.

Der Integrationstest in meinem Lab

Test Integration meldete:

Unc path is not configured.

Im Intune-Assistenten war das UNC-Feld verschwunden; unter den allgemeinen Umgebungseinstellungen habe ich keines gefunden. Trotzdem stand die Umgebung auf Ready. Aus diesen Anzeigen konnte ich die Ursache nicht bestimmen.

Ich würde Recast die Preview-Version, den Umgebungstyp, die Fehlermeldung und das fehlende Eingabefeld melden. Einen Pfad zu erfinden oder die Verbindungsarchitektur nur für eine grüne Anzeige umzustellen, wäre keine belastbare Lösung.

Was würde ich als Nächstes testen?

Nach der Klärung des Integrationstests würde ich einen kleinen Pilot abschliessen:

1. Nur die vorgesehenen Testgeräte in die Pilotgruppe aufnehmen.
2. Den normalen 7-Zip-Prozess speichern und Veröffentlichung, Zuweisung und Installation prüfen.
3. Den Update-Prozess mit älterer Installation und ohne vorhandene App testen.
4. Events und Zeitplan kontrollieren, bevor weitere Geräte hinzukommen.

Recast Cloud stellt die Oberflächen für diesen Ablauf bereit. Die entscheidende Abnahme bleibt für mich, ob die richtige Version auf den richtigen Geräten ankommt und die Anwendung funktioniert. Den grösseren Zusammenhang beschreibe ich im Intune-App-Lifecycle; bei Fehlern hilft mein Intune-Troubleshooting-Guide.