NSP 14.1.0.100 Migration oder von einem Fehler zum nächsten

[MarkusB]

Hallo Zusammen

Hintergrund: Windows Server 2012R2 (alles auf einem System 14.1.0.100) soll nach Windows Server 2022 migriert werden.
Dabei soll Intranet-Role auf einen Server im internen Netz und Gateway + Web-Role auf einen extra Server in die DMZ wandern. Zielversion ebenfalls 14.1.0.100.

Anhand der Anleitung "https://docs.nospamproxy.com/Server...t/How-tos/how-to-migrate-nospamproxy-14-x.htm" ist keine erfolgreiche Migration möglich.

Zunächst konnte man das Setup starten, welches sich dann jedoch direkt wieder beendet hat. Hier im Forum hatte jemand die gleichen Probleme mit Server 2022 Core. Wir haben aber die Variante mit GUI verwendet. Ursache konnten wir selber herausfinden und war auf .Net48 zurückzuführen.

Dann gab es Probleme, dass wir keinen Connect vom Command Center hinbekommen haben. Zertifikat war erfolgreich gebunden auf :6061 und alles Steps der Anleitung mehrmals kontrolliert. Irgendwann dann alles zurück gebaut weil die Ursache unklar ist (erster Abend mit Downtime rum)

Mittlerweile haben wir dies hinbekommen. Dies funktionierte aber nur, wenn man in der "Intranet Role.config" zusätzlich den neuen "dnsName" im Zweig "netatwork.nospamproxy.webApi" hinterlegt. Leider stand dies nicht in der Anleitung.

Jetzt hängen wir an der Hürde, dass die Gateway Role nicht hinzugefügt werden kann. Nach Eingabe Zugangsdaten GatewayRole und kurz warten crashed die App:

Faulting application name: NoSpamProxy.CommandCenter.exe, version: 14.0.23243.1123, time stamp: 0xf1776635
Faulting module name: ntdll.dll, version: 10.0.20348.1906, time stamp: 0xe921dd83
Exception code: 0xc00000fd
Fault offset: 0x00057398
Faulting process id: 0x12ac
Faulting application start time: 0x01d9e5a5afc42b70
Faulting application path: C:\Program Files\NoSpamProxy\Command Center\NoSpamProxy.CommandCenter.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 57b66aa5-6017-445c-b80d-318ab7e780bc
Faulting package full name:
Faulting package-relative application ID:

Also zweiter Abend mit Downtime rum und gerade wieder alles "weggeworfen" und zurück gebaut.

Dann mal nur versucht eine neue Gatewayrolle an den alten Server anzubinden, auch hier crashed die App.
Bug in der 14.1.0.100 oder irgendwas in der Config, womit die Anwendung nicht umgehen kann / Situation nicht im Code abgefangen wird?

Daneben lässt sich die 14.1.0.100 Setup.exe auch nicht erneut starten um z.B. nochmal eine Rolle nach zu installieren.
Hier bleibt es einfach bei "initializing" hängen. Im Log selber sieht man keine Fehler.
Gleicher Fehler auf zwei Servern, einmal installiert ist quasi die Setup.exe verbrannt.

....
[04E0:1E90][2023-09-12T21:18:38]i000: [OnDetectComplete] Detect phase complete. Checking database access if necessary.
[04E0:1E90][2023-09-12T21:18:38]i199: Detect complete, result: 0x0
[04E0:1E90][2023-09-12T21:18:56]i500: Shutting down, exit code: 0x642
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: ConfigureSecurityGroups = 1
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: InstallationPath = C:\Program Files\NoSpamProxy
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: NETFRAMEWORK45 = 528449
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: OSLanguage = 0409
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: RebootPending = 0
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: VersionNT64 = 10.0.0.0
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WebPortalInstallationPath = C:\Program Files\NoSpamProxy\Web Portal
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleAction = 5
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleElevated = 1
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleInstalled = 1
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleLog = C:\Users\cnag.it\AppData\Local\Temp\NoSpamProxy_20230912211837.log
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleManufacturer = Net at Work GmbH
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleName = NoSpamProxy
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleOriginalSource = C:\Install\NSP\NoSpamProxy Setup 14.1.0.100.exe
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleOriginalSourceFolder = C:\Install\NSP\
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleProviderKey = {41a2de89-18c7-4ddf-9be0-d0a154fd4331}
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleSourceProcessFolder = C:\Install\NSP\
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleSourceProcessPath = C:\Install\NSP\NoSpamProxy Setup 14.1.0.100.exe
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleTag =
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleUILevel = 4
[04E0:1E90][2023-09-12T21:18:56]i410: Variable: WixBundleVersion = 14.1.0.100
[04E0:1E90][2023-09-12T21:18:56]i007: Exit code: 0x642, restarting: No

 

[Floh]

Hallo Markus,

wir hatten bei dem Versuch zu migrieren auch jede Menge Probleme und haben uns letztlich entschieden, einen zweiten Server parallel hochzuziehen und umzuschalten, sobald dieser entsprechend dem alten konfiguriert ist.

Ein paar Punkte hatten wir übersehen, aber alles in allem war die Neuinstallation um Längen einfacher als die - ich glaub 7-9 - versuchten Migrationsabende.

Grüße
Flo

 

[869288141]

Moin,
sind Testumgebungen inzwischen "Old School" oder nur für Anfänger gedacht?

Gerade solche doch umfangreichen Umbauten würde ich niemals ohne Testumgebung angehen. Mit Veeam & Co lassen sich doch problemlos über Instant Recovery problemlos und einfach solch eine (temporär) aufbauen um das Vorhaben durchzuspielen.

Anhand der Anleitung "https://docs.nospamproxy.com/Server...t/How-tos/how-to-migrate-nospamproxy-14-x.htm" ist keine erfolgreiche Migration möglich.

Diese Anleitung berücksichtigt in meinen Augen nicht im Ansatz dein Vorhaben. Da geht es meinem Verständnis nach um eine 1:1 Migration.

Gleicher Fehler auf zwei Servern, einmal installiert ist quasi die Setup.exe verbrannt.

Snapshot keine Option gewesen?

Wir haben aber die Variante mit GUI verwendet. Ursache konnten wir selber herausfinden und war auf .Net48 zurückzuführen.

Sprich .NET Framework 4.8 nicht installiert oder was muss ich mir darunter vorstellen?


Gruß,
Daniel

 

[MarkusB]

Moin,

vielleicht habe ich mich nicht 100% klar ausgedrückt, da Testumgebung und Snapshots wohl selbstverständlich sein sollten. In einer Testumgebung ist dies aufgebaut worden, aber es ist nicht in jeder Konstellation / Umgebung möglich eine vollständige Testumgebung mit allen relevanten Servern / zwei stufiger Firewall etc. zu haben. Somit kann es auch bei einer Testumgebung erforderlich sein eine Downtime zu benötigen und Änderungen vorzunehmen (die aber zurückgenommen werden können).

Daneben wurden natürlich auch Snapshots verwendet. Der Hinweis dient eher, dass mit der Setup.exe was nicht stimmt. Ein Snapshot nutzt mir logischerweise nur für den Moment. Ich würde das Risiko nicht eingehen, das System ohne RS mit dem Support produktiv zu nehmen, wenn bereits zu erkennen ist, das spätere Änderungen mit der Setup.exe nicht möglich sind.

NET4.8. Fehler schreiben wir uns selber zu. War installiert (ist ja Default in 2022 OS), aber da war scheinbar mit einem Update was schief gegangen.

Bzgl. Anleitung: Meines Erachtens ist die Anleitung sehr wohl für die Migration auf einen anderen Server gedacht (ansonsten wäre die Übernahme der WebRole so wie beschrieben "parallel" nicht möglich). Klar das es Abweichungen gibt, wenn man die Rollen aufteilen möchte. Aber auch alles auf einem neuen System 1:1 wäre ein Erfolg, ist aber ebenfalls nicht möglich wegen der GW Role. Ob die GW Rolle dabei lokal oder auf ein anderes System installiert wird, sollte irrelevant sein, da die Config jeweils neu erstellt wird aus der Intranet Role.

Um zum eigentlichen Thema zurückzukommen und weiter an einer Lösung zu arbeiten:
Der Ansatzpunkt ist m.E. die Gateway Role um hier weiterzukommen. Warum lässt sich z.B. keine zusätzliche GW Role bereits im produktiv System einbinden und führt zum Crash der CommandCenter.exe? Sowas passiert in der Regel, wenn eine Situation auftritt, welche programmiertechnisch nicht abgefangen ist / bedacht wurde. Ich hatte in der Vergangenheit z.B. schonmal ein Zeichen im Wortfilter, welches bei einem NSP Update zum Absturz führte.

Was könnte der Grund sein, gibt es detailliertere Logs um ggf. die Stelle in der Role Config / DB zu finden?

Parallel ist ein Support-Case eröffnet, die dauern in der Regel zuletzt aber Wochen bis man eine Antwort erhält. Meine Hoffnung liegt also darin hier noch eine gute Idee zu erhalten um selbst weiterzukommen .

Gruß
Markus

 

[MarkusB]

Kurzes Update, nach Rückmeldung innerhalb des Support Cases: Wir werden eine saubere Neuinstallation vornehmen und die Übernahme einzelner noch benötigter Daten (Regelwerk, Inhaltsfilter etc.) manuell (aus DB / Config Files etc.) mit Unterstützung seitens Hersteller vornehmen. Aufwand um die genaue Ursache für das Verhalten der neuen Gatewayrolle (Migration oder Altsystem) zu finden wird diesen Aufwand vermutlich übersteigen und wird daher nicht weiter verfolgt.

 

[Sören]

Diese Anleitung berücksichtigt in meinen Augen nicht im Ansatz dein Vorhaben. Da geht es meinem Verständnis nach um eine 1:1 Migration.

Die Anleitung die er benutzt ist auch dafür gedacht also so gesehen ist das schon okay.

 

[869288141]

Die Anleitung die er benutzt ist auch dafür gedacht also so gesehen ist das schon okay.

Der Fragesteller möchte doch migrieren und in diesem Schritt die Rollen trennen. Meinem Verständnis nach, wird das in der Anleitung so aber nicht behandelt. Oder hab ich das falsch verstanden?

 

[869288141]

. In einer Testumgebung ist dies aufgebaut worden, aber es ist nicht in jeder Konstellation / Umgebung möglich eine vollständige Testumgebung mit allen relevanten Servern / zwei stufiger Firewall etc. zu haben. Somit kann es auch bei einer Testumgebung erforderlich sein eine Downtime zu benötigen und Änderungen vorzunehmen (die aber zurückgenommen werden können).

Für bedeutet Testumgebung, dass ich ein Spiegelbild der produktiven Server, welche verändern möchte (z.B. NSP Update) temporär hochziehe. Im Idealfall natürlich die Firewalls. Da diese in der Regel physikalisch sind, werden diese entsprechend virtualisiert mit einer Dev Lizenz ausgestattet und über Config Export/Import hochgezogen. Wenn einmal das Schema steht, lässt so innerhalb von 30 Minuten eine Spielwiese hochziehen. Evtl. für die Zukunft eine Überlegung wert.

Der Ansatzpunkt ist m.E. die Gateway Role um hier weiterzukommen. Warum lässt sich z.B. keine zusätzliche GW Role bereits im produktiv System einbinden und führt zum Crash der CommandCenter.exe?

Spontan würde mich noch Defender o.ä. einfallen, falls eine Firewall zwischen Intranet- und Gateway-Rolle steht, könnte IPS/IDS einen False Positve blockieren, etc. Dazu kennen wir deine Infrastruktur zu wenig. Was ich interessant fände ist, ob ein neu Server, mit einer neuen Gateway Rolle aufgenommen werden kann oder ob dort das selbe Problem passiert. Da wäre ein Spiegelbild im Lab wieder Gold wert.

Aufwand um die genaue Ursache für das Verhalten der neuen Gatewayrolle (Migration oder Altsystem) zu finden wird diesen Aufwand vermutlich übersteigen und wird daher nicht weiter verfolgt.

Das hat für mich immer einen faden Beigeschmack. Weil man die Ursache nicht kennt und das Problem theoretisch beim nächsten Update wieder haben könnte. Es gibt ein paar Logfiles, aber diese Lesen zu können ist eine Kunst. Gerade in einem anderen Thread hier im Forum 30 Minuten lang eines studiert -> Katastrophe. Bin mal gespannt, ob es dem Fragesteller weiterhilft.

Da vermisse ich in der Tat ein Logfile, dass IT Admins entschlüsseln können! Das würde sicherlich einige Support Anfragen minimieren wenn nicht sogar vermeiden.

 

[MarkusB]

Zwischenzeitlich wurden die Daten der verschiedenen Tabellen und Configs seitens NSP Support migriert, das Thema kann daher hier beendet werden.

Kurze noch Antwort auf den relevanten Punkt, falls es später noch jemand gebrauchen kann:

Spontan würde mich noch Defender o.ä. einfallen, falls eine Firewall zwischen Intranet- und Gateway-Rolle steht, könnte IPS/IDS einen False Positve blockieren, etc. Dazu kennen wir deine Infrastruktur zu wenig. Was ich interessant fände ist, ob ein neu Server, mit einer neuen Gateway Rolle aufgenommen werden kann oder ob dort das selbe Problem passiert. Da wäre ein Spiegelbild im Lab wieder Gold wert.

Ne, das hat nicht funktioniert auch nicht im gleichen Netzwerksegment (ohne Firewall, AV etc.). Von daher war meine Vermutung es war irgendwas in der Konfig, welches verhindert hat eine weitere Gateway Rolle einzufügen.

Das hat für mich immer einen faden Beigeschmack. Weil man die Ursache nicht kennt und das Problem theoretisch beim nächsten Update wieder haben könnte. Es gibt ein paar Logfiles, aber diese Lesen zu können ist eine Kunst. Gerade in einem anderen Thread hier im Forum 30 Minuten lang eines studiert -> Katastrophe. Bin mal gespannt, ob es dem Fragesteller weiterhilft.

Da vermisse ich in der Tat ein Logfile, dass IT Admins entschlüsseln können! Das würde sicherlich einige Support Anfragen minimieren wenn nicht sogar vermeiden.

Das wäre ein Traum

 

[JanJäschke]

Nur kurz zu den Logs:
Mit etwas Zeit sind auch diese lesbar. Wichtig ist immer das ganze Log und im Idealfall ALLE Setup Logs zu betrachten.
Nur das Haupt Log oder nur das Produkt Log reicht selten aus.

Da es sich um einen WiX Installer handelt sind dann in Fällen wo wir selbst keinen Fehler notieren in der Regel Windows Codes hinterlegt.

Ich möchte nicht sagen, dass die Logs super sind, sie sind aber eben auch nicht soo schlecht. Primär sollten diese einfach nicht benötigt werden oder der Fehler führt unweigerlich eh zum Support Ticket.

Gruß
Jan

 

[869288141]

Von daher war meine Vermutung es war irgendwas in der Konfig, welches verhindert hat eine weitere Gateway Rolle einzufügen.

Falls du Zeit und Lust hast, lege doch die Konfiguration von bisherigen und neuen System nebeneinander. Evtl. gibt das Aufschluss auf vermeidliche Fehler.

Ich möchte nicht sagen, dass die Logs super sind, sie sind aber eben auch nicht soo schlecht. Primär sollten diese einfach nicht benötigt werden oder der Fehler führt unweigerlich eh zum Support Ticket.

Wenn ich mir die Beiträge der letzten Wochen anschaue, tauchen mehr (Auszüge von) Logfiles auf wie euch vermutlich lieb ist. Ich weiß es viel zu tun, aber Ursachenforschung fände ich besser als nach und nach gleich zu migrieren.