Tiro

Blende das Update über die rechte Maustaste aus.

Jetzt mußt ich doch glatt ne Minute überlegen und richtig lesen. Gehe in die Eigenschaften der Taskleiste und wechsle zum Reiter "Symbolleisten". Entferne den Haken bei "Desktop", speichere mit "OK" und "fröhlich sein". :-) Das sollte die Biene auf die Blüte heben.

So lange Du nicht mit GPPs arbeitest, gilt die GPO nur, wenn sich der Benutzer oder Rechner in der eingehängten OU befindet. Ein gpupdate ist eigentlich nicht notwendig, weil die GPOs regelmäßig zwischen 60 und 120 min eh neu gezogen wird. Beim Neustart prinzipiell auch. Benutzerrichtlinien halt bei der Anmeldung. Und die alten und neuen GPOs kannst Du ja auf die neue OU mit drauf hängen. Wenn sie nicht konkurrieren ist es schnurz. Wenn doch, dann kannst Du das ggfs. über die Hierarchie der Verarbeitungsreihenfolge lösen. PS: löschen brauchst Du auch nichts.

Ist im Sharepoint nicht schon "Projects" mit Basisfunktionen mit enthalten? Ich habe das dumpf in Erinnerung, als ich früher damit herumgespielt habe.

Ist das Schema schon erweitert? Hast Du die notwendigen Berechtigungen?

Also erstmal genügt eine Filterung mit "where-object" (kurz "where"). Die anderen Bedingungen sind mit "-and" (oder natürlich auch "-or") an die erste anzuhängen. Ich habe es nicht ausprobiert, aber Dein Biespiel funktioniert entweder gar nicht oder es läuft sehr langsam. Woher hast Du die Eigenschaft "timegenerated"? Das ist keine Eigenschaft von Get-ChildItem. CreationTime wäre eine. Also eher sowas where-object {$_.Mode -match 'd-' -and $_.creationtime.Year -match '2014'} (= alle Ordner die 2014 erstellt wurden) get-acl gibt die Berechtigungen aus. (Zitat der Hilfe "Gets the security descriptor for a resource, such as a file or registry key.") "$" verweist auf den reinen Inhalt der Variable. Die Variable kann x mit dem Wert 5 sein. Den Inhalt der Variable fragt man mit $x ab. "$_." ist die Schreibweise/ Syntax für "nehme den Inhalt der Variable aus der Pipeline, verknüpfe ihn mit der angegebenen Eigenschaft nach dem Punkt (hier "Mode") Eher was grundsätzliches: * wenn Du einen Befehl nicht kennst, dann schau in die Hilfe mit "get-help <Befehl> -full" Das muß jeder machen ;-) Sogar Don Jones und Holger Schwichtenberg. Es ist lehrreich und es sind stets Beispiele dabei. * Warum willst Du Dich in PowerShell zu Tode filtern, wenn Du sowieso nach Excel exportierst? Je nach Datenmenge vervielfachst Du die Laufzeit des Skripts. Das "zuviel" an Daten filtere ich doch schneller in Excel mit Pivot. "good practise" ist es, die Daten so unbearbeitet wie möglich zu lassen, wenn es irgendwie geht.

Für die Anzeige der Ordner mußt Du nur eine Filterung zwischen get-childitem und select-object setzen. ein | where {$_.Mode -match 'd-'} sollte da genügen. Für den Benutzer muß man leider ein gewagtes Konstrukt basteln, welches auch Deine Abfrage so dermaßen verlangsamt, daß Du selbst wissen mußt, ob Du es so laufen lassen möchtest. Ersetze "Owner" durch @{n="Owner";e={(get-acl $_.fullname).owner}} Lasse auch die Sortierung weg. In Excel sortierst Du die csv schneller. ;-)

Wäre ein Export-CSV nicht einfacher? ;-) Get-Childitem -Recurse | Select-Object Owner, Name, Fullname, Attributes, LastWriteTime | Export-Csv -path D:\temp\hiereinname.csv -NoTypeInformation -Encoding UTF8 Und "Owner" ist keine Eigenschaft von Get-Childitem. Das sollte also stets leer sein?

Schau mal hier. Es gibt da auch innerhalb des Boards noch weitere Diskussionen darüber. Vielleicht ist das ja hilfreich?

Erstmal "Glückwunsch". Schule und das echte Arbeitsleben sind meist zwei paar Schuhe. Mittlerweile frage ich mich vor jeder Arbeit, die ich mache: "Gibt's da auch was von PowerShell?" (und ich ärgere mich, wenn ich dieses und jenes cmdlet nicht verwendet kann, weil nur unter Windows X ;-) ) Jeder Anbieter von Software, der "bei den großen Jungs" mitspielen will, erstellt mittlerweile seine eigenen Commandlets (cmdlets) für die eigenen Produkte. Und ich gehe auch jedem Anbieter von Software, die wir einsetzen auf die Nüssen, ob sie nicht cmdlets planen. *bg*

Wenn Du die Ansicht "process tree" wählst (wie oben geschrieben), dann sollte Dein Hauptaugenmerk primär dem Zeitbalken (Dauer) gelten. Wenn im log etwas mit langer Dauer aufgeführt ist, dann ist es Dein potentiell "Verdächtiger"und Du mußt genau hinschauen. ;-) Als Goodie: Watch me!

Die Angaben sind ein wenig "mager". Habt Ihr roaming profiles? ist in den GPOs noch ein alter Pfad vom Fileserver drin? Wie ist die Geschwindigkeit der Netzwerkkarte? Wie sehen die Switches aus? Nehm Dir zwischenzeitlich einen dieser Rechner (der noch viel Plattenplatz frei haben sollte), starte den Process Monitor aus der Sysinternal Suite und verwende ihn mit der Boot Option. Boote den Rechner und schaue Dir hinterher das Log des Process Monitors an. Nutze dabei die Ansicht "Process tree". Ich denke, daß gibt Aufschluß wo es beim Loginvorgang lange dauert.

"In jedem Fehler steckt eine Lehre. (V. Birkenbihl)" :-)

OS, Anwendungen und Treiber laufen ja mittlerweile rund. Der Build von Referenz Images läuft auch flüssig. Für DSC ist interessant, wenn wir denn mal W2K12 (R2) Server haben werden. ;-) "Packages" funktionierten bisher gar nicht. Egal, wieviel ich getestet habe. => Feind No. 1 Für's erste wäre mir mit allem les- und brauchbarem dazu schon geholfen.

Momentan nutzen es die Kollegen für Windows 7 Installationen. Ich mache auch Server damit. Virtuell, wie physikalisch Prinzipiell möchte ich einfach die Funktionalitäten des voll MDT ausreizen. ("Hier" ist jemand zu geizig für eine ordentliche ZTI-Lösung :-) )

Ahoi! arbeitet hier jemand mit dem Microsoft Deployment Toolkit (MDT)? Ich habe schon ein funktionierendes Deployment damit erstellt und es läuft auch rund soweit. Allerdings möchte ich da tiefer einsteigen und auch die bisher ungenutzten Funktionen nutzen (packages, advanced configuration etc.) Blöderweise ist die beiliegende Dokumentation und TechNet gelinde gesagt ein klein wenig §$%&/(. Hat jemand gute Links, die mir die o.a. Funktionen näher bringen? Oder möchte sich mit mir darüber austauschen? Danke vorab Tiro

Ohne Dir jetzt zu nahe treten zu wollen: hast Du eine Ahnung von dem was Du gerade tust? Aus Deiner Antwort entnehme ich, daß Du den KB-Artikel auch noch nicht gelesen hast. Deinen bisherigen (für mich nebulösen) Angaben zufolge, denke ich, daß Du genau zwei Optionen hast: * einen externen, guten und vermutlich teueren Dienstleister hinzuholen oder * beten, einen zweiten Server als DC heraufstufen, die FSMOs mit ntdsutil umziehen, noch mal beten und dann hoffen, daß alles wieder funktioniert Sonst sagt der Volksmund: "alles neu macht der Mai" ;-)

Ich bekomme eine Gänsehaut unter den Fußnägeln. Bitte ziehe als erstes nur die FSMO-Rollen gemäß des vom Chief erwähnten KB-Artikels um (ab Absatz "Übertragen von FSMO-Funktionen"). Danach nimmst Du den zweiten Server und machst ihn ASAP wieder zum DC. (so verstehe ich zumindest Deine Beschreibungen bis hier, daß Du wenigstens noch einen funktionierenden DC hast)

'>Das hier ist sehr nett. Ein schickes PowerShell cmdlet und richtig angewandt befragt es auch alle Rechner über das Netzwerk.

Ich würde den McAfee mal nicht ausschließen. Der "pinkelt" mir immer wieder mal unverhofft ans Bein. Sei es beim Update des Deployment Shares im MDT oder bei dem PowerShell Commandlet "Send-MailMessage". Kaum stoppe und deaktiviere ich temporär die Dienste, schon geht alles.

Mit Deinem WMF 4 unter Windows 7 ist alles in Ordnung. Manche Commandlets gibt es erst ab bestimmten OS-Versionen. Z.B. das ganze Printermanagement gibt es erst ab Windows 8, was ich gern auch auf der Arbeit hätte. zu 2) gar nicht mit Windows 7 zu 3) IMHO funktioniert das nicht.

Ich weiß, daß Dir, wertgeschätzter SilentDemise, die Feinheiten von "Get-childitem" klar sind und vermutlich weißt Du über Powershell auch mehr als ich, aber ich sah diese Zusatzinformation auch als selbstgestellten Lehrauftrag für alle anderen an. :-) Ich war halt gerade in Erklärstimmung. Sollte ich Dir damit zu nahe getreten sein, biete ich hiermit eine Entschuldigung an.

Normalerweise hat man so ein Skript als tägliche Aufgabe laufen. Da sind Ausgaben eher minder wichtig, weil es sitzt ja keiner dabei und schaut, ob nachts um xx Uhr auch nicht die falsche Datei gelöscht wird. *bg* Nichts ist nerviger, als diese vermaledeiten thumbs.db Dateien, die im Verzeichnis existieren, weil "früher" einmal ein Bild vorhanden war. Die verhindern dann zu 99% auch das löschen leerer Ordner. ;-) (Get-ChildItem -Path <Pfad> -Recurse | Where-Object {$_.PSIsContainer -eq $True}) | Where-Object {$_.GetFiles().Count -eq 0} | Remove-Item -Recurse -Force

Eigentlich sollte der Einzeiler schon reichen. Get-ChildItem -Path <Pfad> -Recurse -force | Where-Object {$_.LastWriteTime -lt (get-date).adddays(-45)} | Remove-Item -recurse -force Foreach ist immer der letzte Ausweg in Powershell, weil keines der cmdlets das mitbring was man haben will. Ich sehe in der Ausgabe, was er gerade löscht, auch keinen besonderen Mehrwert. Zudem zitiere ich hier den großartigen MVP Don Jones: "every time you use "write-host" god kills a puppy!" :-)

Das funktioniert schon noch ;-) Nur nicht mehr über "Internet Explorer Wartung", sondern über die GPPs. Versuche die GPO von einem W2K12 DC aus zu ändern. Das sind die GPO-Templates vorhanden. Oder richte Dir einen "Central Store" ein. (am besten mit den GPO Definitions eines W2K12 R2 Servers, denn die sind am aktuellsten)