Headless RDP sessie starten

[ktf]

Is er Windows software waarbij het mogelijk is een RDP verbinding op te zetten om een commando uit te voeren, zonder daadwerkelijk een scherm te moeten tonen? Zoals dit, maar dan op Windows.

Ik zal uitleggen waarom.

Ik heb een taakje wat ik graag automatisch zou willen laten uitvoeren op een bepaalde server. Helaas moet die taak gestart worden via een GUI. Ik heb gezocht naar een commandoregel equivalent, maar dat niet gevonden. Ik heb een Powershell script gemaakt wat precies doet wat ik wil, door toetsaanslagen te simuleren. Het probleem is dit script uitvoeren: hiervoor moet een gebruiker zijn ingelogd met GUI, bijvoorbeeld via RDP.

Ik zou graag vanaf een andere server om bijvoorbeeld 2 uur 's nachts zo'n 'headless' RDP-sessie opzetten, waarbij de taak triggert bij inloggen. Probleem: ik kan geen software vinden om dat te faciliteren. Iemand enig idee?

[Markozv]

Je probleem begint al dat programma via een GUI gestart moet worden, dus dit moet onder een active user op de server uitgevoerd worden.

Laten we eerst beginnen bij stap 1:
Wat voor programma is het en wat moet het uitvoeren? Heb je een naam voor ons?

[ktf]

Het gaat om SCADA software, niet iets alledaags dus, specifiek AVEVA System Platform. Er is een taakje wat voor zover ik weet alleen via een snap-in voor Microsoft Management Console (MMC) kan worden gestart.

[jeroen3]

Nouja, technisch gezien kun je natuurlijk een user gebruiken en dat script "at logon" uitvoeren.
Als dat script dan ook weer afmeld kun je dit blijven doen. Dan hoef je alleen een client te hebben die een remote desktop sessie automatisch start.
Wel erg fragiele automations dit, klinkt als een xy probleem.

[F_J_K]

Eerst overleggen met de security mensen. Bij mij zou je op z'n minst een tik op de vingers krijgen. Er zal een reden zijn dat het RDP-only is opgezet en je niet MMC vanaf de eigen device kan gebruiken.

SCADA, dan heb je naar ik aanneem al toegang tot het (juiste V-)LAN. ik mag hopen dat dat niet aan het grote boze interwebs hangt. Als je het script eenmalig klaar zet op de server zelf via RDP kan je die misschien afvuren via schtasks. Of bedoel je een landing server? Zie dan weer m'n eerste zin.

Maar zie vooral Markozv in "Headless RDP sessie starten" en kijk of het niet anders kan. Zijn er geen relevante API's?

[sh4d0wman]

Met @F_J_K wat betreft security...

Anyway: een google search "aveva system platform cli commands" laat zien dat sommige applicaties wel iets aan commandos ondersteunen.

Je kunt nog eens in de directory kijken wat voor exe files je tegen komt en die (samen met de main binary) even op strings scannen. Soms zit die functionaliteit niet in de GUI executable maar een stand-alone exe.

Ik kijk ook wel eens naar SCADA software...

[Markozv]

Persoonlijk al geen voorstander van programmatuur waar een Active user voor nodig is om het te kunnen laten werken. Dat gezegende te hebben is AVEVA System Platform een vrij breed pakket, waar wat @sh4d0wman al zegt ook bepaalde CLI commands mogelijk zijn.

Mijn tweede vraag is waarom moet die taak om 2:00am uitgevoerd worden? En wat voor taak is het?

Wat zegt de software leverancier zelf hierover?

[Dennism]

Markozv schreef op dinsdag 30 december 2025 @ 13:48:


Wat zegt de software leverancier zelf hierover?

Ik zou eerst inderdaad vooral hier aan denken, dit soort pakketten betaal je vaak flink voor de support, maak er dan ook gebruik van. Leg je probleem voor aan de leverancier, en check of ze een supported oplossing hebben.

Kan het niet supported kan je altijd nog verder gaan 'beunen' (mits je natuurlijk toestemming hebt), maar dan zou ik wel even overleggen met de andere betrokken afdelingen (o.a. ook de afdeling die over security gaat). Want dit soort gehobbybob wordt in het bedrijfsleven lang niet altijd op prijs gesteld, ook al denk je bijvoorbeeld het beste voor te hebben. Want je wil bijvoorbeeld ook niet in een situatie komen waarbij jullie een issue hebben en de leverancier komt dan met 'ja, jullie hebben dit op gezet, is niet supported, zoek het verder maakt uit / maak de omgeving eerst maar weer compliant' of iets in die strekking.

[ktf]

Er is een supported oplossing van de leverancier, maar die is te duur (lees: je kunt er een nieuwe auto voor kopen). Momenteel gebeurd het taakje elke dag met de hand. Nogmaals: ik heb al uitgebreid gezocht naar een commandoregel oplossing, en die is er niet. Ik heb dat met powershell geautomatiseerd passend binnen de bestaande security boundaries, maar ik mis de 'active user', anders werkt de toetsaanslagemulatie niet.

De vraag was eigenlijk heel simpel: is er een Windows-RDP tool die headless kan werken, dan kan ik iets wat nu met de hand gebeurt exact een-op-een automatiseren: simuleer de login, simuleer het openen van de mmc, simuleer de toetsaanslagen, simuleer het uitloggen. Dan veranderd er toch ook geen klap qua security?

[Markozv]

uit mijn hoofd, Nee voor een overname sessie is er altijd fysieke handeling van een persoon nodig.

[Question Mark]

ktf schreef op dinsdag 30 december 2025 @ 14:16:
De vraag was eigenlijk heel simpel: is er een Windows-RDP tool die headless kan werken, dan kan ik iets wat nu met de hand gebeurt exact een-op-een automatiseren: simuleer de login, simuleer het openen van de mmc, simuleer de toetsaanslagen, simuleer het uitloggen. Dan veranderd er toch ook geen klap qua security?

Pak een tool als auto-it zou ik zeggen....

AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages (e.g. VBScript and SendKeys).

[ktf]

Question Mark schreef op dinsdag 30 december 2025 @ 14:38:
Pak een tool als auto-it zou ik zeggen....

AutoIT werkt niet als er geen gebruiker actief is ingelogd. Daarom is de vraag: is er een RDP tool waarmee dat inloggen kan simuleren, zodat een tool als AutoIT (in dit geval PowerShell) zijn werk kan doen.

[Ora et Labora]

Misschien denk ik te simpel maar je kunt toch een *.rdp bestand maken waarbij je de credentials opslaat, dat je daar alleen maar op hoef te dubbelklikken?

Dan maak je een schedule aan die de *.rdp aanroept.
Vervolgens een schedule op de desbetreffende machine dat als die gebruiker inlogt, jouw commando's/script worden uitgevoerd.

[ktf]

Ora et Labora schreef op dinsdag 30 december 2025 @ 14:45:
Dan maak je een schedule aan die de *.rdp aanroept.

Dat kan niet, dat kan alleen op een machine waarop iemand is ingelogd. Je kan het dus niet schedulen.

[ Voor 6% gewijzigd door ktf op 30-12-2025 14:46 ]

[jeroen3]

Je kunt hier natuurlijk een virtuele machine voor starten.
Pak een Windows 11 IoT LTSC, die heeft nog autologin, en dan schedule je de remote desktop sessie met je script (welke op je server runt "on logon"?).

Alternatief is je software direct in die VM laden. 't is maar net wat makkelijker is licentie-technisch.

[ Voor 6% gewijzigd door jeroen3 op 30-12-2025 14:55 ]

[Question Mark]

ktf schreef op dinsdag 30 december 2025 @ 14:45:
[...]

AutoIT werkt niet als er geen gebruiker actief is ingelogd. Daarom is de vraag: is er een RDP tool waarmee dat inloggen kan simuleren, zodat een tool als AutoIT (in dit geval PowerShell) zijn werk kan doen.

Je kunt via AutoIT toch een rdp sessie starten, automatisch inloggen en op basis van posities muisinput geven?

[ktf]

jeroen3 schreef op dinsdag 30 december 2025 @ 14:53:
Je kunt hier natuurlijk een virtuele machine voor starten.

Dan komen de eerder genoemde security-dingen wel om de hoek kijken, dus dat is geen optie. Ik kan niet zomaar een VM bijplaatsen.

Question Mark schreef op dinsdag 30 december 2025 @ 15:39:
Je kunt via AutoIT toch een rdp sessie starten, automatisch inloggen en op basis van posities muisinput geven?

Dan moet er dus wel ergens een gebruiker zijn ingelogd, en dan kun je het dus niet op een bepaalde tijd schedulen. Het gebeurd regelmatig dat in die specifieke 'security context' een aantal dagen niemand inlogt op een van de servers in die context. Je kunt dan met de software die ik ken geen RDP sessie opstarten. Daarom zoek ik naar software waarmee dat dus wel kan.

[jeroen3]

Technisch gezien kan een user op Windows Server installatie oneindig ingelogd blijven. Je hebt dan een user van waaruit je kan scripten. Je moet bij een reboot wel één keer opnieuw inloggen.
Het gaat waarschijnlijk net als de VM tegen al je security regels in om een user ingelogd te laten, maar dat is de enige andere optie die ik ken.

Dit hoeft natuurlijk geen normale user te zijn. Je kunt deze enorm begrenzen.

[ Voor 12% gewijzigd door jeroen3 op 30-12-2025 16:33 ]

[Question Mark]

ktf schreef op dinsdag 30 december 2025 @ 16:26:
[...]
Dan moet er dus wel ergens een gebruiker zijn ingelogd, en dan kun je het dus niet op een bepaalde tijd schedulen.

Klopt, maar is dat niet het standaard probleem met software die een GUI nodig heeft? (en meteen ook de reden dat die software eigenlijk verbannen zou moeten worden?)

[sh4d0wman]

@jeroen3 dat is wel een idee. Dan kun je zoiets maken als test:

Dedicated user: svc_gui_automation
“Allow log on through Remote Desktop Services”
Disable screen lock
Prevent RDP sessions from ever disconnecting

Na een eerste aanmelding doe je dan disconnect ipv logoff. De sessie blijft dan gewoon draaien (tot de server eens reboot).

De scheduled task zou volgens AI hier aan moeten voldoen:
- Run as the automation user
- Run only when user is logged on
- NOT run as SYSTEM
-NOT “Run whether user is logged on or not”

This causes Windows to:
Inject the task into the existing interactive session
Attach to WinSta0\Default

[Will_M]

* Will_M heeft een aversie van 'Windows Service Accounts' welke Non-Managed' zijn middels een (Azure / Entra) Active Directory.

Dat soort 'Service' accounts zijn feitelijk gewoon Active Directory User Accounts welke de setting 'User Can Not Change Password' & 'Password Never Expires' mee gekregen hebben.....

Applicaties welke niet met een 'Managed Service-Account' overweg kunnen moet je IMHO in een modern AD Domain eigenlijk niet meer willen zien.

[jeroen3]

@Will_M ja maar dat wil ie niet horen. Mogelijk is het zelfs een reset o.i.d. wat elke nacht gedaan moet worden om matige software in leven te houden. Dat ken ik maar al te goed 🙈

[DutchKel]

Waarom laat je de rdp sessie niet open staan? Als je rdp sluit met het kruisje bovenaan dan blijft de sessie en gui gewoon draaien onder die gebruiker. Het is wel lastiger als er 1 admin en jou sessie is ingelogd en er komt nog een 2e admin om in te loggen, die kan jou sessie dan killen.

Maar in overleg is het bovenstaande geen probleem lijkt mij. Je kunt dan ook de task scheduler gebruiken en instellen dat hij de gui gebruikt.

Edit: ik heb in het verleden een keer hetzelfde ingesteld gehad, hier was een speciaal service account voor gebruikt. Met dat service account logde alle admins in om het proces te debuggen. Dit was toen onderdeel van het document management systeem waar wat onderdelen custom waren ontwikkeld. Deze machine startte Word of Excel op en ging dan het geopende document exporteren naar pdf. De uitdaging zat er uiteraard wel in dat het niet werkte met macro's die mensen erin zetten of als er een wachtwoord op het bestand stond. Vandaar dat er af en toe gecontroleerd moest worden of het nog draaide. Maar hier was ook een gui voor nodig om Word of Excel te kunnen opstarten en aan te sturen. Meer in detail treden is denk ik niet nodig. Inmiddels zijn er ook vele andere manieren om hetzelfde te bereiken.

[ Voor 48% gewijzigd door DutchKel op 30-12-2025 20:06 ]

[Hero of Time]

Bij een eerdere werkgever werd er een logistiek pakket gebruikt en deze moest 4 programma's open hebben om te kunnen werken. Die server logde dan ook automatisch in als deze herstartte en startte die 4 vensters op. Omdat 't een VM was, was het niet zo'n drama dat het scherm een tijdje ontgrendeld bleef. Wat wel een probleem was, was dat een van de vensters zich nog wel eens in een bestand kon verslikken dat verwerkt moest worden en een foutmelding toonde. Het stopte volledig met werken totdat die foutmelding weggeklikt werd.

Omdat IT niet in de avond werkte, maar logistiek wel, gebeurde het wel eens dat het systeem stil stond buiten de standaard IT tijden. Er werd dan gebeld naar wie er waakdienst had, die logde dan in op de server, klikte de foutmelding(en) weg en was klaar. Een andere oplossing was er niet, niet vanuit de leverancier.

Ik heb destijds met Powershell het een en ander gescript met activeren van het betreffende venster en toetsaanslagen sturen. Pauze er bij, nogmaals controleren of het venster er nog was en dan nogmaals proberen die te sluiten om dan het programma weer te starten (het kon maar 1x draaien, dus als de tweede poging mislukte, stond er alleen 'applicatie draait al' als extra melding).

Dat script werd vanuit een geplande taak gestart zodra de gebruiker inlogde. Dus ook als er een RDP sessie werd gestart door iemand om de melding handmatig weg te klikken. Het script had ik zo dat het controleerde wat de hostnaam was van de RDP client. Alleen als dit onze monitoring server was, ging het verder, anders stopte het gelijk (aan het eind van het uitvoeren werd de verbinding ook verbroken). De monitoring server draaide Linux en via xvfb en xfreerdp werd er headless de RDP sessie gestart. Je zou wat vergelijkbaars kunnen doen, check de client hostnaam (te vinden in het register) en voer je script uit. Vervolgens heb je een Linux server, headless, die om 2 uur in de nacht via cron de RDP verbinding maakt en zo je Powershell script triggert.

[J2pc]

Ik kwam deze tegen
https://github.com/kost/rdpcmd

Een autoit script, wat via rdp een commando kan uitvoeren, wellicht kun je dit gebruiken om je powershell script te starten.

Is verder niet mijn project, dus ik zou t script iig even doorlezen op gekke dingen, en even overleggen met je it/sec afdelingen dat je dit nodig hebt en of je dit kunt/mag deployen.

[Dennism]

ktf schreef op dinsdag 30 december 2025 @ 16:26:


Dan moet er dus wel ergens een gebruiker zijn ingelogd, en dan kun je het dus niet op een bepaalde tijd schedulen. Het gebeurd regelmatig dat in die specifieke 'security context' een aantal dagen niemand inlogt op een van de servers in die context. Je kunt dan met de software die ik ken geen RDP sessie opstarten. Daarom zoek ik naar software waarmee dat dus wel kan.

Als dit enkel het issue is, en zoals je aangegeven hebt mag dit binnen jullie security policies (bij veel bedrijven mag dit namelijk niet!).

Waarom log je niet gewoon een user in via RDP, daarna disconnect je de sessie. Als je de instellingen daarvoor goed zet blijft vanaf dat moment die user permanent ingelogd (tot iemand hem uitlogt, of de server herstart) en die user kan dan gewoon powershell commando's op een schedule uitvoeren, die user zit dan ook in een gui enabled sessie (tenzij het een server core is, maar dat zal bij jou niet zo zijn als een gui verplicht is voor de applicatie).

Je moet dan enkel wel even goed documenteren dat dit zo werkt, zodat ook iedereen die op die machine moet inloggen hier vanaf weer en niet per ongeluk die user afmeld. En dat dus na onderhoud de user ook weer even ingelogd wordt.

[ Voor 3% gewijzigd door Dennism op 30-12-2025 21:40 ]

[rickh18]

Je kunt je sessie naar de console zetten en daarmee de sessie met gui actief houden.

https://stackoverflow.com...n-active-after-disconnect

Het is wel een uitdaging om dit stabiel aan de praat te houden. De gebruiker moet niet automatisch uitloggen of locken, bij een herstart is de sessie weer weg, resoluties blijven soms niet behouden.

[Liegebeest]

ktf schreef op dinsdag 30 december 2025 @ 14:16:
Er is een supported oplossing van de leverancier, maar die is te duur (lees: je kunt er een nieuwe auto voor kopen).

Je bedrijf moet eens de afweging maken welke kosten en risico’s ze op de hals halen met dit handmatige werk en de houtje-touwtje oplossing die jij nu aan het bakken bent.

Is er al een poging gedaan er echt een business case voor te schrijven?

[Hero of Time]

Dennism schreef op dinsdag 30 december 2025 @ 21:38:
Waarom log je niet gewoon een user in via RDP, daarna disconnect je de sessie. Als je de instellingen daarvoor goed zet blijft vanaf dat moment die user permanent ingelogd (tot iemand hem uitlogt, of de server herstart) en die user kan dan gewoon powershell commando's op een schedule uitvoeren, die user zit dan ook in een gui enabled sessie (tenzij het een server core is, maar dat zal bij jou niet zo zijn als een gui verplicht is voor de applicatie).

Uitvoeren van scripts op gezette tijden kan je ook zonder GUI doen, dat heet een geplande taak. De reden waarom TS juist een actieve sessie nodig heeft, die niet vergrendeld is, is vanwege dit:

Ik heb een Powershell script gemaakt wat precies doet wat ik wil, door toetsaanslagen te simuleren.

Als je een disconnected sessie hebt, kan je proberen te scripten wat je wilt, maar er zal geen enkele toetsaanslag gesimuleerd/uitgevoerd worden want volgens het systeem is er geen toetsenbord aanwezig. Er is geen interactieve sessie tenslotte.

Ik heb ook met Windows eens gepoogd om via een geplande taak een RDP sessie te starten op de achtergrond en daarin toetsen te simuleren. Werkte ook niet. Vandaar Linux met een virtuele framebuffer.

[The Eagle]

Als je Aveva aan kunt schaffen zijn die tientallen duizenden euros ook kinderspel voor de organisatie.
Een lek in dergelijke systemen dat exploited wordt is vele malen kostbaarder.

Maar ik vraag me af wat dat taakje moet doen

Zelf iets dergelijks wel eens via sc uitgevoerd, maar dat was wel afhankelijk van de user waaronder de software op de server draaide. Als dat system is wordt het al lastiger.

Maar je zou natuurlijk een scheduled task aan kunnen maken die naar een file zoekt op een bepaalde netwerk lokatie, en indien aanwezig jouw taak onder een bepaalde user uitvoert en die file weer weggooit als ie klaar is. Dat soort workarounds werken vrijwel altijd

[Dennism]

Hero of Time schreef op dinsdag 30 december 2025 @ 22:00:
[...]

Uitvoeren van scripts op gezette tijden kan je ook zonder GUI doen, dat heet een geplande taak. De reden waarom TS juist een actieve sessie nodig heeft, die niet vergrendeld is, is vanwege dit:

[...]

Als je een disconnected sessie hebt, kan je proberen te scripten wat je wilt, maar er zal geen enkele toetsaanslag gesimuleerd/uitgevoerd worden want volgens het systeem is er geen toetsenbord aanwezig. Er is geen interactieve sessie tenslotte.

Ik heb ook met Windows eens gepoogd om via een geplande taak een RDP sessie te starten op de achtergrond en daarin toetsen te simuleren. Werkte ook niet. Vandaar Linux met een virtuele framebuffer.

Hmm, misschien dat TS dan wat anders bedoeld dan ik, maar wij hebben juist in het verleden wel eens van dit soort 'hobby bob' oplossingen, juist waarbij commando's in een 3rd party Gui uitgevoerd werden op gezette tijden waarbij die applicaties in een lopen sessie moesten draaien. Maar disconnected was dan geen issue in dat geval. De vooraf ingegeven opdrachten werden gewoon uitgevoerd door de betreffende applicatie.

En dat was uiteraard juist wanneer zaken als scheduled tasks geen optie waren, anders gebruik je immers dat wel.

[ Voor 4% gewijzigd door Dennism op 30-12-2025 22:14 ]

[Hero of Time]

Dennism schreef op dinsdag 30 december 2025 @ 22:13:
[...]


Hmm, misschien dat TS dan wat anders bedoeld dan ik, maar wij hebben juist in het verleden wel eens van dit soort 'hobby bob' oplossingen, juist waarbij commando's in een 3rd party Gui uitgevoerd werden op gezette tijden waarbij die applicaties in een lopen sessie moesten draaien. Maar disconnected was dan geen issue in dat geval. De vooraf ingegeven opdrachten werden gewoon uitgevoerd door de betreffende applicatie.

En dat was uiteraard juist wanneer zaken als scheduled tasks geen optie waren, anders gebruik je immers dat wel.

Er is een verschil tussen een applicatie dat een grafische weergave nodig heeft en commando's uitvoert of API calls doet vs het simuleren van menselijke input. Dat het via geplande taak niet werkte zal dan eerder te maken hebben met het niet kunnen tekenen van het venster. Zie het verschil bij een geplande taak tussen 'altijd uitvoeren' en 'alleen als gebruiker is ingelogd'.

[Dennism]

Hero of Time schreef op dinsdag 30 december 2025 @ 22:25:
[...]

Er is een verschil tussen een applicatie dat een grafische weergave nodig heeft en commando's uitvoert of API calls doet vs het simuleren van menselijke input. Dat het via geplande taak niet werkte zal dan eerder te maken hebben met het niet kunnen tekenen van het venster. Zie het verschil bij een geplande taak tussen 'altijd uitvoeren' en 'alleen als gebruiker is ingelogd'.

Als dat het punt is, dan kan je ipv RDP VNC of iets dergelijks gebruiken. Wel nog meer hobby bob en een stuk minder veilig dan een disconnected RDP sessie natuurlijk. Hebben wij ook wel eens ingezet in combinatie met bijv autoit. Al ben ik er zelf niet direct fan van binnen server omgevingen, zeker niet in enterprise omgevingen.

[ Voor 10% gewijzigd door Dennism op 30-12-2025 22:43 ]

[Hero of Time]

Dennism schreef op dinsdag 30 december 2025 @ 22:42:
[...]

Als dat het punt is, dan kan je ipv RDP VNC of iets dergelijks gebruiken. Wel nog meer hobby bob en een stuk minder veilig dan een disconnected RDP sessie natuurlijk. Hebben wij ook wel eens ingezet in combinatie met bijv autoit. Al ben ik er zelf niet direct fan van binnen server omgevingen, zeker niet in enterprise omgevingen.

VNC is het ook niet echt als oplossing omdat die alleen de console toont en kan gebruiken. Je moet dan apart nog inloggen in Windows zelf. Terwijl met RDP een aparte sessie gestart kan worden en je op het hoofdscherm zelf of de console in je virtualisatiepakket niks ziet gebeuren. Het is minder makkelijk om een RDP sessie (extern) te beïnvloeden dan de console.

Heb wel van AutoIT gehoord, maar nooit gebruikt of gezien, dus kan er ook niks over zeggen hoe het verders z'n werk doet.