BOfH_666

Ich würde ja eher auf die Übergabe des Dateinamens der zu bearbeitenden Datei tippen. Was passiert denn, wenn Du das Kommando manuell mit einem spezifischen Dateienamen in einer Powershell-Konsole eingibst?

Wenn Du die Grundlagen einer Technologie einmal richtig gelernt hast, dann hilft Dir das auch weiter, wenn Du sie nur selten benutzt - 'ist wie Fahrradfahren - Du fällst ja auch nicht um, nur weil Du mal n' halbes Jahr nicht gefahren bist. Ein guter und sogar ansatzweise unterhaltsamer Einstieg gelingt mit dem kostenlosen Videokurs der Microsoft Virtual Acadmy - Getting Started with Microsoft Poswershell. Das Anschauen der enthaltenen Videos dauert nur ca 8-10 Stunden, aber es wird Dir die Augen öffnen und vielleicht in Zukunft eine Menge Deiner Arbeitszeit einsparen weil Du viele Sachen einfach automatisieren kannst. Wenn man des Englishen mächtig ist, ist Powershell-Code in Grenzen quasi selbsterklärend, weil eben keine Hieroglyphen benutzt werden, wie das z.B. bei machen Linux-Tools üblich ist oder war. z.B. braucht man cmdlets wie Test-Path oder Get-Process oder Get-Service nicht wirklich aufwändig erklären, oder? Nun zum Script: Wie Dukel schon geschrieben hat: Wenn die Openssl.exe nicht in der Umgebungsvariable "Path" zu finden ist, musst Du den kompletten Pfad angeben, inclusive der Erweiterung. Die Parameter -Wait und -NoNewWindow zu ergänzen kann auch nicht schaden. -NoNewWindow leitet die Konsolenausgabe von OpenSSL in die Powershell-Konsole um und -Wait wartet einfach mit der Ausführung bis die Aufgerufene externe Anwendung (also OpenSSL in diesem Fall) fertig ist und die Kontrolle wieder abgegeben hat.

Format-cmdlets sollten IMMER als LETZTES in der Pipeline kommen. Alles andere macht normalerweise keinen Sinn. Wenn Du ein Format-cmdlet wie Format-Table benutzt, machst Du aus den Objecten, die üblicherweise von Powershell die Pipeline entlanggereicht werden, Pixel auf auf Deinem Bildschirm, die nicht mehr vernünftig weiterverarbeitet werden können. Measure-Object erwartet ein Objekt bzw. Objekte - wenn es die nicht bekommt, zählt es, was es eben zählen kann ... vermutlich die Zeilen inclusive Leerzeilen. Edit: Noch'n allgemeiner Tipp: Gerade in der Konsole ist es fast immer hilfreich, quasi an jede Pipeline-Etappe ein -ov a oder -ov b oder -ov c usw. anzuhängen. Das macht die Zwischenschritte als Variablen verfügbar und erleichtert häufig die weitere Verarbeitung oder Verfeinerung der Daten. -ov ist dabei der Alias für -OutVariable und a oder b oder c der Variablenname. zB.: get-aduser .... -ov a | ft ... gibt Dir die gefundenene ADUser als Tabelle aus. aber wenn Du auf die "Original-Daten" zugreifen willst, kannst Du einfach $a aus geben und z.B. mit $a.count ... die Anzahl ausgeben.

Hmmm ... wenn Du noch ne Weile in "Windows-Umgebungen unterwegs sein möchtest", nimmst Du Dir bei nächster Gelegenheit mal bitte etwas Zeit und schaffst Dir die Grundlagen von Powershell drauf. Ich glaube, es wird sich für Dich auszahlen und man kommt in Zukunft einfach nicht mehr dran vorbei. Bei der Zuweisung der Variablen gehören die "Werte" in Anführungszeichen - so wie es oben in meinem Code-Beispiel zu sehen ist.

Hmmm ... also ich bin kein Freund von Batch/cmd und auch nie richtig warm geworden damit, aber wenn ich das nicht falsch verstanden habe, sollte es mit Powershell ungefähr so funktionieren: $SourcePath = 'Pfad zum Ordner mit XML-Dateien' $CertFile = 'Zertifikat.pem' # am Besten vermutlich inclusive Pfad Get-ChildItem -Path $SourcePath -Filter *.xml | ForEach-Object { $outfile = $_.BaseName + '.sig' Start-Process -FilePath openssl -ArgumentList "dgst -sha512 -binary -out $outfile -sign $CertFile $_.FullName -passin pass:""hier das Passwort""" } Probier ma! (natürlich erstmal nur an 2 oder 3 Test-XML-Dateien)

... und wenn's was Regelmäßigeres werden soll, kannst Du Dir hier schon mal ein paar Anregungen holen: https://www.netz-weise-it.training/weisheiten/tipps/item/417-mehrfach-umbenennen-mit-powershell-rename-item-und-regulaeren-ausdruecken.html Na dann wird's aber jetzt höchste Zeit!! Schau mal hier ... https://mva.microsoft.com/en-us/training-courses/getting-started-with-powershell-3-0-jump-start-8276?l=r54IrOWy_2304984382 da kannst Du Dich ein paar Stunden berieseln lassen und lernst nebenbei auch noch die Grundlagen von Powershell ...

.... und damit der Aufwand für so etwas nicht zu groß wird, gibt es das ImportExcel-Modul von Douglas Finke... wenn ich nicht irre, kann man da auch Fomratierungen mitgeben.

Das kommt auf Deine Anforderungen und auf Deine Fähigkeiten an. Aber wenn das den Job erstmal erledigt - super. Ich würde aber dringend empfehlen, sich erstmal die Grundlagen draufzuschaffen. Der Videokurs in der MVA dauert nur ca 8 - 10 Stunden und bildet schon mal eine solide Grundlage.

Wie schade ... ein guter Startpunkt ist der kostenlose VideoKurs in der Microsoft Virtual Academy - Getting Started with Microsoft Powershell. Vernünftig formatiert und die Aliasse ausgeschrieben sieht der Code so aus: Get-ChildItem *.ini | ForEach-Object { if (-not(Test-Path (".\config_bak\" + $_.name))) { Copy-Item $_ .\config_bak -passthru | Select-Object -Property name } }

Schau mal hier: https://stackoverflow.com/questions/42249433/signing-all-xml-files-in-directory-using-batch-script Man braucht das Rad ja nicht immer wieder neu erfinden.

Mit dem Vergleich-Operator -contains prüfst Du ob ein einzelnes Element in einem Array von Elementen enthalten ist. Dabei müssen, bis auf die -Groß-Klein-Schreibung, die Elemente identisch sein, um einen positiven Treffer zu erzeugen. $a = 'Eins','zwei','DREI','vIeR','FuEnF','sechs' $b = 'drei' $a -contains $b sollte ein $true zurückliefern. Während zum Beispiel ... $a = 'Eins','zwei','DREI','vIeR','FuEnF','sechs' $b = ' drei' $a -contains $b ... ein $false als Ergebnis liefert. (Man beachte das zusätzliche Leerzeichen). Hast Du überprüft, ob Dein Trimmen, die von Dir erwarteten Resultate liefert? Gibt es ein Muster bei den Gruppen, die nicht erkannt werden? Unabhängig davon: Get-ADGroup -Filter * -Properties * Diese Zeile saugt ALLE Gruppen mit ALLEN Eigenschaften aus Deinem AD. Das dauert länger als nötig und erzeugt (wenigstens kurzzeitig) unnötig große Last auf dem AD-Controller. Empfehlenswert wäre, die Suche mittels -SearchBase auf die entsprechende OU zu begrenzen und unter -Properties nur die zusätzlichen Eigenschaften auszugeben, die wirklich im weiteren Verlauf des Scripts benötigt werden.

Danke.

WPP sagt mir so auf Anhieb erstmal nix. Aber wenn Du schon ein Tool zur Software-Verteilung einsetzt, wird es am einfachsten sein, wenn Du dessen Mechanismen benutzt, um die MSI-Installation zu starten und danach die Dateien zu kopieren und die Einstellungen einzustellen, die die installierte Software benötigt. Wenn Du Dich mit der Materie nicht auskennst und auch keine Zeit/Lust/Möglichkeit hast, Dir das draufzuschaffen, solltest Du es Dir so einfach wie möglich gestallten - das macht die Wartung und (falls nötig ) die Fehlersuche einfacher. Warum willst Du denn eigentlich die zusätzlichen Dateien und Einstellungen unbedingt mit in die MSI-Datei packen? Bringt das einen messbaren Vorteil? Falls nicht - lass es!

Wenn Du schon mit SuperOrca fummelst, weißt Du bestimmt, dass man mit *.mst-Dateien (Transforms-Dateien) eine MSI Installation an die eigenen Bedürfnisse anpassen kann. Google einfach mal danach.

Dann fang doch vielleicht mit den Grundlagen von Powershell an. Dann verstehst Du auch, warum das Script so reagiert, wie es das tut und Du lernst, wie Du das debuggen kannst, bzw. wie Du es verändern musst, um das von Dir gewünschte Verhalten zu erhalten. Und Du lernst auch das integrierte Hilfe-System zu benutzen usw. .... Ein guter und sogar einigermaßen unterhaltsamer Start gelingt relativ einfach mit dem kostenlosen Video-Kurs in der Microsoft Virtual Academy - Getting Started with Powershell. (Keine Ahngst - es geht dort eigentlich um Powershell 3 aber die Grundlagen haben sich nicht geändert.)

Sorry, aber das klingt alles etwas verworren. Von wem hast Du denn so eine Aufgabe bekommen? Normalerweise wird das Homeverzeichnis und die dazugehörige Freigabe nur einmal - EIN EINZIGES MAL - erzeugt. Das Verbinden des Benutzers mit dieser Freigabe und Zuweisung eines Laufwerksbuchstabens geschieht mittels GPOs - da brauchst Du auch kein Script. Wir haben 2018! - Logonscripte sind kaum noch notwendig.

Du kannst das System anweisen, erweiterte Logs zu schreiben und diese dann auswerten. https://blogs.technet.microsoft.com/gladiatormsft/2014/03/17/enabling-advanced-windows-installer-logging/ Aber warum möchtest Du Dich denn in den INstallationsprozess "einklinken"?

Hmmm ... nicht so ergiebig, oder? ... vielleicht bist Du mit solch einer Frage bei StackOverflow besser aufgehoben. Wenigstens findet man dort schon mal die ein oder andere bereits gestlelte Frage mit dem Thema PowerApps.

Hmmm ... es geht Dir also quasi darum, hierarchische Daten darzustellen und keine strukturierten. Da ist eine tabellarische Anzeige sowieso eher ungeeignet. Wenn sich die Anzahl der Desktops pro Server in Grenzen hält, könnte man die Daten eventuell noch serialisieren. Also quasi sowas hier: Server ==> Destop1 ==> Tag1, Desktop2 ==> Tag2 Server2 ==> Desktop3 ==> Tag3, Desktop4 ==> Tag4.

Ich bin mir nicht sicher, ob ich das richtig verstanden habe. Vielleicht wäre auch ein kleine Beispiel oder ein Stück Code von Dir hilfreich gewesen. Soll das dynamisch sein, oder soll es nur übersichtlicher im GridView angezeigt werden?

Yep. Eben genau so, wie es in der Hiilfe beschrieben wird!! Es wäre sehr empfehlenswert, wenn Du Dir IMMER wenn Du ein cmdlet das erste Mal benutzt, die KOMPLETTE Hilfe dazu anschaust - inklusive der Beispiele. Häufig werden damit bereits viele Anfängerfragen (und manchmal auch Profi-Fragen) beantwortet.

Das kann ich quasi nicht beantworten. Ich kenne ja Deine Infrastruktur nicht. Das "Standard-Replikations-Interval" zwischen "benachbarten" DCs ist wohl 45 min. wenn ich nicht irre. Ich würde auch erwarten, dass nach 3 Stunden eine Änderung in der Domäne "durchrepliziert" ist. ... 'gibt aber durchaus Optionen, die ein solches Verhalten plausibel erklären könnten.

ooops ... hatte ich übersehen ... die Select-Anweisung müsste so aussehen: $users = Get-Aduser -Filter {title -eq '...'} -SearchBase "....." | Select-Object -ExpandProperty SamAccountName ... und dann kannste im foreach auch nur $users benutzen.

Versuch ma .... foreach ($MA in $users.sAMAccountName){ ...

Sorry, aber aus professioneller Sicht ist das schlicht und einfach Quatsch? Es ist klar definiert, was Standard- und was Extended Support beinhaltet. In der Standard-Support-Phase werden Feature- UND Security-Updates geliefert. In der Extended-Support-Phase werden nur noch Security-Updates geliefert. Wenn man mit den enthaltenen Features zufrieden ist, spricht Nichts dagegen, den Lebenszyklus eines Produkts auszunutzen. Welche Gründe wären denn das?