30
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:
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.
Das funktioniert im Prinzip. Aber ...
Das Ändern der Trigger auf "Jeder Benutzer" macht keinen Sinn, weil der Task dann in der Sitzung des 1. Benutzers ausgeführt wird (wenn dieser gerade bei "Ausführen ... Benutzerkonto" drin steht), auch wenn sich ein anderer Benutzer parallel anmeldet. Das ist nicht gewünscht! (s.o.)
-------
Frage
-------
Stimmt meine Beobachtung so? Könnt Ihr das so bestätigen oder mache ich hier einen (Denk-)Fehler?
aktuelle Lösung
Meine aktuelle Lösung sieht so aus, dass ich auch im Namen des Task die Variablen %LogonDomain% und %LogonUser% verwende. (Es melden sich Benutzer mehrerer Domänen an). Das bringt das gewünschte Verhalten, weil hierbei je Benutzer ein eigener Task erstellt wird, wo das jeweilige Benutzerkonto im "Ausführen ... Benutzerkonto" und bei den Triggern drin steht.
Der Nachteil dieser Lösung ist jedoch, dass da jetzt zig Tasks erstellt werden. Wir haben Server, da melden sich parallel bis zu 60 oder mehr Benutzer an. Bzw. weil die Benutzer durch Lastverteilung nicht immer auf dem selben TS landen, sammeln sich im Laufe der Zeit die Task, sodass das u.U. mehrere hundert werden können.
Man kann das noch etwas organisieren, indem man die Task in Ordern erstellen lässt. Das kann man z.B. so erreichen:
%LogonDomain%\%LogonUser%\Aufgabe XYZE.
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: 652543
Url: https://administrator.de/forum/terminalserver-scheduled-task-bei-anmeldung-652543.html
Ausgedruckt am: 31.03.2025 um 14:03 Uhr
30 Kommentare
Neuester Kommentar
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
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 ...".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?
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.
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?
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.Andere Frage: Spricht was dagegen den Task als "authentifizierter Benutzer" bei der Anmeldung auszuführen
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.Andere Frage: Spricht was dagegen den Task als "authentifizierter Benutzer" bei der Anmeldung auszuführen
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.
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.
1
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
ich meine nicht die Sicherungsfilter in der GPO. Ich meine die Zeile
"Ausführen ... Benutzerkonto" --> %LogonDomain%\%LogonUser%.
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:
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
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.
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.Ausführen als Gruppe? Habt Ihr Euch jemals schon irgendwo als Gruppe anmelden können?
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:
und prüfst auf Aktiv oder nicht.
Ein zeitlicher Versatz von 2 Sekunden verhindert einen permanenten Dauerlauf.
Mit welchem Ziel / Effekt?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.
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.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.
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:
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.
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 ...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.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.
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.
Als Permanentmonitor für folgende Events
Bin draußen!
- 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
Ach so meinst Du das.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
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.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 ...
Zitat von @147669:
Kann ich gerne ein Demonstrations-Video liefern ...
Sehr gerne!Kann ich gerne ein Demonstrations-Video liefern ...
Zitat von @emeriks:
Bitte sehr:Zitat von @147669:
Kann ich gerne ein Demonstrations-Video liefern ...
Sehr gerne!Kann ich gerne ein Demonstrations-Video liefern ...
https://we.tl/t-pAy5zxaVui
Ach so fast vergessen, genutztes OS war ein Server 2012 R2. Klappt aber testweise auch auf einem aktuellen 2019er.
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.
Es sei denn, Du könntest das bitte auch noch liefern. Das wäre toll.
Kann ich morgen nachliefern, muss jetzt leider weg.
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.
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.
Ja danke. Genau das meinte ich.
Zitat von @emeriks:
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.
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.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.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.
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.
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).
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.
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.
Das funktioniert auch.
Auch, dass die Task gelöschter Benutzer dann einfach so erhalten bleiben. Aber das kann ich durch einen Aufräum-Script erschlagen.
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.
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.
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.Schau dir mal deinen Screenshoot wo es nicht funktioniert und den von Schmitzkatz an.
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.
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.
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.
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.
