26
Windows RDS Aufgabenplanung startet nicht mehr
Hallo zusammen,
ich stehe momentan leider von einem etwas merkwürdigen Problem.
Seit ca. ein bis zwei Wochen habe ich auf einem Windows RDS Hostserver (Windows Server 2022 Datacenter, VM auf VMWare ESXi) das Problem, dass der Aufgabenplanungsdienst nicht mehr startet.
Wenn man den Dienst starten möchte, erscheint folgender Fehler:
Dienst "Aufgabenplanung" wurde auf "Lokaler Computer" gestartet und dann angehalten. Einige Dienste werden automatisch angehalten, wenn sie nicht von anderen Diensten oder Programmen verwendet werden.
Das führt leider logischerweise dazu, dass die geplanten Tasks nicht mehr ausgeführt werden, aber auch dazu, dass der Servermanager die Daten der Leistungsindikatoren nicht abrufen kann. Das ist für die Verwaltung von RDS und das Bereitstellen von RemoteApps leider sehr ungünstig.
Ich habe schon einiges Recherchiert und folgendes probiert:
- Ich habe den "TaskCache" Schlüssel in der Registry unter [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache] geleert und den Server neu gestartet (ohne Besserung, weder mit geleertem Cache, noch mit wiederhergestelltem Schlüssel)
- Ich habe SFC /scannow und DISM Restorehealth Befehle ausgeführt. Beide konnten einige Systemdateien nicht reparieren. Wenn ich die Logs richtig auswerte, liegt das an der "LServer_PKConfig.xml" und "Microsoft-Windows-TerminalServices-Licensing-UI-Package". Auch wenn ich eine Windows ISO Mounte und eine Source angebe.
Das habe ich tatsächlich Online auch öfter gefunden bei Windows RDS Installation, leider waren die meisten Einträge ohne Lösung oder wurden von einer (mir nicht ganz vertrauenswürdigen) Drittanbietersoftware behoben...
- Ich habe Versucht ein Systemimage wiederherzustellen über die gebootete Windows ISO. Leider ohne Aufgabenplanung auch keine Schattenkopien...
- Ich habe einen CHKDSK beim Boot ausgeführt, bei dem auch Dateien repariert wurden, leider aber wohl nicht die richtigen.
- Virenscan (Sophos Endpoint for Server) ist momentan deinstalliert.
Das Einzige, was mir das Ereignisprotokoll ausgibt, ist immer wieder ein Fehler mit dem Softwareschutzdienst (ID 16385, Fehlercode 0x80041315). Meine Recherche hierzu führt mich wieder zurück zum Problem mit der Aufgabenplanung.
Bei Bedarf kann ich auch gerne die DISM und SFC Logs hochladen. Ich bin leider nicht ganz sicher, wie diese richtig ausgewertet werden.
Ich hoffe jemand hier hat Erfahrung mit diesem Fehler und kann mir evtl. weiterhelfen.
Eine Neuinstallation wäre sehr mühsam, da hier einiges an Software läuft inkl. vieler RemoteApps, RDS Lizenzserver, etc...
Ich habe in diesem Netzwerk auch zwei weitere RDS Hosts, ich habe mich bis jetzt nur nicht getraut die LServer_PKConfig.xml einfach von einem anderen Server zu kopieren.
Vielen Dank für eure Hilfe!
Mit freundlichen Grüßen,
Lucas
ich stehe momentan leider von einem etwas merkwürdigen Problem.
Seit ca. ein bis zwei Wochen habe ich auf einem Windows RDS Hostserver (Windows Server 2022 Datacenter, VM auf VMWare ESXi) das Problem, dass der Aufgabenplanungsdienst nicht mehr startet.
Wenn man den Dienst starten möchte, erscheint folgender Fehler:
Dienst "Aufgabenplanung" wurde auf "Lokaler Computer" gestartet und dann angehalten. Einige Dienste werden automatisch angehalten, wenn sie nicht von anderen Diensten oder Programmen verwendet werden.
Das führt leider logischerweise dazu, dass die geplanten Tasks nicht mehr ausgeführt werden, aber auch dazu, dass der Servermanager die Daten der Leistungsindikatoren nicht abrufen kann. Das ist für die Verwaltung von RDS und das Bereitstellen von RemoteApps leider sehr ungünstig.
Ich habe schon einiges Recherchiert und folgendes probiert:
- Ich habe den "TaskCache" Schlüssel in der Registry unter [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache] geleert und den Server neu gestartet (ohne Besserung, weder mit geleertem Cache, noch mit wiederhergestelltem Schlüssel)
- Ich habe SFC /scannow und DISM Restorehealth Befehle ausgeführt. Beide konnten einige Systemdateien nicht reparieren. Wenn ich die Logs richtig auswerte, liegt das an der "LServer_PKConfig.xml" und "Microsoft-Windows-TerminalServices-Licensing-UI-Package". Auch wenn ich eine Windows ISO Mounte und eine Source angebe.
Das habe ich tatsächlich Online auch öfter gefunden bei Windows RDS Installation, leider waren die meisten Einträge ohne Lösung oder wurden von einer (mir nicht ganz vertrauenswürdigen) Drittanbietersoftware behoben...
- Ich habe Versucht ein Systemimage wiederherzustellen über die gebootete Windows ISO. Leider ohne Aufgabenplanung auch keine Schattenkopien...
- Ich habe einen CHKDSK beim Boot ausgeführt, bei dem auch Dateien repariert wurden, leider aber wohl nicht die richtigen.
- Virenscan (Sophos Endpoint for Server) ist momentan deinstalliert.
Das Einzige, was mir das Ereignisprotokoll ausgibt, ist immer wieder ein Fehler mit dem Softwareschutzdienst (ID 16385, Fehlercode 0x80041315). Meine Recherche hierzu führt mich wieder zurück zum Problem mit der Aufgabenplanung.
Bei Bedarf kann ich auch gerne die DISM und SFC Logs hochladen. Ich bin leider nicht ganz sicher, wie diese richtig ausgewertet werden.
Ich hoffe jemand hier hat Erfahrung mit diesem Fehler und kann mir evtl. weiterhelfen.
Eine Neuinstallation wäre sehr mühsam, da hier einiges an Software läuft inkl. vieler RemoteApps, RDS Lizenzserver, etc...
Ich habe in diesem Netzwerk auch zwei weitere RDS Hosts, ich habe mich bis jetzt nur nicht getraut die LServer_PKConfig.xml einfach von einem anderen Server zu kopieren.
Vielen Dank für eure Hilfe!
Mit freundlichen Grüßen,
Lucas
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671135
Url: https://administrator.de/forum/windows-rds-aufgabenplanung-startet-nicht-mehr-671135.html
Ausgedruckt am: 12.03.2025 um 11:03 Uhr
26 Kommentare
Neuester Kommentar
Moin
Die Masse an fehlerhaften Dateien hört sich danach an als ob dein Hauptspeicher oder die Platte gerade die Grätsche macht. Also erst mal die Hardware ausschließen und RAM via Memtest86 und Plattenparameter mittels smartmontools checken bevor du anderweitig weitermachst.
Gruß goldcap
Die Masse an fehlerhaften Dateien hört sich danach an als ob dein Hauptspeicher oder die Platte gerade die Grätsche macht. Also erst mal die Hardware ausschließen und RAM via Memtest86 und Plattenparameter mittels smartmontools checken bevor du anderweitig weitermachst.
Eine Neuinstallation wäre sehr mühsam, da hier einiges an Software läuft inkl. vieler RemoteApps, RDS Lizenzserver, etc...
Wofür gibt es Backups?!Gruß goldcap
Das mache ich. Da es eine VM ist, und die anderen VMs aber problemlos laufen, vermute ich nicht, dass es kein Hardwaredefekt sein wird.
Naja, da nicht ganz sicher ist, wann es das letzte mal funktioniert hat, und die User auch Daten auf dem TS Speichern, wird das mit dem Backup schwierig...
Naja, da nicht ganz sicher ist, wann es das letzte mal funktioniert hat, und die User auch Daten auf dem TS Speichern, wird das mit dem Backup schwierig...
Zitat von @NastyNase:
Das mache ich. Da es eine VM ist, und die anderen VMs aber problemlos laufen, vermute ich nicht, dass es kein Hardwaredefekt sein wird.
Naja die Disk der VM liegt auch nur auf dem physischen Datenträger, wenn die virtuelle Platte der VM in einem Bereich der physischen Platte liegt der Probleme macht dann kann das auch Auswirkungen nur auf eine einzelne VM haben.Das mache ich. Da es eine VM ist, und die anderen VMs aber problemlos laufen, vermute ich nicht, dass es kein Hardwaredefekt sein wird.
Platte und Memtests scheinen ok. Wobei ich nicht ganz sicher bin, ob es sinnvoll ist den Smartmon direkt auf der VM auszuführen...
Zitat von @NastyNase:
Wobei ich nicht ganz sicher bin, ob es sinnvoll ist den Smartmon direkt auf der VM auszuführen...
Das macht natürlich nur Sinn auf dem Virtualization-Host selbst genauso wie ein RAM-Check den man besser auch nur am Host durchführt um wirklich den gesamten Speicher zu erfassen.Wobei ich nicht ganz sicher bin, ob es sinnvoll ist den Smartmon direkt auf der VM auszuführen...
Ich habe Versucht ein Systemimage wiederherzustellen über die gebootete Windows ISO. Leider ohne Aufgabenplanung auch keine Schattenkopien...
Moin. Das Zitierte klingt unlogisch. Als der Fehler noch nicht da war, waren Schattenkopien möglich, den Zustand willst Du haben. Sicher, dass keine Windows-Image-Backups gemacht wurden? Oder habt Ihr nie welche gemacht?Du kannst jederzeit ein Inplace-Upgrade versuchen. Dieses repariert erfahrungsgemäß besser, als DISM und sfc. Downtime je nach Leistungsfähigkeit des Storages und Anzahl der Nutzerprofile zwischen 15 und 60 Minuten.
Naja, eigentlich sind Schattenkopien aktiv, aber er findet kein Systemimage, wenn ich versuche das wiederherzustellen. Bin tatsächlich davon ausgegangen, dass das auch von diesem Fehler kommt.
Ganz blöde Frage, aber wie mache ich denn ein Inplace Upgrade, wenn ich Windows Server 2022 mit aktuellen Updates installiert habe, ohne neu zu installieren? Wenn ich die ISO boote kann ich ja nur Windows neu installieren oder in die Reparaturoptionen booten.
Ganz blöde Frage, aber wie mache ich denn ein Inplace Upgrade, wenn ich Windows Server 2022 mit aktuellen Updates installiert habe, ohne neu zu installieren? Wenn ich die ISO boote kann ich ja nur Windows neu installieren oder in die Reparaturoptionen booten.
Volume shadow copy ist eine Technik, die Windows beherrscht. Imagekopien werden damit im laufenden Betrieb möglich, Hast Du jedoch nie einen Schedule für Imagekopien veranlasst, dann ist da zu Recht auch nichts.
ISO doppelklicken
Setup starten
Upgrade auswählen
->Der Wizard sollte anbieten, alle Programme, Einstellungen und Dateien zu behalten.
Wenn ich die ISO boote...
Nicht davon booten. im Laufenden Windows:ISO doppelklicken
Setup starten
Upgrade auswählen
->Der Wizard sollte anbieten, alle Programme, Einstellungen und Dateien zu behalten.
Ich habe das tatsächlich gerade auch selbst gefunden und probiert, die Option Daten zu behalten ist ausgegraut und nicht auswählbar, obwohl ich die selbe ISO verwende, die zur Installation verwendet wurde...
Mit welcher Begründung? Die solltest Du sehen.
Evtl. brauchst Du eine aktualisierte ISO mit integriertem kumulativem update von Januar25 (kannst Du selbst erstellen mit ntlite oder ein paar DISM-Befehlen).
Evtl. brauchst Du eine aktualisierte ISO mit integriertem kumulativem update von Januar25 (kannst Du selbst erstellen mit ntlite oder ein paar DISM-Befehlen).
Ich probiere hier jetzt schon eine Weile rum. Problem ist - Mein Vorgänger hat hier eine HPE OEM installiert, von HPE bekommt man keine ISO zum Download, heißt die mir vorhandenen ISOs (von CD) sind nicht gerade aktuell.
Ich habe per DISM /online /get-targeteditions die verfügbaren Upgrade-Editionen geprüft.
Das Ergebnis hierbei: Die aktuelle Edition kann auf keine Zieledition aktualisiert werden.
Bei einem anderen Server (auch HPE OEM Datacenter 2022), aber anderer Kunde, wird hier Windows Server 2022 Datacenter aufgeführt.
Bei einem funktionierenden Server im gleichen Netzwerk jedoch die gleiche Meldung beim DISM Befehl...
Edit:
Begründung wird keine Angezeigt...
Ich habe per DISM /online /get-targeteditions die verfügbaren Upgrade-Editionen geprüft.
Das Ergebnis hierbei: Die aktuelle Edition kann auf keine Zieledition aktualisiert werden.
Bei einem anderen Server (auch HPE OEM Datacenter 2022), aber anderer Kunde, wird hier Windows Server 2022 Datacenter aufgeführt.
Bei einem funktionierenden Server im gleichen Netzwerk jedoch die gleiche Meldung beim DISM Befehl...
Edit:
Begründung wird keine Angezeigt...
Du kannst die ISO, die Du hast öffnen und den Inhalt entpacken nach c:\temp\iso
Danach kannst Du bitte das aktuelle CU laden: https://catalog.s.download.windowsupdate.com/c/msdownload/update/softwar ...
Dann auf dem Server selbst so vorgehen:
Danach hast Du im Tempordner aktuelle Setupdateien mit denen du das Inplace-Upgrade erneut probierst.
Die Zahl hinter Index: muss Du raussuchen wie folgt: dism /Get-WimInfo /WimFile:c:\temp\sources\install.wim
Danach kannst Du bitte das aktuelle CU laden: https://catalog.s.download.windowsupdate.com/c/msdownload/update/softwar ...
Dann auf dem Server selbst so vorgehen:
DISM /Mount-image /imagefile:c:\temp\iso\sources\install.wim /Index:X /MountDir:c:\mount\windows
Dism /Image:"C:\mount\windows" /Add-Package /PackagePath="c:\downloads\windows10.0-kb5049983-x64_504225784e5acb6fac71e101f342a0c66cb4a10d.msu" /LogPath=C:\mount\dism.log
Dism /Unmount-Image /MountDir:C:\mount\windows /CommitDie Zahl hinter Index: muss Du raussuchen wie folgt: dism /Get-WimInfo /WimFile:c:\temp\sources\install.wim
Erst mal vielen, vielen Dank für die Hilfe.
Leider komme ich nicht weiter, weil ich das Update nicht auf das gemountete Image installieren kann...
(Ich habe auch mal das Kum. Update vom Dezember aus dem Update Katalog heruntergeladen, leider ohne Erfolg.)
Das Log spricht von einem Version Mismatch, was aber m.M.n. nicht sein kann. Ich habe das Image mit Index 4 gemountet (Datacenter mit Desktopdarstellung) und das Update für Windows Server 21H2 heruntergeladen, was auch laut Systemsteuerung die installierte Version ist.
Kann ich das Logfile hier irgendwie hochladen? Ich kann nur Bilder oder Text einfügen. Aufgrund der Länge des Logfiles wäre das glaube ich aber etwas viel...
Leider komme ich nicht weiter, weil ich das Update nicht auf das gemountete Image installieren kann...
(Ich habe auch mal das Kum. Update vom Dezember aus dem Update Katalog heruntergeladen, leider ohne Erfolg.)
Das Log spricht von einem Version Mismatch, was aber m.M.n. nicht sein kann. Ich habe das Image mit Index 4 gemountet (Datacenter mit Desktopdarstellung) und das Update für Windows Server 21H2 heruntergeladen, was auch laut Systemsteuerung die installierte Version ist.
Kann ich das Logfile hier irgendwie hochladen? Ich kann nur Bilder oder Text einfügen. Aufgrund der Länge des Logfiles wäre das glaube ich aber etwas viel...
Das wundert mich. Was gibt denn das Kommando aus Zeile 2 direkt auf der Shell zurück, wenn man den Logpath weglässt?
Und mich erst.. lol
Die Kommandozeile gibt folgendes aus:
Tool zur Imageverwaltung für die Bereitstellung
Version: 10.0.20348.681
Abbildversion: 10.0.20348.202
1 von 1 wird verarbeitet - C:\temp\Update\windows10.0-kb5048654-x64_ef51e63024cd96187ed7a777b1b6bbafb4c2b226.msu: Fehler
Weitere Informationen finden Sie in der Protokolldatei.
Fehler: 0x800f0823
Fehler: 0x800f0823
DISM-Fehler: Es wurde kein Vorgang ausgeführt.
Weitere Informationen finden Sie in der Protokolldatei.
Die DISM-Protokolldatei befindet sich unter "C:\temp\Update\dism.log".
Die Kommandozeile gibt folgendes aus:
Tool zur Imageverwaltung für die Bereitstellung
Version: 10.0.20348.681
Abbildversion: 10.0.20348.202
1 von 1 wird verarbeitet - C:\temp\Update\windows10.0-kb5048654-x64_ef51e63024cd96187ed7a777b1b6bbafb4c2b226.msu: Fehler
Weitere Informationen finden Sie in der Protokolldatei.
Fehler: 0x800f0823
Fehler: 0x800f0823
DISM-Fehler: Es wurde kein Vorgang ausgeführt.
Weitere Informationen finden Sie in der Protokolldatei.
Die DISM-Protokolldatei befindet sich unter "C:\temp\Update\dism.log".
DISM ist zu alt ...
0x800f0823 == CBS_E_NEW_SERVICING_STACK_REQUIRED
0x800f0823 == CBS_E_NEW_SERVICING_STACK_REQUIRED
Du kannst den Prozess auch auf einem anderen Rechner machen und die Dateien danach auf den Server bringen... Teste das lieber.
Danke für eure Hilfe!
Leider haut auch das nicht hin... Ich habe es sowohl auf meinem Arbeit-PC (DISM Version 10.0.22621.2792), als auch auf einem komplett neuen Surface (DISM Version 10.0.26100.1150) versucht, leider auch hier der Fehler 0x800f0823.
Aber er bringt mir hier noch eine zusätzliche Information:
Fehler beim Anwenden der Datei "Unattend.xml" aus dem MSU-Paket.
Ich habe zu dem Fehler ein wenig recherchiert und herausgefunden, dass der Updatesprung zu groß ist.
Ich bin gerade dabei ein Kumulatives Update aus 2022 auf die ISO zu laden, momentan sieht es zumindest mal besser aus (Gerade bei ca. 6% verarbeitet).
Ich werde mich melden, ob es mit mehreren kleinen Sprüngen funktioniert.
Leider haut auch das nicht hin... Ich habe es sowohl auf meinem Arbeit-PC (DISM Version 10.0.22621.2792), als auch auf einem komplett neuen Surface (DISM Version 10.0.26100.1150) versucht, leider auch hier der Fehler 0x800f0823.
Aber er bringt mir hier noch eine zusätzliche Information:
Fehler beim Anwenden der Datei "Unattend.xml" aus dem MSU-Paket.
Ich habe zu dem Fehler ein wenig recherchiert und herausgefunden, dass der Updatesprung zu groß ist.
Ich bin gerade dabei ein Kumulatives Update aus 2022 auf die ISO zu laden, momentan sieht es zumindest mal besser aus (Gerade bei ca. 6% verarbeitet).
Ich werde mich melden, ob es mit mehreren kleinen Sprüngen funktioniert.
Ahhh. Du hast Recht, Server 2019 (und auch sein ISO!) kann man von der Urversion aus nicht direkt auf die letzte bringen. Du musst zunächst das Servicestackupdate integrieren (selber Prozess, aber mit diesem Paket: https://catalog.s.download.windowsupdate.com/c/msdownload/update/softwar ... )
Danach dann das neueste aus Januar25.
Danach dann das neueste aus Januar25.
Sorry, war die letzten Tage leider krank.
Ich habe alles installiert und sauber unmounted, allerdings kann ich "Keep files, settings, and apps" immer noch nicht auswählen...
Sonst noch Ideen?
Ich habe alles installiert und sauber unmounted, allerdings kann ich "Keep files, settings, and apps" immer noch nicht auswählen...
Sonst noch Ideen?
Wenn Du wirklich im Setup keinen Grund genannt bekommst, warum das nicht auswählbar ist, dann nimm bitte das Logfile (setupact.log aus c:\$... ) und lies da nach und teile, warum es nicht angeboten wird.
Also irgendwas stimmt hier ganz und gar nicht... Da sind nur 7 Zeilen geloggt, ich kopiere sie hier mal rein:
Determining whether we should run ConX or legacy setup
Will launch ConX setup experience
Initializing Media class driver for audio support
Initializing media class driver status: 126
Launching ConX setup experience
Inspecting ConX Setup Cmdline
Launching F:\_temp\iso\Sources\SetupPrep.exe
Danach passiert nichts mehr.
Der untere Pfad ist der Speicherort der extrahierten ISO Datei.
Determining whether we should run ConX or legacy setup
Will launch ConX setup experience
Initializing Media class driver for audio support
Initializing media class driver status: 126
Launching ConX setup experience
Inspecting ConX Setup Cmdline
Launching F:\_temp\iso\Sources\SetupPrep.exe
Danach passiert nichts mehr.
Der untere Pfad ist der Speicherort der extrahierten ISO Datei.
Da weiß ich nicht weiter.
Du könntest den HPE Support fragen.
Du könntest den HPE Support fragen.
Manchmal sieht man den Wald vor lauter Bäumen nicht.
Die ISO/ das Setup war nach Standard auf Englisch (EN-us) gestellt, Windows war aber auf Deutsch installiert.
Ich musste also nach der Installation der Updates noch über DISM die Standard-Sprache im Mount-Verzeichnis anpassen. Danach konnte ich die Installation (Windows Server 2022 Datacenter DE-de) auswählen, und konnte auch meine Daten behalten!
Jetzt hat das Inplace Upgrade funktioniert und die Aufgabenplanung startet auch wieder!
Danke für eure Hilfe!
Die ISO/ das Setup war nach Standard auf Englisch (EN-us) gestellt, Windows war aber auf Deutsch installiert.
Ich musste also nach der Installation der Updates noch über DISM die Standard-Sprache im Mount-Verzeichnis anpassen. Danach konnte ich die Installation (Windows Server 2022 Datacenter DE-de) auswählen, und konnte auch meine Daten behalten!
Jetzt hat das Inplace Upgrade funktioniert und die Aufgabenplanung startet auch wieder!
Danke für eure Hilfe!
O-K....
Falsche Sprache wird doch immer dick und breit zu lesen sein.
Komisch, ich hatte das noch nie, dass es nicht da stand, wenn das zutraf.
Aber gut, erledigt
Falsche Sprache wird doch immer dick und breit zu lesen sein.
Komisch, ich hatte das noch nie, dass es nicht da stand, wenn das zutraf.
Aber gut, erledigt
1
Nope, tatsächlich gar keine Begründung, warum ich das nicht auswählen konnte...
Aber naja, immerhin habe ich es noch gefunden Danke dir nochmal!
Aber naja, immerhin habe ich es noch gefunden
Danke dir nochmal!
