Exchange-Kontakte per Graph API synchronisieren

Microsoft hat die Verwaltung von Kontakten in Exchange geändert. Früher wurden dafür EWS und PowerShell genutzt, heute setzt Microsoft in der Cloud auf Microsoft Graph. EWS bleibt nur noch für lokale Exchange-Server relevant. Für moderne Automatisierung und Synchronisation ist Graph der neue Standard.

Architektur und Schnittstellen

Exchange speichert Kontakte im Postfach eines Benutzers. Diese persönlichen Kontakte sind nicht dasselbe wie die Einträge im globalen Adressbuch (GAL).

• GAL-Kontakte werden zentral in Entra ID gepflegt.
• Persönliche Kontakte liegen dagegen im gleichen Container wie E-Mails, Termine oder Aufgaben.

Diese Trennung bleibt auch in der Cloud bestehen.

Früher griff man auf persönliche Kontakte über EWS zu. EWS ist eine SOAP-API und konnte alles: Kontakte lesen, anlegen, ändern und löschen. Administratoren nutzten sie oft für Skripte, Migrationen oder CRM-Integrationen. Mit Microsoft 365 verschiebt sich der Fokus auf REST-Endpunkte, die Microsoft im Graph bündelt.

Microsoft Graph ist mehr als ein Nachfolger von EWS. Es ist eine einheitliche Plattform für Microsoft 365, Entra ID, Teams, SharePoint, Intune und Windows-Dienste. Über Graph lassen sich Daten mit einem einheitlichen Authentifizierungsmodell abrufen. Die API nutzt offene Standards: OAuth 2.0 für die Anmeldung, OData für Filter und JSON für den Datenaustausch. Sie ist damit nicht auf Exchange beschränkt.

Graph dient als Gateway zu allen Cloud-Daten. Der Zugriff erfolgt per REST-Aufruf oder über das Microsoft Graph PowerShell SDK. Damit können Administratoren in PowerShell dieselben Operationen ausführen wie Apps, die Graph nutzen.

Exchange On-Premises und Entra Connect

Die Verwaltung von Kontakten in lokalen Exchange-Servern läuft weiterhin über EWS oder PowerShell. Die Verbindung zur Cloud erfolgt über Microsoft Entra Connect (früher Azure AD Connect). Dieses Tool synchronisiert Benutzer, Gruppen und Kontakte aus dem lokalen Active Directory in die Cloud. So können Exchange Online und Teams die Daten im globalen Adressbuch nutzen.

Wichtig: Postfachinhalte werden nicht automatisch synchronisiert. Persönliche Kontakte, die ein Benutzer in Outlook oder OWA erstellt, bleiben lokal. Wer diese Kontakte in die Cloud bringen will, braucht eine eigene Schnittstelle, z. B. ein Skript, das über EWS liest und über Graph schreibt.

Für hybride Organisationen gilt: Solange Postfächer noch lokal sind, ist EWS unverzichtbar. Erst wenn alle Benutzer in Exchange Online liegen, kann vollständig auf Microsoft Graph umgestellt werden.

Exchange Online und Unified Contacts

In Exchange Online verwendet Microsoft ein vereinheitlichtes Kontaktmodell. Persönliche Kontakte werden von Outlook, Teams und anderen Diensten gemeinsam genutzt. Ein neu angelegter Kontakt in Outlook erscheint automatisch in Teams und kann dort für Anrufe oder Chats verwendet werden. Dieses Konzept heißt Unified Contacts: beide Anwendungen greifen auf dasselbe Postfachobjekt zu.

Die Vereinheitlichung betrifft nicht nur die Anzeige, sondern auch die Speicherung. Änderungen in Outlook oder Teams werden über Microsoft Graph synchronisiert. So entstehen keine doppelten Daten. Das Modell bereitet den Wechsel von EWS zu Graph vor.

Für den Zugriff über Graph wird immer ein gültiges OAuth-Token benötigt. Fehlermeldungen wie „Access token is empty“ zeigen, dass das Token fehlt, abgelaufen ist oder der HTTP-Header „Authorization“ fehlt. Graph akzeptiert nur Anfragen mit:

Der Token darf weder leer noch abgelaufen sein und muss für die Ressource „https://graph.microsoft.com“ ausgestellt sein. Wird die API im Browser ohne Anmeldung aufgerufen, antwortet der Dienst immer mit dieser Fehlermeldung.

Einstieg in Graph

Graph Explorer

In der Praxis empfiehlt sich der Einstieg über den Graph Explorer, da hier die Authentifizierung automatisch erfolgt.

• Anmeldung erfolgt automatisch über das Microsoft-Konto

• Berechtigungen wie Contacts.Read oder Contacts.ReadWrite lassen sich direkt vergeben

• API-Aufrufe können sofort getestet werden, z. B.:

Für automatisierte Skripte bietet sich das Microsoft Graph PowerShell SDK an. Mit folgendem Befehl stellen wir eine delegierte Verbindung her, mit der Kontakte des angemeldeten Benutzers über Get-MgUserContact -UserId me abgerufen werden.

App-only-Zugriff (ohne Benutzer)

Wer dagegen Anwendungstoken ohne Benutzerkontext verwendet, muss App-only-Authentifizierung einsetzen.

• App-Registrierung in Entra ID
• Über Entra ID ein Access Token per Client-ID, Secret oder Zertifikat angefordert.
• Delegierte Endpunkte wie „/me“ sind in diesem Modus nicht erlaubt. Stattdessen muss der Benutzer explizit angegeben werden:

•  Das Token muss über die Application Permission "Contacts.ReadWrite" verfügen, die zuvor im Mandanten genehmigt wurde.

Access Tokens sind standardmäßig eine Stunde gültig. Längere Skripte brauchen Token Renewal. Außerdem sollten Skripte Fehlercodes wie 401 (Unauthorized) oder 429 (Rate Limit) abfangen.

Praxisbeispiele

Das Graph PowerShell SDK bietet dafür Befehle wie Get-MgUserContact und New-MgUserContact, mit denen sich Kontakte automatisiert anlegen, bearbeiten oder löschen lassen.

Install-Module Microsoft.Graph.PersonalContacts -Scope CurrentUser -AllowClobber
Import-Module Microsoft.Graph.PersonalContacts -Force

Hier sind typische Anwendungsfälle:

• zentrale Organisationskontakte in alle Benutzerpostfächer importieren
• Kontakte aus Microsoft Lists oder SharePoint einlesen
• neue Zielpostfächer automatisch mit vordefinierten Kontakten bestücken

Ein praxisbewährter Ansatz besteht darin, beim Anlegen neuer Postfächer automatisch eine vordefinierte Kontaktliste bereitzustellen, die zentrale Ansprechpartner aus Personalwesen, IT oder Support enthält. Das zugehörige Skript überprüft vor dem Einfügen, ob ein Kontakt bereits vorhanden ist, um doppelte Einträge zu vermeiden. Die Authentifizierung erfolgt über eine in Entra ID registrierte Anwendung, die mit einem Zertifikat arbeitet und die Berechtigungen "Users.Read.All" sowie "Contacts.ReadWrite" besitzt. Wenn die Kontaktinformationen aus einer Microsoft List stammen, wird zusätzlich "Sites.Manage.All" oder "Sites.Read.All" verwendet, um die Datenquelle zu lesen.

Weitere praktische Beispiele zur Verwaltung von Microsoft 365‑Gruppen per Graph PowerShell finden Sie im Artikel Verwalten von Gruppen in Microsoft 365 mit Graph PowerShell.

EWS-Rückbau und Funktionslücken in Graph

Microsoft plant, Exchange Web Services (EWS) in Exchange Online ab dem 01.10.2026 vollständig zu blockieren. Der Zugriff über EWS bleibt in lokalen Exchange-Servern weiterhin bestehen, wird dort jedoch nicht mehr weiterentwickelt.

Aktuell existieren noch einige Funktionslücken, die Graph bis zum Abschalttermin schließen soll:

• Zugriff auf Archivpostfächer, die bisher nur über EWS erreichbar sind
• Folder Associated Information und User Configuration, also Postfach-Metadaten
• Erweiterte Verwaltungsfunktionen für Exchange Online
• Programmgesteuerter Zugriff auf öffentliche Ordner, der künftig auf Outlook-Clients beschränkt wird

Nach Oktober 2026 erlaubt Microsoft nur noch das Lesen und Schreiben von öffentlichen Ordnern für unterstützte Outlook-Clients sowie für den Import oder Export großer Datenmengen. APIs zum Erstellen oder Bearbeiten dieser Ordner entfallen vollständig.

Microsoft empfiehlt Entwicklern,

• bestehende Integrationen frühzeitig zu prüfen,
• betroffene Anwendungen zu identifizieren,
• alle EWS-Aufrufe schrittweise durch Graph-Endpunkte zu ersetzen.

Sicherheit, Berechtigungen und Automatisierung

Microsoft Graph nutzt OAuth 2.0 für die Authentifizierung. Damit wird granular festgelegt, welche Daten eine Anwendung lesen oder ändern darf. Der Zugriff erfolgt über Access Tokens, die nur eine begrenzte Zeit gültig sind. Administratoren sollten sicherstellen, dass Tokens nicht unverschlüsselt gespeichert werden und regelmäßig erneuert werden.

Für automatisierte Abläufe gibt es zwei Möglichkeiten:

• App-Registrierungen in Entra ID mit Secrets oder Zertifikaten, die Tokens generieren
• Managed Identities in Azure Functions oder Logic Apps, die Tokens dynamisch zu beziehen ohne dass Geheimnisse im Code stehen

Dienste wie Logic Apps, Power Automate oder Azure Automation nutzen Graph intern ebenfalls. So lassen sich z. B. zentrale Kontakte automatisch aktualisieren, direkt in Cloud-Workflows, ohne manuelle Schritte.

Entwicklungsumgebung, Zugriffswerkzeuge und Praxisintegration

Für Administratoren und Entwickler ist die Wahl der richtigen Werkzeuge entscheidend, um Graph-Anwendungen produktiv einzusetzen.

• Graph Explorer: Browserbasiert, API-Aufrufe lassen sich direkt testen, kein Code nötig.

• SDKs: Für .NET, JavaScript, Python, PHP – ideal für lokale Entwicklungsumgebungen.

• PowerShell: Mit dem Microsoft Graph PowerShell SDK lassen sich alle REST-Endpunkte in Cmdlets nutzen.

Connect-MgGraph stellt die Verbindung her, sowohl interaktiv mit Benutzeranmeldung als auch App-basiert über Entra ID.

In komplexen Unternehmensszenarien sind Automatisierungen über Azure Functions, Logic Apps oder Power Automate üblich. Diese Dienste verwenden intern ebenfalls Graph-Connectoren. Bei langen Skripten muss die Gültigkeit der Access Tokens beachtet werden. Standardmäßig ist ein Token eine Stunde gültig, kann aber in bestimmten Szenarien durch Token Renewal verlängert werden. Für die Fehlerbehandlung empfiehlt Microsoft, auf Statuscodes wie 429 (Rate Limit) zu reagieren und Wiederholungslogik einzubauen.

Ein großer Vorteil von Graph: Verschiedene Datendienste lassen sich über einen Endpunkt ansprechen.

• Benutzer aus Entra ID,
• Teams-Kontakte,
• SharePoint-Listen und
• Exchange-Postfächer .

So lassen sich Informationen zu Personen, Gruppen, Geräten und Sicherheitsereignissen in gemeinsamen Workflows verknüpfen. Zum Beispiel durch Microsoft Graph Security API; Sicherheitswarnungen aus Defender, Sentinel oder Drittanbietern werden gesammelt und automatisierte Reaktionen über Logic Apps möglich.

Migration und organisatorische Auswirkungen

Für Unternehmen mit hybriden oder reinen Cloud-Umgebungen wird die Migration zu Graph zur Pflichtaufgabe. Die Umstellung betrifft nicht nur Anwendungen, sondern auch Berechtigungskonzepte, Audit-Prozesse und Sicherheitsrichtlinien. Graph ersetzt eine Vielzahl alter APIs wie ActiveSync, EWS, MAPI/HTTP, und bringt alle Microsoft 365-Dienste unter ein gemeinsames Sicherheitsmodell.

Administratoren sollten frühzeitig prüfen, welche internen Tools, Skripte oder Add-ins noch auf EWS basieren. Besonders betroffen sind Automatisierungen für Kontaktpflege, CRM-Synchronisation und Helpdesk-Systeme. Eine erfolgreiche Migration umfasst die Neuregistrierung der Anwendungen in Entra ID, das Ersetzen alter Endpunkte durch Graph-Aufrufe und die Überprüfung aller Berechtigungen.

Organisatorisch verändert sich damit auch die Frage, wo Kontakte verwaltet werden sollen. Lokale Postfächer, Cloud-Konten und hybride Szenarien lassen sich nur mit klar definierten Verantwortlichkeiten synchron halten. Viele Unternehmen verlagern ihre Kontaktverwaltung vollständig in die Cloud, um doppelte Pflege zu vermeiden und Unified Contacts zwischen Outlook und Teams zu nutzen.

Hier kann die my-IAM platform unterstützen: Sie bündelt Identitäts- und Kontaktdaten aus Active Directory, Entra ID, HR- oder CRM-Systemen und stellt sie in Echtzeit für Exchange Online und Teams bereit. Änderungen in einer Quelle greifen sofort auf alle angeschlossenen Systeme durch, ohne Skripte oder manuelle Abgleiche. In Verbindung mit PeopleConnect lassen sich diese Daten zentral in Teams, Outlook oder im Browser anzeigen. 

Strategischer Ausblick

Die Abkündigung von EWS markiert den Übergang zu einer neuen Integrationsära. Microsoft Graph vereint Exchange, Teams, SharePoint und Entra ID in einer Plattform, die nicht mehr nur Daten liefert, sondern auch Kontext, Sicherheit und Intelligenz integriert.

Für Administratoren bedeutet das: Kontaktverwaltung, Automatisierung und Compliance lassen sich in einem konsistenten System kombinieren. Der Wechsel ist mehr als ein technischer Schritt, er verändert, wie Organisationen ihre Kommunikationsstrukturen abbilden. Kontakte sind keine isolierten Objekte mehr, sondern Teil eines vernetzten Cloud-Ökosystems.

Der Folgeartikel „Kontakte in Exchange On-Premises und Online, Best Practices für moderne Unternehmen“ behandelt, welche Modelle sich für die zentrale Kontaktpflege eignen, wie sich Cloud- und On-Premises-Verzeichnisse harmonisieren lassen und welche Governance-Strukturen erforderlich sind, um die neue Architektur langfristig stabil zu betreiben.

Fazit

Die Migration zu Microsoft Graph ist kein reiner Technikwechsel, sondern eine Chance, die Kontaktverwaltung moderner, sicherer und automatisierter zu gestalten. Mit Plattformen wie my-IAM können Unternehmen interne und externe Kontakte zentral verwalten, Workflows automatisieren und Compliance gewährleisten.

Wer früh plant, alte EWS-Integrationen ersetzt und auf Graph setzt, schafft eine stabile Grundlage für die Zukunft und kann von Unified Contacts, dynamischen Gruppen und Echtzeit-Synchronisation profitieren.

Über welches Thema sollen wir als Nächstes schreiben? Senden Sie uns Ihre Themenwünsche, wir greifen sie in unseren nächsten Beiträgen auf.

Ideen senden