BOfH_666

Wenn Du's doch mal mit Powershell probieren möchtest ... Get-CimInstance -ClassName CIM_LogicalDisk -OutVariable Disks switch ($Disks.VolumeName) { 'Backup' { 'Befehle für Laufwerksname "Backup"' break } 'Daten' { 'Befehle für Laufwerksname "Daten"' break } 'Windows_os' { 'Befehle für Laufwerksname "Windows_os"' break } default { 'Befehle die generell ausgeführt werden' break } }

Die Frage ist etwas vage. Mit welcher Script-Technologie kennst Du Dich denn genug aus? bzw Wobei genau brauchst Du da Hilfe? Wenn ich frech sien wollte, würde ich sagen: ..... mit einem Script!! Wenn ich etwas empfehlen sollte, würde ich Powershell empfehlen.

Was genau fehlt Dir denn dabei? Edit: Ich gehe mal davon aus, dass Du wenigstens grundlegende Kenntnisse in Powershell hast und auch weißt, was String-Operationen sind. Richtig?

... das sollte auch nur ein Witz und kein ernstgemeinter Rat sein ... deshalb der Smiley dahinter. Dazu wird Dir wohl nur Microsoft Auskunft geben können. Wobei ich vermuten würde, dass sie nicht mal das machen würden, sondern eher sagen "Nimm die aktuelle Version!" Schreibst Du jedes mal ein neues Log oder überschreibst Du das vorhandene immer? Hast Du schn mal versucht auf Unicode umzustellen? ... oder das neue Log an das alte anzuhängen?

Dann hilft nur noch eins ... den Zielordner vorher leer machen ....

Aber die neuere Version von robocopy funktioniert genau wie die alte. Ich habe es gerade nochmal auf einem W2K12 R2 getestet - incl. dem Datum-Dingens - und es funktioniert genau wie erwartet. Es liegt bestimmt nicht an der robocopy-Version.

Der Schalter ist meines Wissens immer noch der gleiche. Aber warum willst Du denn Dateien, die schon da sind, nochmal verschieben? Das ist doch redundant!? Der robocopy-Befehl, den Du oben angegeben hast (bis auf das Datum-Dingens) funktioniert bei mir genau wie erwartet.

Der Parameter -Identity erwartet entweder einen Distinguished Name, eine GUID, eine SID oder einen sAMAccountName. Wenn Du was anderes lieferst, gibt es eine Fehlermeldung.

Ich gehe mal davon aus, dass Du mit Container und Lokation jeweils Organisationseinheiten meinst - in english Organizational Units oder OUs genannt - richtig? Der "Pfad" zur OU wie Du ihn beispielhaft zeigst nennt sich CanonicalName. Dieses Attribut gehört nicht zu den standardmäßig ausgegebnen Attributen, weshalb Du es explizit mit angeben musst ... also so ungefähr: Get-ADGroupMember -Identity Gruppenname | Get-Aduser -Properties CanonicalName | Select-Object -Property Name,CanonicalName

Das rauszufinden und "zu reparieren" nennt sich dann "Debuggen". Ich würde mal auf fehlende Berechtigungen tippen. Viele Dienste lassen sich mit normalen administrativen Rechten nicht einfach ändern. Ich habe es nochmal getestet - die Syntax ist korrekt und funktioniert. Um herauszufinden, was noch fehlt, kann man bei fast allen cmdlets ein paar der "Common Parameters", wie -Debug oder -Verbose anhängen. Wenn Du Glück hast, erhältst Du zielführende Informationen.

N' bissl übersichtlicher wär's vielleicht so: $ServiceListe = @( 'AxInstSV', 'bthserv', 'CDPUserSvc', ....... 'WpnUserService', 'XblAuthManager', 'XblGameSave' ) Get-Service -Name $ServiceListe | Where-Object -Property Status -Value Running -EQ | Stop-Service -PassThru | ForEach-Object { Set-Service -Name $_.Name -StartupType Disabled } !! Ich hab die Liste der Dienste mal etwas verkürzt - das Prinzip sollte klar sein, oder?

Hmmm .... Du bist hier im Scripting Forum. Ist es denn wirklich das Script, was das Problem auslöst? Im Zweifel könntest Du Dir den Verlauf der geplanten Aufgabe mal ansehen oder vielleicht mal in's Event-Log schauen. Wenn das Problem wirklich vom Script kommen sollte, würde es vermutlich auch helfen, wenn man wüßte, was das Script macht bzw. wenn man sich das Script mal ansehen dürfte. Alles andere wäre nur Raten. Übrigens: Ich bin einfach mal davon ausgegangen, dass der Windows Server 2007 nur ein Tippfehler war - ansonsten wüßte ich, was der Fehler ist!

Supi.

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.