Sage 100: Der Server wurde umbenannt und nichts läuft mehr

Freitagnachmittag, der Administrator räumt die Namenskonventionen im Netz auf. Der Server, auf dem die Sage 100 läuft, heißt seit Jahren ALTSERVER, jetzt soll er SAGE01 heißen. Systemsteuerung, Computername ändern, Neustart, DNS stimmt, Ping antwortet. Fertig, Wochenende.

Samstagvormittag klingelt unsere Notfallhotline. Beim Kunden startet die Sage 100 nicht mehr. Der Smart Client zeigt „Es ist kein Application Gateway erreichbar", in der Diensteverwaltung steht der Sage Applikationsserver auf „Beendet", und wer ihn von Hand startet, sieht ihn nach wenigen Sekunden wieder stehen. Der BlobStorage-Dienst ist ebenfalls aus. Der Mehrbenutzerdienst dagegen läuft, und genau das macht die Sache verwirrend.

Die Empfehlung, die der Kunde bis dahin bekommen hatte, lautete: Applikationsserver und BlobStorage deinstallieren, Registry bereinigen, alles neu installieren. Bei einem Produktivsystem, das am Montag wieder laufen muss, wollten wir diesen Weg vermeiden. Eine komplette Neuinstallation hätte den Ausfall unnötig verlängert. Wir haben stattdessen die Stellen gesucht, an denen der alte Name noch stand, und die Dienste ohne Neuinstallation wieder in Betrieb genommen. Dieser Beitrag beschreibt, warum die Sage 100 auf eine Umbenennung so empfindlich reagiert, wo der Name überall hinterlegt ist und in welcher Reihenfolge die Umstellung gelingt.

Vier Dienste, vier Stellen für denselben Namen

In der von uns untersuchten Installation liefen Applikationsserver, BlobStorage, Mehrbenutzerdienst und Application Gateway auf derselben Maschine. Man könnte annehmen, dass sie einfach den Windows-Computernamen verwenden. Tun sie nicht. Jeder der vier Dienste liest den Namen an einer eigenen Stelle, und keine davon ändert sich, wenn Du den Rechner umbenennst.

Alle vier Dienste laufen als LocalSystem. Ihre Konfiguration liegt im 32-Bit-Zweig der Registry unter HKLM\SOFTWARE\WOW6432Node\Sage\Office Line\9.0, weil die Sage-Prozesse 32-Bit-Anwendungen sind. Wer nur im 64-Bit-Zweig unter HKLM\SOFTWARE sucht, findet die Einträge deshalb nicht.

Das Fehlerbild im Ereignisprotokoll

Auf dem Client gibt es zunächst nur die Meldung, dass kein Application Gateway erreichbar ist. Die technischen Details dahinter zeigen, dass der Client in Bootstrapper.IsApplicationGatewayAvailable scheitert. Das bestätigt, wo der Fehler sichtbar wird, aber nicht, wo er entsteht:

Das Windows-Ereignis 1026 zeigt nur den äußeren Ausnahmetyp. Die eigentliche Aussage steht im Sage-Protokoll des Applikationsservers unter der Ereignisquelle SagedeApplicationServerService90:

Sagede.ApplicationServer.HostedApplicationException
Der Server kann nicht gestartet werden. Applikation lehnt den Start ab.

Sagede.Core.MultiUser.MultiUserException
Es ist ein Fehler im Client des Mehrbenutzerdienstes aufgetreten.
Grund: Es kann keine Verbindung zum Mehrbenutzerdienst auf '\\ALTSERVER'
hergestellt werden.

Das erklärt den scheinbaren Widerspruch. Der Mehrbenutzerdienst läuft, seine Named PipeNamed PipesWindows-Mechanismus für die Kommunikation zwischen Prozessen über benannte Kanäle, lokal oder über das Netzwerk per Servername angesprochen.Mehr im Glossar → \\.\pipe\SageMultiUserService existiert lokal. Die Analyse des Startvorgangs zeigte aber, dass der Applikationsserver den Mehrbenutzerdienst nicht einfach lokal anspricht. Er liest in CommonSettings.get_ServerName den Servernamen aus der Office-Line-Konfiguration und verbindet sich mit \\ALTSERVER. Diesen Namen gibt es nicht mehr, die Namensauflösung scheitert, der Applikationsserver lehnt den Start ab. Damit steht auch der STS nicht zur Verfügung, und der BlobStorage kommt danach gar nicht mehr an die Reihe. Seine eigene Konfiguration kann dabei völlig in Ordnung sein. Die Meldung des Smart Clients beschreibt also nur das letzte Glied dieser Kette, nicht ihre Ursache.

Die naheliegende Abkürzung, die nicht funktioniert

In diesem Zusammenhang wird oft empfohlen, den alten Namen zunächst per Alias wieder erreichbar zu machen. Ein Eintrag in der hosts-Datei, 127.0.0.1 ALTSERVER, und die Sage findet ihren alten Server wieder.

Der Applikationsserver kommt damit tatsächlich ein Stück weiter. In unserem Fall scheiterte anschließend jedoch die Anmeldung am SQL Server mit Fehler 18452: „Die Anmeldung stammt aus einer nicht vertrauenswürdigen Domäne und kann nicht mit der Windows-Authentifizierung verwendet werden." Die Sage-Dienste greifen mit integrierter Windows-Authentifizierung auf den SQL Server zu. Über den tatsächlichen Computernamen und über localhost gelang die Anmeldung, über den Alias nicht. Wird für die Windows-Authentifizierung ein Alias anstelle des Rechnernamens verwendet, entstehen zusätzliche Abhängigkeiten, insbesondere bei SPNs, Kerberos, dem Rückfall auf NTLM und der Loopback-Prüfung von Windows. Welche davon hier griff, haben wir nicht weiter eingegrenzt.

Man könnte diese Alias-Konfiguration technisch weiterführen, etwa über BackConnectionHostNames. Damit würde man jedoch einen nicht mehr gültigen Servernamen künstlich am Leben halten. Sauberer ist es, den alten Namen an den tatsächlichen Konfigurationsstellen der Sage zu ersetzen.

Was Sage selbst empfiehlt

Für den Fall, dass nur die Domäne wechselt und der Servername bleibt, reicht nach Auskunft von Sage der Sage Server Manager: Reparatur, Applikationsserver, „Neue URLs erzeugen". Ändert sich der Servername selbst, müssen zusätzlich alle Clients auf den neuen Mehrbenutzerdienst umgestellt werden. Der übliche Rat für diesen Fall lautet, Applikationsserver und BlobStorage zu deinstallieren, die Registry-Zweige Application Server, Blobstorage Server und Identity Server zu löschen und die Serverkomponenten neu zu installieren.

Genau diese Empfehlung lag unserem Kunden vor. Sie ist nicht falsch, und in einer geplanten Wartung ist die Neuinstallation ein sauberer Weg. Sie kostet allerdings mehrere Stunden, und danach sind Client-Registrierungen am STS, Zertifikate und eventuelle Sonderkonfigurationen neu zu erzeugen. An einem Samstag über die Notfallhotline, mit einem Produktivsystem, das am Montag laufen muss, war das keine Option. Nachdem die relevanten Konfigurationsstellen identifiziert waren, ließ sich die Umgebung in unserem Fall ohne Neuinstallation in weniger als einer Stunde wieder in Betrieb nehmen. Die folgenden Schritte sind der Weg, den wir an diesem Samstag gegangen sind.

Schritt 1: Namensauflösung prüfen

Bevor Du irgendetwas an der Sage anfasst, muss der neue Name vom Server selbst und von den Clients aus auf diese Maschine zeigen. Die Sage-Onlinehilfe nennt dafür die zwei Befehle:

ping -4 SAGE01
ping -a <IP-Adresse aus dem ersten Befehl>

Der zweite Befehl muss den neuen Namen mit der richtigen Domäne zurückliefern. Liefert er noch den alten Namen, stimmt der Reverse-Lookup im DNS nicht. Das führt später zu Zertifikatsfehlern, deren Ursache nicht im Zertifikat liegt.

Schritt 2: Der Name des Mehrbenutzerservers

Das ist die Stelle, an der der Applikationsserver stirbt. Er liest den Namen aus der XML-Konfiguration der Office Line, nicht aus der Registry:

C:\ProgramData\Sage\Office Line\9.0\Office Line.Config

<server>
  <add name="Name" value="\\SAGE01" type="string" />
</server>

Dieselbe Zeile steht in officeLine90.config.template im selben Ordner. Beide Dateien anpassen, sonst schreibt eine spätere Neuanlage der Konfiguration den alten Namen zurück. Die Registry führt eine zweite Kopie, die denselben Wert tragen muss:

HKLM\SOFTWARE\WOW6432Node\Sage\Office Line\9.0\Server
  Name = \\SAGE01

Der Mehrbenutzerdienst selbst bleibt installiert und läuft weiter. Er hat mit der Umbenennung kein Problem, seine Clients haben eins. Auf den Arbeitsplätzen erledigt das die Sagede.OfficeLine.ClientAdmin.exe aus dem Shared-Ordner der Sage-Installation. Sie ändert nichts anderes als diese eine Zeile in der lokalen Office Line.Config.

Schritt 3: Der SQL-Servername in den Datenquellen

Die Datenquellen der Sage zeigen auf den SQL Server, und nach der Umbenennung muss dort der neue Computername stehen. Ein Alias reicht aus dem oben genannten Grund nicht.

• Registry: Unter …\9.0\Admin\Datasources\ gibt es pro Datenquelle einen Schlüssel mit dem Wert ServerName, bei einigen zusätzlich Station. Bei allen lokalen Datenquellen den neuen Namen eintragen.
• Datenbank: In OLGlobal.dbo.LSInfoDatenbanken steht pro Mandantendatenbank der Servername. Nur die Zeilen ändern, deren Datenbank tatsächlich auf diesem SQL Server liegt. Einträge, die auf andere SQL Server zeigen, bleiben wie sie sind.

Nach der Umbenennung und dem Neustart ist die SQL-Instanz grundsätzlich auch über den neuen Computernamen erreichbar. Die internen Metadaten des SQL Servers werden dadurch jedoch nicht angepasst. SELECT @@SERVERNAME liefert deshalb zunächst weiterhin ALTSERVER. Für den Start der Sage-Dienste spielt das keine Rolle. Angleichen solltest Du ihn trotzdem, in einem eigenen Wartungsfenster, weil der SQL-Dienst danach neu starten muss. Das Vorgehen beschreibt Microsoft unter Rename a Computer That Hosts a Stand-Alone Instance of SQL Server:

EXEC sp_dropserver 'ALTSERVER';
EXEC sp_addserver 'SAGE01', 'local';

Bei einer benannten Instanz gehört der Instanzname mit dazu, also ALTSERVER\SAGE. Linked Server, Replikation und Datenbankspiegelung haben eigene Regeln, die Microsoft-Seite listet sie auf.

Schritt 4: Die Instanzschlüssel in der Registry

Jetzt kommt der Teil, der üblicherweise zur Empfehlung führt, neu zu installieren. Sage legt pro Dienst einen Registry-Schlüssel an, der wie der Computername heißt. Im Debugger war zu erkennen, dass der laufende Dienst den Instanzschlüssel erwartet, der zu %COMPUTERNAME% passt. Nach der Umbenennung existiert der nicht, und der Dienst startet ohne Konfiguration oder gar nicht.

HKLM\SOFTWARE\WOW6432Node\Sage\Office Line\9.0\
  Application Server\ALTSERVER
  Application Gateway\ALTSERVER
  Blobstorage Server\ALTSERVER
  Identity Server\ALTSERVER
  Connectivity Server\ALTSERVER

Den alten Schlüssel kopierst Du unter dem neuen Namen, statt nur die URLs darin umzuschreiben:

reg copy "HKLM\SOFTWARE\WOW6432Node\Sage\Office Line\9.0\Application Server\ALTSERVER" ^
         "HKLM\SOFTWARE\WOW6432Node\Sage\Office Line\9.0\Application Server\SAGE01" /s /f

Danach im neuen Schlüssel alle Werte mit Address, Endpoint oder Host im Namen durchgehen und den Hostnamen in den URLs ersetzen. Port und Pfad bleiben. Aus https://altserver:5493/sdata wird https://sage01:5493/sdata. Erst wenn der neue Schlüssel vollständig ist und der Dienst ihn verwendet, löschst Du den alten. Beim Application Gateway ist das besonders wichtig. Bei der Analyse des Smart-Client-Startvorgangs zeigte sich, dass der laufende Windows-Dienst allein nicht ausreicht. Der Client liest in TryGetApplicationGatewayBaseUrl die unter Application Gateway registrierten Instanzen auf dem Server aus, der in Server\Name steht, und nimmt den ersten Eintrag, dessen State auf Started steht. Bleibt der alte Instanzschlüssel mit einem alten Endpunkt bestehen, kann der Client zuerst den erwischen. Hat kein Schlüssel den erwarteten Status, läuft der Windows-Dienst des Gateways, während der Anwender in der Warenwirtschaft trotzdem diese Meldung sieht:

Schritt 5: Die Konfigurationsdateien der Dienste

Dieselben Hostnamen stehen noch einmal in den XML-Konfigurationen der Programmordner. Auch hier nur den Host tauschen:

In der BlobStorage-Konfiguration liegt ein zweiter StsClient-Block mit http://localhost:3333/ im auskommentierten Beispiel. Der ist nicht aktiv und bleibt, wie er ist.

Schritt 6: Zertifikate und TLS-Bindungen

Die Umbenennung ändert kein Zertifikat. Auf dem Server gibt es mindestens zwei mit verschiedenen Aufgaben, und die musst Du auseinanderhalten:

• Das STS-Signaturzertifikat, Betreff CN=SageSTS.<alter Name>. Sein Thumbprint steht im stsServer-Knoten. Es dient der Signierung der ausgegebenen Tokens, sein Subject muss daher nicht mit dem Hostnamen übereinstimmen. Ein alter Rechnername im Zertifikatsnamen ist für sich genommen kein Grund, dieses Zertifikat auszutauschen.
• Die TLS-Zertifikate, die HTTP.sys an die Ports bindet. Hier zählt der Name. Auf dem Gateway-Port 4337 prüft der Smart Client den Hostnamen gegen das Zertifikat. Hängt dort noch CN=altserver, bricht die Verbindung mit RemoteCertificateNameMismatch ab, und der Client meldet, dass kein Application Gateway erreichbar sei. Der Windows-Dienst läuft dabei einwandfrei.

Was aktuell gebunden ist, zeigt Dir:

netsh http show sslcert

Ein Zertifikat mit dem neuen Namen stellt Windows in der Domäne über die Zertifizierungsstelle aus, alternativ ein selbstsigniertes für den internen Gebrauch. Die Bindung tauschst Du pro Port, die appid übernimmst Du aus der Ausgabe des vorigen Befehls:

netsh http delete sslcert ipport=0.0.0.0:4337
netsh http add sslcert ipport=0.0.0.0:4337 certhash=<Thumbprint neues Zertifikat> ^
      appid={<appid aus show sslcert>} certstorename=MY

Ein neues STS-Zertifikat mit dem neuen Namen erzeugt bei Bedarf ASADMIN /command:stsconfig /action:create /all. Das ist ein eigener Schritt mit eigenem Risiko, denn danach müssen alle Dienste den neuen Thumbprint kennen. Für den Start der Dienste ist er nicht erforderlich.

Schritt 7: Dienste in der richtigen Reihenfolge starten

• Der Mehrbenutzerdienst läuft bereits und bleibt es.
• Applikationsserver starten. Er muss im Status „Wird ausgeführt" bleiben. Kommt die HostedApplicationException sofort wieder, steht in der Office Line.Config noch der alte Name.
• BlobStorage starten. Er bleibt nur oben, wenn der STS auf dem konfigurierten Host antwortet.
• Application Gateway neu starten, nachdem der Registry-Schlüssel mit dem neuen Namen existiert und der Port das passende Zertifikat trägt. Der Dienst setzt State dann selbst auf Started.

Zur Kontrolle ein paar Aufrufe von einem Client aus. Ein 401 vom STS ist dabei die richtige Antwort, er verlangt eine Anmeldung, mehr sagt der Code nicht aus:

In netstat gehören diese Ports dem Prozess System mit PID 4. Das ist kein Fehler, HTTP.sys lauscht für die Sage-Dienste im Kernel.

Der belastbare Test bleibt aber ein echter Vorgang aus der Sage 100: Anmelden am Smart Client, einen Beleg öffnen, ein Dokument in der Dateiablage hochladen. Erst dann sind Mehrbenutzerdienst, STS, SData, BlobStorage und Gateway gemeinsam geprüft.

Was bewusst stehen bleiben darf

Nicht jeder Rest des alten Namens ist ein Fehler. Diese Punkte haben beim Kunden den Betrieb nicht gestört und wurden bewusst zurückgestellt:

• Der Betreff des STS-Signaturzertifikats mit dem alten Namen.
• @@SERVERNAME mit dem alten Wert, solange sp_addserver noch nicht gelaufen ist.
• Datenquellen, deren SQL Server auf einer anderen Maschine läuft.
• Der Schlüssel des Connectivity Servers, wenn der Kommunikationsdienst nicht im Einsatz ist.

Vorbeugen

• Einen Sage-Server benennt man nicht nebenbei um. Wenn es sein muss, dann mit Wartungsfenster, Sicherung und der Liste aus diesem Beitrag. Bei einem ohnehin anstehenden Hardwarewechsel ist ein neuer Server mit dem gewünschten Namen und eine saubere Migration oft der weniger riskante Weg.
• Vorher den Registry-Zweig HKLM\SOFTWARE\WOW6432Node\Sage exportieren und die Konfigurationsdateien aller Sage-Dienste an einen Ort außerhalb der Programmordner kopieren.
• Thumbprints, Ports, clientId/clientSecret-Paare und die Namen der Datenquellen in der Systemdokumentation festhalten. Das ist die Liste, die Du bei jeder Reparatur brauchst.
• Änderungen am Server, die nichts mit der Sage zu tun haben, mit dem Sage-Betreuer abstimmen. Umbenennung, Domänenwechsel, neues Maschinenzertifikat, Härtung von TLS: Alles davon trifft die Sage-Dienste, und zwar oft erst Tage später. Wie so eine Verzögerung aussieht, zeigt der Beitrag zur Lizenzprüfung ohne TLS 1.2.

Fazit

Ein neuer Computername ist für Windows eine Kleinigkeit und für die Sage 100 ein Umzug. Der Name steht in der Office Line.Config, in der Registry der einzelnen Dienste, in den Datenquellen, in den XML-Konfigurationen und in den TLS-Bindungen.

In unserem Fall ließ sich die Sage 100 nach Identifikation dieser Abhängigkeiten ohne Neuinstallation in weniger als einer Stunde wieder in Betrieb nehmen. Ein Alias für den alten Rechnernamen hätte dagegen nur einen Teil der eigentlichen Konfigurationsfehler verdeckt. Entscheidend ist deshalb nicht, den alten Namen irgendwie wieder erreichbar zu machen, sondern die Stellen zu finden, an denen die Sage ihn tatsächlich verwendet.

Wenn Deine Sage 100 nach einer Änderung am Server nicht mehr startet, melde Dich bei uns. Wir finden die Stelle, an der der alte Name noch steht.