[gelöst] Azure SQL - NavEncryptionDataTooLongException
10. April 2017 11:34
Hi,
beim Versuch, eine frische Azure-SQL-Datenbank (leere Azure-SQL-DB erzeugt, dann per Import-NAVDATA die DB aufgebaut) den NST mit der DB zu verbinden, erhalte ich folgenden Fehler.....
Ich habe die Vermutung, dass es daran liegt, dass ich die DB per Import-NAVDATA versorgt habe und nicht über das SQL-Management-Studio per bacpac.
Kann jemand meine Vermutung bestätigen? Wäre allerdings schade, da ich die Methode über Import-NAVDATA wesentlich freundlicher finde (und es geht m.E. schneller)
Upate:
nachdem ich nun mal lokal probiert hatte, meinen NST mit der Azure-DB zu verbinden, konnte ich aus dem Eventlog folgende Meldung ziehen:
-- - ok, dann nimm einfach meinen neuen EncyptionKey, den das NAV-Admintool wohl eben nicht wie erwartet in die DB geladen hatte, nachdem er erstellt wurde:
Hinweis:
was ich immer gemacht hatte, war Import-NAVEncryptionKey noch zusätzlich mit "-ServerInstance MeinNST" abzufeuern, was aber dann wohl nicht zum gewünschtem Erfolg führt
Nach dem Import fix den Dienst angemacht -klappt - und er läuft auch mal länger als 5secs - supi ....also direkt auf dem Azure-Server probiert.....und siehe da - es geht
...also jedenfalls läuft der Dienst noch - selbst als ich mich per WinClient verbunden hatte - welch ein Wunder
beim Versuch, eine frische Azure-SQL-Datenbank (leere Azure-SQL-DB erzeugt, dann per Import-NAVDATA die DB aufgebaut) den NST mit der DB zu verbinden, erhalte ich folgenden Fehler.....
- Code:
Server instance: DynamicsNAV100
Tenant ID:
<ii>User:
Type: Microsoft.Dynamics.Nav.Types.Exceptions.Encryption.NavEncryptionDataTooLongException
SuppressMessage: False
SuppressExceptionCreatedEvent: False
FatalityScope: None
Message: <ii>Daten konnten nicht verschlüsselt werden. Die bereitgestellte Zeichenfolge ist zu lang.</ii>
StackTrace:
bei Microsoft.Dynamics.Nav.Types.ServerUserSettings.LoadProperties(Object target, ConfigurationSettingsProvider provider)
bei Microsoft.Dynamics.Nav.Types.ServerUserSettings.CreateInstance(ConfigurationSettingsProvider settingsProvider)
bei Microsoft.Dynamics.Nav.WindowsServices.DynamicsNavServer.Main(String[] args)
Source: Microsoft.Dynamics.Nav.Types
HResult: -2146233088
</ii>
Ich habe die Vermutung, dass es daran liegt, dass ich die DB per Import-NAVDATA versorgt habe und nicht über das SQL-Management-Studio per bacpac.
Kann jemand meine Vermutung bestätigen? Wäre allerdings schade, da ich die Methode über Import-NAVDATA wesentlich freundlicher finde (und es geht m.E. schneller)
Upate:
nachdem ich nun mal lokal probiert hatte, meinen NST mit der Azure-DB zu verbinden, konnte ich aus dem Eventlog folgende Meldung ziehen:
- Code:
The NAV application could not be mounted for database 'XXX' on database server 'ABCDE.DATABASE.WINDOWS.NET' due to the following error: Die Microsoft Dynamics NAV Server-Instanz kann keine Verbindung mit der Anwendungsdatenbank herstellen, da sie einen anderen Kennwortverschlüsselungsschlüssel verwendet als denjenigen, der aktuell in der Datenbank verwendet wird
-- - ok, dann nimm einfach meinen neuen EncyptionKey, den das NAV-Admintool wohl eben nicht wie erwartet in die DB geladen hatte, nachdem er erstellt wurde:
- Code:
Import-NAVEncryptionKey -KeyPath "C:\ProgramData\Microsoft\Microsoft Dynamics NAV\100\Server\Keys\XXX.key" -ApplicationDatabaseServer ABCDE.database.windows.net -ApplicationDatabaseCredentials $mycreds -ApplicationDatabaseName XXX -Force
Hinweis:
was ich immer gemacht hatte, war Import-NAVEncryptionKey noch zusätzlich mit "-ServerInstance MeinNST" abzufeuern, was aber dann wohl nicht zum gewünschtem Erfolg führt
Nach dem Import fix den Dienst angemacht -klappt - und er läuft auch mal länger als 5secs - supi ....also direkt auf dem Azure-Server probiert.....und siehe da - es geht
...also jedenfalls läuft der Dienst noch - selbst als ich mich per WinClient verbunden hatte - welch ein Wunder