BOfH_666

vor 1 Minute schrieb addy0604:

Leider kommt wieder die altbekannte Meldung: dgst: Can only sign or verify one file.

Ich denke das wird mit dem Schalter -passin zusammenhängen.

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?

vor 52 Minuten schrieb addy0604:

Grundsätzlich hast du natürlich recht, das immer mehr mit Powershell gemacht wird. Leider, ich gestehe, ich bin eingefleischter Mausschubser und finde Powershell zum... übergeben, sorry.

Ich finde da echt keinen Draht hin. Aber auch Grundlagen (selbst wenn ich sie hätte) verblassen, wenn man einmal im Jahr ein kleines Script braucht. Eine Batchdatei ist für mich halbwegs nachvollziehbar, Powershell ist für mich ein Sack voll Hieroglyphen und bin da völlig überfordert.

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

vor 3 Minuten schrieb benji84:

Leider habe ich mich mit dem Thema Powershell bisher nur sehr rudimentär befasst..

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 ...

vor 13 Minuten schrieb NilsK:

..... Geht auch, ist nur deutlich mehr Aufwand.

.... 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.

vor 9 Minuten schrieb Gu4rdi4n:

Ist das so sinnvoller als mit ner schleife?

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. 

vor 26 Minuten schrieb Gu4rdi4n:

Da ich mit Powershell noch nicht so viel am Hut habe,

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.

vor 11 Minuten schrieb NorbertFe:

WSUS Package Publisher. Ein Tool für die Bereitstellung eigener Updatepakete über den WSUS.

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. 

vor 7 Minuten schrieb otonashi:

... einfach für den Lernefekt

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.)

vor 9 Minuten schrieb otonashi:

Ja das Homeverzeichnis soll auch nur einmal erzeugt werden aber dann muss ja die Freigabe oder so...

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?

vor 43 Minuten schrieb g2sm:

Jedoch denke ich mir gerade, dass ich einfach nur searchbase falsch verstehe. Kann es sein, dass dieser einfach immer recursive sucht und ich immer angeben muss, dass er nur in dieser angegeben OU mit hilfe von searchscope suchen soll?

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.

Zitat

Würde mich aus verschiedenen Gründen nicht auf den Extendet Support verlassen.

Welche Gründe wären denn das?