Microsoft hat den Azure SRE Agent in die General Availability gebracht – einen KI-gesteuerten Operations-Agenten, der Incidents diagnostiziert, Root Cause Analysen beschleunigt und Workflows automatisiert. Mit „Deep Context“ lernt der Agent kontinuierlich aus eurem Code, euren Logs und eurer Infrastruktur. Für den DACH-Mittelstand ist das ein Signal: AIOps ist kein Experiment mehr, sondern ein produktionsreifes Werkzeug, das den Fachkräftemangel im Ops-Bereich konkret adressiert.


🔥 Top-Thema der Woche

Azure SRE Agent – General Availability mit Deep Context

Der Azure SRE Agent ist ab sofort allgemein verfügbar. Was als Preview begann, ist jetzt ein vollwertiger KI-Operations-Partner: Der Agent verbindet sich mit euren Repos, Logs, Azure-Ressourcen und Ticketing-Systemen und baut kontinuierlich ein Verständnis eurer Umgebung auf. Das Kernfeature „Deep Context“ bedeutet: Der Agent klont eure Repositories, analysiert Code-Strukturen und korreliert Runtime-Fehler direkt mit dem verursachenden Code. (Microsoft Tech Community)

Was ist neu im GA Release:

  • Deep Context: Persistentes Gedächtnis über Incidents und Systeme hinweg – der Agent wird mit jeder Interaktion besser
  • MCP-Connector-Ökosystem: Integration mit beliebigen Systemen über Model Context Protocol – Monitoring, Ticketing, interne APIs
  • Custom Skills und Plugin Marketplace: Eigene domänen-spezifische Fähigkeiten einbringen oder fertige Plugins installieren
  • Redesigned Onboarding: Neuer Agent wird am selben Tag produktiv – Code, Logs, Incidents und Azure-Ressourcen in einem Guided Flow verbinden
  • Python Runtime: Custom Tools schreiben, die beliebige Endpoints ansprechen

(Microsoft Learn)

Meine Einschätzung: Das ist der bisher konsequenteste Schritt von Microsoft in Richtung AIOps. Der SRE Agent löst nicht das Problem „wir brauchen keine Ops-Leute mehr“ – aber er löst das Problem „unsere Ops-Leute verbringen 80% ihrer Zeit mit Routine-Diagnostik statt mit Architekturverbesserungen“. Deep Context ist der entscheidende Unterschied zu generischen KI-Assistenten: Der Agent versteht euren spezifischen Stack, nicht nur generisches Azure-Wissen. Für Teams mit 2-5 Ops-Engineers ist das ein Game Changer.


AI:

  • Fireworks AI auf Microsoft Foundry (Public Preview): High-Performance Open Model Inference kommt auf Azure. Fireworks verarbeitet über 13 Billionen Tokens pro Tag mit mehr als 180.000 Requests/Sekunde. Verfügbar sind u.a. Minimax M2.5, OpenAIs gpt-oss-120b, MoonshotAI Kimi-K2.5 und DeepSeek-v3.2. Bring-your-own-Weights wird ebenfalls unterstützt – interessant für Teams mit Fine-tuned Models. (Azure Blog)
  • Claude Opus 4.6 und Claude Sonnet 4.6 in Microsoft Foundry: Anthropics Frontier-Modelle sind jetzt im Foundry Model Catalog verfügbar. Claude Opus 4.6 für komplexe autonome Tasks, Claude Sonnet 4.6 für Coding und Agents at Scale. Erweitert die Model-Auswahl für Teams, die Multi-Provider-Strategien fahren. (Microsoft Foundry)
  • azd AI Agent Debugging (Preview): Neue Commands azd ai agent show und azd ai agent monitor bringen Container-Status, Health-Checks und Live-Logs für Hosted AI Agents direkt in das Terminal. Schluss mit Portal-Hopping bei Agent-Debugging. (Azure SDK Blog)
  • Azure Content Understanding in Foundry Tools (Beta): Neues Python SDK für die Analyse von Dokumenten, Audio und Video über eine einheitliche API. Erster Schritt in Richtung multimodaler Content-Verarbeitung auf Enterprise-Niveau. (Azure SDK Release)

📢 Azure Core Updates

UpdateKategorieRelevanzStatusQuelle
Azure SRE AgentOperations/AI🔴 HochGALink
Fireworks AI auf Microsoft FoundryAI/Inference🔴 HochPreviewLink
Conditional Access Enforcement ChangeSecurity🔴 HochAb 27.03.2026Link
Azure Storage Mover – Private S3 TransfersMigration🟡 MittelPreviewLink
azd AI Agent Debugging CommandsDevelopment🟡 MittelPreviewLink
VS Code MSSQL Query ProfilerDevelopment🟡 MittelGALink
Azure DevOps Server March PatchesDevOps🟡 MittelPatchLink
March Patch Tuesday (2 Zero-Days, 79+ Flaws)Security🟡 MittelPatchLink
Azure Monitor Retry Bin für Log AnalyticsMonitoring🟢 NiedrigGALink

Hybrid & Modern Work

  • Azure Storage Mover – Private AWS S3 Transfers (Preview): Cloud-to-Cloud-Migrationen von AWS S3 nach Azure Blob Storage laufen jetzt über Private Endpoints statt über das öffentliche Internet. Für regulierte Branchen und Unternehmen mit strengen Compliance-Anforderungen ein wichtiger Baustein bei der Multi-Cloud-Konsolidierung. (Microsoft Learn)
  • Azure DevOps Server March Patches: Sicherheitsupdates für Azure DevOps Server On-Premises. Wer noch On-Prem-Instanzen betreibt, sollte zeitnah patchen. (Azure DevOps Blog)
  • Copilot Cowork Experience: Microsoft hat die Copilot Cowork Experience vorgestellt – ein Desktop-Tool für Nicht-Entwickler zur Automatisierung von Datei- und Task-Management mit KI-Unterstützung. Erweitert das Copilot-Ökosystem über Developer-Szenarien hinaus. (RCPMag)

🔐 Security & Identity

  • Conditional Access Enforcement Change (27. März 2026): Microsoft ändert die Durchsetzung von Conditional Access Policies mit Resource Exclusions. Bisher wurden Policies mit „All resources“ und Resource Exclusions bei Sign-ins über OIDC-only Scopes nicht erzwungen. Ab dem 27. März werden diese Policies konsequent angewendet. Wer Resource Exclusions in CA-Policies nutzt, muss jetzt testen, ob Applikationen betroffen sind. (Microsoft Entra Blog)
  • March Patch Tuesday – 2 Zero-Days: Microsoft hat 79+ Sicherheitslücken gepatcht, darunter CVE-2026-21262 (SQL Server Elevation of Privilege, CVSS 8.8) und CVE-2026-26127 (.NET Denial of Service, CVSS 7.5). Beide Zero-Days waren öffentlich bekannt, aber nicht aktiv ausgenutzt. Besonders CVE-2026-21262 ist relevant für jede Organisation mit SQL Server-Workloads. (BleepingComputer)
  • SyncJacking Hard Match Enforcement: Ab Juni 2026 blockiert Entra ID Versuche, über Entra Connect Sync oder Cloud Sync neue AD-User-Objekte per Hard Match auf bestehende Cloud-User mit privilegierten Rollen zu mappen. Wer Hybrid Identity betreibt, sollte Audit Logs auf entsprechende Warnungen prüfen. (Microsoft Learn)
  • Secure Boot Zertifikate – Ablauf ab Juni 2026: Microsoft warnt, dass die Secure Boot-Zertifikate vieler Windows-Geräte ab Juni 2026 ablaufen. Betrifft potenziell die Boot-Fähigkeit von Geräten – besonders relevant für Flotten-Management im Mittelstand. (Microsoft Support)

⚠️ Abkündigungen & Breaking Changes

Dienst / FeatureFristHandlungsbedarfLink
Conditional Access Enforcement Change27.03.2026CA-Policies mit Resource Exclusions testenLink
Default Outbound Internet Access (neue VNets)Ende März 2026NAT Gateway oder expliziten Outbound konfigurierenLink
Azure Unmanaged Disks31.03.2026Alle VMs auf Managed Disks migrierenLink
Service-Principal-Less Authentication31.03.2026Service Principals für alle Tenant-Apps anlegenLink
GPT-4o-mini in Azure AI Foundry31.03.2026Migration auf neuere ModelleLink
Azure ACS für SharePoint Online02.04.2026Migration auf Entra ID-AuthentifizierungLink
GPT-4.1 Familie (inkl. mini/nano)11.04.2026Migration auf GPT-5.x Modelle planenLink
SyncJacking Hard Match Block (privilegierte Rollen)01.06.2026Hybrid Identity Konfiguration prüfenLink
Secure Boot ZertifikateAb Juni 2026Geräte-Firmware und Zertifikate prüfenLink

FinOps-Tipp der Woche:

SRE Agent ROI berechnen – lohnt sich die Investition? Der Azure SRE Agent ist GA und kostet Geld. Die entscheidende Frage für den Mittelstand: Ab wann rechnet sich das? Der Break-even liegt typischerweise bei Teams, die mehr als 10 Incidents pro Monat bearbeiten und durchschnittlich 2+ Stunden pro Incident für Diagnostik aufwenden. Schneller Check für eure MTTR:

# Mean Time to Resolve der letzten 90 Tage aus Azure Monitor abfragen
az monitor metrics list \
--resource "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Insights/components/{app-insights}" \
--metric "requests/duration" \
--interval PT1H \
--start-time $(date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)

Wenn eure durchschnittliche Incident-Diagnosezeit über 30 Minuten liegt und ihr mehr als ein Dutzend Incidents pro Monat bearbeitet, ist der SRE Agent fast sicher kosteneffizient – allein durch die Zeitersparnis bei Root Cause Analysis.


💡 Deep Dive: Azure SRE Agent – vom KI-Experiment zum produktionsreifen Ops-Partner

Der Azure SRE Agent markiert einen Wendepunkt in Microsofts AIOps-Strategie. Was als Preview mit begrenztem Funktionsumfang startete, ist jetzt ein vollwertiger Operations-Agent, der sich fundamental von bisherigen KI-Assistenten unterscheidet. Der entscheidende Unterschied: Deep Context.

Bisherige KI-Tools im Ops-Bereich arbeiteten stateless – jede Anfrage begann bei Null. Der SRE Agent hingegen lebt permanent in eurer Umgebung. Er klont Repositories, analysiert Code-Strukturen, korreliert Deployment-Logs mit Infrastruktur-Events und baut ein persistentes Gedächtnis auf. Wenn ein Incident auftritt, kennt der Agent nicht nur den Fehler, sondern den Kontext: Welcher Commit hat die Änderung eingeführt? Welcher Service ist betroffen? Welche ähnlichen Incidents gab es in den letzten 3 Monaten?

Die Integration über MCP-Connectors ist der zweite Game Changer. Statt nur Azure-nativ zu arbeiten, verbindet sich der Agent mit PagerDuty, ServiceNow, Datadog, Grafana oder jedem System, das eine API hat. Custom Python Tools erlauben die Anbindung interner APIs. Das eliminiert das klassische Problem von AIOps-Tools: Sie sehen nur einen Ausschnitt des Gesamtbildes.

Für den DACH-Mittelstand mit typisch kleinen Ops-Teams (2-5 Personen) bietet der SRE Agent den größten Hebel bei Incident Response und Root Cause Analysis. Das Onboarding ist bewusst niedrigschwellig: Code-Repos, Logs und Azure-Ressourcen verbinden, und der Agent beginnt sofort mit der Kontextbildung. Die ersten brauchbaren Ergebnisse kommen laut Microsoft am selben Tag.

Die Einschränkungen sollte man kennen: Der Agent braucht Zugriff auf Repos und Logs, was in regulierten Umgebungen Freigaben erfordert. Die Qualität der Ergebnisse hängt direkt von der Qualität der Observability-Daten ab. Und der Agent ersetzt keine Ops-Strategie – er beschleunigt die Ausführung einer bestehenden.

Vollständiger Artikel folgt auf Azure SRE Agent GA – vom KI-Experiment zum produktionsreifen Ops-Partner – Rays Cloud Blog


✅ Eine Maßnahme für diese Woche

Conditional Access Policies mit Resource Exclusions testen: Am 27. März ändert Microsoft die Enforcement-Logik für CA-Policies. Wer Policies mit „All resources“ Target und Resource Exclusions nutzt, muss jetzt prüfen, ob Applikationen betroffen sind:

# Alle Conditional Access Policies mit Resource Exclusions auflisten
az rest --method GET \
--url "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
--query "value[?conditions.applications.excludeApplications != null].{Name:displayName, State:state, Exclusions:conditions.applications.excludeApplications}" \
--output table

Falls Policies mit Resource Exclusions auftauchen: In einer Test-Umgebung die Auswirkungen der neuen Enforcement-Logik validieren, bevor Microsoft am 27. März umstellt.

Hinterlasse einen Kommentar