BOfH_666

Tjaaaa .... da kannst Du mal sehen, was die Powershell unter der Haube alles implizit für Dich tut. Ohne Deinen Code zu kennen, kannst Du entweder die Ausgabe Deinen Wünschen entsprechend anpassen, oder die Abfrage der nötigen Informationen vom Anwender auf eine andere Methode umstellen. Dann könntest Du die einfache Ausgabe über Write-Output beibehalten. Die Ausgabe anpassen könntest Du vielleicht so: Write-host "ComputerName:`t'$($result.ComputerName)'`nMitarbeiter:`t'$($result.Mitarbeiter)'" Das sollte dann ungefähr so aussehen: Computername: xyz Mitarbeiter: BLA

Write-Output schreibt die Ausgabe in die Pipeline. Write-Host und die Read-Host - Aufforderung schreiben direkt in die Konsole. Das sind verschiedene Streams, die die Powershell unterschiedlich sortiert. Da gewinnt so gut wie immer Write-Host. Wenn die Reihenfolge wichtig ist, musst Du bei so einem Konstrukt wohl Write-Host verwenden. .... oder einen anderen Ansatz für die nötigen Anwender-Eingaben finden. z.B. eine Funktion zu benutzen mit einem "mandatory" Parameter.

Yeehaa ... cool.

War es nicht so, dass man mit try/catch nur "richtige" Powershell Fehler eingefangen bekommt und keine Fehler von "externen" Programmen? Du könntest beim Start-Process die Standardausgabe und die Fehlerausgabe jeweils in eine Datei umleiten und diese dann auswerten. Oder Du benutzt den Exitcode falls reg.exe oder regedit.exe so etwas zurückliefern. $Ergebnis = (Start-Process -FilePath "reg.exe" -ArgumentList "IMPORT <reg-Datei>" -NoNewWindow -PassThru -Wait ).ExitCode

Je nach dem, von welcher Zahl an Clients wir hier reden, wäre vielleicht eine vernünftige Software-Verteilung die richtige Lösung (SCCM, Altiris, Matrix42 oder was auch immer). Davon mal abgesehen, kann man zur Not auch mit Gruppenrichtlinien Software verteilen. Das ist wahrscheinlich die deutlich zuverlässigere Lösung als etwas Selbstgestricktes.

Klar - dann musst Du aber eben die zu übergebende Variable explizit nach [Uint64] casten. Und je nach dem, wer den Wert eingibt, muss er oder sie wissen, wie man den Wert eingibt. "3 GB" wäre zum Beispiel falsch - es muss wirklich "3GB" sein. Vielleicht könnte man auch eine Vorauswahl von möglichen (sinnvollen) Werten präsentieren und man wählt eine davon aus. Das würde Fehleingaben noch besser ausschließen.

Der zu übergebende Wert ist nicht "2GB" sondern "2147483648". Ich würde empfehlen, einfach nur die reine "Zahl" abzufragen - also ohne die Einheit GB und dann vor dem Aufruf des cmdlets einfach in Byte umzurechnen.

Hmmm .... ich hätte ja dann doch eher Restart-Computer empfohlen. Das unterstützt auch den Parameter -ComputerName, mit dem man dann auch remote Computer neustarten kann.

Tipp: Updaten! SCNR.

Hast Du schon mal versucht, danach zu googeln? Du kannst Dir bestimmt vorstellen, dass Du nicht der Erste mit dieser Aufgabe bist, oder? Powershell to ignore blank or NULL entries in import-csv Bulk update of AD users properties Skip Blank Values in Import-CSV

Ich glaube, er möchte die Kontakte aus der CSV in sein Exchange-Online importieren, wenn sie dort noch nicht vorhanden sind.

... dabei war ja das letzte Mal eigentlich schon das letzte Mal .... ... im Zweifel einfach zeilenweise oder "befehlsweise" ausführen (wenn ein Befehl über mehrere Zeilen geht, musst Du natürlich alle Zeilen des Befehls in die Ausführung einschließen). In der Powershell_ISE oder im VSCOde kannst Du den Code, den Du ausführen möchtest mit der Maus markeiren und dann einfach F8 drücken. Dann sollte das gewünschte Ergebnis im Befehlsfenster erscheinen. ... ähhmm .... Nein. Das cmdlet Get-ADUser gibt standardmäßig nur einen Teil der Attribute die ein AD-Objekt hat aus. Möchtest Du mehr sehen als diese standardmäßig ausgegebenen Attribute, musst Du Diese mit dem Parameter -Properties anfordern. Das Select-Object kann nur die Attribute beeinflussen, die es über die Pipeline geliefert bekommt. Wenn Du den Code wirklich so ausführst, wie Du ihn oben gepostest hast, kann es nicht funktionieren. Wenn Du ewtas per Export-CSV exportieren möchtest, musst Du dem cmdlet auch etwas liefern. Entweder per Pipeline, das ist eher der Normalfalls, sag ich mal. Oder per -InputObject, das sieht man eher selten, glaube ich. Ich würde Dir empfehlen, Dir die Grundlagen von Powershell anzueignen. Mit Raten kommt man da leider nciht so richtig weit. Du ersparst Dir damit ne Menge verschwendete Zeit und Frustration. Es ist auch empfehlenswert, selbst wenn man die Grundlagen schon drauf hat, sich die Hilfe für die cmdlets anzusehen, die man benutzt und noch nicht richtig kennt - inclusive der Beispiele!!! $OU_Liste= 'OU=Bundesuser1,OU=User,OU=Gruppe,DC=domäne,DC=firmendomäne,DC=de', 'OU=Bundesuser2,OU=User,OU=Gruppe,DC=domäne,DC=firmendomäne,DC=de' $KomplettListe = Foreach($OU in $OU_Liste){ Get-ADUser -Filter 'objectClass -eq "user"' -Properties EmployeeID -SearchBase $OU | Sort-Object surname | Select-Object -Property GivenName,Surname,SamAccountName,@{Name='personalnummer';Expression={$_.EmployeeID}} } Die beiden Befehlszeilen saugen die gewünschten INformationen aus dem AD und speichern das Ergebnis in der Variablen $KomplettListe. $KomplettListe So gibst Du dIr diese Liste einfach auf der Konsole aus. $KomplettListe | Export-Csv -Path Desktop\Script\Bundesmitarbeiter.csv -NoTypeInformation -Encoding UTF8 -Delimiter ';' ... und so pipe'st Du Dir diese Liste in eine CSV-Datei.

... und dann nie nie wieder?? Spräche denn etwas dagegen, einfach nur die gewünschten OUs abzufragen? Also so in etwa: $OU_Liste = 'OU=Bundesuser1,OU=User,OU=Groups,DC=domäne,DC=firmadomäne,DC=de', 'OU=Bundesuser1,OU=User,OU=Groups,DC=domäne,DC=firmadomäne,DC=de' Foreach($OU in $OU_Liste){ Get-ADUser -Filter 'objectClass -eq "user"' -Properties * -SearchBase $OU } So brauchst Du nicht mehr aus dem AD abfragen als Du später benötigst. Ich würde übrigens für Dein "produktives" Script empfehlen, nur die Properties anzugeben, die Du wirklich brauchst und nicht einfach * zu benutzen. Geht meistens schneller und erzeugt nicht so viel Last auf'm DC.

Hmmm ... welchen Befehl meinst Du? Dieses Forum ist, wenn ich mich nicht sehr irre, eher für IT-Profis, die mit einem selbstgeschreibenen Script ein Problem haben. Du hast bisher leider gar nichts geliefert. Sorry, aber das sieht für mich so aus, als sollten wir Dir ein entsprechendes Script schreiben. Mit welcher Script-Technologie kennst Du Dich denn genug aus, um das Ganze umsetzen zu können? Wenn Deine Antwort jetzt lautet "mit keiner", dann bist Du hier vermutlich nicht im richtigen Forum. Wenn es um Windows Betriebssysteme geht, würde ich Dir empfehlen, Dir die Grundlagen von Powershell anzueignen. Die Einstiegshürde ist sehr niedrig und man bekommt mit relativ wenig Aufwand einen großen Nutzen. Als Einstieg kannst Du Dir ja mal den kostenlosen Video-Kurs von MS ansehen: Getting Started with Microsoft PowerShell - der ist sehr empfehlenswert für Einsteiger. Für Dein Script könntest Du dann für den Anfang mit cmdlets wie Test-Connection und Invoke-Webrequest schon mal ein bissl spielen. Ich wünsche Dir viel Erfolg.

... zeig mal her, was hast Du denn so probiert. Vielleicht brauchst Du ja nur einen kleinen Schubs in die richtige Richtung.

Ein paar Grundlagen von Powershell würden Dir bestimmt weiterhelfen. Raten ist immer ein schlechter Ratgeber. Powershell arbeitet mit Objekten. Diese kannst Du mit entsprechenden cmdlets beeinflussen. Wie testperson schon geschreiben hat, solltest Du besser Out-File anstelle von > benutzen. Vorher könntest Du mit Select-Object die Properies auswählen, die Du in Deiner Ausgabe-Datei sehen willst.

Wenn Du das ganze ein wenig "scriptgesteuerter" (gibt's das Wort überhaupt? ) gestaltest, kannst Du, nachdem das robocopy-Fullbackup gelaufen ist eine kleine Datei mit einem Zeitstempel des gerade beendeten Backups irgendwohin schreiben, und das dann von einem Script, das das differentielle Backup erledigt, auslesen und entsprechend reagieren. Die zu erledigenden Schritte sind zwar immer noch die gleichen, aber Du musst halt nicht selbst Hand anlegen. Das Ganze sollte mit Powershell mit nur ein paar Zeilen Code zu machen sein.

Warum so kompliziert? $ENV:COMPUTERNAME gibt einfach nur den Computernamen aus. Einfach mal in der Console probieren!! Edit: Was mir gerade noch aufgefallen ist: Bekommst Du keine Fehlermeldung, wenn Du den Code so ausführst, wie Du ihn oben gezeigt hast? Das eigentliche cmdlet heißt Get-ChildItem und nicht Get-ChildrenItem.

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?