daabm

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.

Danke @tesso

Hat da möglicherweise der Absender nur einen Link eingefügt statt des Originals?

Man löscht Profile nicht mehr durch das Entfernen des Profilordners. Entweder über das GUI oder über Win32_UserProfile.

Hmmm - hohe Anzahl von Geräten und kein AD, das paßt für mich nicht zusammen. Was ist der Grund dafür? Und die Aufgaben ansich - alles relativ einfach mit Powershell oder anderen Skriptsprachen umzusetzen. Woran genau scheiterst Du?

Kontraproduktiver Kommentar - mir geht es defintiv nicht um das Verheimlichen von Lösungen, sondern um das unaufgeregte (und gern unkommentierte!) Feststellen des eigentlichen Problems. Wer mich kennt, sollte das eigentlich wissen, aber ok, erst mal druff. Danke dafür... Edit: Das gleiche gilt auch für den darauf folgenden Kommentar BTT: Ich würde erst mal Batch streichen und auf Powershell umsteigen. Die Einstiegshürde ist nicht besonders groß, sehr viele (sehr sehr viele) Standardanforderungen in der Administration lassen sich googeln und Du wärst unendlich viel flexibler.

Weil nicht jeder KI mag, die Mails vorsortiert? Mir geht schon der Junkmail-Filter von Outlook.de auf die Nerven... @SBK das scheint derzeit tatsächlich nicht zu gehen :-( Ich hab nur das hier gefunden: https://docs.microsoft.com/en-us/office365/admin/setup/configure-focused-inbox?view=o365-worldwide Aber das bezieht sich auf O365, nicht auf die lokale Office-Installation...

Ich hab dazu wso viele Anregungen und Meinungen, daß ich möglicherweise die Größengrenze eines einzelnen Beitrags sprengen könnte, wenn ich jetzt alles dazu schreibe 1. Batch ist Grütze. Nicht nur, weil Powershell unendlich flexibler ist, sondern auch, weil Batch über UNC extreme Performance-Issues hat. Vor allem über langsame Leitungen. Datei öffnen, Zeile lesen, Positionsmarker setzen, Datei schließen, Zeile ausführen. Und das für JEDE EINZELNE ZEILE im Batch... 2. @echo off schaltet nur die Ausgabe des jeweiligen Befehls in der Konsole ab. Die Ausgaben der Befehle an sich werden sehr wohl ausgegeben. 3. Batch-Verschachtelung ist so Grütze wie Batch. Wenn schon, alles in eins rein. 4. Läuft das asynchron oder synchron? Wenn asynchron: Probleme mit Netzlaufwerken in Explorer oder Anwendungen sind vorprogrammiert. Wenn synchron: Desktop erscheint erst, wenn es fertig ist. Wenn die Shares nicht erreichbar sind: 30 Sekunden Wartezeit pro Share... (Genauer 29,56 ). 5. bis 99. spare ich mir hier mal - kannst mich ja mal direkt kontaktieren. Edit: Grad fällt mir 5. ein: Net use x: /d trennt die Verbindung. Aber nur, wenn da keine offenen Dateien sind, sonst kommt ne Rückfrage und das Skript bleibt stehen. Wenn schon "net use x: /d /y"... Edit 2 Ich werfe noch 6. hinterher: Startup und Logon Skripts sollten IMMER lokal liegen und lokal aufgerufen werden. Nur dann laufen sie auch, wenn keine Domänenverbindung besteht. Bei dem Skript hier ist das aber sinnfrei, weil es keinerlei Errorhandling oder "Situationserkennung" implementiert. Damit also dann auch nicht weiß, daß es offline ist (RootDSE nicht erreichbar) und nichts (oder nur wenig) machen sollte. Und man kann das nach dem Herstellen einer VPN-Verbindung auch automatisch ausführen, da gibt es so komische Events, die das signalisieren Um noch die Anfangsfrage zu beantworten - Datei ausführen, Ergebnis als XML erstellen; Beides sollte rein lokal passieren, und ins Netz kopiert wird dann, wenn das Netz auch verfügbar ist. Dann klappt es auch mit dem Nachbarn.

Jetzt pack den Tiger wieder in den Tank und mach ihm keine Angst - das passiert seltener, als man denkt. Mitbekommen tust ja immer nur, wenn es NICHT klappt...

Ich würde schon den Trigger an die Event-ID hängen und dann im aufgerufenen Skript die Anzahl (oder was auch immer) konkret auswerten...

Ich würde noch gerne nach dem eigentlichen Zweck fragen. Das Erscheinen von Notepad wird es ja wohl kaum sein Für so was würde ich übrigens auf WMI-Eventing zurückgreifen. Da muß eben KEIN Skript in einer Endlosschleife laufen, sondern WMI löst einen Eventtrigger aus, wenn was bestimmtes erscheint/geändert wird/verschwindet.

Geht im laufenden Betrieb - da authentifiziert sich ja i.d.R. nur selten jemand, und die morgens bei der Anmeldung ausgestellten Kerberos-Tickets gelten per Default 8 Stunden. Machst Du das am späten Vormittag, sollte niemand etwas bemerken, wenn es nicht grandios in die Hose geht