BOfH_666

Dafür gibt es die Kommandozeilen-Option "-WindowStyle Hidden". Diese muss aber als erstes (vor allen anderen ...) angegeben werden, um korrekt zu funktionieren. ☝

Für User-Pakete braucht er keine Adminrechte. Ein Chrome oder Teams oder sowas, installierst Du Dir im Standard auch in Dein eigene s Profil, ohne dass Du dafür Adminrechte hast. 🤷🏼‍♂️ Entweder Du benutzt einen Admin-Account, der das Paket für ALLE Benutzer entfernt, oder jeder einzelne Benutzer entfernt sein eigenes Paket. Das Letztere ist ja offenbar das was Du machen möchtest, wenn Du das Skript bei Anmeldung der Benutzer ausführen möchtest ...

Du führst das Skript im Kontext "System" aus. Ich hatte es in meiner ersten Antwort bereits empfohlen, das Skript mal im Kontext des Benutzers zu starten. Hast Du das schon mal probiert? Wenn es ein Paket ist, welches P R O U S E R installiert ist, findest Du für den User "System" natürlich kein Paket. 🤷🏼‍♂️

Geht es dabei um ein "User-Package"? Dann sollte der jeweilige Benutzer als ausführendes Konto benutzt werden. Hast Du schon mal den Parameter "-AllUsers" probiert? Das sollte ein Package für alle de-installieren. Dann brauchst Du es pro PC auch nur einmal ausführen und nicht für jeden Benutzer einzeln.

Mein Kunde benutzt seit ca. 4,5 Jahren 64-Bit Office und es gibt keine Probleme. Also jedenfalls keine, die durch 64-Bit verursacht werden. 🤷🏼‍♂️

Wenn ich mich nicht irre, funktioniert das Update auf die Version 22H2 mittels des sogenannten "Enablement-Package" nur, wenn vorher bereits alle vorangegangenen kumulativen Updates installiert wurden. Dann sind alle Funktionen quasi schon an Bord und müssen nur noch aktiviert werden. Wenn das nicht der Fall ist, dann ist das Update-Paket eben wie früher eine Update-Installation. Aber 134 GB erscheinen mir trotzdem zu griß. Bist Du sicher, dass Du da keinen Fehler irgendwo drin hast?

Wenn Du die Befehle interaktiv in der Konsole eingibst, hat das nix mit der ExecutionPolicy zu tun. Die greift nur bei Skripten.

Es gibt also keine Fehlermeldung dabei? Dann häng doch mal ein "-Verbose" an. Hast Du probiert, den Befehl in einer Konsole mit Admin-Rechten zu starten?

Hast Du denn die Fehlermeldung mal gelesen und den darin enthaltenen Hinweis befolgt?

Auf der anderen Seite, klingt das wie eine Investition in die Zukunft und ein Erweitern des eigenen Portfolios, was sich vielleicht noch auszahlen könnte. ¯\_(ツ)_/¯

Hat er neben seiner PIN noch ein weiteres Merkmal für Windows Hello eingerichtet? Fingerabdruck oder Gesicht oder so? Dann das auch einmal entfernen, bitte.

OK, ich hab nur 1/2 soviel Erfahrung damit, aber meine waren im Allgemeinen positiv. ¯\_(ツ)_/¯

Da darf man aber auch anderer Meinung sein, oder?

<SCNR> Laufen die bei Euch mit Strom? </SCNR>

Nur wegen der Vollständigkeit: Welche Leistung hast Du denn gebucht?

Da hab ich offenbar Glück. Der letzte 2012r2 wird nächste Woche abgelöst und dann ist das Älteste, was wir haben, Server 2019.

Richtig. Das Ergebnis wäre aber das gleiche. Wenn der Client noch nicht installiert ist, schlägt der Task eben fehl. ¯\_(ツ)_/¯

Ich würde mir das Leben leichter machen und einfach die "update_task.exe" als Task ausführen - nicht das Script. ¯\_(ツ)_/¯ Welcher User ist das? Üblicherweise nimmt man hier den lokalen Built-In User "SYSTEM" Hast Du denn dafür gesorgt, dass das Batchfile auf dem Computer auf existiert? Erstmal schon - wenn alle Voraussetzungen erfüllt sind. Der Pfad ist egal ... Du hast ihn ja hoffentlich korrekt angegeben, oder? Wo liegt die Datei denn?

Was ist ... ? Wenn Du da den ComputerNamen des lokalen Rechner einsetzen möchtest, kannst Du "$ENV:COMPUTERNAME" verwenden.

Wenn da sowieso nur Web-Zugriff erlaubt sein soll, wäre eventuell ein Linux auch eine Option. Unter Linux lassen sich Benutzer meist sicherer einschränken als unter Windows und die Zahl derjenigen, die sich mit Linux soweit auskennen, dass sie den konfigurierten Proxy umgehen können, ist vermutlich geringer als unter Windows. ¯\_(ツ)_/¯

Ach, so rum. Da war ich auf der falschen Spur. ¯\_(ツ)_/¯

Ich habe Deine Frage zwar nicht wirklich verstanden, aber ich würde sagen "Auf jeden Fall". ¯\_(ツ)_/¯ Sag doch noch mal genau, was Du im AD suchst? Wenn es um einen erzwungen Passwort-Wechsel geht, brauchst Du ja nur die Property "ChangePasswordAtLogon" auf "$true" setzen und die Andwendenden müssen bei der nächsten Anmeldung ihr Passwort wechseln.

Amen. Ich hab das mal bei einem Kunden in Brasilien gesehen. Da wurde an Ort und Stelle jedes einzelne Kabel für genau die Stelle konfektioniert/gecrimpt, an der es benutzt wurde. Und dann haben sie diese "Vogel-Ringe" - farbcodiert für die entsprechende Funktion und nummeriert - angebracht. Das sah richtig gut aus ... weil auch von keinem Kabel eine Überlänge irgendwo versteckt werden musste.