Server 2019 reboot task scheduler 'in wachtrij'

[FastFred]

Mijn vraag
Afgelopen donderdag op vrijdagnacht is een nieuwe versie van ons Citrix image van test naar productie gegaan. Er zijn wat aanpassingen gedaan een week eerder door de vaste engineer van onze MSP om issue's met FSlogix op te lossen en daarnaast een aantal 'updates', maar wat precies is mij (nog) niet bekend.

Wat er nu gebeurd, op het tijdstip dat de herstart taak moet worden uitgevoerd, dan springt deze van 'Gereed' naar 'In wachtrij' en verder gebeurt er niks. Tijdens het testen van dit image is ons helaas niet opgevallen dat de dagelijkse reboot niet functioneert.

Relevante software en hardware die ik gebruik

1. XenApp server op basis van Server 2019 1809 17763.2300. Image distributie met Citrix Provisioning
2. De dagelijkse herstart doen we via task scheduler omdat een restart schedule vanuit de Citrix Delivery Group nog nooit stabiel gewerkt heeft waardoor servers niet herstarten, of een shutdown doen ipv een reboot.

Configuratie van de taak
De taak start iedere dag (incl. weekend) om 3:30. Autorisatie is standaard met de domain admin, hoewel ik inmiddels diverse andere accounts zonder succes geprobeerd heb. De taak roept 'shutdown.exe' aan in Windows\System32, met parameters '-r -f -t 5'

Wat ik al gevonden of geprobeerd heb

1. Vanuit command prompt handmatig 'shutdown -r -f -t 5' uitvoeren werkt
2. Handmatig de task uitvoeren werkt
3. De taak automatisch laten lopen met diverse accounts, zowel lokaal als domein werkt niet.
4. Taak volledig van scratch aangemaakt i.p.v. import
5. Alle andere taken uitgeschakeld

[PD2JK]

Vinkje 'execute whether user is logged on or not' ?
Wat mij als eerst te binnen schiet.

[MAX3400]

Er zijn wat aanpassingen gedaan

Dan zou ik daar ook maar eens achteraan gaan; als je "domain admins" niets meer mogen en ook je local accounts niet...

[FastFred]

PD2JK schreef op dinsdag 25 januari 2022 @ 15:39:
Vinkje 'execute whether user is logged on or not' ?
Wat mij als eerst te binnen schiet.

Die staat uiteraard gewoon aan.

MAX3400 schreef op dinsdag 25 januari 2022 @ 15:40:
Dan zou ik daar ook maar eens achteraan gaan; als je "domain admins" niets meer mogen en ook je local accounts niet...

Jep, eensch. Maar als authenticatie het probleem zou zijn dan zou het niet moeten werken als je de taak handmatig triggert, en dat doet ie dus wel.

De taak lijkt dus wel gewoon te functioneren zoals het hoort, behalve als je een tijdstip invult en het automatisch laat doen.

[ Voor 52% gewijzigd door FastFred op 25-01-2022 15:53 ]

[MAX3400]

Long shot maar staat er iets in de eventlogging van jouw DC's? Tenminste, build 2300 op Server 2019 kan (in sommige gevallen) een OOB-patch nodig hebben KB5008602.

[Viper®]

Wordt de taak wel aangeroepen, m.a.w. staat deze in de task history ?
Zo nee controleer eens of de schedule trigger ook actief is, triggers > enabled
controleer ook of de taak voor windows server 2019 ingesteld staat en ook als de user niet logged in is


Verder weet ik niet of de gebruikte user ook 'log on as a batch job' rechten heeft.

[FastFred]

MAX3400 schreef op dinsdag 25 januari 2022 @ 15:53:
Long shot maar staat er iets in de eventlogging van jouw DC's? Tenminste, build 2300 op Server 2019 kan (in sommige gevallen) een OOB-patch nodig hebben KB5008602.

DC's zijn build 2366. Moet ik naar een specifiek iets zoeken in de eventlogs? Want ik kan zo niks vinden

Viper® schreef op dinsdag 25 januari 2022 @ 15:55:
Wordt de taak wel aangeroepen, m.a.w. staat deze in de task history ?
Zo nee controleer eens of de schedule trigger ook actief is, triggers > enabled

Bingo! Bij task history staat een waarschuwing voor ieder tijdstip dat ik de taak automatisch wilde laten uitvoeren, dat de taak in de wachtrij geplaatst is, maar geen reden erbij...

controleer ook of de taak voor windows server 2019 ingesteld staat en ook als de user niet logged in is
[Afbeelding]

Dat staat allemaal al correct.

Verder weet ik niet of de gebruikte user ook 'log on as a batch job' rechten heeft.
[Afbeelding]

Daar is de lokale Administrators groep lid van, en daar is weer de lokale Administrator en de Domain Admins groep lid van.

[ Voor 8% gewijzigd door FastFred op 25-01-2022 16:15 ]

[Tostiee]

Dit probleem vorig jaar met het opbouwen van een nieuwe RDS2019 ook gehad. Alle taken in de task scheduler bleven in een queue hangen. Handmatig uitvoeren ging wel goed maar automatisch inderdaad niet.

Dit was destijds voor mij de oplossing: https://docs.microsoft.co...9-rds-task-scheduler.html

Heb van een werkende 2019 server de volgende registry sleutel geëxporteerd en vervolgend geïmporteerd op de problematische server. "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications"

[Viper®]

FastFred schreef op dinsdag 25 januari 2022 @ 16:04:
[...]


DC's zijn build 2366. Moet ik naar een specifiek iets zoeken in de eventlogs? Want ik kan zo niks vinden


[...]


Bingo! Bij task history staat een waarschuwing voor ieder tijdstip dat ik de taak automatisch wilde laten uitvoeren, maar zonder reden...


[...]


Dat staat allemaal al correct.


[...]


Daar is de lokale Administrators groep lid van, en daar is weer de lokale Administrator en de Domain Admins groep lid van.

Anders vinkje bij 'If the running task does not end'
En dan in de dropdown "Stop the existing instance"

https://i.stack.imgur.com/jkBZp.png

[FastFred]

@Viper® Nope, al geprobeerd en net nogmaals voor de sicherheit.

[FastFred]

Tostiee schreef op dinsdag 25 januari 2022 @ 16:09:
Dit probleem vorig jaar met het opbouwen van een nieuwe RDS2019 ook gehad. Alle taken in de task scheduler bleven in een queue hangen. Handmatig uitvoeren ging wel goed maar automatisch inderdaad niet.

Dit was destijds voor mij de oplossing: https://docs.microsoft.co...9-rds-task-scheduler.html

Heb van een werkende 2019 server de volgende registry sleutel geëxporteerd en vervolgend geïmporteerd op de problematische server. "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications"

Moet die werkende server 2019 server ook die reboot taak hebben of maakt dat niet uit? Want we hebben geen server 2019 machines draaien waar die reboot taak ook op zit.

Nog iets getest
Aangezien de taak wel werkt als je 'm handmatig start, en het shutdown commando ook werkt in cmd, heb ik het ff geprobeerd door de scheduled task een batch file te laten aanroepen met in die batchfile

code:

shutdown.exe -r -f -t 5

Maar dan doet ie het ook niet.

[Tostiee]

FastFred schreef op dinsdag 25 januari 2022 @ 16:32:
[...]


Moet die werkende server 2019 server ook die reboot taak hebben of maakt dat niet uit? Want we hebben geen server 2019 machines draaien waar die reboot taak ook op zit.

Nog iets getest
Aangezien de taak wel werkt als je 'm handmatig start, en het shutdown commando ook werkt in cmd, heb ik het ff geprobeerd door de scheduled task een batch file te laten aanroepen met in die batchfile

code:

shutdown.exe -r -f -t 5

Maar dan doet ie het ook niet.

Nee op die werkende 2019 server hoeft de reboot taak niet aanwezig te zijn.

[Viper®]

FastFred schreef op dinsdag 25 januari 2022 @ 16:32:
[...]


Moet die werkende server 2019 server ook die reboot taak hebben of maakt dat niet uit? Want we hebben geen server 2019 machines draaien waar die reboot taak ook op zit.

Nog iets getest
Aangezien de taak wel werkt als je 'm handmatig start, en het shutdown commando ook werkt in cmd, heb ik het ff geprobeerd door de scheduled task een batch file te laten aanroepen met in die batchfile

code:

shutdown.exe -r -f -t 5

Maar dan doet ie het ook niet.

Is het een optie om vanaf een andere machine de scheduler te laten draaien. Met /m kan je een remote systeem opgeven. Wel even zorgen dat het account rechten heeft op de machine. Niet ideaal natuurlijk

[Rolfie]

Misschien het administrator account aanpassen naar System?

Eventueel de Reboot task ook laten aanmaken via GPO? Zodat deze hier vanuit de reboot doet?
Je kunt eventueel een CMD hiervoor maken, met bepaalde logging er in, zodat je iets meer informatie hebt.

Alternatief zou je het eens via powershell kunnen doen, ipv shutdown.exe?

eventueel een andere scheduletask aanmaken, met dezelfde configuratie, maar dat deze iets anders doet? Bijvoorbeeld een logfile maken op een UNC share, zodat je weet dat dit goed werkt?

[FastFred]

Tostiee schreef op dinsdag 25 januari 2022 @ 16:09:
Dit probleem vorig jaar met het opbouwen van een nieuwe RDS2019 ook gehad. Alle taken in de task scheduler bleven in een queue hangen. Handmatig uitvoeren ging wel goed maar automatisch inderdaad niet.

Dit was destijds voor mij de oplossing: https://docs.microsoft.co...9-rds-task-scheduler.html

Heb van een werkende 2019 server de volgende registry sleutel geëxporteerd en vervolgend geïmporteerd op de problematische server. "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications"

Dat was 'm wel. Ik heb de hele HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications folder geexport van onze 2019 (AD)DC server en geimport op de XenApp server en meteen werken.