BOfH_666

Was für ein nachlässig geschriebener PowerShell-Code .... "dir" ist ein PowerShell-Alias für Get-ChildItem. der Parameter -Directory teilt Get-ChildItem mit, dass es ausschließlich Verzeichnisse auflisten soll. Wenn Du auch Dateien angezeigt haben möchtest, musst Du den also weglassen. Haben wirklich einzelne Dateien separat gepflegte Berechtigungen?

... was ja aber nicht heißt, dass es wie von Zauberhand auf Zuruf funktioniert und es kein Fachwissen mehr braucht, um es einzurichten und zu betreuen. Und spätestens, wenn die Hardware im eigenen Serverraum eingerichtet ist und so lange sie ohne Fehler läuft, ist der Unterschied zwischen der Administration von Cloud-Ressourcen zu lokalen Ressourcen nicht sooo wahnsinnig groß.

.... und wenn der Preis ein starkes Kriterium ist, machens vielleicht auch einfach 10 Raspberry Pi's.

Hmmm ... denkst Du wirklich, dass das eine gute Lösung für Anwender ist, die so charakterisiert werden?

Was verunsichert Dich denn daran? ... dass der Computer das macht, was Du ihm gesagt hast? ... wie schon gesagt, wird dieser Fall im "Regelbetrieb" ja kaum auftreten. Diese Einstellung ist eher für Jobs gedacht, die lange genug laufen, um sich quasi mit der nächsten Ausführung zu überlappen. Und dafür hat man dann zur Not noch die Optionen, zu lange laufende Jobs abzubrechen.

Wenn Du die Aufgabe 1x monatlich ausführst, wie hoch ist die Wahrscheinlichkeit, dass sie noch vom letzten Monat ausgeführt wird, wenn sie für diesen Monat startet? ... wenn die Antwort "Nahezu null" ist, brauchst Du Dir über diese Einstellung ja kaum Gedanken machen, oder?

Im Zweifel nachlesen oder googlen ... anders machen wir das auch nicht https://www.powershellgallery.com/packages?q=Tags%3A"ExchangeOnline"%2C"Management" https://docs.microsoft.com/en-us/powershell/exchange/exchange-online-powershell-v2?view=exchange-ps https://www.powershellgallery.com/packages/AzureAD https://www.powershellgallery.com/packages/MSOnline

Ja. Was ist denn dabei für Dich verwirrend? Ist doch alles ziemlich gerade aus ....

Es sollte genügen, einfach in der Konsole die folgenden Befehle auszuführen: Install-Module ExchangeOnlineManagement Install-Module AzureAD Install-Module MSOnline

Und eben das zweifle ich nach wie vor an. Wenn Du Dir mal mit Get-Member die Eigenschaften dieser Property anschaust, wirst Du feststellen, dass es bereits ein String ist. $User = Get-ADUser -Identity 'IrgendEinADUser' -Properties Department $User.Department | Get-Member

Lass doch mal bitte das Write-Host weg und teste es mit einem (oder mehreren) Test-User.

Also bei mir funktioniert das hier : $users = Get-ADUser -SearchBase "OU=x,OU=y,DC=DOMAIN,DC=LOCAL" -Filter * -Properties Department foreach ($user in $users) { Set-ADUser -Identity $user.SamAccountName -Add @{extensionAttribute1 = "$($User.Department)" } }

Was soll diese Zeile denn bewirken? Write-Host Set-ADUser -Identity $user.SamAccountName -Add @{extensionAttribute1="$String"} Ich würde das "Write-Host" an dieser Stelle entfernen.

Warum? Und warum remote? Und warum machst Du es dann nicht einfach?

Nein, Du musst keine Datei zwischenspeichern. ABER ... wenn Deine Input-Daten keine validen CSV-Daten sind, werden die Ergebnisse auch wieder fehlerhalft sein. Du musst also z.B. sicherstellen, dass jede Zeile die gleiche Anzahl an Feldern hat und dass, wenn Du ein Delimiterzeichen in einem Feld hast, dieses auch mit Gänsefüßchen umschlossen ist. Es genügt Deinen Input-Content in einer Variablen zu speichern und dann mit dieser weiterzuarbeiten ... so ungefähr ... $RawInput = @' Zeile 01 "Zeile 02 Zeile 03 Zeile 04 Zeile 05 Schmitz;Harald;Schmitz@zuHause.de;123456; ;Heiner;;234567; Müller;;Mueller@zuHause.de;; Maier;Susanne;;456789; '@ -split "\r\n" $WithoutFirst5Rows = $RawInput | Select-Object -Skip 5 $WithoutFirst5Rows | ConvertFrom-Csv -Header "Nachname", "Vorname", "Email", "PersonalNummer" -Delimiter ";"

... hatte ich aber doch schon ergänzt!? ... also zumindest vor Deiner Nachricht

Bitte den Code so ausführen, wie ich ihn gepostet hatte!!!! Und das Ergebnis Array ist dann natürlich $ergebnis[3] ... usw ...

Vielleicht isses einfacher, wenn Du es als Code siehst: $ergebnis = Import-Csv -Path C:\temp\Test.csv -Header 'Nachname','Vorname','Email','PersonalNummer' -Delimiter ';' | Select-Object -Skip 5 Aber nochmal: .... Nils Ansatz wäre der um Welten professionellere!!

OK.... also prinzipiell bin ich absolut bei Nils. Wir haben hier schon öfters an Lösung von hinten durch die Brust ins Auge gebaut, die aber für die eigentlich zu lösende Aufgabe völlig unnötig waren. Davon unabhängig: Du kannst Dir doch das ganze Geraffel sparen, wenn Du die aus Deiner Excel-Datei erzeugte CSV-Datei, die ja keine Header hat, ganz normal mit Import-CSV einliest, dabei mit dem Parameter -Header, die gewünschten Header dazupackst und mit einem Select-Object -Skip 5, die ersten 5 Zeilen auslässt.

Es gibt ein Modul, mit dem Du Excel-Dateien direkt verarbeiten kannst: ImportExcel. Das macht die Sache eventuell leichter. Dafür gibt es beim cmdlet Import-Csv den Parameter -Header, mit dem man eigene Header hinzufügen kann. Ja ... quasi oben alles beantwortet ... Ach übrigens, wenn Du Code postest, diesen am Besten auch als Code formatieren (das ist der Button "</>" oben im Editor)

So ... ich hab's nochmal gründlich durchdacht und glaube den (Denk)-Fehler gefunden zu haben. Du möchtest gar nicht $Group.FullName haben. Das wären ja auch wieder alle Dateien einer Gruppe. Du wolltest ja nur die Aktuellste, richtig? Also brauchen wir das Ergebnis der "Gruppen-Auswertung" ... also statt ... foreach ($Group in $SeparatedGroupList) { $Group.Group | Sort-Object -Property VersionInt | Select-Object -Last 1 -Property PartlyFileName, DocumentKey, VersionInt, FullName } besser das hier: foreach ($Group in $SeparatedGroupList) { $LastVersionInt = $Group.Group | Sort-Object -Property VersionInt | Select-Object -Last 1 -Property PartlyFileName, DocumentKey, VersionInt, FullName $LastVersionInt.FullName } Besser so?

Das hat meiner Meinung nach wenig Sinn, wenn der "Fehlerfaktor" legitim in den Verzeichnissen arbeiten soll. Nur weil nochmal eine Nachfrage "Bist Du sicher?" kommt, heißt das ja nicht, dass keine Fehler mehr passieren - dafür kennen wir alle mehr als ausreichend Beispiele. Für zu veröffentlichende Daten könnte ein "Vier-Augen-Prinzip" eine gewisse Sicherheit liefern. Es wird also erst veröffentlicht, wenn mindestens zwei verschiedene "Fehlerfaktoren" zugestimmt haben.

Na, so toll war sie dann wohl offenbar nicht ... Das ist üblicherweise nicht nötig. Wenn man's doch unbedingt möchte, dann ganz normal mit "$MeineNeueSupiVariable = $Group.FullName". Da es fast immer darum geht, mehrere gleichartige Operationen an gleichartigen Objekten auszuführen und wir dabei entweder die Pipeline-Laufvariable $_ oder $PSItem oder bei einer foreach-Schleife die jeweilige definierte Schleifenvariable zur Verfügung haben, können wir diese bereits existierenden Variablen mit all ihren Properties benutzen. Wir würden normalerweise nicht das Array mit allen Elementen ($SeparatedGroupList) benutzen, sondern die Schleifenvariable - in dem Beispiel wäre das also $Group. Demzufolge wäre dann $Group.FullName der Quell-Pfad der in der Schleife aktuell bearbeiteten Datei. Häufig hilft es, wenn man sich die jeweiligen Objekte und Properties einfach auf der Konsole ausgibt. Im Zweifel mit ein bissl "Eye-Candy" drumrum. Beispiel: Get-ChildItem -Path "$env:SystemRoot\system32" -Filter *.dll | Select-Object -Skip 10 -First 5 | ForEach-Object { "Der BaseName der aktuellen Datei ist '$($_.BaseName)', die Produktversion ist '$($PSItem.VersionInfo.ProductVersion)' und die Größe beträgt '$($_.Length)' Bytes" } Ich habe mir angewöhnt, bei solchen Ausgaben, den eigentlichen Inhalt der Variablen in einfache Gänsefüßchen einzuschließen. So würde man führende oder folgende Leerzeichen bemerken, falls das relevant ist. Und man sieht auch, wenn die Variable im Zweifel leer ist, weil dann ein doppeltes einfaches Gänsefüßchen ausgegeben wird.

Wie wäre es, die Zugriffsrechte entsprechend zu gestallten, sodass nur Personen schreibenden Zugriff auf das Verzeichnis haben, die wissen was sie tun?

Was hoffentlich heißt, dass Du trotzdem weitermachst .... Da gibt's generell zwei Ansätze: 1. Indem Du die Funktion oder den Code ausführst, die oder der den Wert gewünschten ausgibt. Das ist normalerweise der Weg, wenn man einen Wert nur einmal braucht. 2. Indem Du den gewünschten Wert in einer Variablen speicherst und diese statt des Wertes verwendest. Das ist der Weg, wenn man einen Wert mehrfach braucht. In PowerShell arbeiten wir mit Objekten und deren Eigenschaften. Wenn Du also einen Befehl ausführst und das Ergebnis-Objekt in der Variable $Objekt speicherst, kannst Du auf die Eigenschaft1 mit der sogenannten "Dot-Notation" $Objekt.Eigenschaft1 darauf zugreifen. Sollte das Ergebnis-Objekt mehr als eine Instanz enthalten, kann man mit einem Index die einzelnen Elemente adressieren - also z.B. $Objekt[0].Eigenschaft1. So, den Rest der Grundlagen holst Du Dir aber bitte aus einem Buch oder Tutorial oder Erklärvideo auf Youtube oder so. Es gibt im Netz zum Thema PowerShell mehr als ausreichend Material. Sehr viele Fragen - auch Anfängerfragen - werden z.B. auf StackOverflow beantwortet. Dort findest Du also schon vieles inklusive Beispielen erklärt.