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!