Feb 16, 2021, updated at 13:35:14 (UTC)

5185

Terminalserver - Scheduled Task "Bei Anmeldung"

Hi,
wie der Name der Frage schon sagt:

Es geht um Windows Terminalserver unter Win2016. RDP oder ICA, egal.

Ziel:
Es soll für jeden Benutzer bei Anmeldung oder Wiederaufnahme einer Sitzung ein Scheduled Task ausgeführt werden. Der Task muss unter der Anmeldung des sich gerade anmeldenden Benutzers ausgeführt werden. Und nur in dieser.

Ansatz:

Für den Terminalserver wird der GPO Loopback Modus "ersetzen" (oder "mischen") aktiviert.
Per GPO wird unter "Benutzerkonfiguration" ein Scheduled Task erzeugt. GPO wirkt für alle TS (durch Loopback für alle sich am TS anmeldenden Benutzer)

GPP-Aktion: "aktualisieren"
"Ausführen ... Benutzerkonto" --> %LogonDomain%\%LogonUser%.
2 Trigger

Bei Anmelden von %LogonDomain%\%LogonUser%
Bei Remoteverbindung ... von %LogonDomain%\%LogonUser%

Aktionen: Eine Batch starten.

Meldet sich der erste Benutzer an, dann wird der Task erstellt. Bei "Ausführen ... Benutzerkonto" steht das Konto dieses Benutzers drin. Bei den beiden Triggern auch. Die Aufgabe wird wie gewünscht für diesen Benutzer ausgeführt.
Meldet sich jetzt parallel ein weiterer Benutzer an, dann wird der Task geändert. Jetzt steht der 2. Benutzer unter "Ausführen ... Benutzerkonto" und bei den Triggern drin.

Folge: Trennt der 1. Benutzer seine Sitzung und verbindet sie wieder, dann wird der Task nicht für ihn ausgeführt.

Wird in der Sitzung des 1. Benutzers ein gpupdate ausgeführt, dann wird der Task wieder auf den 1. Benutzer eingestellt. Mit der Folge, das er nicht mehr für den 2. Benutzer läuft.

-------

Frage

-------

aktuelle Lösung

%LogonDomain%\%LogonUser%\Aufgabe XYZ

Please also mark the comments that contributed to the solution of the article

Content-Key: 652543

Url: https://administrator.de/contentid/652543

Printed on: April 26, 2024 at 17:04 o'clock

30 Comments

Latest comment

Hallo Emeriks,

klingt Kurios, aber ich kämpfe derzeit auch mit einem Kuriosum in den geplanten Tasks. ist mir so noch nicht aufgefallen, ergibt aber auch keinen Sinn. Ergo: Könnte Seitens MS tatsächlich so sein

Ich weiß jetzt nicht genau was das Skript macht und wieso es als geplanten Task laufen soll, aber wenn ich ein Skript bei der Anmeldung laufen lassen möchte, dann verteil ich es per GPO als Richtline, Windows Einstellung, Skripts, Anmelden. Die Option kommt für dich nicht in Frage?

Gruß
Doskias

Zitat von @Doskias:
Ich weiß jetzt nicht genau was das Skript macht und wieso es als geplanten Task laufen soll, aber wenn ich ein Skript bei der Anmeldung laufen lassen möchte, dann verteil ich es per GPO als Richtline, Windows Einstellung, Skripts, Anmelden. Die Option kommt für dich nicht in Frage?

Beachte 2. Trigger "Bei Remoteverbindung ...".
Der Task muss auch ausgeführt werden, wenn der Benutzer eine getrennte Sitzung wieder verbindet.
Loginscripte laufen nur bei Anmeldung.
Registry-Schlüssen "Run" wird auch nur bei Anmeldung ausgeführt.
Startmenü "Autostart" auch nur bei Anmeldung.

Zitat von @emeriks:
Beachte Trigger "Bei Remoteverbindung ...".

Nicht beachtet, ok

Andere Frage: Spricht was dagegen den Task als "authentifizierter Benutzer" bei der Anmeldung auszuführen anstatt als explizitem Benutzer? Oder meinst du das mit "jeder" Benutzer?

Zitat von @Doskias:
Andere Frage: Spricht was dagegen den Task als "authentifizierter Benutzer" bei der Anmeldung auszuführen

Dass das so nicht geht.

Oder meinst du das mit "jeder" Benutzer?

"Jeder Benutzer" ist eine Option welche man in den Triggern "Bei Anmeldung" und "Bei Remoteverbindung ..." auswählen kann.

Zitat von @emeriks:

Zitat von @Doskias:
Andere Frage: Spricht was dagegen den Task als "authentifizierter Benutzer" bei der Anmeldung auszuführen

Dass das so nicht geht.

Oder meinst du das mit "jeder" Benutzer?

"Jeder Benutzer" ist eine Option welche man in den Triggern "Bei Anmeldung" und "Bei Remoteverbindung ..." auswählen kann.

Fast: Im Trigger die Einstellung auf "jeder Benutzer lassen" und in den Sicherheitsoptionen "authentifizierter Benutzer" wählen oder führt das dann zu dem Problem, dass es bei der Anmeldung von User B auch für User A ausgeführt wird?

@Doskias, nicht für ungut bitte. Aber weißt Du tatsächlich, was ich meine?
Mit "Sicherheitsoptionen" meinst Du sicherlich die Sicherheitsfilterung? Wenn ja: Diese steht bei mir auf "Authentifizierte Benutzer". Das hat aber nichts mit dem Konto zu tun, unter welchem der Task dann ausgeführt wird. Das Eine hat mit dem Anderen nichts zu tun. Null.

Ich verusche zu verstehen was du meinst, damit ich das Verhalten bei mir replizieren kann. Und ich meine auf dem Reiter "allgemein" im Bereich "Sicherheitsoptionen". Dort wo steht "Beim Ausführen der Aufgabe folgendes Benutzerkonto verwenden." Ich habe dich so verstanden, dass du dort den jeweiligen Benutzer drin stehen hast und so für jeden Benutzer ein neue Aufgabe erstellt wird.

ich meine nicht die Sicherungsfilter in der GPO. Ich meine die Zeile

"Ausführen ... Benutzerkonto" --> %LogonDomain%\%LogonUser%.

Ich denke er @Doskias meint es so

Gruß SK

Hi,

wie wäre denn folgendes?

Du legst das Script als Login_Script an und lässt es (bei VBScript) in einer Do...Loop-Schleife dauernd laufen.
Im Script fragst Du z.B. folgendes dann ab:

query session %sessionname%

und prüfst auf Aktiv oder nicht.
Ein zeitlicher Versatz von 2 Sekunden verhindert einen permanenten Dauerlauf.

Ich lasse viele meiner Scripts auf diesem Wege Verzeichnisse und Systeme "monitoren".

Gruß
bdmvg

Ausführen als Gruppe? Habt Ihr Euch jemals schon irgendwo als Gruppe anmelden können?
Das ist bloß ein Bug dieses Dialogs, dass man da auch Gruppen auswählen kann.

Zitat von @emeriks:

Ausführen als Gruppe? Habt Ihr Euch jemals schon irgendwo als Gruppe anmelden können?

Ja, habe ich hier schon mal mit einem Task gemacht. Der Task wird dann aber mit dem jeweiligen Anmelde-User ausgeführt sofern er Mitglied der Gruppe ist.

Zitat von @beidermachtvongreyscull:
Du legst das Script als Login_Script an und lässt es (bei VBScript) in einer Do...Loop-Schleife dauernd laufen.
Im Script fragst Du z.B. folgendes dann ab:

query session %sessionname%

und prüfst auf Aktiv oder nicht.
Ein zeitlicher Versatz von 2 Sekunden verhindert einen permanenten Dauerlauf.

Mit welchem Ziel / Effekt?

Zitat von @147669:
Ja, habe ich hier schon mal mit einem Task gemacht. Der Task wird dann aber mit dem jeweiligen Anmelde-User ausgeführt sofern er Mitglied der Gruppe ist.

Sorry, aber dass ist Unsinn.
Man kann keinen Task erstellen und dabei im "Ausführen mit.." eine Gruppe angeben. Wenn man das manuell machen will, dann kommt eine Fehlermeldung beim Speichern des Task (siehe Screenshot). Wenn man das per GPO macht, dann nimmt er das in der GPO zwar noch ab, aber er erstellt den Task dann nicht auf dem Client.

Zitat von @emeriks:

Zitat von @147669:
Ja, habe ich hier schon mal mit einem Task gemacht. Der Task wird dann aber mit dem jeweiligen Anmelde-User ausgeführt sofern er Mitglied der Gruppe ist.

Doch klappt hier sowohl als GPO angelegt aber auch testweise mal lokal auf einer Maschine angelegt! Und Task läuft auch im Test mit dem User der Mitglied der Gruppe ist ... Kann ich gerne ein Demonstrations-Video liefern ...

Als Permanentmonitor für folgende Events

Nutzer meldet sich an --> Script startet und läuft im Hintergrund
Nutzer reconnect mit vorhandener Session --> gestartetes Script wird getriggert

Bin draußen!

Zitat von @beidermachtvongreyscull:
Als Permanentmonitor für folgende Events

Nutzer meldet sich an --> Script startet und läuft im Hintergrund
Nutzer reconnect mit vorhandener Session --> gestartetes Script wird getriggert

Ach so meinst Du das.
OK, sowas haben wir hier quasi schon im Einsatz. Das habe ich mal als Dienst mit .Net programmiert. Das funktioniert soweit auch, nur dass das Teil öfters mal viel CPU in Anspruch nimmt. Die Kollegen wollen das deshalb mit Bordmitteln erschlagen. Auch in der Hoffnung, damit ein paar Timing-Probleme zu umgehen. z.B. dass die Benutzerumgebung bei Anmeldung ne Weile braucht, bis sie vollständig initialisiert ist. Umgebungsvariablen und Drucker usw. Also die Hoffnung, dass diese Task immer erst gestartet werden, wenn die Benutzerumgebung voll initialisiert ist.

Zitat von @147669:
Doch klappt hier sowohl als GPO angelegt aber auch testweise mal lokal auf einer Maschine angelegt! Und Task läuft auch im Test mit dem User der Mitglied der Gruppe ist ... Kann ich gerne ein Demonstrations-Video liefern ...

Ich kann das hier nicht reproduzieren. Der Task wird nicht erstellt. Weder manuell noch über die GPO. Ich habe es explizit ausprobiert.

Zitat von @147669:
Kann ich gerne ein Demonstrations-Video liefern ...

Sehr gerne!

Zitat von @emeriks:

Zitat von @147669:
Kann ich gerne ein Demonstrations-Video liefern ...

Sehr gerne!

Bitte sehr:
https://we.tl/t-pAy5zxaVui

Ach so fast vergessen, genutztes OS war ein Server 2012 R2. Klappt aber testweise auch auf einem aktuellen 2019er.

Zitat von @147669:
Bitte sehr:
https://we.tl/t-pAy5zxaVui

Danke. Aber das habe ich ja bereits geschrieben. Man kann das in einer GPO so anlegen. Aber der Task wird dann nicht auf dem Client erstellt.
Es sei denn, Du könntest das bitte auch noch liefern. Das wäre toll.

Kann ich morgen nachliefern, muss jetzt leider weg.

Zitat von @emeriks:

Es geht um Windows Terminalserver unter Win2016. RDP oder ICA, egal.

Ziel:
Es soll für jeden Benutzer bei Anmeldung oder Wiederaufnahme einer Sitzung ein Scheduled Task ausgeführt werden. Der Task muss unter der Anmeldung des sich gerade anmeldenden Benutzers ausgeführt werden. Und nur in dieser.

Welches Problem soll denn gelöst werden?
Evtl. bietet Citrix WEM hier schon die benötigten Aktionen.

Zitat von @147669:
Ich denke er @Doskias meint es so
Gruß SK

Ja danke. Genau das meinte ich.

Zitat von @emeriks:

Zitat von @147669:
Ja, habe ich hier schon mal mit einem Task gemacht. Der Task wird dann aber mit dem jeweiligen Anmelde-User ausgeführt sofern er Mitglied der Gruppe ist.

Schau dir mal deinen Screenshoot wo es nicht funktioniert und den von Schmitzkatz an. Konfigurieren für ist hier anders. Das kann durchaus (auch wenn es nicht logisch ist) Unterschiede bewirken. Genau da habe ich nämlich zum Beispiel das Problem. Ich hab auch eine GPO die einen eplanten Task verteilt. Allerdings habe ich unterschiedliche Optionen bei Konfigurieren für. Diese sind von Rechner zu Rechner (bei gleichem Image und gleichen GPOs) unterschiedliche. MAnchmal hab ich nur XP zur erfügung, manchmal nur Win 10 und manchmal beides. Der bzw. die DCs haben dann noch andere Optionen. Und als ob das nicht genug wäre variieren die Optionen auch abhängig ob ich mich lokal als Dom-Admin anmelde oder Remote die Aufgabenplanung als Dom-Admin öffne. Und als ob das nicht genug wäre, wechseln die Optionen auch mal von einem Tag zum anderen. Der Effekt: Meine durch GPO verteilte Aufgabe wird erfolgreich verteilt und erfolgreich (als System) ausgeführt, wenn sich ein User anmeldet, während ich die Option "Konfigurieren für" neuer als XP habe. Händisch kann ich sie jederzeit starten, bearbeiten nur dann, wenn zufällig die Option "Konfigurieren für" neuer ist als XP. Wenn ich also die GPO auf dem DC für Windows 10 konfiguriere, dann wird sie auf alle Rechner verteilt. Wenn der Rechner dann aber (und das ist der Punkt den ich nicht verstehe) auf einmal nur die Option "konfigurieren für XP" zur Verfügung hat, dann wird der geplante Task nicht richtig ausgeführt. Am nächsten Tag ist dann wieder alles Verfügbar und der Task läuft und 2 Tage später dann wieder nicht, weil nur noch Konfigurieren für XP zur Verfügung steht. Mir ist das in meinem Problem hier gestern aufgefallen. Ich weiß nicht ob da wirklich ein Zusammenhang besteht aber ich finde es schon auffällig, dass wir beide merkwürdiges Verhalten bei geplanten Tasks haben, die via GPO verteilt wurden. Ich bin noch nicht weiter wieso ich verschiedene Optionen an verschiedenen Rechner habe, aber vielleicht hilft dir der Hinweis ja weiter.

Moin Emeriks.

Ich sehe auch keine andere Lösung als %username% in den Tasknamen mit aufzunehmen (oder, falls mehrere Domänen, wie Du es schon geschrieben hast, auch die Logondomain).

Der Nachteil dieser Lösung ist jedoch, dass da jetzt zig Tasks erstellt werden.

Wo ist das Problem dabei? Fressen kein Brot.

Ich möchte anmerken, dass du noch den Trigger "on connection to user session" hinzufügen musst, denn "at logon" zieht nur "at logon" und nicht bei Wiederverbindung einer getrennten Sitzung.

Hi DWW,
Danke für Deinen Input.

Ich möchte anmerken, dass du noch den Trigger "on connection to user session" hinzufügen musst, denn "at logon" zieht nur "at logon" und nicht bei Wiederverbindung einer getrennten Sitzung.

Ja, aber das ist schon drin. ("Bei Remoteverbindung ... von")
Das funktioniert auch.

Wo ist das Problem dabei? Fressen kein Brot.

Nur Kosmetik.
Auch, dass die Task gelöschter Benutzer dann einfach so erhalten bleiben. Aber das kann ich durch einen Aufräum-Script erschlagen.

Zitat von @mbehrens:
Welches Problem soll denn gelöst werden?

Es gibt Aktionen, die müssen bei der Wiederverbindung ausgeführt werden. z.B. müssen Drucker Client-abhängig verbunden werden. Wir haben Anwendungen, die haben selbst eine Client-abhängige Druckeransteuerung integriert und bekommen es nicht mit, wenn sich während der Runtime der Client ändert.
Mit GPO/GPP bekommt man das nicht adäquat erschlagen. Zu aufwändig (tausende Clients) und zu langsam.

Evtl. bietet Citrix WEM hier schon die benötigten Aktionen.

Soweit ich weiß wird der WEM bei uns nicht genutzt. Warum, weiß ich nicht.

Zitat von @Doskias:
Schau dir mal deinen Screenshoot wo es nicht funktioniert und den von Schmitzkatz an.

Danke für den Hinweis. Aber das hatte ich schon wahrgenommen.
Und es ist auch logisch, dass die GPO-Bearbeitung da unterschiedliche Anzeigen bringt, wenn man diese auf Windows Versionen verschiedenen Alters startet. Windows XP kennt kein Windows 7 und dieses wiederum kein Windows 10. Die Anzeige einer GPO in der Bearbeitung ist nur eine Interpretation der zur GPO gehörigen Dateien. Das gleiche Problem hat man ja oft auch bei anderen Programmen, wenn man versucht, in älteren Versionen Dokumente zu öffnen, welche mit neueren Versionen erstellt wurden. Die GPO-Dateien sind da nichts weiter als Dokumente, welche interpretiert werden müssen. Beim Design ebenso wie bei der Anwendung.

Zitat von @emeriks:
Und es ist auch logisch, dass die GPO-Bearbeitung da unterschiedliche Anzeigen bringt, wenn man diese auf Windows Versionen verschiedenen Alters startet. Windows XP kennt kein Windows 7 und dieses wiederum kein Windows 10.

Das ist schon klar. Aber wieso zeigen mir dann identischen Windows 10 Rechner (alle vom gleichen Image und in identischen OUs mit gleichen GPOs) manchmal die Option Windows 10, manchmal Windows XP, Manchmal Vista und manchmal alle drei an. Das ich auf dem DC in der Konfiguration der GPO verschiedene Werte zur Auswahl habe ist ja klar, aber auf dem Clients sollte es meiner Meinung nach identisch sein. Mir ist auch keine GPO bekannt, die die Auswahlfelder "Konfigurieren als" verändern.

Zitat von @Doskias:

Das ist in der Tat seltsam.

So. Die Rätsels Lösung für die unterschiedlichen "Konfigurieren für" Einstellungen, habe ich jetzt gefunden und Sie sind definitiv reproduzierbar. In bislang 10 von 10 Rechner war das Verhalten reproduzierbar. Ursache sind (offenbar, auch wenn da erstmal kein Zusammenhang besteht) MS-Edge Updates.

Immer wenn ein Rechner via WSUS eine neue Edge Update bekommt, dann ist "nur" noch eine der Optionen verfügbar. Dann wird der Rechner neu gestartet und es ist wieder alles verfügbar, dann gebe ich das nächste Update frei und habe kurze Zeit später bis zum Neustart wieder nur eine Option. Keine Ahnung wieso der Edge an der Stelle eine Auswirkung darauf hat, aber wie gesagt: gezielt reproduzierbar und erklärt auch, wieso es an einem Tag anders ist als am nächsten.

German Question Windows Server Microsoft