BOfH_666

Wie Du hier einen Thread als Beantwortet kennzeichnest, kann ich Dir tatsächlich gar nicht sagen. Ich hatte noch nie die Gelegenheit, das zu selbst zu tun. Ich würde aber davon ausgehen, dass Du als Ersteller des Threads irgendwo einen Button hast, der das erledigt. Wie Du in der Doku zum cmdlet Get-ADUser sehen kannst, nimmt der Parameter -SearchBase nur einen einzelnen String-Wert entgegen ([-SearchBase <String>] wenn mehrere erlaubt wären, würde es so aussehen: [-SearchBase <String>[]]). Du hast also mindestens 2 Wege, das Problem anzugehen. 1. - Du schränkst die Suche schon beim Ermitteln der Daten ein: Du kannst die betreffenden "Suchbasen" in ein Array packen und mit einer Foreach-Schleife abarbeiten. Damit die Ausgabe aller 3 "Durchläufe" dann trotzdem in einer einzigen CSV-Datei landen, hängst Du ans Export-CSV cmdlet einfach ein -Append an. 2. - Du beginnst die Suche erstmal in der "Parent" - OU und filterst mittels eines Where-Object cmdlets die unerwünschten Ergebnisse "hinten" raus. Wie Du die Filterkriterien setzt, hängt dann von Deiner OU-Struktur ab. Du könntest unerwünschte OUs explizit ausfiltern oder gewünschte OUs einschließen. Da müsstest Du dann schauen, was in Deinem Fall das Beste für Dich ist.

Hmmm .... und Du sagtest noch, dass Du jetzt fitter mit der Powershell bist .... ... Zeilenumbrüche sind nur an bestimmten Stellen erlaubt. Wenn Du einen Parameter angibst, wie z.B. -Property, musst Du ihm auch einen Wert mitgeben. Da darf also kein Zeilenumbruch vor dem ersten Wert sein. An Kommata, Semikola und einigen Punkten kannst Du gern einen Zeilenumbruch machen. Das macht den Code dann im Zweifel hoffentlich besser lesbar. Edit: ooops ... jetzt hab ich nochmal genauer auf Deinen Code geschaut. Das Select-Object brauchst Du nicht zweimal ... und Sort-Object würde ich eher weiter hinten, also, wenn überhaupt, vor den Export packen. Export-CSV braucht ein Pipe davor .... ein Komma genügt da nicht! Edit 2: ... achja ... nach dem Pipe-Symbol sind Zeilenumbrüche natürlich auch erlaubt.

Ihr immer mit Euren oberflächlichen kosmetischen Änderungen ... ... das Zeug is nun mal english ... Du kannst mittels "calculated Properties" die Namen ganz nach Belieben anpassen. Get-ADUser -Identity $env:USERNAME -Properties OfficePhone,Department,EmployeeID,EmployeeNumber,Initials | Select-Object -Property @{Name='Active Directory Objekt Name';Expression={$_.Name}}, @{Name='Name,den die Eltern ausgesucht haben';Expression={$_.GivenName}}, @{Name='FamilienName';Expression={$_.SurName}}, @{Name='Windows AnmeldeName';Expression={$_.SamAccoutnName}}, @{Name='Bürotelefonnummer';Expression={$_.OfficePhone}}, @{Name='Abteilung';Expression={$_.Department}}, @{Name='PersonalKennzeichen';Expression={$_.EmployeeID}}, @{Name='PersonalNummer';Expression={$_.EmployeeNumber}}, @{Name='Anfangsbuchstaben des Namens';Expression={$_.Initials}}

Ich bin jetzt auch nicht der GPO-WMI-Filter-Profi, aber das sieht für mich von der Syntax her ganz plausibel aus. ... aber im Zweifel kannst Du es ja bevor Du es "produktiv" ausrollst nochmal testen.

Der ProductType in der WMI-Klasse OperationgSystem unterscheidet meines Wissens zwischen Workstation, Server (nicht nur 2016) und Domain Controller. Wenn Du in einem Where-Object-Filter Bedingungen verknüpfen willst, musst Du die "Script-Schreibweise" nehmen. Und ich würde die etwas modernere Variante empfehlen. Also so ungefähr: Get-CimInstance -ClassName CIM_OperatingSystem | Where-Object -FilterScript {$_.Version -like '10.*' -and ($_.ProductType -eq 3 -or $_.ProductType -eq 2)} Es wird aber kein True oder false zurückgeliefert, sondern ein Object vom Typ "Microsoft.Management.Infrastructure.CimInstance#root/cimv2/Win32_OperatingSystem". Du könntest aber auch einfach erst mal das Object "einsammeln" und dann die gewünschten Properties prüfen. Also so ungerfähr: $OS = Get-CimInstance -ClassName CIM_OperatingSystem If($OS.Version -like '10.*' -and ($_.ProductType -eq 3 -or $_.ProductType -eq 2)){ 'Jawoll' } Else{ 'Nö' } Ich würde empfehlen, sich die Grundlagen von Powershell anzueignen. Einen guten Einstieg gibt's bei Microsoft in der Virtual Academy: Microsoft Virtual Academy - Getting Started with Microsoft PowerShell Viel Spaß

Selbst wenn das "Schnelle Entfernen" konfiguriert ist, sollten, nach dem der eigentlich Copy- oder Backup-Job abgeschlossen ist, nach wenigen Sekunden alle Daten auf dem Datenträger geschrieben sein. Der USB-Platten-DJ wird ja wohl kaum vor dem Rechner Gewehr bei Fuß sitzen und das Ding in der nächsten Sekunde abziehen, wenn das Backup beendet ist. Darf ich mal so neugierig sein und fragen, warum ihr USB-Platten benutzt? Ist das nicht ziemlich Fehler-trächtig und unzuverlässig?

Es mag ketzerisch klingen, aber Du musst doch die USB-Platte sowieso physisch vom Computer trennen. Lohnt sich da wirklich der Aufwand, das Ding vorher auch noch per Script virtuell auszuwerfen?

Hättest Du nur .... ;) :wink2: ... das funktioniert leider nicht. :nene: :schreck:

Deswegen die Empfehlung die Grundlagen von Powershell zu erlernen. Dabei lernst Du auch, wie Du an benötigte Informationen kommst. Der oben verlinkte MVA Kurs ist kostenlos und bietet einen guten strukturierten Einstieg und kostet Dich nur ein bissl Deiner Zeit. Wenn Du Dir zum Beispiel mal ALLE bei Euch benutzten Attribute anzeigen lässt, siehst Du, welches Du davon für Deinen Zweck gebrauchen kannst: Get-ADUser -Identity 'DEIN SAMACCOUNTNAME' -Properties * | Select-Object -Property * Wenn Du Deine eigene Personalnummer kennst und sie im AD gepflegt ist, siehst Du jetzt in welchem AD-Attribut sie gespeichert ist. .... da kann man nur die Daumen drücken ... ;) :thumb1: :D :schreck: :wink2:

Wenn das keine einmalige Aufgabe ist, würde ich Dir dringend empfehlen, Dir die Grundlagen von Powershell anzueignen. Ich glaube, es würde sich für Dich in der Zukunft auszahlen. Mit Get-ADUser erhältst Du Informationen über Benutzer-Konten aus dem Active Directory. Mit entsprechenden Parametern kannst Du die ausgegebenen Informationen beeinflussen. Get-ADUser -Filter * -SearchBase 'OU=Mitarbeiter,OU=User,OU=CV,DC=Hamburg,DC=local' -Properties OfficePhone,Department,EmployeeID,EmployeeNumber,Initials | Select-Object -Property Name,GivenName,SurName,SamAccoutnName,OfficePhone,Department,EmployeeID,EmployeeNumber,Initials | Export-Csv -Path 'C:\ADUserliste.csv' -Delimiter ';' -NoTypeInformation Dieser Befehl gibt die Benutzer-Konten mit den angegebenen Attributen in eine CSV-Datei aus. Die SearchBase musst Du natürlich noch entsprechend Deiner Umgebung anpassen. An dieser Stelle musst Du den Distinguished Name der OU eintragen, in dem die Benutzer-Konten liegen, die Du ausgeben möchtest. Exchange brauchst Du für diese Informationen nicht. Wenn Du in Zukunft hier Code postest, bitte formatiere diesen als Code. Das vermeidet ungewollte zeilenumbrüche und macht den Code einfacher zu lesen und zu verstehen. Solche Kleinigkeiten macht man eigentlich normalerweise alleine - also ohne großartige Scripte aus dem Internet. Man muss es ja sowieso an die eigene Umgebung anpassen. Fertige Scripte für viele Gelegenheiten findest Du notfalls hier: Powershell Gallery oder hier: Microsoft Technet Script Center.

Das hilft mir noch nicht wirklich, zu verstehen, wie Du Vergleichsoperatoren "variabel" gestallten willst. Klingt für mich im Moment eher danach, als würdest Du mehr als 2 Attribute/Werte/Items miteinander vergleichen wollen. Dafür kann man eine If-IfElse-Then-Kaskade benutzen oder ein switch-Statement benutzen.

Was meinst Du mit variabel?

Hmmm ... eigentlich weiß ich ja ... das ist aber kein Grund aufzugeben ... ;) :cool: :thumb1:

... prima Gelegenheit, das mal wieder erneut zu überdenken und vielleicht mit der Konzernsicherheit zu diskutieren. Die Welt dreht sich ja permanent weiter - vielleicht sollte das die Konzernsicherheit auch.

$heute = Get-Date noch einfacher geht's kaum, oder? ;) :cool: :thumb1: Eigentlich isses sogar eher: $jetzt = Get-Date Für nur das Datum müsste's eher heißen: $heute = (Get-Date).Date

Robert, es mag an der aktuelleren Version liegen - wir sind schon auf SCCM 2016, aber in einer interaktiven Remote-Session kann ich ohne Probleme auf den Configuration Manager Provider zugreifen. Wie interaktiv soll denn die Aktion sein? Wenn es komplett automatisiert ablaufen soll, kannst Du's ja auch als geplante Aufgabe auf dem SCCM-Server laufen lassen. Oder DU installierst Dir einfach die SCCM-Console auf der Kiste, auf der Du es laufen lassen willst, Da kommt dann der Configuration Manager Provider gleich mit.

Du benötigst die entsprechenden Rechte. Da führt kein Weg dran vorbei.

Das ist aber eigentlich kein Scripting-Thema. Wie mit der Anforderung für Empfangs- oder Lesebestätigung umgegangen wird, kann jeder Mailanbieter / Mailserverbetreiber selbst festlegen. Gmail zum Beispiel fordert niemals Empfangs- oder Lesebestätigungen an und reagiert auch nicht auf entsprechende Anforderungen.

Hmmm ... keinen Kommentar dazu. Falls Du also weder Nils noch dem Entwickler glaubst, dass das Tool das kann, was auf der Homepage im Feature-Set angegeben ist, kannst Du immernoch ICACLS benutzen. Auch damit kann man existierende ACLs ersetzen - also eine neue erwünschte ACL konfigurieren, ohne die alte zu übernehmen oder zu ergänzen.

Hast Du Dir denn die Empfehlung von Nils mal angesehen? SetACL von Helge Klein!

Vielleicht fragst Du einfach den Author des Scripts um Rat. ;) ... und nur aus Neugier: Du möchtest 1.800 User-Shares anpassen und willst dafür die User jeweils per Textbox eingeben?? :schreck: ... wow ... Hut ab! ;)

OK ... soweit bin ich jetzt bei Dir. Ma kukn, ob wir nicht eine bessere Idee finden, diese Aufgabe zu lösen .... Ich vermute mal, es ist nur ein geringer Teil, der in dem Restore-Script dynamisch ist, bzw. spezifisch für den jeweiligen Backup-Satz, richtig? Wie wäre es dann, wenn Du einfach ein Script baust, welches sich die nötigen "variablen" Informationen aus einer Steuerdatei holt? Das könnte eine einfache Text-Datei sein, eine INI-Datei, eine XML-Datei oder vielleicht sogar eine per Export-CLIXML erzeugte Powershell-XML-Datei. Die sind alle deutlich einfacher per PoSh erzeugen oder von einer Vorlage anpassen als direkt ein PoSh-Script zu erzeugen. Wenn Du darauf bestehst, unbedingt ein Script als Ergebnis zu haben, wäre es noch denkbar, in diesem Fall auch eine Vorlage zu benutzen. Dann kannst Du das Script quasi schon fertig bauen und fügst für die veränderlichen Teile einfach gut per Regex "fassbare" Platzhalter ein. z.B. " ###Vairable01###" .... dann kannst Du per PoSh diese Vorlage einlesen und per Regex und Replace die Variablen gegen die "Arbeitsdaten" austauschen. Was hältst Du davon? ;) :cool: :D :)

Na mit welcher Script-Sprache willst Du denn eigentlich arbeiten? Du erwartest aber nicht, dass wir Dir jetzt ein Script bauen, oder? :wink2: :schreck:

hmmm ... ich verstehe schon nicht, warum Du ein Powershell script mittels eines Powershell scripts erstellen willst. :eek: :nene: :wink2: :schreck:

Noch'n genereller Tipp: Ich weiß nicht, ob das hier der Fall ist, aber es gibt Einstellungen, die kann man nicht für ALLE Benutzer eines Computers machen, die muss man für JEDEN Benutzer eines Computers machen. Microsoft Software (früher z.B. der IE) benutzt dafür gerne mal eine Technik namens Active Setup.