none
SQL Server 2008 R2 Standard unter Netzwerkdienst RRS feed

  • Frage

  • Hallo,

    habe ein kleines Problem. Wir haben eine SQL Server Instanz (IN) auf SQL Server 2008 R2 Standard am Laufen. Heute haben wir ein paar Updates eingespielt u.A. auch das SP1 für SQL 2008 R2. Seit dem kann ich den SQL Server (IN) nicht starten und erhalten einen 17058 zurück.

    Anschließend habe ich ein wenig probiert und folgendes herausgefunden:

    Unter der services.msc den SQLServer(IN) ein anderes Anmeldekonto zum Starten hinzufügen (lokales Systemkonto) = funktioniert!

    Unter den lokalen Benutzergruppen den Netzwerkdienst in die Gruppe der Administratoren stecken und den Dienst SQLServer(IN) mit dem Netzwerkdienst starten = funktioniert.

    Vorher war, so meine ich, der Netzwerkdienst nicht Mitglied der lokalen Gruppe Administratoren, ferner lief der Dienst mit der Instanz unter dem Konto Netzwerkdienst. Nach dem Update halt das Problem.

    Jemand eine Idee?


    • Bearbeitet SADFR Sonntag, 24. März 2013 14:42
    Sonntag, 24. März 2013 14:41

Antworten

  • Am 24.03.2013 schrieb SADFR:

    Wenn ich es über den Server Konfigurationsmanager einstelle, dann erhalte ich folgende Fehlermeldung:

    Fehler bei WMI-Anbieter.

    Fehler bei WMI-Anbieter [der Aufruf des WMI-Anbieters gab folgenden Fehlercode zurück: 0x800742a2].

    Ist zwar kein 2008R2, aber evtl. hilft der Artikel:
    http://support.microsoft.com/kb/955496/de

    Setze ich den Netzwerkdienst wieder in die Gruppe der lokalen Administratoren und wiederhole o.g. Vorgang, dann läuft alles ohne Probleme.

    In den lokalen Admins hat der NETZWERKDIENST nichts verloren.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Sonntag, 24. März 2013 17:51
  • Hallo,

    wie Winfried schon schreibt:
    Änderungen an den Dienstkonten solltest Du nur über den SQL Server Konfigurationsmanager vornehmen.
    Nur dann ist sichergestellt, dass die notwendigen Rechte für Verzeichnisse und Registry eingestellt werden.

    Den SQL Server Konfigurationsmanager starte ggf. über Ausführen als Administrator.
    Auch den von Winfried genannten KB Artikel beachten.

    Wenn eine Windows Domäne existiert ist es Sinnvoller ein Domänen-Konto zu verwenden, 
    siehe Einrichten von Windows-Dienstkonten

    Gruß Elmar

    Sonntag, 24. März 2013 18:11
  • Hallo,

    die zitierten Abschnitte stammen alle aus " Einrichten von Windows-Dienstkonten"
    Ich weiß, ein (zu) langer Artikel, aber letztendlich die Referenz.

    Ansonsten könntest Du mit dem Process Monitor, schauen was wo mangels Rechten fehlschlägt.

    Und falls alles nicht hilft oder es einfach zu lange dauert - sichere die Nutzer-Datenbanken
    deinstalliere die Instanz und installiere sie anschließend neu; danach die Datenbank wiederherstellen.
    Das geht oft  schneller als die Suche nach ominösen Änderungen.

    Gruß Elmar

    Sonntag, 24. März 2013 20:11
  • Danke für eure Geduld, es läuft nun. Wie auch immer dieser Fehler entstanden ist.

    Ich habe nun folgendes gemacht (mit eurer Hilfe versteht sich!):

    Alles wieder in den originalen Zustand wie vor dem Update versetzt

    Nochmal doof aus der Wäsche geschaut

    Alle Verzeichnisse nochmals überprüft

    Den Aha-Effekt genossen

    Den SQLSERVERMSSQLUSER$SERVER$INSTANZ zu den NTFS Berechtigungen im Verzeichnis LOG hinzugefügt (der User war nur noch durch seine SID abgebildet, der Name war verschwunden)

    Anschließend über den Konfigurationsmanager wieder auf Netzwerkdienst zurückgestellt

    DB gestartet, funktioniert!

    Danke für eure Geduld, aber Sonntag Abend halt...



    Sonntag, 24. März 2013 20:24

Alle Antworten

  • Am 24.03.2013 schrieb SADFR:

    Unter der services.msc den SQLServer(IN) ein anderes Anmeldekonto zum Starten hinzufügen (lokales Systemkonto) = funktioniert!

    Unter den lokalen Benutzergruppen den Netzwerkdienst in die Gruppe der Administratoren stecken und den Dienst SQLServer(IN) mit dem Netzwerkdienst starten = funktioniert.

    Vorher war, so meine ich, der Netzwerkdienst nicht Mitglied der lokalen Gruppe Administratoren, ferner lief der Dienst mit der Instanz unter dem Konto Netzwerkdienst. Nach dem Update halt das Problem.

    Dann fehlt dem Netzwerkdienst an der richtige Stelle ein paar
    NTFS-Berechtigungen lokal auf der Maschine. Mit Hilfe des
    ProcessMonitor kannst Du rausfinden, wo genau es hapert.
    http://technet.microsoft.com/de-de/sysinternals/bb896645.aspx

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Sonntag, 24. März 2013 16:58
  • Am 24.03.2013 schrieb SADFR:

    Jemand eine Idee?

    Im SQL-Server Konfigurationsmanager von SYSTEM auf Netzwerkdienst
    umstellen, dann werden auch die NTFS-Berechtigungen angepasst.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Sonntag, 24. März 2013 16:59
  • Danke für deine Antwort aber das hatte ich schon versucht.

    Wenn ich es über den Server Konfigurationsmanager einstelle, dann erhalte ich folgende Fehlermeldung:

    Fehler bei WMI-Anbieter.

    Fehler bei WMI-Anbieter [der Aufruf des WMI-Anbieters gab folgenden Fehlercode zurück: 0x800742a2].

    Habe nun nichts weiter gemacht als den Netzwerkdienst aus der Gruppe der lokalen Administratoren zu entfernen, anschließend über den Konfigurationsmanager unter dem Punkt Anmelden, Anmelden als: Radio Button an Integriertes Konto: Netzwerkdients auszuwählen. Danach genannte Fehlermeldung.

    Setze ich den Netzwerkdienst wieder in die Gruppe der lokalen Administratoren und wiederhole o.g. Vorgang, dann läuft alles ohne Probleme.

    Sonntag, 24. März 2013 17:10
  • Am 24.03.2013 schrieb SADFR:

    Wenn ich es über den Server Konfigurationsmanager einstelle, dann erhalte ich folgende Fehlermeldung:

    Fehler bei WMI-Anbieter.

    Fehler bei WMI-Anbieter [der Aufruf des WMI-Anbieters gab folgenden Fehlercode zurück: 0x800742a2].

    Ist zwar kein 2008R2, aber evtl. hilft der Artikel:
    http://support.microsoft.com/kb/955496/de

    Setze ich den Netzwerkdienst wieder in die Gruppe der lokalen Administratoren und wiederhole o.g. Vorgang, dann läuft alles ohne Probleme.

    In den lokalen Admins hat der NETZWERKDIENST nichts verloren.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Sonntag, 24. März 2013 17:51
  • Hallo,

    wie Winfried schon schreibt:
    Änderungen an den Dienstkonten solltest Du nur über den SQL Server Konfigurationsmanager vornehmen.
    Nur dann ist sichergestellt, dass die notwendigen Rechte für Verzeichnisse und Registry eingestellt werden.

    Den SQL Server Konfigurationsmanager starte ggf. über Ausführen als Administrator.
    Auch den von Winfried genannten KB Artikel beachten.

    Wenn eine Windows Domäne existiert ist es Sinnvoller ein Domänen-Konto zu verwenden, 
    siehe Einrichten von Windows-Dienstkonten

    Gruß Elmar

    Sonntag, 24. März 2013 18:11
  • Der Netzwerkdienst gehört dort in der Tat nicht rein, dessen bin ich mir bewusst. Zur Zeit ist das halt die einzige Möglichkeit den Dienst zu starten. Andere SQL Server Instanzen (SQL Express) auf der gleichen Maschine laufen.

    Ich bin den Artikel durchgegangen, leder ohne Erfolg, gleiches Problem. Habe auch den Manager als Administrator ausgeführt, ebenfalls ohne Erfolg. Der Server ist ein Memberserver einer bestehenen Domäne. Verstehe nur nicht warum der Fehler heute nach Update auftrat, vorher lief es, haben auch nichts  geändert und auf einmal startet der Dienst nicht mehr. Würde gerne die Benutzereinstellungen so lassen wie sie vorher waren, daher bin ich den 2. Lösungsvorschlag nicht nachgegangen.

    Ich habe so beinahe alles durch. Habe auch schon dem NETZWERKDIENST auf die entsprechenden SQL Ordner Schreibrechte erteilt, ebenfalls ohne Erfolg. Was ich nun noch getestet habe ist, dass ich den Datenbankdateien NTFS Rechte gesetzt habe, denn dort ist in keiner der Dateien der NETZWERKDIENST zu sehen gewesen, da sollte er aber eigentlich sein. Habe aber alles wieder auf den Zustand von vor dem Update zurück geändert, wie beschrieben ohne Erfolg.

    Sonntag, 24. März 2013 18:46
  • Hallo,

    die Berechtigungen werden nicht direkt dem Dienstkonto zugewiesen, sondern dem Konto
    SQLServerMSSQLUser$<ComputerName>$<InstanceName>

    Erläutert im obigen Link: Unterstützte Dienstkonfigurationen
    Von SQL Server werden Ressourcen-ACLs mithilfe einer Sicherheitsgruppe und nicht direkt mithilfe des Dienstkontos festgelegt. Dadurch kann das Dienstkonto geändert werden, ohne den Prozess für Ressourcen-ACLs zu wiederholen. Bei der Sicherheitsgruppe kann es sich um eine lokale Sicherheitsgruppe, um eine Domänensicherheitsgruppe oder um eine Dienst-SID handeln.

    Zu den Berechtigungen siehe den Abschnitt:
    Überprüfen der für SQL Server-Dienstkonten erteilten Windows NT-Rechte und -Privilegien

    Wenn Du weitere funktionierende Instanzen hast, schau Dir die Sicherheitskonfiguration dort an.

    Gruß Elmar

    Sonntag, 24. März 2013 19:06
  • Nun ja die Einstellungen sind nahezu die Gleichen.

    Einziger Unterschied sind die NTFS Berechtigungen auf die DB Files innerhalb von DATA im SQL Pfad. Diese habe ich auch schon geändert, ohne Erfolg. Die SQL Gruppen habe die Berechtigung "anmelden als Dienst" in den lokalen Sicherheitsrichtlinien.

    Der Fehler scheint ja auch in sämtlichen Variationen allgegenwärtig. Alles probiert, kein Erfolg. Mit deinem letzten Post kann ich leider nichts anfangen. Was sollte deiner Meinung nach wo eingetragen sein? Nun es läuft ja auch, wenn der Netzwerkdienst Administratorprivilegien hat. Steh gerade mehr als nur auf dem Schlauch, srry.

    Sonntag, 24. März 2013 19:49
  • Hallo,

    die zitierten Abschnitte stammen alle aus " Einrichten von Windows-Dienstkonten"
    Ich weiß, ein (zu) langer Artikel, aber letztendlich die Referenz.

    Ansonsten könntest Du mit dem Process Monitor, schauen was wo mangels Rechten fehlschlägt.

    Und falls alles nicht hilft oder es einfach zu lange dauert - sichere die Nutzer-Datenbanken
    deinstalliere die Instanz und installiere sie anschließend neu; danach die Datenbank wiederherstellen.
    Das geht oft  schneller als die Suche nach ominösen Änderungen.

    Gruß Elmar

    Sonntag, 24. März 2013 20:11
  • Danke für eure Geduld, es läuft nun. Wie auch immer dieser Fehler entstanden ist.

    Ich habe nun folgendes gemacht (mit eurer Hilfe versteht sich!):

    Alles wieder in den originalen Zustand wie vor dem Update versetzt

    Nochmal doof aus der Wäsche geschaut

    Alle Verzeichnisse nochmals überprüft

    Den Aha-Effekt genossen

    Den SQLSERVERMSSQLUSER$SERVER$INSTANZ zu den NTFS Berechtigungen im Verzeichnis LOG hinzugefügt (der User war nur noch durch seine SID abgebildet, der Name war verschwunden)

    Anschließend über den Konfigurationsmanager wieder auf Netzwerkdienst zurückgestellt

    DB gestartet, funktioniert!

    Danke für eure Geduld, aber Sonntag Abend halt...



    Sonntag, 24. März 2013 20:24