Scheduled tasks starten niet na upgrade Windows Server 2025

[Mr Magic]

Mijn vraag

Ik heb mijn thuisserver geupdatet van Windows Server 2022 naar Windows Server 2025.
Nu blijkt dat alle tasks in de task scheduler die de optie "Run whether user is logged on or not" gebruiken niet meer willen starten. Ik zie het proces (bijv. PowerShell.exe of cmd.exe) wel in de task manager verschijnen met de juiste command line, maar het betreffende script wordt niet uitgevoerd.

Relevante software en hardware die ik gebruik

Windows Server 2025 op een zelfbouw thuisserver met daarin een Intel 12700K en 128 GB geheugen. Enkele SSD's en een hard disk voor de storage. De server is ook tegelijk domain controller.

Wat ik al gevonden of geprobeerd heb

De tasks draaien onder een domain account. Ik heb geprobeerd het meest simpele CMD scriptje in een task te draaien die alleen een bestandje op disk aanmaakt, maar zelfs dat werkt niet. Ook het aanpassen van de task zodat deze bijv. onder SYSTEM of NETWORK SERVICE draait maakt geen verschil.

Het enige dat werkt is om de task aan te passen naar "Run only when the user is logged on", maar dat is niet wenselijk, want ik wil dat de tasks automatisch starten na een herstart van de server. Overigens werkt het "Hidden" maken van de tasks ook niet, want als ze nu starten komt er telkens even een zwart venster van PowerShell of CMD naar voren.

Zoals gezegd werkte dit allemaal prima onder WS2022, maar dus niet meer onder WS2025.

Als iemand een idee heeft...

[Falcon]

Deze gebruiker geeft hetzelfde aan: https://x.com/kaidja/status/1862918196614844851

Regressie bug?

[Mr Magic]

@Falcon Thanks, deze had ik nog niet gevonden

Ik heb ook nog een VM draaien met WS2025 die ook domain controller is en daarop werkt mijn test-script (een simpele .cmd) wel gewoon. Erg vaag dit.

[MAX3400]

Mr Magic schreef op zondag 15 december 2024 @ 10:54:
@Falcon Thanks, deze had ik nog niet gevonden

Ik heb ook nog een VM draaien met WS2025 die ook domain controller is en daarop werkt mijn test-script (een simpele .cmd) wel gewoon. Erg vaag dit.

Dan zou ik maar eens beginnen met je gpresult te controleren van / op beide machines? Want als je 2x hetzelfde OS hebt, 2x "als domain controller" en de ene doet het wel en de andere niet, klinkt het als een issue tussen stoel en keyboard In je startpost zeg je dat het op de niet-werkende machine onder "een domain account" draait; welke memberships heeft dat account?

En ja, waarschijnlijk tegen alle best practices in maar werkt het script ook niet als je het als "domain\administrator" aftrapt?

En als je beide tasks (werkend en niet werkend) eens exporteert als XML; welke SID / member staat daarin dan vermeld?

[Mr Magic]

MAX3400 schreef op zondag 15 december 2024 @ 12:37:
[...]

Dan zou ik maar eens beginnen met je gpresult te controleren van / op beide machines?

Bedankt voor de tip, ga ik bekijken.

klinkt het als een issue tussen stoel en keyboard

Niet nodig deze opmerking. Ik werk al met Windows Server versies sinds NT 3.51, so this is not my first rodeo Bovendien werkte het zoals gezegd wel goed onder WS2022 en stopte het met werken na een inplace upgrade naar WS2025.

In je startpost zeg je dat het op de niet-werkende machine onder "een domain account" draait; welke memberships heeft dat account?

Het draaide al onder het "domain\administrator" account. Ik weet het, niet best practice, maar het is maar voor thuis. Ik heb ook een gewone domain user geprobeerd en deze het "login as a batch job" recht gegeven, maar dat werkte ook niet.

En als je beide tasks (werkend en niet werkend) eens exporteert als XML; welke SID / member staat daarin dan vermeld?

Dat ga ik ook nog even bekijken.

Het vreemde is dat de betreffende tasks wel worden gestart en ook in de task manager te zien zijn met de juiste command line, alleen doen ze niks:



Waar de dubbele quotes vandaan komen is me ook niet duidelijk, want die staan niet ingevuld onder Program/script in de task definitie.

In helloworld.cmd staat alleen dit:

code:

@echo off
cd /d C:\Tasks
echo Hello world > hello.log

Het bestand hello.log wordt dus niet aangemaakt, tenzij ik de task configureer met "Run only when the user is logged on".

Ik heb overigens ook PowerShells scripts geprobeerd met PowerShell.exe als executable en "-File C:\Tasks\Test.ps1" als arguments, maar ook die werken niet meer.

Ik heb het gevoel dat de scripts staan te wachten op één of andere input, maar aangezien ze in session 0 draaien en dus niet meer interactive zijn, kun je dat nergens zien voor zover ik weet. Ook een "Start-Transcript" aan het begin van een .ps1 script maakt geen log aan helaas.

[Blokker_1999]

Ben je nu letterlijk het domain administrator account aan het gebruiken om een scheduled taak te draaien? Misschien dat daar net het probleem zit. Ik zou eens proberen met een ander accont, danwel met het system account van de server.

[Mr Magic]

@Blokker_1999 Of je leest eerst even mijn antwoord hierboven:

Het draaide al onder het "domain\administrator" account. Ik weet het, niet best practice, maar het is maar voor thuis. Ik heb ook een gewone domain user geprobeerd en deze het "login as a batch job" recht gegeven, maar dat werkte ook niet.

Daarnaast:

1. Het is maar een thuisserver.
2. Het heeft altijd goed gedraaid onder WS2019 en WS2022.
3. Het werkt wel op een andere server (ook domain controller) met WS2025.

Het zou nog aan de GPO's kunnen liggen, maar daar moet ik nog wat dieper induiken.

[Blokker_1999]

Wat is de status van de taak? En geeft het laatste resultaat iets van foutmelding? Of blijft de taak gewoon eeuwig draaien totdat je ze zelf stopzet?

En als je de venstertjes wel kunt zien net omdat ze bij het starten niet verborgen zijn, kan je dan eens proberen van ze niet te verbergen? Zie je dan toevallig iets van een prmopt die aangeeft waarop gewacht wordt?

In plaats van PowerShell aan te roepen met een bestand kan je ook nog eens proberen of je PowerShell kunt aanroepen met enkel een commando, bijvoorbeeld een commando dat een nieuw bestand aanmaakt, om te zien of dat wel werkt en het systeem dus mogelijks problemen heeft met het ophalen van het bestand.

[MAX3400]

Ik heb overigens ook PowerShells scripts geprobeerd met PowerShell.exe als executable en "-File C:\Tasks\Test.ps1" als arguments, maar ook die werken niet meer.

Dan zal ik wel verkeerd lezen maar de goede code is toch:

code:

PowerShell.exe -File "C:\Tasks\Test.ps1"

Je moet -File niet tussen de quotes rammen. Los daarvan; als je geen spaties in je padnaam hebt, zijn de dubbele quotes tegenwoordig ook niet meer nodig.

Het zou nog aan de GPO's kunnen liggen, maar daar moet ik nog wat dieper induiken.

en meteen voor onze sanity zodat we aannames over het installatie-proces en typefouten in GPO's kunnen uitsluiten; zijn beide 2025-Servers binnen hetzelfde forest/domain opgenomen en hebben ze exact dezelfde GPO's op hun OU? Of zijn het 2 losse DC's die niets met elkaar te maken hebben?

Dat scheelt nogal een slok op een borrel als je je GPO's wil nalopen / vergelijken. Of, als het echt aparte domains zijn: even met Wincompare of Notepad++ je hele NETLOGON vergelijken op file & char niveau?

[ Voor 44% gewijzigd door MAX3400 op 15-12-2024 20:42 ]

[Mr Magic]

Blokker_1999 schreef op zondag 15 december 2024 @ 19:49:
Wat is de status van de taak? En geeft het laatste resultaat iets van foutmelding? Of blijft de taak gewoon eeuwig draaien totdat je ze zelf stopzet?

Geen foutmelding helaas. De taak blijft op "Running" staan en is ook zichtbaar in de Task Manager (zie screenshot hierboven).

En als je de venstertjes wel kunt zien net omdat ze bij het starten niet verborgen zijn, kan je dan eens proberen van ze niet te verbergen? Zie je dan toevallig iets van een prmopt die aangeeft waarop gewacht wordt?

Als je een taak draait met de optie "Run wether user is logged on or not" krijg je helaas geen vensters te zien. De taak draait dan in de z.g. "session 0" die gereserveerd is voor services en niet-interactieve taken. "Vroeger" t/m Windows Server 2003 kon je aan sessie 0 connectie via "mstsc /console", maar vanaf Vista/Windows Server 2008 is dat veranderd i.v.m. verbeterde security.

[Mr Magic]

MAX3400 schreef op zondag 15 december 2024 @ 20:27:
[...]

Je moet -File niet tussen de quotes rammen. Los daarvan; als je geen spaties in je padnaam hebt, zijn de dubbele quotes tegenwoordig ook niet meer nodig.

Typefout van mijn kant. In de properties van de Tasks staat het gewoon goed. De tasks draaien ook goed zolang ik het via de optie "Run only when the user is logged on" doe.

en meteen voor onze sanity zodat we aannames over het installatie-proces en typefouten in GPO's kunnen uitsluiten; zijn beide 2025-Servers binnen hetzelfde forest/domain opgenomen en hebben ze exact dezelfde GPO's op hun OU? Of zijn het 2 losse DC's die niets met elkaar te maken hebben?

Het zijn twee DCs in hetzelfde domain en ze staan ook in dezelfde OU. Ze krijgen dan ook dezelfde GPO's. Alleen is de ene server mijn fysieke thuisserver en de andere een VM, zodat ik altijd een replica van de AD heb.

Er moet iets niet goedd zitten in de thuisserver, maar het vervelende is dat je de output van de scripts niet kunt zien zolang ze in session 0 draaien. En log files laten aanmaken door de scripts werkt ook niet, omdat ze niet eens beginnen (hoewel ze wel in de task manager zichtbaar zijn).

[MAX3400]

Mr Magic schreef op zondag 15 december 2024 @ 20:43:
[...]

Het zijn twee DCs in hetzelfde domain en ze staan ook in dezelfde OU. Ze krijgen dan ook dezelfde GPO's. Alleen is de ene server mijn fysieke thuisserver en de andere een VM, zodat ik altijd een replica van de AD heb.

Er moet iets niet goedd zitten in de thuisserver, maar het vervelende is dat je de output van de scripts niet kunt zien zolang ze in session 0 draaien. En log files laten aanmaken door de scripts werkt ook niet, omdat ze niet eens beginnen (hoewel ze wel in de task manager zichtbaar zijn).

Ik ben gewoon lastig (altijd al geweest) maar als beide machines "identiek" zijn want allebei DC in hetzelfde domain en de ene doet het wel met schtasks en de andere niet; dan is toch ergens de configuratie niet 100% gelijk tussen beide machines.

Heb je alle tasks van machine A (werkend) al eens allemaal geexporteerd en geimporteerd op machine B (niet werkend)? Heb je niet toevallig iets (onbewust) gedaan met dMSA op de niet-werkende machine? Zijn de permissies van de scripts wel allemaal hetzelfde? Wat geeft gpresult vanuit gpmc (kruiselings, dus machine A vraagt gpresult van B op en andersom) en wat geeft gpresult (verbose via cmd) op de machines zelf?

Mr Magic schreef op zondag 15 december 2024 @ 20:43:
[...]

En log files laten aanmaken door de scripts werkt ook niet, omdat ze niet eens beginnen (hoewel ze wel in de task manager zichtbaar zijn).

Hardop gedacht; je kan toch pwershell.exe starten. Dan een transcript-log starten. En dan pas de andere ps1 inladen en uitvoeren. Volgens mij moet dan alles in je transcript terecht komen.

[ Voor 14% gewijzigd door MAX3400 op 15-12-2024 20:53 ]

[Mr Magic]

MAX3400 schreef op zondag 15 december 2024 @ 20:52:
[...]

... dan is toch ergens de configuratie niet 100% gelijk tussen beide machines.

Mee eens. Alleen de uitdaging is om te vinden wat. Nu is het wel zo dat de machine waar het niet op werkt wat meer "vervuild" zal zijn omdat ik daar ook allerlei andere zaken op draai zoals Hyper-V, nzbget, Plex Server, etc. etc., terwijl de werkende machine alleen een "kale" DC is (weliswaar ook tot WS2025 gekomen via inplace upgrades vanaf ik meen uit m'n hoofd WS2016).

Heb je alle tasks van machine A (werkend) al eens allemaal geexporteerd en geimporteerd op machine B (niet werkend)?

Nee, maar wel de andere kant op. Dus een niet-werkend test script (de helloworld.cmd) overgezet naar de werkende machine (via export van de task naar XML) en daar werkte het meteen.

Heb je niet toevallig iets (onbewust) gedaan met dMSA op de niet-werkende machine?

Nee nog niks gedaan met dMSA accounts.

Zijn de permissies van de scripts wel allemaal hetzelfde?

Voor zover ik kan zien wel. Overigens is het probleem er niet alleen met scripts. Ik heb bijv. een Iperf3.exe die ook niet wil werken als ik hem op dezelfde manier start. Ook hier zie ik de .exe wel in het geheugen staan in de task manager, maar als ik met netstat controleer, zie ik geen listening poort op 5201. Start ik de .exe zelf of via de optie "Run only when user is logged on", dan werkt het wel.

Wat geeft gpresult vanuit gpmc (kruiselings, dus machine A vraagt gpresult van B op en andersom) en wat geeft gpresult (verbose via cmd) op de machines zelf?

Dat moet ik nog verder uitzoeken.

Hardop gedacht; je kan toch pwershell.exe starten. Dan een transcript-log starten. En dan pas de andere ps1 inladen en uitvoeren. Volgens mij moet dan alles in je transcript terecht komen.

Je bedoelt neem ik aan zelf een interactieve PowerShell starten en dan een Start-Transcript en daarna de scheduled task starten?

[Mr Magic]

Korte update: Ik kwam erachter dat de server waar e.e.a. wel werkt één Windows Update achterloopt (2024-11), terwijl de niet werkende server 2024-12 draait.

Ik zag dit pas nadat ik met ProcMon het startgedrag van een task bekeek waarbij opviel dat bij de niet-werkende server het proces conhost.exe stopte en er daarna niks meer gebeurde, terwijl op de wel werkende server het proces wel gewoon doorliep.

Het blijkt dat conhost.exe een nieuwer versienummer heeft op de niet-werkende server. Helaas heeft het simpelweg vervangen door een oudere versie het probleem niet opgelost. Maar ik vermoed dat het probleem wel wordt veroorzaakt door de 2024-12 update. De update is alleen niet (of niet makkelijk?) te verwijderen, omdat er ook een Servicing Stack Update bij zit

Morgen maar eens een snapshot maken van de werkende server en dan daar ook 2024-12 op zetten

Update 2

Ik zou bijna zeggen "helaas", want ook na installatie van update 2024-12 blijft alles werken op de werkende server. De zoektocht gaat door...

[ Voor 8% gewijzigd door Mr Magic op 16-12-2024 17:07 ]

[asterixonline]

Ik heb dezelfde problemen op twee server 2025 servers, beide domain controllers. Taken werken niet, en heel veel conhost processen. Eigenlijk geen enkele taak aangestuurd door een process of job werkt.

Misschien iemand al een oplossing gevonden?

[Mr Magic]

@asterixonline Ik heb uiteindelijk een ticket aangemaakt bij Microsoft via het Visual Studio abbo van m'n werk.

Daar kwam na wat experimenteren de volgende oplossing uit:

Resolution:
Full Task Scheduler reset with the following steps:

1. Backed up the tasks from %systemroot%\System32\Tasks using a ZIP file with paths included.
2. Deleted Task Scheduler files:
- Navigated to %systemroot%\System32\Tasks in File Explorer.
- Deleted all files and directories
3. Navigated to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Schedule and ensured the Start value was set to 2.
4. Restarted the Task Scheduler by closing and reopening the app.
5. Imported the backed-up tasks from ZIP file back into %systemroot%\System32\Tasks.
6. Restarted the server.

Hopelijk is dit voor jou ook de oplossing.

[asterixonline]

@Mr Magic Hoe doe je dat importeren uiteindelijk? Ik heb dan een zip, maar je kan toch alleen xml importeren?


Of gewoon de bestanden weer terug zetten in de map?

[Mr Magic]

asterixonline schreef op donderdag 6 maart 2025 @ 21:31:
Of gewoon de bestanden weer terug zetten in de map?

Gewoon weer terugzetten in de map ja, incl. de paden uiteraard.

Ik snapte eerst ook niet waarom dat zou helpen, maar het was voor mij wel de oplossing.

[asterixonline]

@Mr Magic Okay, Lijkt voor mij niet te helpen.

Zelf installaties met installer werken niet.. heel vaag allemaal.

[asterixonline]

Ik heb uiteindelijk een 2e domein controller opgezet. Alle fsmo rules verplaatst naar de 2e domein controller. De oorspronkelijke domein controller role verwijderd, en daarna werkt alles weer zoals het hoort op deze server.

Taken werken weer, installaties werken weer. echt zeer apart.