[Gelöst] Sync Zugriffsrechte auf dem SQL Server aus FBK

Hallo,

wir sind gerade bei der Umsetzung (Sortierung einer bestehenden NAV- Installation umstellen) auf Probleme gestoßen. Am Ende der Aktion lassen sich die Zugriffsrechte bzw. die Windows-Logins nicht mehr synchronisieren.

Unsere Vermutung: Irgendwas mit den Gruppenanmeldungen ist nicht richtig, die folgende Fehlermeldung deutet ja auch darauf hin.. Die Authentifikation ist "mixed". Windows-Logins per User und Rechtevergabe per Windows(login)-Gruppe. Wir verwenden die Build 32012. Das Sicherheitsmodell ist Standard.

Beim Synchronisieren der Zugriffsrechte erscheint die Fehlermeldung:

Code:

---------------------------
Microsoft Dynamics NAV Classic
---------------------------
Die folgenden SQL Server-Fehler sind aufgetreten:

15259,"42000",[Microsoft][ODBC SQL Server Driver][SQL Server]Die DEFAULT_SCHEMA-Klausel kann mit einer Windows-Gruppe oder mit Prinzipalen, denen Zertifikate oder asymmetrische Schlüssel zugeordnet sind, nicht verwendet werden.

SQL:
{CALL [sp_grantdbaccess](?)}

---------------------------
OK   
---------------------------


Das Prozedere sieht wie folgt aus:

• NAS deaktivieren
• NST deaktivieren
• Navision in den Single User Modus schalten.
• Komplette Datensicherung (SQL) erstellen und für den Ernstfall wegpacken.
• Mittels Dataport "Company Ex/Import" die Company-Tabelle sichern. (wegen Anpassungen)
• mind. 2 FBK-Sicherungen erstellen:
  a) eine Sicherung für Objekte und globale Tabellen
  b) eine oder mehr Sicherungen für alle Mandanten
• Neue Native-Datanbank aufbauen und die FBK-Sicherungen einspielen.
• Die FBK-Sicherungen aus b) für alle Mandanten aus der Native-Datenbank erneut erstellen.
• Beim SQL Server MAXDOP auf 7 stellen. Schwellwert für Parallelisierung auf 0. Beim Schlüsselaufbau bringt das ein wenig mehr Geschwindigkeit.
• Neue SQL-Datenbank aufbauen, mit der entsprechenden Sortierung: Windows Latin1_CS_AS, Codepage nicht überprüfen, Protokollierung auf "einfach"
• FBK Sicherung aus a) (Objekte und globale Tabellen) zurücksichern. Dabei die Option Sicherheits und Systemtabellen ersetzen mit Ja beantworten
• In Teil-Schritten von jeweils die Mandanten fbk aus b) zurücksichern.
• Mittels Dataport "Company Ex/Import" die Company-Tabelle wieder zurücksichern.
• Protokollierung der Datenbank auf "vollständig" ändern.
• Beim SQL Server MAXDOP auf 1 zurücksetzen, Schwellwert für die Parallelisierung auf 5.

Wird dann das Sicherheitssystem synchronisiert erscheint obere Fehlermeldung. Es lassen sich keine Veränderungen vornehmen (Löschen/Hinzufügen von Logins). Es kommt immer diese Meldung

In unserem Testszenario holen wir die SQL Sicherung von Produktivrechner A und stellen das auf Testsystem B wieder her. Dann starten wir mit den obigen Prozedere. Auf dem Testsystem sind noch weitere wiederhergestellte SQL-DB-Clones von Produktivrechner A. Wenn wir die SQL Sicherung direkt wiederherstellen können wir das Sicherheitssystem problemlos synchronisieren.

Damit sieht es für uns so aus, dass bei dem "Übergang" von SQL > FBK > SQL informationen verloren gehen oder SQL Server nicht zurechtkommt.
Hat jemand einen Tipp wie wir uns dem Problem weiter nähern oder noch besser: lösen können?

Viele Grüße,
Janosch

Zuletzt geändert von janosch am 5. April 2013 12:32, insgesamt 1-mal geändert.

- sind die Server in der gleichen Domäne/Forest?
- warum erstellt ihr die DB nicht über den NAV Client?
- warum erzeugt ihr 2 fbks?

Das Prozedere wie du es beschreibst sieht für mich viel zu aufwendig aus.
Ihr wollt nur die Collation der DB ändern?
Von welche auf welche?
Was spricht dagegen dies über Datenbank -> Ändern zu machen? Dort kann man Collations umstellen.

Wenn ihr von CI_AS auf CS_AS umstellen wollt, ist dies ein ganzer Haken und etwas Wartezeit.

Hallo JanGD,

danke für deine Antwort.

- sind die Server in der gleichen Domäne/Forest?

ja, die beiden Server sind in der gleichen Domäne.

- warum erstellt ihr die DB nicht über den NAV Client?

Wie meinst du das? Wir legen jeweils die neuen Datenbanken per NAV-Client (Native als auch SQL) an.

- warum erzeugt ihr 2 fbks?

Zum einen Trennen wir Objekte und mandanten übergreifende Tabellen von den mandanten bezogenen Informationen. Des Weiteren haben wir insgesamt ~300 Mandanten. Volumen der DB ca. 60 GB.

Beim Wiederaufbau in einer nativen DB und dem wieder anschließenden Sichern als FBK werden leere mandanten bezogene Tabellen entfernt. Kurz: Reduzierung der Anzahl von Tabellen.

Das Prozedere wie du es beschreibst sieht für mich viel zu aufwendig aus.
Ihr wollt nur die Collation der DB ändern?
Von welche auf welche?
Was spricht dagegen dies über Datenbank -> Ändern zu machen? Dort kann man Collations umstellen.

Wenn ihr von CI_AS auf CS_AS umstellen wollt, ist dies ein ganzer Haken und etwas Wartezeit.

Historisch bedingt haben wir aktuell folgende DB Einstellungen in NAV:
Sortierungstyp: "SQL Sortierung"
Sortierung: "Binary Sort order, code page 850 (40)"
Sortierung überprüfen: Aus
Weitere Einstellungen wie "Binär, Groß-/Kleinschreibung, Akzent beachten" sind ausgegraut.
Aus dem SQL Management Studio: SQL_Latin1_General_CP850_BIN


Wir wollen damit wir eine Toleranz bei der Groß/Kleinschreibung bekommen, aber auch osteuropäische Schriftzeichen verarbeiten können, folgende Einstellung haben:

Sortierungstyp: "Windows Sortierung"
Sortierung: "Afrikaans, Basque, Catalan, Dutch, English, Faeroese, German, Indonesian, Italian, Portuguese"
Sortierung überprüfen: Aus
Binär = Aus
Groß-/Kleinschreibung beachten: An
Akzent beachten: Aus

Aus dem SQL Management Studio: Latin1_General_CS_AS

Viele Grüße,
Jjanosch

Hallo,

ich habe nun den SQL Profiler in einer separaten DB bemüht. Auffällig: Ich versuche den User DOMAIN\GruppennameXYZ hinzuzufügen, im SQL Profiler erscheint aber DOMAIN\GruppennameABC.

DOMAIN\GruppennameABC ist aber der "alte" Name, die Gruppe wurde irgendwann (nicht während der Durchführung) umbenannt.

Code:

EventClass   TextData   Application Name
SQL:BatchStarting   set quoted_identifier on use "permission"   [Shadow NDO Session 0000003E]
SQL:BatchCompleted   set quoted_identifier on use "permission"   [Shadow NDO Session 0000003E]
RPC:Completed   exec sp_cursorclose 180153213   Microsoft Dynamics NAV Classic client
RPC:Completed   exec [sp_grantlogin] N'DOMAIN\GruppennameABC'   [Shadow NDO Session 0000003E]
RPC:Completed   exec [sp_grantdbaccess] N'DOMAIN\GruppennameABC'   [Shadow NDO Session 0000003E]
RPC:Completed   exec sp_cursorclose 180153209   Microsoft Dynamics NAV Classic client
SQL:BatchStarting   IF @@TRANCOUNT > 0 ROLLBACK TRAN   Microsoft Dynamics NAV Classic client
SQL:BatchCompleted   IF @@TRANCOUNT > 0 ROLLBACK TRAN   Microsoft Dynamics NAV Classic client
SQL:BatchStarting   SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED   Microsoft Dynamics NAV Classic client
SQL:BatchCompleted   SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED   Microsoft Dynamics NAV Classic client
RPC:Completed   exec sp_execute 890,5,'',1   Microsoft Dynamics NAV Classic client
RPC:Completed   exec sp_execute 896,0,0x36943577002D532D312D352D32312D313736393530333030322D313230383737303935352D313533393835373735322D3131393630000000   Microsoft Dynamics NAV Classic client



Bringt das vielleicht etwas?

Viele Grüße,
Janosch

Also die Tätigkeit wie du sie beschrieben hast...
Mach folgendes:

SQL-Backup vom Prod-System
SQL-Restore auf Test-System
NAV Client -> Login-Sync
NAV Client -> Database Alter -> Options -> Single User -> OK
NAV Client -> Database Alter -> Collation -> Deine Einstellungen vornehmen -> OK
"Stoppuhr" mitlaufen lassen (für ungefähre Abschätzung für Prod-Umstellung)
Nachdem fertig:
NAV Client -> Database Alter -> Options -> Single User (aus) -> OK
NAV Client neu starten, fertig.

Alter Statements auf leere Tabellen sollten keine Zeit kosten. Je größer die Tabelle, desto länger könnte es dauern.

Was mir bei Deiner Prozedur auch noch nicht so ganz klar ist, ob es überhaupt die erwünschte Wirkung hat.
Bist Du Dir sicher, dass das Restore eines fbk nicht vom NAV Client auch wieder die ursprungs-Collation herstellt?
Zwar ist die DB-Einstellung dann anders (gilt nur für neue Objekte), aber trotzdem kann man ja die Collation pro Tabelle/Spalte einstellen.
Wenn NAV die Collation nicht die vom Backup wiederherstellt, weiß ich nicht, ob Deine Prozedur überhaupt offiziell unterstützt wird (Sortierung A-Backup nach Sortierung-B wiederherstellen). Auch daher könnte dieser "interessante" Fehler kommen.

Die Collation von ganzen Datenbanken umstellen (also die schon vorhandenen Objekte) ist nicht trivial. Im Endeffekt muss auf jede Tabelle ein ALTER-Befehl abgesetzt werden. Und dies tut der NAV Client, wenn Du die von mir beschriebene Prozedur vornimmst.

Hallo JanGD,

den Weg direkt in der DB zu ändern funktioniert bei uns nicht, da der NAV Client irgendwann abbricht. Die Anzahl der Mandanten usw. scheint einfach zu groß zu sein. Daher jetzt der Umweg über fbk Backups.

Bist Du Dir sicher, dass das Restore eines fbk nicht vom NAV Client auch wieder die ursprungs-Collation herstellt?

Wir erstellen erst eine neue SQL DB mit der entsprechenden neuen Collation, in der dann die FBKs wieder eingelesen werden. Die entsprechenden Tabellen usw. werden dann ja komplett neu erstellt.

Die Frage ist: Speichert NAV/SQL Server alte Logins, zeigt aber in der Windows-Logins Übersicht die aktuellen an? Siehe mein Beispiel oben.

Viele Grüße,
Janosch

Hallo JanGD,

habe eine Lösung gefunden. Hier zu finden http://www.msdynamics.de/viewtopic.php?f=34&t=12526#p89774

Viele Grüße,
Janosch