none
Fehler 0x851A001A bei der Installation / 0x80092004 beim starten des Dienstes RRS feed

  • Frage

  • Hi,

    also ich schreib erst mal was passiert ist:

    Ich wollte eine weitere SQL 2014 Instanz (bereits zwei waren vorhanden) auf dem Server 2012R2 - der auch DC ist - installieren, was aber mit dem obigen Fehler quittierte. So wie ich herausgefunden habe, versucht das Setup den SQL Server Dienst zu starten, was ihm aber nicht gelingt...

    Also hab ich ein wenig im Internet nachgeforscht und bin der Empfehlung von hier gefolgt und habe alles deinstalliert, um es nochmal neu zu installieren. Allerdings wollte ich keinen extra Benutzer in der AD erstellen (wie vorgeschlagen), da der Service Account eigentlich ausreichend ist und bis jetzt immer (installiere das so schon des öfteren) so funktioniert hat. Local System usw Netzwerkdienst gehen ja auch nicht wirklich, da es ein DC ist.

    Egal, nach dem Deinstallieren, Neustarten und wieder installieren der ersten Instanz lief erst mal alles wieder. Prima dachte ich mir und installierte nun die zweite wieder. Und was kam, der gleiche Fehler wie zuvor. Nachdem ich das dann ein paar mal mit kleinen nicht nennenswerten unterschieden versucht habe, bin ich auf die Logfiles im Ordner C:\Program Files\Microsoft SQL Server\MSSQL12.INSTANZ\MSSQL\Log gestoßen.

    Dort habe ich diese Logzeilen entdeckt:

    2016-02-01 17:05:59.07 spid14s     Error: 17190, Severity: 16, State: 1.
    2016-02-01 17:05:59.07 spid14s     Initializing the FallBack certificate failed with error code: 1, state: 20, error number: 0.
    2016-02-01 17:05:59.07 spid14s     Unable to initialize SSL encryption because a valid certificate could not be found, and it is not possible to create a self-signed certificate.
    2016-02-01 17:05:59.07 spid14s     Error: 17182, Severity: 16, State: 1.
    2016-02-01 17:05:59.07 spid14s     TDSSNIClient initialization failed with error 0x80092004, status code 0x80. Reason: Unable to initialize SSL support. 
    2016-02-01 17:05:59.07 spid14s     Error: 17182, Severity: 16, State: 1.
    2016-02-01 17:05:59.07 spid14s     TDSSNIClient initialization failed with error 0x80092004, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors. 
    2016-02-01 17:05:59.07 spid14s     Error: 17826, Severity: 18, State: 3.
    2016-02-01 17:05:59.07 spid14s     Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.
    2016-02-01 17:05:59.07 spid14s     Error: 17120, Severity: 16, State: 1.


    Also wieder das Internet durchsucht und bin nun bei folgendem Tipp fündig geworden:

    SQL Server generates a self-signed certificate – if it is not available – during the startup process. It is saved in the service account application data folder – for example network service account:%userprofile%\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-xxxxx where xxxxx is specific to your environment.

    Quelle: http://iamberke.com/post/2013/07/05/SQL-Server-cannot-start-TDSSNIClient-initialization-failed.aspx

    Also habe ich mir diesen Ordner bei beiden Dienst Konten (das eine das geht und das andere das nicht geht) angesehen.

    Bei dem wo der Server starten kann ist eine Datei enthalten. Beim neuen nicht. Rechte auf den Ordner stimmen auch (deswegen ist der Tipp leider nicht die Lösung). Aber es bedeutet ja schon mal, dass er dieses Zertifikat nicht erstellt.

    Jetzt die Frage, wieso erstellt der SQL Server das Zertifikat nicht (hab den Profil Ordner auch schon test-weise vor Neuinstallation schon wie vorgeschrieben über System -> Benutzerprofile gelöscht). 

    Eine Vermutung habe ich: denn ich habe ein Zertifikat für den RADIUS Dienst auf dem Server installiert. Das Zertifikat ist auf den Namen des Servers ausgestellt. Hat das was damit zu tun? Kann man den Dienst dazu zwingen, ein eigenes Zertifikat zu erstellen?

    Die Fehlermeldung lautet ja aber, dass er kein Zertifikat findet und auch keins erstellen kann, also sollte es ja nichts mit dem RADIUS Zertifikat zu tun haben?!

    Jetzt wird es noch merkwürdiger:

    Wenn ich im Konfigurationmanager für die Instanz das Radius Zertifikat auswähle, gibt es einen neuen Fehler (unter anderen das er das Zertifikat nicht laden kann, was ich aber wegen den zuvor auftretenden Fehlern wieder mit Löschen entfernt habe - deswegen die Ausgabe jetzt ohne das Zertifikat).

    2016-02-02 16:31:05.09 spid7s      Error: 17204, Severity: 16, State: 1.
    2016-02-02 16:31:05.09 spid7s      FCB::Open failed: Could not open file E:\sql12_main_t.obj.x86Release\sql\mkmastr\databases\mkmastr.proj\MSDBData.mdf for file number 1.  OS error: 3(Das System kann den angegebenen Pfad nicht finden.).
    2016-02-02 16:31:05.09 spid7s      Error: 5120, Severity: 16, State: 101.
    2016-02-02 16:31:05.09 spid7s      Unable to open the physical file "E:\sql12_main_t.obj.x86Release\sql\mkmastr\databases\mkmastr.proj\MSDBData.mdf". Operating system error 3: "3(Das System kann den angegebenen Pfad nicht finden.)".
    2016-02-02 16:31:05.09 spid7s      Error: 17207, Severity: 16, State: 1.
    2016-02-02 16:31:05.09 spid7s      FileMgr::StartLogFiles: Operating system error 2(Das System kann die angegebene Datei nicht finden.) occurred while creating or opening file 'E:\sql12_main_t.obj.x86Release\sql\mkmastr\databases\mkmastr.proj\MSDBLog.ldf'. Diagnose and correct the operating system error, and retry the operation.
    2016-02-02 16:31:05.10 spid7s      File activation failure. The physical file name "E:\sql12_main_t.obj.x86Release\sql\mkmastr\databases\mkmastr.proj\MSDBLog.ldf" may be incorrect.
    2016-02-02 16:31:05.11 spid12s     The resource database build version is 12.00.4100. This is an informational message only. No user action is required.
    2016-02-02 16:31:05.19 spid12s     Starting up database 'model'.
    2016-02-02 16:31:05.19 spid12s     Error: 17204, Severity: 16, State: 1.
    2016-02-02 16:31:05.19 spid12s     FCB::Open failed: Could not open file E:\sql12_main_t.obj.x86Release\sql\mkmastr\databases\mkmastr.proj\model.mdf for file number 1.  OS error: 3(Das System kann den angegebenen Pfad nicht finden.).
    2016-02-02 16:31:05.19 spid12s     Error: 5120, Severity: 16, State: 101.
    2016-02-02 16:31:05.19 spid12s     Unable to open the physical file "E:\sql12_main_t.obj.x86Release\sql\mkmastr\databases\mkmastr.proj\model.mdf". Operating system error 3: "3(Das System kann den angegebenen Pfad nicht finden.)".
    2016-02-02 16:31:05.19 spid12s     Error: 17207, Severity: 16, State: 1.
    2016-02-02 16:31:05.19 spid12s     FileMgr::StartLogFiles: Operating system error 2(Das System kann die angegebene Datei nicht finden.) occurred while creating or opening file 'E:\sql12_main_t.obj.x86Release\sql\mkmastr\databases\mkmastr.proj\modellog.ldf'. Diagnose and correct the operating system error, and retry the operation.
    2016-02-02 16:31:05.19 spid12s     File activation failure. The physical file name "E:\sql12_main_t.obj.x86Release\sql\mkmastr\databases\mkmastr.proj\modellog.ldf" may be incorrect.
    2016-02-02 16:31:05.19 spid12s     Error: 945, Severity: 14, State: 2.
    2016-02-02 16:31:05.19 spid12s     Database 'model' cannot be opened due to inaccessible files or insufficient memory or disk space.  See the SQL Server errorlog for details.
    2016-02-02 16:31:05.19 spid12s     SQL Server shutdown has been initiated
    2016-02-02 16:31:05.19 spid12s     SQL Trace was stopped due to server shutdown. Trace ID = '1'. This is an informational message only; no user action is required.

    Ich vermute, dass kommt weil er das Setup ja schon nicht ganz fertig stellen konnte. Also wäre es sicher das richtige herauszufinden, wieso er auf einmal kein Zertifikat erstellen kann.


    Gruß




    • Bearbeitet tcr82 Dienstag, 2. Februar 2016 15:37
    Dienstag, 2. Februar 2016 15:19

Antworten

  • Okay, ich habe es endlich hinbekommen. Und zwar habe ich mit dem procmon (sysinternals) die Zugriffe des Benutzers verfolgt und gesehen, dass er einen ACCESS DENIED unter C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys bekommen hat. Es gab zwar auch noch ein paar ACCESS DENIED beim Zugriff auf die Registry Schlüssel, aber die waren eigentlich immer auf einen Policy Schlüssel, was also okay ist.

    Also habe ich nach dem MachineKeys Ordner gesucht und den Artikel von MS gefunden:

    The MachineKeys directory is configured with non-default permissions

    Und dort hab ich dann Jeder Vollzugriff auf den Ordner gegeben und die Rechte durch vererbt (musste sie erstmal durch Besitzübernahme an mich reisen...).

    Dann die Instanz wieder deinstalliert, neu gestartet, den Instanz Ordner unter C:\Program Files\Microsoft SQL Server\ gelöscht, das Profil über System->Profilliste gelöscht und wieder neu installiert.. 

    Tata :) Das Setup war erfolgreich!

    Ich denke das ist eigentlich auch wieder mehr ein Workaround, denn ich habe nicht die Rechte des MachineKeys Ordners verändert gehabt. Außerdem finde ich die Rechte auf den Ordner so nicht wirklich okay (so kann jeder (z.B. gehackte Dienst) die Zertifikate (inkl. privaten Schlüssel) der Maschine abgreifen! Im Profil des Dienst-Accounts kommt auch kein Crypto Ordner mehr, also erstellt er wohl auch kein Zertifikat mehr.

    Ob das Problem mal wieder durch irgend ein Update ausgelöst wurde....

    Hoffe auf jeden Fall, dass das anderen aus der unglücklichen Lage hilft, da das Internet viele Beiträge zum dem Thema hergibt, die aber teils mit Falschaussagen gepflastert sind und teils auch von anderen (ähnlichen Fehlern, welche meist nicht mal klar herausgearbeitet werden) her rühren und deswegen eine anderen Lösung benötigen.

    Wenn jetzt aber trotzdem noch jemand eine Idee hat, wieso das vorher nicht geklappt hat, immer her damit :)

    • Bearbeitet tcr82 Dienstag, 2. Februar 2016 16:48
    • Als Antwort markiert tcr82 Dienstag, 10. Mai 2016 12:58
    Dienstag, 2. Februar 2016 16:41

Alle Antworten

  • Okay, ich habe es endlich hinbekommen. Und zwar habe ich mit dem procmon (sysinternals) die Zugriffe des Benutzers verfolgt und gesehen, dass er einen ACCESS DENIED unter C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys bekommen hat. Es gab zwar auch noch ein paar ACCESS DENIED beim Zugriff auf die Registry Schlüssel, aber die waren eigentlich immer auf einen Policy Schlüssel, was also okay ist.

    Also habe ich nach dem MachineKeys Ordner gesucht und den Artikel von MS gefunden:

    The MachineKeys directory is configured with non-default permissions

    Und dort hab ich dann Jeder Vollzugriff auf den Ordner gegeben und die Rechte durch vererbt (musste sie erstmal durch Besitzübernahme an mich reisen...).

    Dann die Instanz wieder deinstalliert, neu gestartet, den Instanz Ordner unter C:\Program Files\Microsoft SQL Server\ gelöscht, das Profil über System->Profilliste gelöscht und wieder neu installiert.. 

    Tata :) Das Setup war erfolgreich!

    Ich denke das ist eigentlich auch wieder mehr ein Workaround, denn ich habe nicht die Rechte des MachineKeys Ordners verändert gehabt. Außerdem finde ich die Rechte auf den Ordner so nicht wirklich okay (so kann jeder (z.B. gehackte Dienst) die Zertifikate (inkl. privaten Schlüssel) der Maschine abgreifen! Im Profil des Dienst-Accounts kommt auch kein Crypto Ordner mehr, also erstellt er wohl auch kein Zertifikat mehr.

    Ob das Problem mal wieder durch irgend ein Update ausgelöst wurde....

    Hoffe auf jeden Fall, dass das anderen aus der unglücklichen Lage hilft, da das Internet viele Beiträge zum dem Thema hergibt, die aber teils mit Falschaussagen gepflastert sind und teils auch von anderen (ähnlichen Fehlern, welche meist nicht mal klar herausgearbeitet werden) her rühren und deswegen eine anderen Lösung benötigen.

    Wenn jetzt aber trotzdem noch jemand eine Idee hat, wieso das vorher nicht geklappt hat, immer her damit :)

    • Bearbeitet tcr82 Dienstag, 2. Februar 2016 16:48
    • Als Antwort markiert tcr82 Dienstag, 10. Mai 2016 12:58
    Dienstag, 2. Februar 2016 16:41
  • Hallo,

    ich hätte nur eine Anmerkung: Man kann einen SQL Server auf einem DC = Domain Controller installieren, es ist aber nicht empfehlenswert, siehe You may encounter problems when installing SQL Server on a domain controller


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Mittwoch, 3. Februar 2016 07:18
  • Aber das KB ist schon älter und nennt auch nicht explizit den SQL Server 2014. Nennt auch nur, dass es spezielle Restriktionen gibt und das ganze nicht so performant läuft. Auch warnt es speziell vor Ro-DCs und Failover Clustern (was wahrscheinlich mit den Restriktionen gemeint ist).

    Und wie gesagt, funktioniert die Installation mit den genannten Instanzen sonnst auch immer auf den DCs ohne Probleme.

    Es ist ganz klar das man für mehr Sicherheit auf einem DC (jeder weitere Dienst gefährdet die Sicherheit des Systems) so etwas auf einen extra Server auslagert (wenn auch nur als VM). Das setzt aber vorausgesetzt man hat genug Ressourcen und/oder die Sicherheit ist einem so extrem Wichtig.

    Man sollte aber auch anmerken, dass bei meinen Instanzen keine über das Netzwerk erreichbar ist, was das Sicherheitsrisiko wieder senkt.

    Somit denke ich, dass de KB wirklich zu vernachlässigen ist und in meinen Fall keine Anwendung findet.

    Aber trotzdem danke für den Hinweis :)

    • Bearbeitet tcr82 Mittwoch, 3. Februar 2016 09:43
    Mittwoch, 3. Februar 2016 09:35