daabm

Eventlogs kannst Du mit XPath filtern, da kriegst Du also alles raus, wenn die Daten irgendwie vorhersehbar in XML-Nodes liegen.

(Blödsinn gelöscht - war was anderes...) Oder auch nicht - FSRM hat ein "Wiederholungsintervall" von 60 Minuten, und der hektische Admin will das ja sofort wissen und nicht ne Stunde warten :) Rechtsklick auf den obersten Knoten - Optionen?

MS16-072/MS16-087 - love it or leave it :)

Wenn F3 nicht F3 ist, sondern die herstellereigene Sonderfunktion -> siehe mba. Schalte das um auf das Standardverhalten :)

Die Meldung kommt daher, daß das gecachte MSI der Altversion in C:\Windows\Installer nicht mehr vorhanden ist. Woher soll der Installer jetzt wissen, wie er die Altversion wegbekommt? Knallharte Abhilfe: msizap !TW aus dem Office RK.

...und bei SA sieht das ganze vmtl. wieder ganz anders aus - wir haben O365 E3/E4 lizenziert, installieren aber die Setup-Version. Gottseidank hab ich damit außer dem AADSync nix zu tun :) Da bist ja echt "lost" inzwischen...xd

MS16-072? Ein GPO-Ergebnissatz könnte hilfreich sein. xd

Um das mal anders zu beantworten: Das geht nicht. Wenn Du im AD den Computernamen änderst, bekommt der Client davon nichts mit - das muß auf dem Client passieren. Und zwar im Kontext eines Accounts, der notfalls auch den Computeraccount im AD umbenennen darf.

Keine Ahnung - das ist Lizenzierung, Buch mit 700 Siegeln :)

Warum willst Du dafür ein Skript schreiben? WSUS Package Publisher macht das doch alles automatisch...

WSUS hier, der W10, 2012R2, 2008R2 und Office2013/2016 versorgt - deutsch und englisch: 795 GB. Ok, da liegt vmtl. auch noch altes Zeug von W7 mit drin -aber hey, was kostet Plattenplatz? Notfalls schmeiß ich das Zeug auf ne USB-Platte :-) :-) :-)

Ich korrigiere mal ein paar Aussagen hier... (Auch wenn der Fred schon beantwortet ist) 1. Client sended "give me GPOs" an den Server 2. Server liefert eine Liste aller verknüpften GPOs im Scope of Management an den Client zurück (alle!) 3. Client versucht von jedem GPO den GPC zu lesen (also den AD-Teil) 4. Client kriegt für alle GPCs ohne LEserechte gleich eins auf die Finger 5. Client wertet "Flags" des GPC aus - User/COmputer aktiviert? 6. Client wertet gPCUserExtensionNames oder gPCMachineExtensionNames aus - sind Settings vorhanden? Und den Computerteil zu deaktivieren, erspart einem exakt diesen Schritt. Da der GPC aber ein AD-Objekt mit Attributen ist, das "im Ganzen" gelesen wird, ist der Performance-Unterschied definitiv "Null". 7. DACL auswerten - ist "Apply" dabei? 8. WMI-Filter - wenn vorhanden - wahr? 9. Inhalte lesen - jetzt kommt der erste Sysvol-Zugriff... Einziger Vorteil: Wenn ich den ungenutzten Teil deaktiviere, passiert nicht so viel, falls meine GPO mal wo wirkt, wo sie nicht sollte (Stichwort "Computer-GPOs mit vergessenen User-Settings, und jetzt aktiviere ich Loopback"...) Das CSE-Processing zu optimieren bringt in der Tat sehr viel mehr - es ist kontraproduktiv, z.B. GPP Registry über 100 GPOs zu verteilen, weil dann 100 registry.xml gelesen werden müssen. Besser alles in eine einzige GPO (= 1 registry.xml) packen und den Rest über ILT erledigen. Und die meisten Performance-Verbesserungen findet man i.d.R. ohnehin bei WMI-Filtern und synchronen Skripts. http://evilgpo.blogspot.de/2014/11/wmi-filter-queries-and-thoughts-on.html Noch Fragen? Dann fragen! :-) Edit: Bei der genauen Reihenfolge von 5/6/7 bin ich mir nicht sicher - kann auch sein, daß 7 vor 5/6 kommt. Aber 5/6 stimmt auf jeden Fall.

tapinego ist jetzt kein sooo geläufiges Protokoll - wirf raus den Eintrag :)

Je nach dem, was Du da auswerten willst, wäre Powershell sicher ganz gut geeignet :)

Surface 3 - geh mal bei surfaceinside.de vorbei, Ralf könnte da nen Tip haben. Und wenn nicht, meldet er das sicher gerne der PG weiter :)

Jungs Ihr stochert grad alle im Nebel - die Problembeschreibung ist eindeutig, und möglicherweise hat MS da mal wieder was verbaselt... Ich würde als Workaround empfehlen, das Aktualisierungsintervall auf den maximalen Wert zu setzen, dann dürfte auch Ruhe sein - ganz abschalten kannst Du es aber nicht, da Sicherheitsrichtlinien zwangsweise festcodiert nach spätestens 16 Stunden erneut angewendet werden. Aber normalerweise macht das Hintergrundupdate keine Probleme, wenn man seine Settings entsprechend setzt (siehe Laufwerkzuordnungen :) )

O365 ist ClickToRun (so ähnlich wie App-V). O2016 ist klassisches Setup.

Passt schon. Ist leider relativ schlecht dokumentiert, welche Besonderheiten GPOs haben, die an der Domäne selbst verlinkt sind :)

Bin kein Fileserver-Profi, aber FSRM kann relativ viel...

paxi, mit nem WDS und etwas Unattended (wie hieß das noch mal? MDT? :-) ) isses auch net wirklich schwer... War schon immer "generell" einfacher, ein Master-Image nur mit Fixen zu präparieren statt Sysprep. ym2c.

Kann es sein, daß Du die Large Integers erst konvertieren mußt? (Schon lang nimmer gemacht...)

Kennwort- und Kerberos-Policies, die mit der DOmäne verknüpft sind, werden nicht (und wurden noch nie) von Domain Membern verarbeitet - ausschließlich DCs machen das. Du willst ja auch nicht den Client konfigurieren, sondern die Domäne :-)

Ich werfe dann mal noch MS16-087 in den Ring, wenn die Treiber keine "Package Driver" sind :)

Die Forenregeln sind für die Katz... Das mit den Crossposts und "darauf hinweisen" liest keiner, und wer es liest, der beachtet es nicht :)

Dunkelbier bevorzugt :)