daabm

Dann würde ich mal einen Blick ins GroupPolicy Eventlog empfehlen.

Kein Treiber für nen verschlüsselten USB-Key...?

Portfast ist aktiviert?

Ich lese die erste Zeile und bin schon fast irritiert - warum wartest Du 4 Minuten? Und Du weißt, daß MS ein Logon Script Delay eingeführt hat? https://gpsearch.azurewebsites.net/#10686

Was hindert Dich daran, das ganz nativ mit Group Policy Preferences "Registry" zu machen? Item Level Targeting auf den Wert, wo der neue Name drinsteht, und dann halt schreiben... Geht da nämlich auch in HKLM.

Man kann den Krempel auch hinterher bereinigen, wenn man denn unbedingt will - ich wüßte nur nicht, wozu. Wen stört's?

Nachdenken - wie wolltest Du die eingeben?

Eine echte Übersicht gibt es nicht - nur die unterschiedlichen Downloads, die meist ein Excel-Referenzsheet enthalten. Ich halte es wie Nils - nimm die neuesten, speicher die vorherigen ab. Wenn es Fehler geben sollte, kannst dann leicht zurück (und Fehler gab es in den letzten Jahren viele...)

Ich möchte diesen Absatz betonen: Before we set the new password locally, we ensure we have a valid secure channel to the DC. If the client was never able to connect to the DC (where never is anything prior the time of the attempt – time to refresh the secure channel), then we will not change the password locally. Von alleine wird ein Client, der "offline" ist, also niemals seinen Secure Channel verlieren, weil er sein Kennwort schlicht NICHT ändert, wenn er keinen DC erreichen kann. Das wird oft falsch verstanden

Jein. Wenn Du das volle Programm buchst, gibt es schon einen Mehrwert. O365, was hat OO da zu bieten? Aber brauchst nicht wirklich antworten, das ist eine Einzelfall- und Grundsatzfrage für jedes Unternehmen.

You get what you pay for... You get what you pay for...

Prima. Hilft immer, wenn man bei Powershell alle Objekte auch Objekte sein läßt und halt mit denen arbeitet. Du kannst denen ja sogar per Add-Member nachträglich Properties anklatschen, wenn das später irgendwo hilfreich ist...

Jepp. Collect once, then process...

Ich verweise mal auf ein unbekanntes Blog zum Thema "WMI-Filter auf nicht vorhanden": http://evilgpo.blogspot.com/2012/05/inverting-wmi-filters.html Loopback brauchts auch nicht - zum Screensaver hab ich damals einen der ersten Artikel überhaupt geschrieben: http://evilgpo.blogspot.com/2012/03/how-to-save-my-screen.html Und seit MS16-072 geht das sogar noch einfacher, indem einfach die entsprechenden Computer ein "Deny Read" für die GPO bekommen.

Never ending story - das elevated Token... Da hat entweder MS was falsch erklärt - oder (meine Vermutung) die meisten Admins verstehen nicht, was ein Token ist und warum es restricted sein könnte

Und man kann auch spaßeshalber mal die 4 "Policies"-Keys in der Registry (je 2 unter HKCU und HKLM) einfach löschen. Alles, was aktuell noch aus Domain-GPOs kommt, kommt eh wieder. Und jedweder Experimentier-Müll verschwindet

Wenn Du den Power Button drücken mußt, dann ist es NICHT nur der Bildschirm, dann ist der PC im Energiesparmodus. Fakt.

Auf dem PDC-Emulator einen RSoP erstellen, dann siehst Du es... Und NUR da.

Firefox soll doch inzwischen GPO-fähig sein? Aber laut https://github.com/mozilla/policy-templates/blob/master/README.md gehört der Download-Ordner NICHT dazu... Und wenn Du schon per Skript im prefs.js arbeitest, sollte es recht einfach sein, vorher noch die profiles.ini auszulesen. Da steht der Pfad zum Defaultprofil drin.

Task mit Trigger auf ein Ereignis in einem Eventlog: Hier kannst das XML aus dem Link im Prinzip direkt reinkopieren. Ja, wenn man das noch nie gesehen hat, kommt man nicht so schnell drauf Aber ein IT-ler mit grundlegenden Kenntnissen bekommt das schon hin. Und wie Norbert schon geschrieben hat: Das Task-XML exportierst Du von dem Referenzrechner, wo Du den Task passend eingerichtet hast. Per Startup-Skript erstellst Du daraus mit schtasks /create /tn "Mein neuer Task" /xml <Pfad zum XML> /ru SYSTEM den Task auf den Zielrechnern. Kann sein, daß ein Parameter fehlt, aber so prinzipiell...

Hast Du einen Central Store? Dann mußt Du den halt mal aktualisieren...

Unser Office-PFE hat bereits bestätigt, daß die OnPremise-Versionen auf dem Client "out of scope" sind. Feature Updates z.B. werden sie über die Laufzeit nicht erhalten.

Naja, dann grenze den Zeitpunkt ein bis zu dem es noch ging. Und dann finde heraus, wer genau was genau geändert hat

Nirgends - das lernt man, wenn man seit Windows 8 mal ein Profil durch Löschen des Ordners versuchte zu entsorgen - und danach alles mit Apps nicht mehr wirklich funktionierte

Sodele, nachdem wir ( @j.bussmann und ich) heute telefonisch mal das eigentliche Problem besprochen haben - insbesondere die Hintergründe der eigenartigen Situation ( @Sunny61 manche Interna kann man am Telefon besprechen, die definitiv nicht in ein Forum gehören) - hier mal meine gesammelten Gedanken zu einer skriptbasierten Lösung. Teile davon wurden bereits erwähnt. Wir sprechen ab sofort nicht mehr über Logonskripte. Das ist der falsche Andockpunkt. Richtig ist ein geplanter Task mit geeigneten Triggern. Der Task kann erstellt werden entweder über ein Computerstartup-Skript oder über die vorhandene Softwareverteilung. Idealerweise mit beiden Methoden, um die Trefferquote zu maximieren. Und nein, ich würde ihn nicht über GPP erstellen, das ist zu fehleranfällig. Lieber in der Aufgabenplanung an einem Referenzrechner interaktiv zusammenbauen und dann als XML exportieren. Das kann dann mit schtasks (oder register-taskdefinition) importiert werden. Trigger, die ich für sinnvoll halte: Startup (Delay 30 Minuten mit 10 Minuten Zufall), dann alle 12 Stunden im Hintergrund. Und auf Netzwerk-Events -> https://ardamis.com/2015/09/09/windows-event-log-query-for-domain-joined-network-connection/ Die Trigger sind der Teil, der per GPP relativ mühsam ist, das geht einfacher in der Aufgabenplanung. Der Trigger auf Domain Joined Network würde den Usern heute schon helfen - wer führt schon nach der VPN-Verbindung noch manuell ein Logonskript aus? Der Task muß IMHO ein Skript ausfürhen und in diesem dann folgende Aufgaben erledigen - seriell, nacheinander: Test-NetConnection (oder ping) auf den Server, der die UNC-Ressourcen bereitstellt Robocopy <Docusnap-Programmquellpfad> <lokaler Docusnap-Programmpfad> /xj /mir /log:xyz.log (Logs sind wichtig...) Docusnap-Inventoryskript aufrufen Robocopy <lokaler Docusnap-Inventorypfad> <Docusnap-Shared Inventory> Bei Step 4 muß der Zielpfad passend gestaltet sein - jeder PC braucht sein eigenes Verzeichnis. Wie genau es darunter dann aussehen soll, muß definiert werden. Und natürlich brauchen die Computer Leserechte auf den Programmquellpfad und Schreibrechte auf ihr Shared Inventory (könnte man ähnlich wie bei servergespeicherten Benutzerprofilen regeln...). Die Parameter für Robocopy sind auch nicht erschöpfend, dan kann man noch ein wenig tunen. Anmerkung: Ich hab keine Ahnung von Docusnap. Wenn Step 3 und 4 so nicht umsetzbar sind, dann kann 4 auch entfallen und 3 direkt irgendwo zentral ablegen... Wenn der Task mal auf einen Rechner verteilt wurde, dann sollte das alles relativ reibungslos laufen. Wie gesagt, Logging ist wichtig (egal wohin). Und Logs dürfen nicht überlaufen, auch da muß was passendes gestaltet werden (entweder nur ein Log immer überschreiben, oder anhängen und die Größe überwachen, oder mit Timestamp und die Anzahl überwachen). Und wenn man noch etwas tunen will, zerlegt man das in 2 Tasks. Der eine macht die beiden Robocopys und läuft mit dem Trigger auf Domain Joined Network Connection und zyklisch. Der andere macht nur das Inventory und läuft nur zyklisch.