Dynamics 365 IIC und IBS

Dynamics 365 einrichten

Voraussetzungen und fachliche Hinweise für Dynamics-365-Integrationen mit IIC und IBS.

Aktualisiert: 2026-08-10 35 Minuten Lesezeit Zielgruppe: Administratoren und Key User

Ziel der Dynamics-Integration

Die Dynamics-365-Integration übergibt von Orimize vorbereitete Finanzdaten an das ERP. Für IIC betrifft das Eingangsrechnungen. Für IBS betrifft das Kontoauszüge, Buchungen oder vorbereitete Bankdaten.

Eine gute Einrichtung trennt technische Verbindung, fachliche Zielstruktur und produktspezifische Exportlogik.

Betriebsarten: Cloud Direct und On-Premises

Die bestehende Cloud-Direct-Anbindung verbindet Orimize direkt mit einem von der Cloud erreichbaren Dynamics-Endpunkt. Die folgenden allgemeinen Hinweise zu OData, IIC, IBS, Test und Monitoring gelten weiterhin für diese Betriebsart.

Ist Dynamics 365 Finance & Operations nur im Kundennetz erreichbar, wird stattdessen der Orimize On-Premises Connector eingesetzt. Seine Einrichtung ist im Abschnitt On-Premises Connector beschrieben. Beide Betriebsarten dürfen für dasselbe fachliche Ziel nicht gleichzeitig aktiv schreiben, da sonst doppelte Exporte entstehen können.

Allgemeine Voraussetzungen

Vor dem produktiven Einsatz sollten diese Punkte geklärt sein:

richtige Dynamics-Umgebung für Test oder Produktion.
Legal Entity beziehungsweise Gesellschaft.
Benutzer, App-Registrierung oder Service-Client mit passenden Berechtigungen.
erreichbare API- oder OData-Endpunkte.
Stammdaten für Lieferanten, Konten, Dimensionen, Bankkonten und Steuerlogik.
abgestimmter Umgang mit Fehlern und Wiederholungen.

OData-Metadatencache vorbereiten

Für Integrationen über OData sollte in Dynamics 365 Finance & Operations der OData-Metadatencache bereits beim Start des Application Object Server (AOS) aufgebaut werden. Dadurch ist der erste OData-Aufruf nach einem AOS-Neustart deutlich schneller und Export- oder Synchronisationsprozesse warten nicht erst auf den Cache-Aufbau.

Aktiviere die Option in Dynamics unter System administration > Setup > System parameters. Öffne dort den Tab General, aktiviere Build metadata cache when AOS starts und speichere die Änderung.

Wichtig: Die Option greift erst beim nächsten AOS-Neustart. Laut Microsoft sollte der AOS beim Aktivieren bereits laufen und mindestens einen OData-Request verarbeitet haben, damit der Cache initial aufgebaut ist. Siehe auch die Microsoft-Dokumentation zum OData metadata cache warm-up.

IIC: Export von Eingangsrechnungen

Bei Rechnungen müssen Dynamics-Zielobjekte und Pflichtfelder zu den erkannten IIC-Daten passen. Besonders wichtig sind Lieferant, Rechnungsnummer, Datum, Währung, Beträge, Steuerlogik, Kontierung und Dimensionen.

Wenn Dynamics eine Rechnung ablehnt, liegt die Ursache häufig in fehlenden Stammdaten, ungültigen Dimensionen, Pflichtfeldern oder Dublettenlogik.

Für die operative Arbeit im IIC-F&O-Modul gibt es einen eigenen Academy-Bereich:

IIC in Dynamics 365 F&O erklärt Arbeitsbereiche, Rechnungen, Journale, Workflows, Abfragen und Einstellungen.
Rechnungen: Kreditorenrechnungen beschreibt die zentrale Maske für importierte Kreditorenrechnungen.
Prozess: Rechnung übertragen und Journal prüfen erklärt den Ablauf von der validierten Rechnung zum Dynamics-Journal.

IBS: Export von Kontoauszügen

Bei Kontoauszügen müssen Bankkonto, Auszugsnummer, Buchungsdaten, Salden und Transaktionsreferenzen zum Dynamics-Prozess passen.

Wenn Dynamics Bankdaten ablehnt, prüfe Bankkonto-Stammdaten, Auszugszeitraum, Währung, doppelte Referenzen und Berechtigungen für den genutzten Service-Client.

Testen mit Debug-Modus

Nutze für die Einrichtung zuerst eine Testumgebung und aktiviere bei Bedarf den Debug-Modus. So können Dokumente verarbeitet werden, ohne produktive Buchungen oder ERP-Folgeaktionen auszulösen.

Erst wenn Testdaten stabil verarbeitet werden, sollte die Produktivumgebung aktiviert oder der Debug-Modus deaktiviert werden.

Betrieb und Monitoring

Im laufenden Betrieb sollten Administratoren regelmäßig fehlgeschlagene Exporte prüfen. Wiederkehrende Fehler sind ein Hinweis auf Stammdaten-, Mapping- oder Berechtigungsthemen.

Für Supportfälle sind Scope, Dokument-ID, Dynamics-Umgebung, Zielobjekt und konkrete Dynamics-Fehlermeldung entscheidend.

On-Premises Connector

Architektur und Sicherheitsgrenze

Der Connector läuft als Windows-Dienst im Kundennetz und baut Verbindungen ausschließlich ausgehend auf:

Orimize Cloud  <--- HTTPS 443 / Polling ---  On-Premises Connector  --->  D365FO / AD FS
                                                       |
                                                       +-- lokaler Secret- und Zertifikatsspeicher

Es ist keine eingehende Freigabe aus dem Internet zu Dynamics, AD FS oder zum Connector-Host erforderlich. Der Connector meldet seinen Zustand, claimt Arbeit mit einer zeitlich begrenzten Lease, lädt ein kurzlebiges Artefakt und führt den Auftrag lokal gegen Dynamics aus.

Die Cloud erhält ausschließlich Routing- und Betriebsdaten wie Connector-Gruppe, Zielreferenz, Contract-Version, Heartbeat, Auftragsstatus und technische Fehlercodes. Diese lokalen Geheimnisse dürfen nie an Orimize übertragen werden:

AD-FS-Passwörter oder Client-Secrets,
private Schlüssel und Zertifikatspasswörter,
Windows-Servicekonto-Passwörter,
lokale Proxy-Zugangsdaten,
exportierte PFX-Dateien oder andere D365-Anmeldeinformationen.

Private Schlüssel gehören in den Windows-Zertifikatsspeicher; andere lokale Geheimnisse in den vom Connector unterstützten Windows-Secretspeicher. Sie gehören weder in Portal-Felder noch in Support-Tickets, Logs, DLQ-Einträge oder Backups im Klartext.

Voraussetzungen und Wahl zwischen OData und DMF

Prüfe vor der Installation:

Die eingesetzte D365FO-Version und das Plattform-Update müssen in der für den Connector-Release veröffentlichten Kompatibilitätsmatrix freigegeben sein. Eine pauschale Mindestversion ist nicht ausreichend; Custom Entities und Hotfix-Stand gehören in den Abnahmetest.
DNS, Uhrzeit und Zertifikatsketten müssen auf allen Connector-Hosts korrekt sein. Größere Zeitabweichungen führen zu Token-, Lease- und Artefakt-TTL-Fehlern.
Die benötigten Data Entities, Legal Entities, Nummernkreise, Dimensionen, Steuergruppen, Bankkonten und Journalnamen müssen in der Zielumgebung vorhanden sein.
Eine getrennte D365-Test- oder UAT-Umgebung muss für den ersten Durchlauf verfügbar sein.

Nutze OData, wenn einzelne Datensätze oder kleine Composite-Vorgänge synchron und mit unmittelbarer fachlicher Rückmeldung geschrieben werden. OData eignet sich besonders für kontrollierte IIC-Header-/Zeilenfolgen und IBS-Operationen, bei denen einzelne Fehler präzise zurückgemeldet werden sollen.

Nutze Data Management Framework (DMF), wenn die D365-Version oder die Ziel-Entity den Vorgang nur als Datenpaket unterstützt, wenn größere Batches verarbeitet werden oder wenn Staging, Importjobs und deren Status Teil des gewünschten Prozesses sind. DMF benötigt zusätzliche Rechte auf Datenprojekte, Paket-Upload und Jobstatus. Die Wahl wird pro freigegebenem Ziel festgelegt; ein automatischer Wechsel zwischen OData und DMF im Fehlerfall ist nicht zulässig.

Connector-Gruppen und Hochverfügbarkeit

Eine Connector-Gruppe beschreibt ein logisches On-Premises-Ziel. Alle Instanzen einer HA-Gruppe müssen dieselbe freigegebene Contract-Version und dieselbe fachliche Zielkonfiguration verwenden.

Installiere für HA mindestens zwei Instanzen auf getrennten Windows-Hosts und nach Möglichkeit in unterschiedlichen Fehlerdomänen.
Jede Instanz sendet eigene Heartbeats. Ein Auftrag darf durch Claim und Lease immer nur einer Instanz gehören.
Lease-Verlust ist kein Grund, denselben Auftrag lokal weiterzuführen. Die Instanz muss die Verarbeitung stoppen; die neue Lease-Inhaberin übernimmt.
Idempotency-Keys müssen bei Wiederholung unverändert bleiben. Damit verhindert Dynamics beziehungsweise der lokale Connector doppelte Buchungen nach Timeout, Prozessabbruch oder Failover.
Plane Wartungen nacheinander: erst eine Instanz drainen und aktualisieren, dann die zweite.

Firewall, DNS, Proxy und TLS

Erlaube vom Connector-Host aus nur die tatsächlich benötigten Ziele. Die konkreten Werte werden bei Bereitstellung tenant- und umgebungsspezifisch angegeben:

https://<TENANT-API-FQDN> für Enrollment, Heartbeat, Claim und Status,
https://<ARTIFACT-FQDN> für kurzlebige Auftragsartefakte,
https://<ADFS-FQDN> und https://<D365FO-FQDN> im Kundennetz,
erforderliche CRL-/OCSP-Ziele der eingesetzten Zertifikatsketten,
gegebenenfalls https://<PROXY-FQDN> nach dem Sicherheitsstandard des Kunden.

Alle Werte in spitzen Klammern sind Platzhalter und müssen durch die für die Umgebung freigegebenen FQDNs ersetzt werden. Keine pauschalen Wildcard-Freigaben einrichten, wenn exakte Ziele verfügbar sind. Ausgehend wird normalerweise TCP 443 benötigt; eingehende Internet-Regeln für den Connector sind nicht erforderlich.

Stabile Windows-Prüfungen mit expliziten Platzhaltern:

Resolve-DnsName "<TENANT-API-FQDN>"
Test-NetConnection "<TENANT-API-FQDN>" -Port 443
Test-NetConnection "<D365FO-FQDN>" -Port 443

Der Windows-Dienst muss denselben Proxy-Weg nutzen können wie das dedizierte Servicekonto. Eine interaktive Browseranmeldung beweist nicht, dass WinHTTP- oder Service-Proxyregeln funktionieren. TLS-Inspektion ist nur zulässig, wenn deren Root-CA im Computer-Zertifikatsspeicher vertraut wird. Zertifikatsprüfung niemals deaktivieren; mindestens TLS 1.2 gemäß Connector-Release voraussetzen.

Installationspaket und Versionierung

Für Kundeninstallationen und Upgrades nur das signierte Kundenartefakt aus der freigegebenen Release-/Sign-Pipeline verwenden. Unsigned CI-Builds aus der normalen Build-Pipeline dienen der internen Validierung und sind nicht für produktive Kundensysteme vorgesehen.

Release-Tags folgen dem Muster connector-vX.Y.Z und setzen Binary-, MSI- und Paketversion. Installiere Upgrades mit dem MSI derselben Produktfamilie; Enrollment und lokale Secrets bleiben unter den ProgramData-Pfaden erhalten, sofern der Installationsleitfaden nichts anderes verlangt.

Dediziertes Windows-Servicekonto

Für den produktiven Betrieb ist ein gMSA (Group Managed Service Account) der Standard. NetworkService oder ähnliche eingebaute Konten sind nur für ausdrücklich freigegebene interne Smoke-Tests zulässig.

Recht Anmelden als Dienst, aber keine lokalen Administratorrechte für den gMSA,
Leserecht auf den privaten Schlüssel eines Connector-Clientzertifikats, falls Zertifikatsauth genutzt wird,
Vollzugriff nur auf die freigegebenen ProgramData-Pfade des Connectors (Konfiguration, Secrets, Journal, Artefakte),
kein Zugriff auf Benutzerprofile, Freigaben oder Datenbanken, die der Connector nicht benötigt,
dokumentierter Owner sowie Ablauf- und Rotationstermin.

Der Connector-Dienst darf nicht unter einem persönlichen Administratorkonto oder LocalSystem betrieben werden. Der Installationsbenutzer benötigt Elevation; der gMSA selbst nicht.

Prüfe nach der Installation:

Get-CimInstance Win32_Service -Filter "Name='<CONNECTOR-SERVICE-NAME>'" |
  Select-Object Name, State, StartMode, StartName
Test-ADServiceAccount <GMSA-SAMACCOUNTNAME>

Identitätsanbieter: AD FS statt Entra-Cloud-App

Für on-premises erreichbare D365FO-Umgebungen mit AD FS gehört die OAuth-Client-Registrierung in AD FS (Application Group / Server Application) auf dem freigegebenen AD-FS-Host – nicht in eine Microsoft-Entra-ID-Cloud-App-Registrierung. Eine Entra-Client-ID ist für AD FS unbekannt und führt zu Fehlern wie invalid_client / „No registered client is found“.

Cloud-Direct-Szenarien mit Entra bleiben davon unberührt; sie gelten nur, wenn Dynamics und Auth von der Cloud aus freigegeben sind.

AD FS, Anwendung, Zertifikate und D365-Rollen

Richte für den Connector eine eigene AD-FS-Anwendung beziehungsweise Application Group ein. Verwende getrennte IDs und Zertifikate für Test und Produktion.

Registriere Client-ID, Token-Endpoint (https://<ADFS-FQDN>/adfs/oauth2/token) und den exakten D365-Ressourcenbezeichner (typisch die D365-Basis-URL ohne abweichenden Slash oder Alias).
Bevorzuge zertifikatbasierte Clientauthentifizierung. Importiere das Zertifikat mit privatem Schlüssel in den Computer-Zertifikatsspeicher des Connector-Hosts und erteile nur dem Servicekonto Leserecht.
Hinterlege lokal Token-Endpoint, Client-ID, Resource, D365-Basis-URL und Zertifikat-Thumbprint beziehungsweise Client-Secret. Der private Schlüssel und das Secret werden nicht in Orimize eingetragen.
Ordne dem technischen D365-Prinzipal nur die Rollen und Berechtigungen für die ausgewählten OData-Entities oder DMF-Datenprojekte zu. Trenne IIC- und IBS-Rechte, wenn der betriebliche Rollenstandard dies verlangt.
Prüfe Audience, Issuer, Zertifikatskette und Uhrzeitsynchronisation in der UAT-Umgebung.

Wenn eine ältere D365FO-/AD-FS-Konstellation nur ein Secret unterstützt:

Verwende das Secret-Value (den geheimen Schlüssel), niemals die Secret-ID.
Das Value wird bei Entra-/Portal-ähnlichen UIs oft nur einmal beim Anlegen angezeigt; fehlt es, muss ein neues Secret erzeugt werden.
Das Secret liegt ausschließlich lokal im freigegebenen Windows-Secretspeicher des Connectors. Es ist kein Cloud-Secret und darf nicht in Connector-Gruppe, API-Antwort oder Logmeldung erscheinen.

Manueller Token-Smoke-Test (Platzhalter ersetzen, Secret nicht protokollieren):

$body = @{
  grant_type    = 'client_credentials'
  client_id     = '<ADFS-CLIENT-ID>'
  client_secret = '<ADFS-CLIENT-SECRET-VALUE>'
  resource      = 'https://<D365FO-FQDN>'
}
Invoke-RestMethod -Method Post `
  -Uri 'https://<ADFS-FQDN>/adfs/oauth2/token' `
  -ContentType 'application/x-www-form-urlencoded' `
  -Body $body

Empfohlene Installationsreihenfolge

Preflight: DNS und TCP 443 zu Tenant-API, AD FS und D365FO; gMSA vorhanden und auf dem Host installiert.
Signiertes MSI installieren, Dienstkonto = gMSA, Dienst startet verzögert automatisch.
Im Portal Connector-Gruppe anlegen und Zielsystem mit Routing On-Premises Connector sowie dem freigegebenen Profile Key anlegen (Company/Legal Entity nach fachlicher Vorgabe).
One-Time-Enrollment-Token erzeugen und lokal enrollen.
Lokales D365-Profil (configure-target) mit exakt demselben Profile Key wie im Portal setzen.
Nach CLI-Schritten, die Secrets schreiben, NTFS-ACLs auf dem Secrets-Verzeichnis für den gMSA wiederherstellen (siehe unten) und Dienst neu starten.
Im Portal Heartbeat/Online prüfen, danach Verbindungstest (Stages dns → token → odata).
Kleinen fachlichen IIC-/IBS-UAT-Lauf fahren, bevor produktiv freigegeben wird.

Enrollment

Enrollment verbindet eine lokale Installation einmalig mit einer Connector-Gruppe:

Lege im Orimize-Portal die Connector-Gruppe und eine nicht geheime Zielreferenz an. Der Profile Key der Zielreferenz muss später exakt dem lokalen Profilnamen entsprechen.
Erzeuge für genau diese Installation ein kurzlebiges One-Time-Enrollment-Token.
Melde dich am Connector-Host als Installationsadministrator an und übergib das Token über die freigegebene CLI (stdin, niemals als MSI-Property oder Klartextargument in Skripten). Beispielmuster:

"<ENROLLMENT-TOKEN>" |
  & "${env:ProgramFiles}\Orimize\Connector\cli\Orimize.Connector.Cli.exe" enroll `
    --api "https://<TENANT-API-FQDN>" `
    --token-stdin

Der Connector tauscht das Token einmalig gegen seine Connector-Identität aus und speichert diese lokal geschützt.
Entferne das Enrollment-Token aus Zwischenablage, temporären Dateien und der administrativen Shell-Historie. Eine zweite Verwendung muss abgelehnt werden.
Prüfe im Portal den ersten Heartbeat, Host/Instanz, Contract-Version und Gruppenzuordnung. Status Ausstehend bedeutet: noch kein frischer Heartbeat; Online typischerweise bei Heartbeat innerhalb weniger Minuten.

Ein Enrollment-Token ist kein dauerhaftes Laufzeit-Credential und gehört nicht in Images, Gruppenrichtlinien, Skripte oder Backups.

Lokale Target-Konfiguration

Konfiguriere pro Ziel lokal mindestens:

D365FO-Basis-URL (HTTPS) und OData-Root gemäß Umgebung (häufig /namespaces/AXSF/data),
AD-FS-Token-Endpoint, Resource und Client-ID,
Client-Secret (stdin) oder Zertifikat-Thumbprint,
denselben stabilen Profile Key wie in der Portal-Zielreferenz,
Timeouts und TLS-Verifikation (TLS nicht abschalten; ausstellende CA im Windows-Trust-Store).

Beispielmuster (Secret nur über stdin; Profile Key und URLs sind Platzhalter):

"<ADFS-CLIENT-SECRET-VALUE>" |
  & "${env:ProgramFiles}\Orimize\Connector\cli\Orimize.Connector.Cli.exe" configure-target `
    --profile "<PROFILE-KEY>" `
    --d365 "https://<D365FO-FQDN>" `
    --token-endpoint "https://<ADFS-FQDN>/adfs/oauth2/token" `
    --resource "https://<D365FO-FQDN>" `
    --client-id "<ADFS-CLIENT-ID>" `
    --set-secret --secret-stdin

Speichere niemals private Schlüssel, Passwörter oder Client-Secrets in der Cloud-Zielreferenz. Config-Version im Portal leer lassen oder als Ganzzahl führen; gebrochene Versionsstrings sind zu vermeiden.

ACLs nach CLI-Wartung (gMSA)

CLI-Befehle wie enroll und configure-target laufen oft unter einem interaktiven Administratorkonto. Dabei kann das Secrets-Verzeichnis vorübergehend auf dieses Konto gehärtet werden. Der Dienst startet dann als gMSA nicht mehr oder Heartbeats/Claims scheitern mit Access Denied.

Nach solchen CLI-Schritten als Administrator die ACLs auf dem Secrets-Pfad wieder auf gMSA, SYSTEM und lokale Administratoren setzen und den Dienst neu starten. In PowerShell müssen Namen mit abschließendem $ (gMSA) in einfachen Anführungszeichen stehen, sonst interpretiert PowerShell $ als Variable. Sprachneutrale SIDs (*S-1-5-18 für SYSTEM, *S-1-5-32-544 für Administratoren) sind robuster als lokalisierte Gruppennamen.

$secrets = "$env:ProgramData\Orimize\Connector\secrets"
icacls $secrets /inheritance:r `
  /grant:r '<DOMAIN>\<GMSA-SAMACCOUNTNAME>$:(OI)(CI)F' `
  /grant:r '*S-1-5-18:(OI)(CI)F' `
  /grant:r '*S-1-5-32-544:(OI)(CI)F'
Get-ChildItem $secrets -Force | ForEach-Object {
  icacls $_.FullName /inheritance:r `
    /grant:r '<DOMAIN>\<GMSA-SAMACCOUNTNAME>$:(F)' `
    /grant:r '*S-1-5-18:(F)' `
    /grant:r '*S-1-5-32-544:(F)'
}
Restart-Service <CONNECTOR-SERVICE-NAME>

Prüfe anschließend, dass der gMSA (nicht das Installationsbenutzerkonto) auf dem Secrets-Ordner steht.

Test und Aktivierung

Führe die Abnahme in dieser Reihenfolge durch:

DNS-, TCP-443-, Proxy- und TLS-Prüfung zu Cloud, AD FS und D365. Eine erfolgreiche interaktive DNS-Auflösung beweist nicht automatisch, dass der Dienstkontext (gMSA) auflösen kann; bei „Host unbekannt“ trotz funktionierendem Test-NetConnection DNS/Proxy im Maschinen-/Dienstkontext prüfen, Cache leeren und Dienst neu starten.
AD-FS-Tokenabruf (client_credentials) und rein lesender D365-OData-Zugriff (z. B. LegalEntities).
Heartbeat im Portal (Status Online) sowie Claim/Lease ohne produktive Buchung.
Portal-Verbindungstest: Stages dns, token, odata müssen SUCCEEDED sein. Mit gesetzter Company filtert der Test LegalEntities über LegalEntityId (nicht dataAreaId); company-gebundene Entities nutzen weiterhin dataAreaId.
Ein kleines IIC-Composite mit Header und Zeilen; prüfe Erfolg und gezielten partiellen Validierungsfehler.
Einen IBS-Test mit Determine und Lines; erzwinge einen Lines-Fehler und bestätige den Rollback. Ein Determine-Fehler darf keinen Rollback auslösen, weil noch nichts geschrieben wurde.
Retry, temporäre Offline-Phase, DLQ und Replay mit demselben Idempotency-Key.
HA-Failover, indem eine Instanz nach Lease-Übernahme kontrolliert beendet wird.
Fachliche Prüfung der erzeugten Testdaten in D365. Wenn Dynamics den Datensatz enthält, das Portal aber noch einen Verarbeitungsfehler zeigt, zuerst D365 und Connector-/Worker-Version prüfen (Teilerfolg oder bereits behobene Status-Auswertung), bevor blind erneut exportiert wird.

Aktiviere das produktive Ziel erst nach technischer und fachlicher Freigabe. Stelle vor der Aktivierung sicher, dass Cloud Direct für dasselbe Ziel deaktiviert ist.

Monitoring und DLQ

Überwache im Portal Connector-Gruppe, letzte Heartbeats, Contract-Version, Claim-/Lease-Zustand, Erfolgsquote, Retry-Anzahl und DLQ. Lokal gehören Windows-Dienststatus, Eventlog, freier Speicher, Zertifikatsablauf, Proxy-/TLS-Fehler und Größe der lokalen DLQ in das Monitoring.

Get-Service -Name "<CONNECTOR-SERVICE-NAME>"
Get-WinEvent -LogName Application -MaxEvents 100 |
  Where-Object ProviderName -eq "<CONNECTOR-EVENT-PROVIDER>"

<CONNECTOR-SERVICE-NAME> und <CONNECTOR-EVENT-PROVIDER> sind releaseabhängige Platzhalter. Logs und DLQ dürfen Dokument- oder Auftrags-IDs und stabile Fehlercodes enthalten, aber keine Payloads, Tokens, Passwörter, Client-Secrets oder privaten Schlüssel.

DLQ-Einträge erst nach Behebung der Ursache wiederholen. Replay muss denselben Idempotency-Key verwenden. Bei fachlich unklarem Teilerfolg zuerst in Dynamics prüfen, bevor ein Auftrag erneut freigegeben wird.

Rotation, Upgrade und Backup

Rotiere AD-FS-Zertifikate mit Überlappung: neues Zertifikat bereitstellen, Berechtigung und Tokenabruf testen, lokal umschalten, danach das alte Zertifikat sperren oder entfernen.
Rotiere die Connector-Identität über den vorgesehenen Portal-/Installer-Workflow. Enrollment-Token nicht als dauerhaftes Credential wiederverwenden.
Aktualisiere HA-Instanzen nacheinander und prüfe nach jeder Instanz Heartbeat, Contract-Version und einen Testclaim. Keine Instanz mit inkompatibler Contract-Version aktiv lassen.
Sichere nur verschlüsselte lokale Konfiguration, notwendige Zustands-/Idempotency-Daten und dokumentierte Zertifikat-Wiederherstellungsverfahren. Enrollment-Token, Klartext-Secrets und ungeschützte PFX-Dateien gehören nicht ins Backup.
Teste Restore und Zertifikatsberechtigungen regelmäßig auf einem isolierten Host.

Troubleshooting

Dienst startet nicht / Access Denied auf Secrets: Nach enroll/configure-target als Admin die ACLs für den gMSA wiederherstellen (siehe oben). Eventlog: UnauthorizedAccessException auf %ProgramData%\Orimize\Connector\secrets.
Kein Heartbeat / Status Ausstehend: Dienststatus, Enrollment vorhanden, DNS/Port 443 zur Tenant-API im Dienstkontext, WinHTTP-/Service-Proxy, TLS-Kette und Connector-Identität prüfen. Erfolgreiche Heartbeats erscheinen oft nicht als Warning im Eventlog; fehlgeschlagene schon (Heartbeat cycle failed).
Host unbekannt trotz funktionierendem interaktivem DNS: Maschinen-DNS, Split-DNS/VPN nur für Benutzerkontext, WinHTTP-Proxy (netsh winhttp show proxy), ipconfig /flushdns, Dienst neu starten.
Heartbeat vorhanden, keine Claims: Gruppenzuordnung, Zielaktivierung, Profile Key, Contract-Version, Drain-/Wartungsstatus und verfügbare Arbeit prüfen.
AD FS invalid_client: Client-ID muss aus der AD-FS Application Group stammen (nicht Entra-Cloud). Resource und Token-URL exakt prüfen.
AD FS 401/403 / invalid_client_secret: Secret-Value statt Secret-ID, Zertifikat-Thumbprint, private-key ACL, D365-Rolle und Systemzeit prüfen.
Verbindungstest token FAILED, dns OK: Token-Endpoint, Client-ID/Secret oder Zertifikat; manuellen Token-Smoke-Test nutzen.
Verbindungstest odata FAILED, Token OK: OData-Root, App-User/Rollen in D365, Entity-Freigabe, Legal Entity/LegalEntityId, Metadatencache. Lesenden Aufruf gegen LegalEntities mit demselben Token prüfen.
OData 404 oder Metadatenfehler: D365-Version, Entity-Name, Data-Entity-Freigabe, Legal Entity und Metadatencache prüfen. Der Root /data ist nicht in jeder Umgebung gültig; häufig /namespaces/AXSF/data.
DMF-Fehler: Datenprojekt, Paketformat, Staging-/Importjob, Jobberechtigungen und D365-Jobprotokoll prüfen.
Portal meldet Exportfehler, Datensatz existiert in D365: Zuerst in Dynamics prüfen, ob Header/Zeilen vollständig sind. Teilerfolg, verzögerte Statusauswertung oder veraltete Worker-/Connector-Version können den Portalstatus verzerren; nicht blind erneut schreiben.
Lease lost: lokalen Auftrag sofort stoppen. In einer HA-Gruppe kann eine andere Instanz die Lease übernommen haben; nicht manuell parallel fortsetzen.
SHA256- oder TTL-Fehler: Systemzeit, Proxy-Cache, unvollständigen Download und erneuten Claim prüfen. Artefakte nicht manuell verändern oder dauerhaft speichern.
Wachsende DLQ: Fehlercode gruppieren, Ursache zuerst beheben und Replay kontrolliert in kleinen Mengen ausführen.
Verdacht auf Secret-Leak: Logs/DLQ sperren, betroffenes Secret oder Zertifikat rotieren und den Incident-Prozess starten.

Rollback

Bei einer fehlerhaften Aktivierung:

Ziel beziehungsweise Connector-Gruppe im Portal pausieren und aktive Leases auslaufen oder kontrolliert drainen lassen.
Prüfen, welche Aufträge in Dynamics vollständig, teilweise oder gar nicht geschrieben wurden.
DLQ und offene Aufträge nicht blind wiederholen; Idempotency- und Rollback-Status sichern.
Auf die zuletzt freigegebene Connector-Version und die dazu passende verschlüsselte lokale Konfiguration zurückgehen.
Einen technischen und fachlichen UAT-Auftrag ausführen, bevor die Gruppe erneut aktiviert wird.

Ein Rückwechsel auf Cloud Direct ist nur möglich, wenn Dynamics wieder sicher von der Cloud erreichbar ist, die Direct-Konfiguration separat getestet wurde und der On-Premises-Schreibpfad vollständig deaktiviert ist. Lokale D365-Geheimnisse werden dabei nicht in die Cloud migriert.