In einem meiner vorherigen Blogbeiträge habe ich erklärt, wie du mit Azure Automation und Azure Cognitive Services (jetzt Azure AI Services) den Compliance-Status deiner Umgebung überwachen und dich benachrichtigen lassen kannst, falls es größere Abweichungen gibt. In diesem Teil der Serie möchte ich dir zeigen, wie du das auf die Bereitstellung deiner Anwendungen anwenden kannst und ebenfalls benachrichtigt wirst, wenn die Installation einer Anwendung plötzlich ungewöhnlich häufig fehlschlägt.

Inhaltsverzeichnis
Wie wir an die Daten gekommen sind
Jede App in deinem Portfolio in Intune liefert detaillierte gerätebezogene Berichte zum Status der Installation. Du kannst sehen, ob die Installation erfolgreich war oder fehlgeschlagen ist. Genau diese Information möchten wir überwachen.

Um diese Information zu erhalten, starten wir im Edge-Browser eine Netzwerkaufzeichnung und aktualisieren die Ansicht. In der Aufzeichnung erhalten wir den Graph-Endpunkt. Der Graph-Endpunkt muss mit einer POST-Anfrage und einigen Parametern im Body aufgerufen werden, um festzulegen, welche Daten wir erhalten möchten.


Das sind alle Informationen, die wir brauchen, also legen wir los.
Bereitstellung des Azure AI Services Anomaly Detector
- Öffne das Azure-Portal und suche nach Anomaly detectors

- Klicke auf + Create

- Wähle ein Subscription und eine Resource group
- Wähle eine Region und gib den Name des Anomaly Detector ein
- Wähle das Preismodell (zum Testen reicht Free F0)

- Klicke auf Create

Teams-WebHook-URL abrufen
- Erstelle einen MS-Teams-Kanal und füge den Webhook-Connector hinzu
- Kopiere die WebHook-URL

Eine App-Registrierung erstellen
- Suche nach Microsoft Entra ID

- Wähle App registration

- Wähle +New registration

- Gib einen Name ein und klicke auf Register

- Klicke auf API permissions und +Add a permission

- Wähle Microsoft Graph

- Wähle Application permissions

- Suche nach DeviceManagementApps.Read.All

- Klicke auf Grant admin consent for *** und bestätige mit Yes

- Wähle Certificates & secrets und klicke auf +New client secret

- Gib eine Description ein und wähle eine Expires time
- Klicke auf Add

- Kopiere und speichere den Value und die Secret ID

Automation Account erstellen
- Suche nach Automation Accounts

- Klicke auf + Create

- Wähle ein Subscription und eine Resource group
- Gib einen account name ein und wähle eine Region
- Klicke auf Next

- Klicke auf Next

- Klicke auf Next -> Next -> Create

Das Runbook erstellen
- Öffne den Automation Account
- Navigiere zu Variables und klicke auf + Add a variable

- Füge den Secret Value, die TenantId, den AnomalyKey, WebHookUri und die App ID als Variable hinzu
- Wähle Runbooks
- Klicke auf + Create a runbook

- Gib einen Name ein
- Wähle PowerShell als Runbook-Typ
- Wähle 5.1 als Runtime-Version
- Klicke auf Create

- Füge das Skript aus meinem Github-Repository ein
- Bearbeite die Variable $anomalyEndpoint (trage hier deinen Endpunkt aus dem Azure AI Services Anomaly Detector ein)

Hinweis: Wenn du die Empfindlichkeit der Anomalieerkennung ändern möchtest, kannst du die Attribute anpassen:
– maxAnomalyRatio: Die maximale Anzahl an Anomalien, die im Verhältnis zur Gesamtzahl der Datenpunkte erkannt werden sollen.
– sensitivity: Gib einen niedrigeren Wert an, um sicherzustellen, dass weniger Anomalien akzeptiert werden

- Speichere und teste das Skript



- Klicke auf Publish

- Navigiere zu Schedules und klicke auf + Add a schedule


- Klicke auf Link to schedule und füge den erstellten schedule hinzu


Fazit
Ich hoffe, der zweite Teil meiner Serie hat dir gefallen und ich konnte dir helfen, Fehler in deiner Intune-Umgebung früher zu erkennen. Die Anwendungsbereitstellung ist ein sehr zentraler Bestandteil eines guten Device Managements, und um die Produktivität der Nutzer sicherzustellen, ist es wichtig, dass sie zuverlässig und fehlerfrei funktioniert. Um bei Problemen mit einzelnen Anwendungen so schnell wie möglich reagieren zu können, sendet diese Implementierung Benachrichtigungen direkt an einen Teams-Kanal.
Ein häufiger Stolperstein: Der Anomaly Detector benötigt genügend historische Datenpunkte, um ein normales Muster zu lernen. Wenn du das Runbook direkt nach dem Rollout einer neuen App laufen lässt, fehlen ihm diese Vergleichswerte und es kommt schnell zu falschen Alarmen. Plane den Lauf deshalb in einem festen Intervall, das zu deinem Deployment-Rhythmus passt, und gib der Erkennung ein paar Tage Zeit, bevor du den Schwellenwerten vertraust.
Bleib gesund, Cheers
Jannik
























Comments are closed.