Datenbank Intranetrolle auf anderen SQL verschieben

[mabu]

Hallo.

Bei uns steht Umzug von Datenbanken auf einen neuen SQL-Server an. Und ich möchte mit dieser Anfrage nur auf Nummer sicher gehen.

Die Intranetrolle nutzt die DB "NoSpamProxyAddressSynchronization" auf einem externen SQL-Server.

Vom Ablauf her folgendes Vorgehen okay oder würdet Ihr da was anders machen?
1.) Intranetrolle stoppen
2.) Export der Datenbank auf altem SQL und Import auf neuem SQL-Server (müsste da dann an Einstellungen evtl. auch Berechtigungen alles so passen? sind beide in der gleichen Domäne)
3.) in NCC unter "NSP Komponenten" bei Datenbanken im Eintrag Intranetrolle den FQDN des neuen SQL-Server eintragen - unter Authentifizierung ist ein SQL-interner Username eingetragen, der dann so ja unverändert bleiben müsste
4.) Intranetrolle wieder starten

Habe ich da was übersehen?

Danke vorab.

Gruß,
Martin

 

[JanJäschke]

Hallo Martin,

vom Prinzip her passt das so.
Ich möchte dir dennoch zwei Sachen mit geben:

1. Bennen die Datenbank auf dem neuen Server direkt um: NoSpamProxyAddressSynchronization > NoSpamProxyIntranetRole
   Damit bist du dann auf dem neuen Stand und wirst es in Zukunft mit den meisten Sachen leichter haben da es der Default ist.
2. Blockiere die Kommunikation zwischen Intranet Rolle und Gateways per Firewall, z.B. Windows Firewall. Das bewirkt, dass das Gateway alle Daten erst einmal im Speicher vorhält. Dadurch kannst dud die Intranet Rolle starten ohne Messagetrack Daten zu verlieren.
   Wenn du dann noch sicherstellen kannst, dass keine neuen Zertifikate angefragt werden, kannst du ganz entspannt umstellen.

Jetzt hoffe ich mal, das ich selbst nichts vergessen habe

LG
Jan

 

[mabu]

Hallo Jan.

Danke für die Rückmeldung. Ich habe es intern weitergegeben.

Bezüglich der Umbenennung hatte ich überlegt, aber hätte mich eher nicht getraut. Wenn das aber kein Problem macht, dann erledigen wir das gleich mit.

Da wir den Umzug mit Sicherheit außerhalb der Geschäftszeiten machen werden, stoppen wir am besten die GW-Rolle und dann brauchen wir da nicht viel anpassen.

LG
Martin

 

[869288141]

3.) in NCC unter "NSP Komponenten" bei Datenbanken im Eintrag Intranetrolle den FQDN des neuen SQL-Server eintragen - unter Authentifizierung ist ein SQL-interner Username eingetragen, der dann so ja unverändert bleiben müsste

Den SQL Benutzer musst natürlich noch auf dem neuen Server anlegen, Berechtigungen zuweisen, etc.

 

[mabu]

Rückfrage zum Vorgehen "Intranet-Datenbank auf anderen SQL verschieben".

Ich hatte im Ausgangsthread ja die Reihenfolge beschrieben, die ich mir vorstellen kann. Und es gab keinen Widerspruch.

Eben in der Theorie durchgegangen und dabei folgendes Problem bemerkt: wenn die Intranetrolle gestoppt ist, wie komme ich denn dann in der NCC an "Konfiguration -> NSP-Komponenten"? Bei nicht laufender Intranetrolle wird da ja gar nichts angezeigt.

Wir würden gerne am morgigen Mittwoch die Datenbank umziehen. Aber aktuell sehe ich da an dieser Stelle in Problem.

Das einzige was mir einfallen würde:

1. GW-Rolle stoppen
2. Intranetrolle stoppen
3. Backup der SQL-Datenbank und auf neuem SQL einspielen (Benutzer anlegen - Datenbankname ändern)
4. Intranetrolle starten (mit Verbindung auf alten SQL) - da dürfte ja bei deaktivierter GW-Rolle nichts passieren
5. in NCC auf neuen SQL-Server umstellen (auf altem SQL-Server sollte dann in der Datenbank nichts mehr passieren)
6. GW-Rolle wieder starten

Vermutlich sind die Informationen für die Datenbank auf dem Server der Intranetrolle ja in einer Datei oder in der Registry gespeichert. Somit wäre eine Änderung dort evtl. auch möglich (aber beim Passwort durch hoffentlich Nutzung eines Hashwertes vielleicht schwierig).

Ist das aus Eurer Sicht so okay mit der kurzzeitigen Nutzung der "alten" Datenbank?

 

[JanJäschke]

Guten Morgen Martin,

ja das wäre ein machbarer Weg.
In der Zeit habt ihr dann aber keinen Mailflow mehr.
Leichter wäre es einfach in der Windows Firewall die Kommunikation mit dem Gateway komplett zu unterbinden, dann habt ihr noch E-Mails die rein und raus gehen.


Gruß
Jan

 

[mabu]

Umzug der Datenbank erfolgt. Aber es war doch etwas aufwendiger als zuerst vermutet.

Nach erfolgten Änderungen wollte Nachrichtenverfolgung immer noch auf alten SQL zugreifen -> Reboot des Servers mit Intranetrolle und dann hat die NSP-Konsole komplett wieder funktioniert (evtl. hätten da neben Intranetrolle auch die anderen Dienste auf dem Server einfach neu gestartet werden müssen - Reboot war leichter).

Hatten dann aber noch das Problem, dass in der Nachrichtenverfolgung die neuen EInträge fehlten. In Ereignisanzeige dann Warnungen mit der Info "Die EXECUTE-Berechtigung wurde für das Artefact-Objekt, NoSpamProxyIntranetRole-Datenbank, DataReplication-Schema, verweigert."

Da hatten wir wohl zuerst ein paar Einstellungen im SQL-User nicht mit gesehen und die fehlten dann auf dem neuen Server.

Der Kollege, der das duchgeführt hat, war da doch ein wenig am Fluchen. Letztlich hat es dann wieder funktioniert. Lag letztlich wohl an unterschiedlichen IDs der Datenbankuser und dies musste dann neu zugeordnet werden (irgendwie so - ist gar nicht mein Thema).

Hoffe, dass ich beim Update auf 14.1 kein Problem mit der Datenbank bekomme.

Und es ist schon irre, wenn man endlich mal einen performanten SQL-Server nutzen kann. Irre, wie schnell die Nachrichtenverfolgung sich öffnet. Und auch die anderen Seiten in der NCC und auch die WebApp - kannten wir bisher so nicht.

 

[869288141]

Der Kollege, der das duchgeführt hat, war da doch ein wenig am Fluchen. Letztlich hat es dann wieder funktioniert. Lag letztlich wohl an unterschiedlichen IDs der Datenbankuser und dies musste dann neu zugeordnet werden (irgendwie so - ist gar nicht mein Thema).

Auch SQL Benutzerkonten haben eindeutige SIDs wie es bei Windows Benutzern der Fall ist. Je nachdem wie der Umzug geplant wurde, muss diese noch angepasst werden.

Hoffe, dass ich beim Update auf 14.1 kein Problem mit der Datenbank bekomme.

Wie immer ohne Gewähr. Ich wiederhole mich gerne - Backup, Backup, Backup.