Connector Installation Schritt für Schritt

Diese Anleitung führt Bildschirm für Bildschirm durch die Installation des Documents Partner API Connector auf einem Windows-Server. Sie ist zum Mitlesen gedacht, während man vor der Maschine sitzt.

Die Abbildungen stammen von einem deutschen Windows-11-Rechner.

Alle Werte auf den Bildern, die wie Platzhalter aussehen, sind Platzhalter. Es ist kein einziger echter Kundenwert abgebildet. In den beiden Anmeldekonsolen wurde der echte Hostname nachträglich durch <mandant>.stp-cloud.de ersetzt. Überall dort, wo ein geschwärzter Wert eine Rolle spielt, sagt der Text daneben, was dort hingehört.

Bevor es losgeht

Diese Angaben sollten bereitliegen. Nach der ersten fragt der Assistent zwingend, die beiden anderen bietet er an:

Anforderungen an den Rechner

Zur Mindestversion des Dokumentenmanagements. Verlangt ist v8.8.16 (Build 8.8.195.16) – die aktuell im STP Downloadportal verfügbare Fassung.

Die Angabe ist bewusst auf den vollständigen Build genau und nicht auf „8.8 oder neuer“ gerundet: Innerhalb der 8.8-Reihe wurden Bestandteile der Server-Infrastruktur mehrfach angepasst, und ein älterer Stand derselben Reihe kann deshalb nicht als verträglich zugesagt werden. Auf einem solchen Stand können Aufrufe fehlschlagen, ohne dass es dafür eine aussagekräftige Meldung gibt.

Wenn Sie unsicher sind, welche Fassung bei Ihnen läuft, klären Sie das mit dem STP-Service, bevor Sie den Connector installieren.

1. Voraussetzung installieren: .NET Runtime 10 (x64)

Der Connector wird ohne eingebettete Laufzeitumgebung ausgeliefert. Die .NET-Laufzeit ist also nicht Teil des Installationspakets und muss vorher auf dem Rechner vorhanden sein.

Download-Seite: https://dotnet.microsoft.com/download/dotnet/10.0

Es werden zwei Laufzeitumgebungen benötigt, und der Installer der ASP.NET Core Runtime bringt die .NET Runtime nicht mit. Es gibt daher zwei Wege:

Beide Installer als Administrator ausführen und die Vorgaben übernehmen. Danach prüfen:

dotnet --list-runtimes

Beide Zeilen müssen mit einer 10.*-Version erscheinen:

Microsoft.AspNetCore.App 10.0.x [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App    10.0.x [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Wie es aussieht, wenn sie fehlen

Wird das Installationspaket ohne die Laufzeitumgebungen gestartet, bricht es gleich zu Beginn ab – es verweigert die Installation, statt einen Dienst einzurichten, der nie starten könnte:

„Die Microsoft .NET Runtime 10 (x64) inklusive ASP.NET Core Runtime ist auf diesem Computer nicht installiert. Bitte installieren Sie sie von https://dotnet.microsoft.com/download/dotnet/10.0 und starten Sie das Setup danach erneut.”

Dahinter steht eine Prüfung, die unter C:\Program Files\dotnet\shared\ nach einem 10.*-Ordner für beide Laufzeitumgebungen sucht. Ein Rechner mit nur .NET 9 oder mit nur einer der beiden wird also hier abgefangen und nicht erst drei Minuten später im Ereignisprotokoll. Laufzeitumgebungen installieren und das Installationspaket erneut starten.

Unbeaufsichtigte Installationen laufen in dieselbe Prüfung und enden mit einem Rückgabewert ungleich null.

2. Willkommensseite

Documents Partner API Connector by SEPTEO <version>.msi als Administrator starten.

Hier ist nichts zu entscheiden – „Weiter >“.

Es gibt weder eine Lizenzseite noch eine Seite für Benutzer- und Firmenangaben: Ein Dienstinstaller für den ganzen Rechner braucht beides nicht.

3. Setuptyp

„Vollständig“ ausgewählt lassen und mit „Weiter >“ fortfahren.

„Benutzerdefiniert“ existiert nur, um das Installationsverzeichnis zu ändern. Das Produkt besteht aus einer einzigen Komponente, es gibt also nichts abzuwählen. Der Weg dorthin ist zugleich die schnellste Möglichkeit, das Zielverzeichnis zu sehen, ohne etwas zu ändern:

C:\Program Files\SEPTEO\Documents Partner API Connector\

Der Komponentenbaum enthält genau einen Eintrag – Documents Partner API Connector by SEPTEO, rund 11 MB. Deshalb installieren „Vollständig“ und „Benutzerdefiniert“ dasselbe. „Ändern…“ verschiebt das Verzeichnis, alles Übrige auf dieser Seite ist reine Information.

4. Verbindungskonfiguration

Das ist der eine Wert, den der Connector wirklich braucht: der Mandant.

Den Mandantennamen in „Mandant (Tenant)“ eintragen – den ersten Teil der STP-Cloud-Anmeldeadresse (https://<mandant>.stp-cloud.de) aus den Zugangsunterlagen der Kanzlei. (Im Bild ist das Feld geschwärzt; ein echter Eintrag sieht aus wie kanzlei-mustermann.)

Was damit geschieht: Der Mandant wird zum Adressierungsziel des Connectors und bestimmt die beiden Anmeldeadressen, gegen die er sich anmeldet. Die Cloud-Umgebung selbst ist fest auf die STP-Produktivumgebung voreingestellt – die Seite fragt bewusst nach nichts weiter.

Das Feld darf leer bleiben. Der Dienst wird dann installiert, aber nicht konfiguriert, und wartet, bis der Mandant nachgetragen wird. Bei einer Aktualisierung ist der zuvor gespeicherte Mandant bereits eingetragen – er wird außerhalb des Installationsverzeichnisses abgelegt und zu Beginn jedes Laufs wieder eingelesen.

5. DMS-Verbindung (optional)

Die Zugangsdaten, mit denen sich der Connector mit dem lokalen LEXolution.DMS verbindet.

Die beiden Kennwortfelder maskiert der Assistent selbst. Die übrigen Werte im Bild sind Beispiele – bei Ihnen stehen dort die Angaben Ihres DMS-Administrators.

Es gilt alles oder nichts, und das ist Absicht:

• Alle vier Angaben ausgefüllt → Eine aktive Dms-Konfiguration wird geschrieben, der Connector spricht mit dem echten DMS.
• Irgendetwas leer gelassen → Stattdessen wird eine inaktive Vorlage geschrieben, die die eingegebenen nicht geheimen Werte (Host, Benutzernamen) enthält, damit sie niemand erneut eintippen muss. Kennwörter werden nie in die Vorlage geschrieben. Der Connector startet dann normal, liefert aber vorgefertigte Testdaten aus, bis die Vorlage vervollständigt und aktiviert wird. Das übernimmt der STP-Service.
• Eine vorhandene Dms-Konfiguration wird nie überschrieben – weder durch eine Neuinstallation noch durch eine Aktualisierung, gleich, was hier eingetragen wird.

Wo diese Kennwörter landen. Im Klartext in der Konfigurationsdatei des Connectors unter %ProgramData%\SEPTEO\Documents Partner API Connector, per Zugriffsrechten auf SYSTEM und Administratoren beschränkt. Im Installationsprotokoll sind sie maskiert und in die Registrierung werden sie nie geschrieben – ein lokaler Administrator kann sie allerdings während der Installation in der Prozess-Befehlszeile sehen. Ist das bei der Kanzlei nicht akzeptabel, diese fünf Felder leer lassen und die Zugangsdaten anschließend als Dms__*-Umgebungsvariablen am Dienst hinterlegen. Das ist die einzige Variante ohne ein Geheimnis auf der Festplatte.

Weiter mit „Weiter >“.

6. Proxy (optional)

Diese Seite entscheidet, wie der Connector ins Internet kommt. Ihre Unterzeile nennt die Regel: „Nur ausfüllen, wenn dieser Computer die STP Cloud ausschließlich über einen Proxy erreicht.” Auf einem Rechner mit direktem ausgehendem Zugang über Port 443 wird diese Seite komplett übersprungen – alles leer lassen und „Weiter >“.

Die vier Felder in der Reihenfolge, in der sie erscheinen:

Eine leere Adresse ändert nichts. Das ist kein Fehler und kein eingeschränkter Betrieb: Die Proxy-Einstellungen von Windows und die Umgebungsvariablen HTTP_PROXY / HTTPS_PROXY gelten unverändert weiter. Die anderen drei Felder sind dann bedeutungslos. Diese Seite wird nur ausgefüllt, wenn der Rechner die Cloud ohne Proxy nicht erreicht oder der Proxy eine Anmeldung verlangt.

⚠️ „Ausnahmen“ sind reguläre Ausdrücke, keine Platzhalter. Das ist das eine Feld dieser Seite, das zuverlässig für Verwirrung sorgt – *.firma.local ist nicht das, was erwartet wird. Richtig ist dms\.intern\.local, oder .*\.firma\.local für eine ganze Domäne; mehrere Einträge werden mit Semikolon getrennt. Ein ungültiger Ausdruck lässt den Dienst mit einer lesbaren Meldung nicht starten, statt den Eintrag stillschweigend zu ignorieren.

Was dann über den Proxy läuft. Alles, was der Connector in Richtung Cloud öffnet: die Verbindung zum Nachrichtenvermittler, die Anmelde- und Geräteanmeldungsaufrufe, das Abholen des Cloud-Schlüssels und die Dokumentübertragungen. Die Verbindung zum lokalen DMS ist nicht betroffen: Die läuft im Netz der Kanzlei und geht nie über einen Proxy.

„STP Cloud“ ist mehr als ein Ziel. Nur die Anmeldung und die Cloud-Schlüssel-Aufrufe gehen an https://<mandant>.stp-cloud.de. Der Nachrichtenvermittler ist AWS IoT Core (….iot.eu-central-1.amazonaws.com), und die Dokumentbytes laufen über signierte S3-Adressen – beides wird direkt bei AWS erreicht, außerhalb der Domäne stp-cloud.de. Eine Proxy- oder Firewall-Freigabeliste, die nur *.stp-cloud.de zulässt, blockiert daher die Verbindung zum Vermittler und jede Dokumentübertragung; die amazonaws.com-Adressen müssen ebenfalls freigegeben sein.

Der Dienst läuft als LocalSystem – die Proxy-Einstellungen eines Browsers gelten für ihn nicht. Der Hinweis auf der Seite sagt es ausdrücklich: „der Dienst läuft als LocalSystem und sieht die benutzerbezogenen Proxy-Einstellungen des Browsers nicht.” „Im Edge funktioniert es doch“ sagt also nichts darüber aus, ob der Connector hinauskommt. Wo der Proxy je Benutzer statt rechnerweit eingerichtet ist, ist diese Seite die einzige Möglichkeit, ihn dem Dienst mitzuteilen.

Wo das Proxy-Kennwort landet. Genau wie die DMS-Kennwörter aus Schritt 5: im Klartext in der Rechnerkonfiguration unter %ProgramData%\SEPTEO\Documents Partner API Connector, auf SYSTEM und Administratoren beschränkt, im Installationsprotokoll maskiert – und nie in der Registrierung. Dort werden nur Adresse, Benutzername und Ausnahmeliste abgelegt, damit der Assistent bei einer Aktualisierung vorausgefüllt erscheint. Weil das Kennwort nicht dabei ist, kommt eine Aktualisierung mit leerem Kennwortfeld daher, und der Installer übernimmt das bestehende Kennwort, statt einen funktionierenden Proxy zu leeren. Ist auch hier kein Geheimnis auf der Festplatte akzeptabel, „Proxy-Passwort“ leer lassen und Proxy__Password anschließend als Umgebungsvariable am Dienst setzen.

Weiter mit „Weiter >“. Über diese vier Felder hinaus gibt es weitere Proxy-Einstellungen – integrierte Anmeldung mit dem Computerkonto, eine NTLM-Domäne, die Regel für lokale Adressen –, nach denen der Assistent nicht fragt; sie werden als Installationsparameter übergeben oder von Hand in der Rechnerkonfiguration eingetragen.

7. Installation

Die Bestätigungsseite „Bereit das Programm zu installieren“ ist der letzte Punkt, an dem „< Zurück“ noch etwas ändern kann:

„Installieren“ startet den Kopiervorgang – das Schildsymbol auf der Schaltfläche bedeutet, dass Windows nach erhöhten Rechten fragt. Danach arbeitet der Assistent die Installation ab:

Die Statuszeile nennt den aktuellen Schritt; „Produkt wird registriert“ und „Dienste werden gestartet” sind die beiden entscheidenden, denn dort wird der Windows-Dienst angelegt und gestartet. Was in dieser Phase geschieht:

1. Die Programmdateien landen in C:\Program Files\SEPTEO\Documents Partner API Connector.
2. Der Dienst DocumentsPartnerApiConnector wird registriert – Anzeigename Documents Partner API Connector by SEPTEO, Konto LocalSystem, Starttyp automatisch – und gestartet.
3. Die Werte aus den Schritten 4 bis 6 werden nach %ProgramData%\SEPTEO\Documents Partner API Connector\appsettings.json geschrieben, außerhalb des Installationsverzeichnisses, damit sie jede künftige Aktualisierung überstehen. Die nicht geheimen Werte werden zusätzlich unter HKLM\SOFTWARE\SEPTEO\Documents Partner API Connector vermerkt, was den Assistenten bei einer späteren Aktualisierung vorausfüllt – ein Kennwort wird dort nie abgelegt.
4. Zwei Verknüpfungen namens „Documents Partner API Connector anmelden“ werden angelegt, eine im Startmenü und eine auf dem Desktop.

Die Schritte 2 und 3 erfolgen in dieser Reihenfolge – die Konfiguration wird vor dem Start des Dienstes geschrieben, sodass der Dienst seinen Mandanten von Anfang an kennt.

Mit „Fertig stellen“ abschließen. Diese Seite meldet ausschließlich, dass die Installation erfolgreich war – sie sagt nichts darüber, ob der Dienst die Cloud auch erreichen kann. Dafür sind die nächsten beiden Schritte da.

8. Den Dienst prüfen

Der Connector ist ein Windows-Dienst und sollte unmittelbar nach der Installation laufen:

Der Dienst hat zwei Namen, und beide sollte man kennen – services.msc zeigt den einen, PowerShell und die Registrierung verwenden den anderen:

Die Zeile muss den Dienst als laufend, den Starttyp als automatisch und das Konto LocalSystem zeigen – auf einem deutschen Windows also Wird ausgeführt / Automatisch / Lokales System, wie in der Abbildung. Aus PowerShell mit dem technischen Dienstnamen:

Get-Service DocumentsPartnerApiConnector | Format-List Name, DisplayName, Status, StartType

Die Beschreibung steht nicht in dieser Ausgabe – sie kommt aus WMI:

(Get-CimInstance Win32_Service -Filter "Name='DocumentsPartnerApiConnector'").Description

Nicht mit dem Nachbarn verwechseln. Wo der STP Documents On-Premise Agent for STP.Documents installiert ist, steht er in derselben Liste. Das ist ein anderer, unabhängiger STP-Dienst. Beide bestehen bewusst nebeneinander und keiner ersetzt den anderen. Unserer ist der, dessen Anzeigename auf by SEPTEO endet und dessen Beschreibung die Documents Partner API nennt; sein Dienstname lautet DocumentsPartnerApiConnector.

Die Installation erscheint auch unter „Apps & Features“ – der schnellste Weg, die Version eines betreuten Rechners abzulesen:

Version und Herausgeber sind die beiden interessanten Felder. Als Herausgeber steht dort STP Informationstechnologie GmbH – die juristische Person, auch wenn der Produktname by SEPTEO trägt.

Läuft der Dienst nicht dauerhaft, ist die übliche Ursache ein leer gelassener Schritt 4 – kein Mandant konfiguriert, also nichts, womit sich verbinden ließe. Das ist eine Konfigurationslücke, keine kaputte Installation. Die zweithäufigste Ursache ist eine aktive DMS-Konfiguration, die auf ein nicht erreichbares DMS zeigt; das bricht den Start bewusst ab. In beiden Fällen hilft der STP-Service weiter.

9. Anmeldung – den Connector einmalig anmelden

Ein Schritt fehlt noch: Der Connector muss sich einmalig gegen die STP-Cloud anmelden, damit er eine eigene, dauerhafte Identität erhält. Der Installer hat dafür eine Verknüpfung auf dem Desktop und im Startmenü angelegt:

⚠️ Die Anmeldung braucht Administratorrechte – sie holt sie sich selbst

Ein Doppelklick auf die Verknüpfung genügt. Das Skript prüft, ob es erhöhte Rechte hat, und startet sich andernfalls über die Benutzerkontensteuerung neu. Es erscheint also eine Rückfrage von Windows – diese muss bestätigt werden.

Wird sie abgelehnt, meldet das Fenster „Administrator rights are required – the elevation prompt was declined.”, bleibt offen und endet mit dem Rückgabewert 740.

Warum die Rechte nötig sind: Die Anmeldung schreibt die Identität des Connectors nach %ProgramData%\SEPTEO\Documents Partner API Connector – ein Verzeichnis, dessen Zugriffsrechte nur SYSTEM und Administratoren erlauben.

Wer die Anmeldung aus einer Eingabeaufforderung startet, sollte dennoch von vornherein eine erhöhte verwenden – dann entfällt die Rückfrage.

9a. Die Konsole zeigt einen Code und öffnet den Browser

Die Konsole zeigt den Benutzercode samt zugehöriger Adresse und wartet dann:

To enroll this connector, approve code 316269830 at:
  https://<mandant>.stp-cloud.de/identity/device?userCode=316269830
Waiting for approval...

Die Domäne in dieser Adresse ist die, für die dieser Rechner konfiguriert wurde – sie lautet also nicht immer stp-cloud.de. Kommt sie unbekannt vor, sollte sie mit dem Eintrag aus der „Verbindungskonfiguration“ abgeglichen werden.

Der Browser öffnet sich von selbst auf der Anmeldeseite:

„Melden Sie sich mit Ihrem stp.one-Konto an“ fragt nach E-Mail und Passwort. Hier meldet man sich mit dem Connector-Anmeldekonto der Kanzlei an – einem Benutzerkonto des Mandanten mit der Rolle DmsCloudApi.Connector. Ein gewöhnliches Benutzerkonto genügt nicht.

Nicht zu verwechseln mit dem Konto einer Partneranwendung. Das Connector-Anmeldekonto dient allein dazu, diese Installation einmalig anzumelden; es greift selbst auf keine Akten zu. Die Konten, unter denen später Dokumente gelesen und geschrieben werden, tragen die Rollen DmsCloudApi.User bzw. DmsCloudApi.User.Reader und sind davon unabhängig.

Die Rolle vergibt der Administrator der Kanzlei in der Benutzerverwaltung der STP Cloud – über die Standardgruppe Documents Partner API Connector, die in jedem Mandanten bereits vorhanden ist. Fehlt die Rolle, scheitert die Anmeldung an der Zustimmungsseite.

9b. Die Berechtigungen bestätigen

Die Zustimmungsseite nennt die Anwendung – Documents Partner API - On-Premise Connector – und fragt zwei Berechtigungen ab.

⚠️ Beide Berechtigungen angehakt lassen. Die Seite lädt dazu ein, „Berechtigungen abzuwählen, die Sie nicht gewähren möchten” – das sollte man nicht tun. Ohne Offline Access wird kein Erneuerungstoken ausgestellt, und die Anmeldung scheitert mit genau dieser Begründung; ohne den Zugriffsbereich erreicht der Connector den Vermittler nicht.

Mit „Ja, erlauben“ bestätigen.

Wer versehentlich auf „Nein, ablehnen“ landet, bekommt vom Browser:

Die Konsole erfährt von der Ablehnung nichts. Sie bleibt bei „Waiting for approval…“ stehen, bis ihr Code abläuft – was sich wie ein Hänger anfühlt und nicht wie eine Ablehnung. Die Konsole schließen, die Verknüpfung erneut starten und den neuen Code bestätigen. Der alte ist tot; die Adresse des ersten Versuchs erneut aufzurufen wiederholt nur die Ablehnung.

9c. Beide Fenster bestätigen

Der Browser meldet das Gerät als berechtigt und kann geschlossen werden:

Und die Konsole, die im Hintergrund gewartet hat, wird von selbst fertig:

info: STP.Dms.Core.Authentication.Stp.DeviceFlowEnrollment[0]
      Device-flow enrollment approved for client dms.cloud.api.connector
Enrollment complete. The connector can now start without re-authenticating.

Enrollment succeeded.

„Enrollment succeeded.“ ist die entscheidende Zeile – das Fenster wartet auf einen Tastendruck, damit es nicht verschwinden kann, bevor man sie gelesen hat. Ein Fehlschlag meldet an derselben Stelle „Enrollment FAILED with exit code …“.

Unabhängig davon nachprüfbar: Bei Erfolg liegt eine refresh.dat in %ProgramData%\SEPTEO\Documents Partner API Connector. Das Vorhandensein dieser Datei ist die schnellste Bestätigung von außen, dass ein Rechner angemeldet ist.

Test-Path "$env:ProgramData\SEPTEO\Documents Partner API Connector\refresh.dat"

Der Dienst meldet sich auch selbst im Hintergrund an, sobald ein Mandant konfiguriert ist. Die Verknüpfung ist also eine Bequemlichkeit und keine harte Voraussetzung – sie liefert das Ergebnis nur sofort, statt es im Ereignisprotokoll nachlesen zu lassen.

10. Fertig – die Abschlussprüfung

Weder ein laufender Dienst noch „Enrollment succeeded.“ beweisen für sich, dass die Cloud die Kanzlei jetzt sieht. Erst diese drei Punkte zusammen tun das:

Punkt 3 ist der eigentliche Nachweis, und er lässt sich nicht auf dem Kanzleirechner führen – ihn beantwortet die Cloud. Dafür genügt eine Rückfrage beim STP-Service oder ein Aufruf durch die Partneranwendung, die den Connector künftig nutzt: Meldet der Zustandsabruf "connected": true, ist die Installation abgeschlossen.

Meldet er false, obwohl Punkt 1 und 2 stimmen, ist die häufigste Ursache eine Firewall oder ein Proxy, der die AWS-Adressen nicht durchlässt – siehe Schritt 6.

Und was danach noch offen ist

• DMS-Zugangsdaten in Schritt 5 nicht eingetragen? Dann liefert der Connector vorgefertigte Testdaten aus. Die echte DMS-Verbindung aktiviert der STP-Service nachträglich.
• Hinter einem Proxy und Schritt 6 leer gelassen? Der Connector erreicht die Cloud nur, wenn die Proxy-Einstellungen des Rechners bereits das LocalSystem-Konto abdecken.
• Läuft etwas nicht wie beschrieben? Für den laufenden Betrieb hat der STP-Service eine eigene Handreichung – wenden Sie sich mit dem Mandantennamen und dem Zeitpunkt an ihn.
• Fragen zum Dokumentenmanagement selbst? Das gehört nicht hierher, sondern in die Produktdokumentation: STP Documents – allgemein.

Fehlerbilder rund um die Installation

Für alles jenseits der Installation selbst ist der STP-Service die richtige Adresse.

Symptom	Ursache und Abhilfe
Das Setup bricht mit diesem Dialog ab	Eine oder beide .NET-10-Laufzeitumgebungen fehlen. Schritt 1 ausführen – der Installer der ASP.NET Core Runtime allein genügt nicht, die .NET Runtime ist ein separater Download (oder das Hosting Bundle verwenden). Mit dotnet --list-runtimes prüfen.
dotnet --list-runtimes zeigt 10.*, das Setup bricht trotzdem ab	Falsche Architektur – der Connector ist x64 und die Prüfung sucht unter C:\Program Files\dotnet\shared. Eine x86-Laufzeit unter C:\Program Files (x86)\dotnet zählt nicht.
Das Mandantenfeld ist bei einer Aktualisierung leer	Der gespeicherte Wert konnte nicht gelesen werden. Erneut eintragen; er wird am Ende des Laufs neu gespeichert.
Der Dienst ist installiert, stoppt aber sofort	Höchstwahrscheinlich wurde kein Mandant konfiguriert (Schritt 4 leer). Nachtragen und den Dienst neu starten.
Dokumente sehen aus wie Testdaten	Der Connector läuft mit seinen eingebauten Beispieldaten, weil keine aktive Dms-Konfiguration existiert – die Vorlage aus Schritt 5 vervollständigen.
Die Anmeldeverknüpfung meldet „endpoints not configured“ (Rückgabewert 2)	In Schritt 4 wurde kein Mandant konfiguriert, es gibt also keine Anmeldeadressen. Mandant konfigurieren, dann die Verknüpfung erhöht erneut starten.
Die Anmeldekonsole meldet „Administrator rights are required“ und endet mit 740	Die Rückfrage der Benutzerkontensteuerung wurde abgelehnt. Die Verknüpfung erneut starten und die Rückfrage bestätigen.
Der Browser meldete „Sie haben das Gerät authorisiert“, die Konsole meldet einen Fehler	Die Bestätigung hat geklappt, das Speichern des Tokens nicht. Prüfen, ob die Rückfrage der Benutzerkontensteuerung bestätigt wurde, und die Verknüpfung erneut starten – die Bestätigung im Browser kann noch einmal erteilt werden.
Die Anmeldung beklagt ein fehlendes Erneuerungstoken	Offline Access war auf der Zustimmungsseite abgewählt. Erneut durchlaufen und beide Berechtigungen angehakt lassen.
Der Code in der Konsole ist abgelaufen, bevor jemand bestätigt hat	Gerätecodes sind kurzlebig. Einfach die Verknüpfung erneut starten – es wird jedes Mal ein neuer Code ausgestellt.
Es kommt überhaupt nichts in der Cloud an, und der Rechner steht hinter einem Proxy	Der Dienst läuft als LocalSystem und sieht die benutzerbezogenen Proxy-Einstellungen eines Browsers nicht. Den Proxy ausdrücklich einrichten – Schritt 6. Die Protokollzeile Outbound proxy: … bei jedem Start nennt den, der gilt.
Der Proxy ist eingerichtet und nun startet der Dienst nicht mehr	Die Meldung im Ereignisprotokoll lesen: eine Adresse ohne http://, ein Benutzer ohne Kennwort oder ein ungültiger regulärer Ausdruck unter „Ausnahmen“ lassen den Start bewusst scheitern, statt den Proxy halb anzuwenden. Die Ausnahmen sind reguläre Ausdrücke, keine Platzhalter.
Der Proxy antwortet mit 407	Er verlangt eine Anmeldung – „Proxy-Benutzer“ und „Proxy-Passwort“ in Schritt 6 hinterlegen.

Weiterführend

• Überblick über die Documents Partner API – wofür der Connector da ist und was über ihn läuft.