Last Week in Azure & Tech – Vol. 9

Top-Thema der Woche: Azure MCP Server 2.0 – Agentic Cloud Automation wird Enterprise-ready

Microsoft hat am 10. April den Azure MCP Server 2.0 als Stable Release veröffentlicht – und damit einen entscheidenden Schritt in Richtung produktionsreifer KI-Agent-Infrastruktur gemacht. Die Kernneuerung: Self-Hosted Remote MCP Server Support. Teams können den MCP Server jetzt zentral in ihrer eigenen Infrastruktur betreiben, statt auf lokale Entwickler-Setups angewiesen zu sein.

Die wichtigsten Neuerungen:

• 276 MCP Tools über 57 Azure Services: End-to-End-Szenarien für Provisioning, Deployment, Monitoring und Diagnostics – alles über das Model Context Protocol steuerbar
• Self-Hosted Remote Server: Enterprise-Grade Shared Access mit zentraler Konfiguration und Governance. Der Server läuft innerhalb eurer Netzwerkgrenzen – kein Datenabfluss an externe Endpunkte
• Erweiterte Authentifizierung: Managed Identity Support (zusammen mit Microsoft Foundry), On-Behalf-Of (OBO) Flow via OpenID Connect Delegation für User-Context-Zugriff
• Sovereign Cloud Support: Azure US Government und Azure China (21Vianet) werden unterstützt – relevant für regulierte Umgebungen im DACH-Raum mit strengen Boundary Controls
• Breite Client-Kompatibilität: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor, GitHub Copilot CLI, Claude – der Server integriert sich in praktisch jede Entwicklungsumgebung

Meine Einschätzung: MCP Server 2.0 ist der fehlende Baustein zwischen „KI-Agenten als Demo“ und „KI-Agenten in der Produktion“. Die Self-Hosted-Variante löst das zentrale Problem für Enterprise-Kunden: Governance und Netzwerkkontrolle. Wer heute Azure-Infrastruktur mit KI-Agenten automatisieren will – ob für Provisioning, Incident Response oder Compliance Checks – hat jetzt einen produktionsreifen, sicheren Weg dafür. IT-Leiter sollten evaluieren, ob ein zentraler MCP Server für ihre DevOps- und Platform-Engineering-Teams sinnvoll ist.

🔗 Azure MCP Server 2.0 Stable Release

🤖 KI & Azure AI

Foundry Labs April 2026 – Neue Modelle und Embedding-Familie

Microsoft hat in den Foundry Labs eine Reihe neuer Modelle veröffentlicht, die das KI-Portfolio deutlich erweitern:

Harrier-oss-v1 – Open-Source Multilingual Embeddings: Eine neue Familie von Embedding-Modellen in drei Größen (270M, 0.6B, 27B Parameter), die 94 Sprachen unterstützen und State-of-the-Art auf dem Multilingual MTEB v2 Benchmark erreichen. Instruction-tunable ohne Fine-Tuning – ideal für RAG-Szenarien im mehrsprachigen Enterprise-Umfeld.

Phi-4-Reasoning-Vision-15B: Ein kompaktes Vision-Reasoning-Modell mit 88.2% auf ScreenSpot_v2 und 83.3% auf ChartQA. Versteht Diagramme, GUIs und Screenshots – relevant für Document Intelligence und UI-Automatisierung.

VibeVoice ASR: Verarbeitet bis zu 60 Minuten Audio in einem einzigen Durchlauf mit kombinierter Transkription, Speaker Diarization und Timestamping. Unterstützt 50+ Sprachen mit Code-Switching und Custom Hotword Injection. Für Contact Center und Meeting-Transkription ein interessanter Kandidat neben MAI-Transcribe-1.

🔗 What’s new in Foundry Labs – April 2026

MCP auf Azure Functions – Foundry Agents bekommen Custom Tools

Microsoft zeigt, wie man MCP Server auf Azure Functions hostet und direkt als Custom Tools in Microsoft Foundry Agents einbindet. Authentifizierungsoptionen: Key-based Auth, Entra, OAuth Identity Passthrough oder unauthentifiziert. Wer eigene Tools für KI-Agenten baut, hat jetzt einen vollständigen Hosting- und Integrationspfad.

🔗 Foundry Agent Custom Tools with MCP on Azure Functions

Fluent API für MCP Apps – .NET macht MCP einfacher

Die neue Fluent Configuration API für .NET Isolated Worker vereinfacht das Bauen von MCP Tools mit UI-Erlebnissen erheblich. Jedes MCP Tool kann per Builder-Methoden (WithView, WithPermissions, WithCsp) zur vollständigen MCP App mit Views, Permissions und Security Policies promoviert werden.

🔗 Fluent API for MCP Apps

📋 Azure Core Updates

🏢 Hybrid & Modern Work

Azure MCP Server 2.0 – Agentic DevOps im Enterprise

Die Self-Hosted-Variante des MCP Servers ermöglicht es Platform-Engineering-Teams, einen zentralen MCP-Endpunkt bereitzustellen, über den Entwickler KI-gestützt Azure-Ressourcen provisionieren, diagnostizieren und monitoren können. Die Integration in CI/CD-Pipelines ist ebenfalls möglich – MCP Workflows als Teil des Deployment-Prozesses.

🔗 Azure MCP Server 2.0

Security Copilot jetzt in Microsoft 365 E5 enthalten

Microsoft packt 400 Security Compute Units (SCUs) pro 1.000 User in die M365 E5 Lizenz. Copilot ist damit über Defender, Entra und Purview integriert nutzbar – ohne zusätzliche Lizenzkosten. Für Unternehmen mit bestehender E5-Lizenz ein erheblicher Mehrwert.

Neue SharePoint-Experience mit Copilot-Integration

Die neue SharePoint-Oberfläche bringt eine „Discover / Publish / Build“-Navigation mit integrierter Copilot-Unterstützung. Dazu kommen verbesserte OneDrive-Offboarding-Tools mit Bulk-Transfer und „Move and Keep Sharing“-Funktionalität – relevant bei Mitarbeiterwechseln.

🔐 Security & Identity

• Cross-Tenant Security Group Sync (GA): Security Groups können jetzt über Tenant-Grenzen hinweg synchronisiert werden. Admins aktualisieren Attribute Mappings, Cross-Tenant Access Policies im Ziel-Tenant erlauben die Synchronisation. Für Multi-Tenant-Architekturen im Konzernumfeld ein Meilenstein
• Entra Authenticator Jailbreak Detection: Credentials werden automatisch gelöscht, wenn eine Device-Kompromittierung erkannt wird. Schützt vor Credential Theft auf kompromittierten Mobilgeräten
• AI Model Security in Defender for Cloud (Preview): Security-Teams können Custom AI Models in Azure ML Registries und Workspaces entdecken und vor dem Deployment auf Risiken scannen
• Purview AI-Powered DLP Alert Summaries: Der Triage Agent fasst Alerts zusammen, kategorisiert Risiken und beschleunigt Investigations. Unterstützt jetzt Metadata-basierte Regeln und Non-Content Alerts
• Conditional Access Enforcement für Device Registration: Rollout-Phase hat begonnen, Default für alle Tenants ab Mai 2026. Betrifft Windows Hello for Business und macOS Platform SSO. Report-Only Mode jetzt aktivieren!
• Content Security Policy Updates (Entra Sign-In): Phase 1 rollt seit Mitte April aus – Cross-Site Scripting-Schutz auf der Entra-Anmeldeseite

🔗 Microsoft Entra What’s New 🔗 Defender for Cloud Release Notes

⚠️ Abkündigungen & Retirements

ACHTUNG: Die GPT-4.1 Model Retirement ist seit dem 11. April aktiv – bestehende Deployments funktionieren nicht mehr. Wer noch nicht migriert hat, muss sofort auf GPT-4o oder GPT-5 umstellen. Ebenfalls kritisch: Die Message Trace API wurde am 8. April retired – alle Custom-Lösungen müssen auf Microsoft Graph API umgestellt werden.

💰 FinOps-Tipp der Woche: Shift-Left FinOps – Kostenkontrollen in die CI/CD Pipeline

Kosten erst nach dem Deployment zu prüfen, ist wie eine Code Review nach dem Merge – zu spät. Der aktuelle Trend im FinOps heißt „Shift Left“: Kostenchecks direkt in Build, Test und Release Stages einbauen.

Konkrete Umsetzung:

bash

# Azure Cost Estimation in der Pipeline mit "what-if" Deployment
az deployment group what-if \
  --resource-group rg-production \
  --template-file main.bicep \
  --parameters @params.json
# Ergebnis: Zeigt welche Ressourcen erstellt, geändert oder gelöscht werden
# Kombiniert mit Pricing API für Kostenabschätzung VOR dem Deployment

Regeln für Pipeline Cost Gates: Budget-Überschreitungen blocken, unkontrollierte Environment-Erstellung verhindern, fehlende Tags rejecten, überdimensionierte SKUs flaggen. Schwellenwerte gemeinsam mit Engineering und Finance definieren.

Zusätzlich prüfen: Sentinel Entity Analyzer wird seit 1. April nach Security Compute Units (SCUs) abgerechnet. Wer dieses Feature nutzt, sollte die Kosten im Azure Cost Management monitoren.

🔗 Shift-Left FinOps for Azure

💡 Deep Dive: Azure MCP Server 2.0 – Self-Hosted Remote MCP für Enterprise Agentic Workflows

Das Model Context Protocol (MCP) hat sich als offener Standard für die Kommunikation zwischen KI-Modellen und externen Tools etabliert. Mit Azure MCP Server 2.0 liefert Microsoft die Enterprise-Implementierung: ein Self-Hosted Remote Server, der 276 Tools über 57 Azure Services bereitstellt – sicher, governed und innerhalb eurer eigenen Infrastruktur.

Das Problem mit lokalen MCP Setups: Bisher lief der Azure MCP Server primär lokal auf Entwickler-Maschinen. Jeder Entwickler hatte seine eigene Konfiguration, eigene Authentifizierung, eigene Tool-Versionen. Für ein einzelnes Team mag das funktionieren – für Enterprise-Umgebungen mit 50+ Entwicklern, Compliance-Anforderungen und Netzwerk-Segmentierung skaliert das nicht.

Was der Self-Hosted Remote Server löst:

1. Zentrale Governance: Ein Server, eine Konfiguration, ein Satz an Policies. Admins definieren, welche MCP Tools verfügbar sind, welche Azure-Subscriptions angesprochen werden dürfen und welche Authentifizierungsmethoden erlaubt sind
2. Netzwerk-Isolation: Der Server läuft innerhalb eures VNets oder eurer privaten Infrastruktur. Kein Traffic verlässt die Netzwerkgrenzen – wichtig für regulierte Branchen
3. Authentifizierung auf Enterprise-Level: Managed Identity für Service-to-Service-Kommunikation, OBO Flow für User-Context-Operationen. Keine statischen API Keys mehr
4. Konsistente Tool-Versionen: Alle Entwickler arbeiten gegen denselben Server mit denselben Tool-Versionen. Keine „works on my machine“-Probleme bei MCP-basierten Automationen

Architektur-Pattern: Zentraler MCP Server für Platform Engineering

┌──────────────────────────────────────────────┐
│  Developer Clients                            │
│  (VS Code, Cursor, GitHub Copilot CLI)       │
└──────────┬───────────────────────────────────┘
           │ HTTPS (Streamable HTTP Transport)
           ▼
┌──────────────────────────────────────────────┐
│  Azure MCP Server 2.0 (Self-Hosted)          │
│  - Container App / AKS / VM                  │
│  - Managed Identity                          │
│  - 276 Tools / 57 Services                   │
│  - Centralized Config & Policies             │
└──────────┬───────────────────────────────────┘
           │ Managed Identity / OBO
           ▼
┌──────────────────────────────────────────────┐
│  Azure Resources                              │
│  (Subscriptions, Resource Groups, Services)  │
└──────────────────────────────────────────────┘

Setup: Self-Hosted MCP Server auf Azure Container Apps

bash

# 1. Container App Environment erstellen
az containerapp env create \
  --name mcp-server-env \
  --resource-group rg-platform-engineering \
  --location westeurope
# 2. Managed Identity erstellen
az identity create \
  --name mi-mcp-server \
  --resource-group rg-platform-engineering \
  --location westeurope
# 3. RBAC-Rollen zuweisen (Least Privilege!)
# Reader auf die relevanten Subscriptions
az role assignment create \
  --assignee $(az identity show --name mi-mcp-server \
    --resource-group rg-platform-engineering \
    --query principalId -o tsv) \
  --role "Reader" \
  --scope /subscriptions/<target-subscription-id>
# 4. Container App deployen
az containerapp create \
  --name mcp-server \
  --resource-group rg-platform-engineering \
  --environment mcp-server-env \
  --image ghcr.io/microsoft/azure-mcp-server:2.0 \
  --target-port 8080 \
  --ingress external \
  --min-replicas 1 \
  --max-replicas 3 \
  --user-assigned $(az identity show --name mi-mcp-server \
    --resource-group rg-platform-engineering \
    --query id -o tsv)
# 5. MCP Client konfigurieren (VS Code settings.json)
# {
#   "mcp": {
#     "servers": {
#       "azure": {
#         "url": "https://mcp-server.<env>.<region>.azurecontainerapps.io/sse",
#         "transport": "sse"
#       }
#     }
#   }
# }

Vergleich: Lokal vs. Self-Hosted Remote

Einschränkungen:

• Write-Operations (Provisioning, Deployments) erfordern entsprechende RBAC-Rollen – nicht nur Reader
• Der OBO Flow setzt voraus, dass die Client-App eine Entra App Registration mit den richtigen API Permissions hat
• Sovereign Cloud Support erfordert separate Konfiguration der Cloud-Endpunkte
• Container Image Sizes wurden reduziert, sind aber für minimale Umgebungen immer noch relevant

Meine Einschätzung: Azure MCP Server 2.0 ist die Infrastruktur, die gefehlt hat, um KI-gestützte Cloud-Automatisierung vom Experiment in die Produktion zu bringen. Der Self-Hosted-Ansatz respektiert Enterprise-Anforderungen an Governance und Netzwerksicherheit. Wer ein Platform-Engineering-Team hat, sollte einen zentralen MCP Server als „AI-Gateway für Azure-Operationen“ evaluieren. Der ROI liegt in der Standardisierung: Ein Server, konsistente Policies, keine Schatten-Konfigurationen.

🔗 Azure MCP Server 2.0 Stable Release 🔗 Azure MCP Server GitHub 🔗 Model Context Protocol Specification

✅ Eine Maßnahme für diese Woche

GPT-4.1 Retirement prüfen und Azure MCP Server 2.0 evaluieren

bash

# 1. DRINGEND: GPT-4.1 Deployments identifizieren (Retirement seit 11. April!)
az cognitiveservices account deployment list \
  --name <your-openai-resource> \
  --resource-group <your-rg> \
  --query "[?contains(properties.model.name, 'gpt-4.1')]" \
  -o table
# Falls noch vorhanden: Sofort auf GPT-4o oder GPT-5 migrieren
az cognitiveservices account deployment create \
  --name <your-openai-resource> \
  --resource-group <your-rg> \
  --deployment-name gpt4o-replacement \
  --model-name gpt-4o \
  --model-version "2024-11-20" \
  --model-format OpenAI \
  --sku-capacity 10 \
  --sku-name Standard
# 2. Azure MCP Server 2.0 testen (lokal, 5 Minuten)
# Voraussetzung: Docker installiert
docker pull ghcr.io/microsoft/azure-mcp-server:2.0
docker run -p 8080:8080 ghcr.io/microsoft/azure-mcp-server:2.0
# 3. Sentinel Entity Analyzer Kosten prüfen (neues SCU-Billing seit 1. April)
# Azure Portal > Cost Management > Filter: "Microsoft Sentinel"
# Prüfen ob SCU-Kosten für Entity Analyzer auftauchen

Die GPT-4.1 Migration hat höchste Priorität – bestehende Deployments sind seit dem 11. April nicht mehr funktionsfähig. Parallel dazu lohnt ein erster Blick auf Azure MCP Server 2.0 – der lokale Test dauert 5 Minuten und gibt einen guten Eindruck, was agentic Cloud Automation in der Praxis bedeutet.

🔗 Azure OpenAI Model Retirements 🔗 Azure MCP Server Quick Start