none
Active Directory-Zertifikatdienste: starten nicht möglich nach Austausch Motherboard RRS feed

  • Frage

  • Hallo

    Wir mussten letzte Woche bei einem SBS Server 2011 das Motherboard austauschen. Der Server läuft seither stabil, nur der Dienst Active Directory-Zertifikatdienste lässt sich nicht mehr starten.

    Der Fehler wird mit Ereignis-ID 7024 protokolliert; es wird auf den Fehler %%-939522880 und auf Fehler %%-939523595 verwiesen. Die ESENTUTL Abfrage der CA Datenbank ergibt einen Clean Shutdown.

    Gibt es dazu Lösungsansätze, sodass der Dienst wieder gestartet werden kann? Habe leider im Internet dazu nicht gefunden.

    Danke und Gruss,
    Marianne

    Montag, 13. August 2018 19:24

Antworten

  • Hallo Evgenij

    Gerne kann ich bestätigen, dass der Dienst nun wieder läuft.

    Zur Info an alle, die es interessieren mag:

    Der Befehl esentutl /r edb führte zu einem Fehler: jet_errattacheddatabasemismatch an outstanding database attachment has been...

    Mit dem Befehl esentutl /r edb /i konnte das Recovery durchgeführt werden.

    Danke trotzdem und einen schönen Tag.

    Gruss,
    Marianne

    • Als Antwort markiert MarianneK Mittwoch, 15. August 2018 07:13
    Mittwoch, 15. August 2018 07:13

Alle Antworten

  • Moin,

    check mal bitte den Speicher "Vertrauenswürdige Stammzertifizierungsstellen" des Computers auf dem SBS, und zwar auf zwei Dinge hin:

    1. das aktuelle Root CA-Zertifikat ist enthalten (welches das ist, kannst Du mit der Konsole "Zertifizierungsstelle" auch feststellen, wenn der Dienst nicht läuft)
    2. es ist kein Zertifikat enthalten, das kein Root-Zertifikat ist (Root = von sich selbst signiert)

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 13. August 2018 19:54
  • Hallo Evgenij

    Danke für die Info. Ich habe mal auf dem Server die certmgr.msc aufgerufen und finde da das Root-CA in der Liste der vertrauenswürdigen Stammzertifizierungsstellen, noch gültig bis 2021.

    Wenn ich Dich richtig verstehe, müsste ich den Inhalt des effektiven Dateipfades kontrollieren, aber kann diesen nicht finden. Wo liegen die Zertifikate?

    Danke und Gruss,
    Marianne
    Dienstag, 14. August 2018 08:27
  • Moin, nee, das war schon richtig.

    Frage: Nutzt ihr die CA für kurzlebige Zertifikate a la 802.1x? Wäre es schlimm, die Datenbank zu verlieren? Falls nicht, würdenich das Root CA-Zertifikat und die CerSrv-Registry sichern, die capolicy.inf kontrollieren und die CA entfernen und gleich wieder neu aufsetzen.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 14. August 2018 10:47
  • Hallo Evgenij

    Ich bin mit Datenbanken im SBS Server immer etwas vorsichtig, da sich diese ja nicht gleich verhalten wie bei einem normalen Windows Server 2008 R2.

    Wir nutzen die Zertifikate für die Exchange-Zertifizierung und somit auch auf den Geräten, die Outlook Anywhere einsetzen. Daher wäre der Aufwand doch etwas grösser, die neuen Zertifikate auf den Endgeräten neu zu installieren, auch wenn es nicht sehr viele sind.

    Was mir noch aufgefallen ist:

    Der Reparaturversuch der Datenbank (mit ESENTUTL) hat eine Logdatei als beschädigt gekennzeichnet. Es ist die edb.log, ohne weitere Kennzeichnung dahinter. Werde mir die weiteren Reparaturwerkzeuge von ESENTUTL nochmals genau ansehen; kenne sie leider nur von Seite Exchange her.

    Danke und Gruss,
    Marianne

    Mittwoch, 15. August 2018 06:10
  • Hallo Evgenij

    Gerne kann ich bestätigen, dass der Dienst nun wieder läuft.

    Zur Info an alle, die es interessieren mag:

    Der Befehl esentutl /r edb führte zu einem Fehler: jet_errattacheddatabasemismatch an outstanding database attachment has been...

    Mit dem Befehl esentutl /r edb /i konnte das Recovery durchgeführt werden.

    Danke trotzdem und einen schönen Tag.

    Gruss,
    Marianne

    • Als Antwort markiert MarianneK Mittwoch, 15. August 2018 07:13
    Mittwoch, 15. August 2018 07:13
  • Moin,

    schön, dass es geklappt hat.

    Nur zu Deinem Verständnis: Es hätte auch dann kein einziges Zertifikat (vor seinem jeweiligen Ablauf) neu ausgestellt und verteilt werden müssen, wenn Du die Datenbank aufgegeben hättest. Du hättest sie nur nicht einfach per Mausklick ZURÜCKZIEHEN können, da die CA dann nicht mehr wüßte, dass sie sie einmal ausgestellt hat.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Mittwoch, 15. August 2018 09:05