3
Designfehler im Autoupdate vom Remoteapp-Updatetask
Und schon wieder ein schöner Bug, der zeigt, dass MS seine Software mangelhaft testet...
Wer RemoteApps administriert, wird vermutlich die Möglichkeit kennen, diese zu deployen über eine GPO ("specify default connection url").
Das funktioniert auch sehr schön und die veröffentlichten Anwendungen erscheinen bei den Nutzern im Startmenü.
Ändert man am Server jedoch etwas, fügt zum Beispiel eine weitere RemoteApp hinzu oder verweigert den Zugriff auf eine andere, so sollte dies per geplanter Aufgabe auch auf den Clients gesynct werden - hier steckt ein Bug (getestet auf Windows 10)
Bei Interesse einfach prüfen: der Pfad im Taskplaner ist Taskplanerbibliothek - Microsoft - Windows - RemoteApp and Desktop connections update
Darunter sind für jeden Nutzer des Rechners Ordner mit Tasks. Es geht um den Task "Update connections". Dieser hat als Trigger unschlauerweise von Microsoft "täglich um Mitternacht" eingesetzt bekommen
Wer zufällig um Mitternacht schon Feierabend haben sollte, bekommt keine Updates!
Doch "Moment!" werden einige rufen, der Task steht ja auf der Einstellungsoption "run as soon as possible after a scheduled start is missed" - funktioniert das aber? Nein. Es funktioniert schlicht nicht, da die launch condition "run only when the user is logged on" gesetzt ist - das lässt sich nicht kombinieren, da beim Start des Task schedulers (wo der Dienst schaut, welche Tasks nachgeholt werden müssen) niemand angemeldet ist. Setze ich von Hand den Trigger auf "at logon of testuser", dann klappt es natürlich...
Also: wer gerne hätte, dass User eine stets aktuelle Liste von RemoteApps haben oder gar darauf angewiesen ist, muss von Hand nachbessern und diesen Trigger ändern! Dies geht auch per GPO, ich werde eine Lösung in Kürze nachpflegen.
Völlig veraltet!
Wer RemoteApps administriert, wird vermutlich die Möglichkeit kennen, diese zu deployen über eine GPO ("specify default connection url").
Das funktioniert auch sehr schön und die veröffentlichten Anwendungen erscheinen bei den Nutzern im Startmenü.
Ändert man am Server jedoch etwas, fügt zum Beispiel eine weitere RemoteApp hinzu oder verweigert den Zugriff auf eine andere, so sollte dies per geplanter Aufgabe auch auf den Clients gesynct werden - hier steckt ein Bug (getestet auf Windows 10)
Bei Interesse einfach prüfen: der Pfad im Taskplaner ist Taskplanerbibliothek - Microsoft - Windows - RemoteApp and Desktop connections update
Darunter sind für jeden Nutzer des Rechners Ordner mit Tasks. Es geht um den Task "Update connections". Dieser hat als Trigger unschlauerweise von Microsoft "täglich um Mitternacht" eingesetzt bekommen
Wer zufällig um Mitternacht schon Feierabend haben sollte, bekommt keine Updates!Doch "Moment!" werden einige rufen, der Task steht ja auf der Einstellungsoption "run as soon as possible after a scheduled start is missed" - funktioniert das aber? Nein. Es funktioniert schlicht nicht, da die launch condition "run only when the user is logged on" gesetzt ist - das lässt sich nicht kombinieren, da beim Start des Task schedulers (wo der Dienst schaut, welche Tasks nachgeholt werden müssen) niemand angemeldet ist. Setze ich von Hand den Trigger auf "at logon of testuser", dann klappt es natürlich...
Also: wer gerne hätte, dass User eine stets aktuelle Liste von RemoteApps haben oder gar darauf angewiesen ist, muss von Hand nachbessern und diesen Trigger ändern! Dies geht auch per GPO, ich werde eine Lösung in Kürze nachpflegen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 306528
Url: https://administrator.de/contentid/306528
Ausgedruckt am: 18.11.2024 um 23:11 Uhr
3 Kommentare
Neuester Kommentar
Man erstelle also einen geplanten Task per Group Policy preference item (in der Benutzerabteilung einer GPO)
Name: \Microsoft\Windows\RemoteApp and Desktop Connections Update\Update connections
Ausführendes Konto: %LogonDomain%\%LogonUser%
Trigger: bei Anmeldung eines beliebigen Benutzers
Aktion: %SYSTEMROOT%\System32\RUNDLL32 mit dem Parameter tsworkspace,TaskUpdateWorkspaces2
und alles wird gut. Aber eins bleibt seltsam: der Task braucht zum Teil ewig (bis 30 min) um fertig zu werden, während ein manuelles Update über die GUI weniger als 3 Sekunden braucht. Qualitätssoftware durch und durch. Aber immerhin funktioniert es dann überhaupt einmal.
Name: \Microsoft\Windows\RemoteApp and Desktop Connections Update\Update connections
Ausführendes Konto: %LogonDomain%\%LogonUser%
Trigger: bei Anmeldung eines beliebigen Benutzers
Aktion: %SYSTEMROOT%\System32\RUNDLL32 mit dem Parameter tsworkspace,TaskUpdateWorkspaces2
und alles wird gut. Aber eins bleibt seltsam: der Task braucht zum Teil ewig (bis 30 min) um fertig zu werden, während ein manuelles Update über die GUI weniger als 3 Sekunden braucht. Qualitätssoftware durch und durch. Aber immerhin funktioniert es dann überhaupt einmal.
3
Guten Abend DWW,
vielen Dank für den Hinweis.
Unter Windows 7, Enterprise läuft die Task "nur" 20 Minuten. Wobei der manuelle Aufruf über die Eingabeaufforderung auch seine 5 Minuten hat, bis die Anzeige in der Systemsteuerung aktualisiert wurde.
Gruß,
Dani
vielen Dank für den Hinweis.
Unter Windows 7, Enterprise läuft die Task "nur" 20 Minuten. Wobei der manuelle Aufruf über die Eingabeaufforderung auch seine 5 Minuten hat, bis die Anzeige in der Systemsteuerung aktualisiert wurde.
Gruß,
Dani
Hi.
Ich vergleiche nicht mit der Kommandozeile, sondern mit der GUI. Da sind es wenige Sekunden
Ich vergleiche nicht mit der Kommandozeile, sondern mit der GUI. Da sind es wenige Sekunden
