Servicelayer Crash seit Windows Updates 15.11.2023

  • Hallo, wir haben hier einen kompletten Servicelayer Crash seid den Windows Updates vom 15.11.2023


    Wir bekommen den Servicelayer überhaupt nicht mehr hoch,

    Ich versuche gerade die Updates wieder rückgängig zu machen


    Ob es die Udpates sind oder ein anderes Problem versuche ich gerade herauszufinden.



    Ich habe im Hintergrund auch alle TEMP Dateien nach

    Q-100.559
    Kein Starten von Service Layer und Ports möglich


    Versuche aber Ohne Erfolg. =O



    Es gab vor dem Crash auch jemanden der versucht hatte sein SMIME Zertifikate auf CLASS1 oder CLASS2 zu erneurn, direkt nach der Erneuerung des CERT ist der Servcielayer gecrasht, evtl kann das auch damit zusammenhängen

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • "Wizzard" Du hast mich und die Firma gerettet, vielen Dank.

    Hast ein Bier gut bei mir.


    d....sadasdfadsfdfds


    unfassbar... ich hatte alle Windows Updates zurückgerollt ohne Erfolg, die komische Zertifikats Order Datei war es.

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

    Einmal editiert, zuletzt von kingcopy ()

  • Ich hatte auch bei einem Kunden das Problem, dass die Zertifikate nicht erneuert werden konnten.


    Fehler: "Failed to create Challenge. Rate Limit reached".


    Der Server lief aber ohne Probleme. Nach drei Tagen ging es dann plötzlich wieder.


    Wie kann man denn die automatische Zertifikatserneuerung temporär deaktivieren?

  • Ich hatte heute Nacht bei 3 Servern (haben nichts miteinander zu tun, nur das ich mich drum kümmere) , alles Windows Server 2022, das um 3 im Ereignisprotokoll 2 Einträge standen, sinngemäß "Service Layer konnte nicht bis zum Timeout gestartet werden" Der Dienst war "beendet" aber ich konnte ihn normal starten. Hm? Das kann doch kein Zufall sein? Aber einer von denen war noch 410

  • Bei ca. 20% unserer Kunden war heute morgen ebenfalls der SL inaktiv. Ließ sich aber manuell anstoßen.


    Über Nacht war bei vielen ein "hotfix 358701" installiert worden. Ich hab' leider keine Ahnung, was es damit auf sich hat, auf unserem eigenen Server ist dieser Hotfix bislang nicht eingetroffen.

  • Bei mir war auch der SL beendet. David3 von unterwegs geht nicht. ActiveSync geht. Auch der Chayns Zugang funktioniert nicht.

    david (Sitecare) :thumbup: - seit FaxWare 3 dabei ;(

  • Hier ist heute morgen auch der Hofix eingetrudelt
    (dvupdate.chayns-static.space/hotfix/3587/01_DVHF358701.exe), der hebt die SL.exe auf 3593. Wir hatten das Problem allerdings nicht (der Win2022 hat diesen Monat auch seine Updates noch nicht bekommen), daher k.a. Ahnung, ob er die obrigen Probleme fixt. Vielleicht bringt der Fix ja was, da ich nicht sehe, ob die Probleme nach oder vor dem Hotfix sind bei Euch.

  • Hmmm habt ihr mal nach dem Hotfix die Server restartet und den SL Dienst beobachtet, nicht das es durch den Hotfix noch schlimmer wird, bei uns hat die White Porgramm Ausführung verhindert das der Hotfix sich ohne Freischaltung installiert hatte.


    und was macht der Hotfix wenn man wegen dem Crash die besagte JSON Datei vorher schon umbenannt hatte? Muss man die dann wieder zurück Umbennenen? Vorher, zwischendrinn oder danach?

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • Weiss wer, welche Datei(en) durch den Hotfix geändert wird? Bei mir ist der Hotfix heute um 8 Uhr angekommen. Ich wollte den Hotfix vielleicht manuell installieren. Vorher die alte Datei sichern.


    Bei einem 2012R2 Server UND an einem 2019 Server kriege ich kein Purging Report mehr, im Ereignisprotokoll erscheint stattdessen:

    David Hotfix #358701 not installed
    ReasonRequired David ServiceLayer (3587) not found.
    Hotfix#358701
    UserAdministrator

    Das passiert auch wenn ich den Hotfix manuell anklicke. Ich muss den Hotfix umbenennen und hoffen das mit dem nächsten Service-Pack das Problem erledigt ist. :( Der Servicelayer läuft. Oder sollte ich den erst stoppren?


    Ich habe jetzt im David Admin angekreuzt, das automatische Hotfixes NICHT automatisch installiert werden. Ich warte eh mit den Service Packs ein paar Tage oder Wochen,



    Kann es vielleicht sein, das der "required Service Layer" der "314" ist? Ich glaub ich habe da noch "313", ich prüfe das nochmal. Aber denn versucht er ja trortzdem immer wieder den Patch zu installieren. Der Purging report kommt dann halt nicht. Das passiert auch wenn es Probleme gibt beim Lesen der Virussignaturen. Teleweise habe ich den Purging Report verlegt auf 4:00 Uhr.

  • wenn man dem Z$Backup Ordner glauben darf, hat er wohl folgende Dateien ersetzt:


    Z$BACKUP\David.358701\David\code\sl.exe

    Z$BACKUP\David.358701\David\code\resource\code.aux

    Z$BACKUP\David.358701\David\code\resource\code.eng

    Z$BACKUP\David.358701\David\code\resource\code.fra

    Z$BACKUP\David.358701\David\code\resource\code.ger

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!