addy0604

Hallo Nobby aus Bremen, du hattest ja geschrieben, dass das CU13 auch dotNET 4.8 unterstützt, also in meinen Augen nicht uuuuunbedingt notwendig. Deshalb hab ich zuerst das CU13 installiert, danach dotNET 4.8 (weil ich es eh schon mal heruntergeladen habe) und zum Schluss über die Windows Updates das Security Update. Der Server läuft wie geschmiert, kann keine Auffälligkeiten feststellen... Grüße Matthias

Hmm, eigentlich hätte schon ein simpler Neustart gereicht. Hab trotzdem das CU13, dotNET 4.8 und das Security Update für CU13 installiert. Kurioserweise hatte ich nach dem Security Update und dem anschließenden Neustart das gleiche Problem wieder. Ich brauchte wieder einen zusätzlichen Neustart, damit wieder alles funktioniert. Egal, Hauptsache es geht nun :) Besten Dank und schöne Grüße Matthias

Dachte ich mir fast ;) Dann installiere ich mal das CU13 heute Abend. Werde morgen berichten... Grüße Matthias

Hallo zusammen, ich hab eben ein dickes Problem auf dem Exchange bemerkt, das mir Sorgen macht. MS Exchange 2016 CU12 auf Windows 2012 R2 Am 11.07. hab ich das letzte Postfach eines neuen Mitarbeiters angelegt. Alles normal. Am 18. und 19.07. hab ich Sicherheitsupdates für Windows Server 2012 R2 und Flashplayer und das Security Update for Exchange 2016 CU12 KB4503027 installiert. Gestern am 07.08. hab ich Sicherheitsupdate für Windows Server 2012 R2, DotNET, IE11 und das Security Update for Exchange 2016 CU12 KB4509409 installiert. Nach den Installationen schaue ich in der Regel nach, ob ein- und ausgehende Mails gehen und ob ich auf die Konsole zugreifen kann. Lief eigentlich alles wie geschmiert. Heute Nachmittag wollte ich nun ein Postfach über das EAC bearbeiten. Das entsprechende Popup-Fenster geht zwar auf, aber die Felder sind leer und auch die Einträge Allgemein - Postfachnutzung etc lassen sich nicht anklicken. Im Eventlog gibt es die IDs 4 und 21 MSExchange Control Panel mit dem Fehlerhinweis: Microsoft.Exchange.Management.ControlPanel.BadRequestException: Die vom Browser gesendete Anforderung war ungültig. ---> System.Exception: 'ToolkitScriptManager' could not generate combined script resources file. Das gleiche bei den Verteilergruppen. Ich sehe zwar alle Gruppen, aber wenn ich eine markiere und auf bearbeiten gehe, bekomme ich nur ein inaktives Popup-Fenster Hat mir da eins von den Updates was zerschossen? Ist es besser zu versuchen die letzten Updates zu deinstallieren? Oder gleich das CU13 drüber installieren? Bin momentan ratlos? Was meint ihr? Grüße Matthias

Nachtrag nur der Vollständigkeit halber... Ich bekomme ja jeden Tag eine CSV-Datei mit aktuellem Datum im Dateinamen. Der sieht dann so aus: Neukunden_20190605_1.csv Deshalb hab ich den Import-csv-String noch mit einer Variable umgestrickt: $Filename = 'Neukunden_' + [datetime]::today.tostring('yyyyMMdd') + '_1.csv' Import-Csv -Path "c:\test\signatur\$Filename" -Delimiter ";" | foreach { $Ausgabe = ($_."Counterparty Number") $Datei = $Ausgabe + "*Contract.pdf" Get-ChildItem -Path c:\test\signatur\ -Include $Datei -Recurse | Copy-Item -Destination c:\test\test1 } Die Write-Host Einträge werde ich dann wieder rausnehmen. War ja nur zur Kontrolle in der ISE... Grüße Matthias

Hallo Sunny, yep, ein Plus-Zeichen musste noch dazwischen, dann passt es. Hier noch mal der ganze Code: Import-Csv ".\test1.csv" | foreach { $Ausgabe = ($_."Counterparty Number") $Datei = $Ausgabe + "*Contract.pdf" Write-Host "$Datei" Get-ChildItem -Path c:\test\signatur\ -Include $Datei -Recurse | Copy-Item -Destination c:\test\test1 } Das passt prima. Besten Dank und schöne Grüße Matthias

Hmmm... also Teile habe ich hinbekommen, aber ein Ganzes ist es noch nicht geworden... Das ist der Inhalt der CSV-Datei, von der ich nur die "Counterparty Number" brauche: Counterparty Number;Last Name;First Name;Entry Date 9701278;Schubert;Heinrich;29.03.2019 9701138;Kowalczyk;Klaus;29.03.2019 9700808;Markovic;Walter;29.03.2019 Die foreach-Schleife habe ich so gebastelt: Import-Csv ".\test1.csv" | foreach { $Ausgabe = ($_."Counterparty Number") Write-Host "$Ausgabe"} Dann bekomme ich zumindest das angezeigt: 9701278 9701138 9700808 Um die PDF-Datei in den Unterordnern zu finden und zu kopieren hab ich es so gelöst und funktioniert auch soweit: Get-ChildItem -Path c:\test\signatur\ -Include 9700106*Contract.pdf -Recurse | Copy-Item -Destination c:\test\test1 Die hier fest eingetragene Kundennummer "9700106" muss allerdings dann durch die Nummer "Counterparty Number" aus der CSV-Datei ersetzt werden. Aber wie bekomme ich die beiden Sachen jetzt miteinander verbunden, das im Get-Childitem-String statt der statisch eingetragenen Nummer die Variable $Ausgabe aus der foreach-Schleife auftaucht? Da hängt es bei mir an der Syntax. Kann man den Get-Childitem-String da überhaupt so einbauen? Oder gibt es eine bessere Lösung? Grüße Matthias

Schau ich mir gleich mal an... mal sehen ob ich was gestrickt kriege... Vielen Dank schon mal. Gruß Matthias

Hallo Zusammen, meine Scripting-Kenntnisse sind leider sehr bescheiden, deshalb weiß ich momentan nicht, wie ich an mein Problem am besten herangehe. Folgende Situation habe ich... Ich habe auf dem Server ein Verzeichnis, in dem täglich automatisiert Unterverzeichnisse erstell werden und in diesen landen dann einer Reihe von PDF-Dateien. Die Namen der PDF-Dateien beginnen alle mit der Kundennummer und danach eine Beschreibung des Inhaltes, z.B. Vertrag, Vertragsentwurf, Vertrag-unterzeichnet etc. Nun bekomme ich jeden Tag eine Excel-Datei (CSV ist auch möglich), wo in der ersten Spalte die Kundennummer steht. Jetzt sollen alle PDF-Dateien, die mit der Kundennummer in Spalte 1 der Excel-Datei beginnt und mit "Vertrag-unterzeichnet" endet, in ein separates Verzeichnis kopiert werden. Mit Powershell wird es wohl irgendwie gehen, aber damit hab ich mich noch nicht so viel beschäftigt. Geht so was auch mit einem Makro? Und kann man das dann auch per Aufgabenplanung ausführen? Bin für jede Hilfe dankbar... Grüße Matthias

Bei dem Pentest ging es lediglich darum von extern aus dem Internet zu prüfen, welche Schwachstellen die Systeme aufzeigen. Er hat uns lediglich darüber zu informieren und eine Einschätzung über die Risiken und Eintrittswahrscheinlichkeiten aufzuzeigen. Was wir mit den Informationen machen ist dann nicht sein Bier. Und auch wenn TLS 1.0 in der "üblichen Praxis" nicht mehr genutzt wird, so besteht zumindest die theoretische Möglichkeit. 100%ige Sicherheit gibt es sowieso nicht, aber man sollte zumindest versuchen, die Risiken im akzeptablen Rahmen zu minimieren.

Nee oder... ähm, guten Morgen... die Zahl dort im Link ist die KB-Nummer? Da wäre denen kein Zacken aus der Krone gefallen, wenn sie das auf der Seite noch mal erwähnt hätten... Naja, egal, wenn damit wirklich das Update KB3140245 gemeint ist, dann ist es schon knapp 3 Jahre alt und auch schon per WSUS im Netzwerk verteilt. Ich hab gestern Abend die Reg-Datei getestet und auf meiner Testbüchse hat das prima funktioniert. Ich werde die Reg-Datei nun über die Gruppenrichtlinien verteilen und am nächsten Wochenende das TLS 1.0 auf dem Exchange deaktivieren. Vielen herzlichen Dank für die Hilfe Und ja, auch um das CU12 werde ich mich bei Gelegenheit kümmern Grüße Matthias

Welches Update meinst du? Auf der Microsoft-Seite sehe ich nur: To apply this update, the DefaultSecureProtocols registry subkey must be added. Note To do this, you can add the registry subkey manually or install the "Easy fix" to populate the registry subkey. Das liest sich für mich so, als wenn ich entweder die Einträge manuell vornehme oder automatisch von einem "Easy fix" eintragen lasse. Es ist zwar noch von einem hotfix-installer die Rede... Note The hotfix installer doesn't add the DefaultSecureProtocols value. The administrator must manually add the entry after determining the override protocols. Or, you can install the "Easy fix" to add the entry automatically. ... aber einen Download-Button oder eine KB-Nummer hab ich nicht gefunden... oder bin ich blind? Ich habe jedenfalls mal diese Einträge für das Reg-File zusammengestellt: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings] "SecureProtocols"=dword:00000a80 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings] "SecureProtocols"=dword:00000a80 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] "DefaultSecureProtocols"=dword:00000a00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] "DefaultSecureProtocols"=dword:00000a00

Wie Nils schon richtig vermutet hat, hat der Pentester uns einfach nur darauf hingewiesen, das TLS 1.0 noch aktiv ist. Also hab ich es mal abgeschaltet, ist schließlich auch Teil von diversen Anleitungen für das "Härten" von Exchange, und bin daraufhin auf das oben genannte Problem gestoßen. Klar könnte ich es bei TLS 1.0 belassen, funktioniert ja, aber es würde mir bei jedem Test wieder vor die Füße fallen, und so ein klein bissl Ehrgeiz hat man ja auch noch... Ich hab mir mal die Registry-Key von der Microsoft-Seite herausgeschrieben und eine Reg-Datei gebaut. Ich teste das heute Abend mal und gebe euch morgen Bescheid... Grüße Matthias

Hmmm, ich bin mal blauäugig davon ausgegangen, das Win7 auch TLS 1.1 und TLS 1.2 verwendet, wenn man schon in den Internetoptionen einen Haken bei "TLS 1.1 verwenden" und "TLS 1.2 verwenden" setzen kann. Dem scheint ja nicht so zu sein... ich schau mir den Artikel von Microsoft mal genauer an... vielen Dank schon mal für den Tipp

Hallo zusammen, ich bin momentan etwas ratlos und weiß nicht so richtig wo das Problem sein soll. Wir haben von einem Dienstleister einen externen Penetrationstest durchführen lassen. Der hat angemosert, das auf dem Mail-Server noch TLS 1.0 aktiv ist. Also hab ich es einfach mal über die Registry deaktiviert. HKLM\System\CurrentControleSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.0\Server - DisabledByDefault 1 - Enabled 0 Nach einem Neustart war keine Verbindung mehr vom Outlook 2016 Client mehr zum Server möglich. Auch das Löschen des Profils und neu Hinzufügen klappt nicht: Es steht keine verschlüsselte Verbindung mit Ihrem E-Mail-Server zur Verfügung. Mit einem Klick auf weiter kommt die Meldung: Probleme beim Herstellen einer Verbindung mit ihrem Konto.... Wenn ich die Änderungen in der Registry rückgängig mache läuft alles wieder reibungslos wie bisher. Hier mal meine Umgebung: Ganz normale Windows-Domäne. Seit letzten Sommer haben wir einen Exchange 2016 mit CU10 auf Windows Server 2012 R2 (Migration von Exchange 2010) Alle Clients laufen auf Windows 7 mit Office 2016 HB bzw. Standard. Autodiscover läuft normal, Verbindungsstatus zeigt keine Auffälligkeiten, Protokoll http, Verschlüsseln ssl etc. Ich habe gerade gesehen, das auf den Clients noch TLS 1.0 aktiv ist. Kann das damit zusammen hängen? Ich hatte es vor einigen Monaten mal per GPO ausgeschaltet. Da es einige Zugriffsprobleme zu internen und externen Seiten gab hatte ich es wieder aktiviert... Grüße Matthias

Nee oder? Ich krieg die Kriese.... wieso funktioniert das nun plötzlich... Ich hab mir die Scripte mal angeschaut und noch mal durchprobiert. Es liegt echt daran, das die Parameter in einer bestimmten Reihenfolge angeordnet sein müssen. An die Möglichkeit hab ich nicht gedacht und ist auch nirgends extra erwähnt worden. Ich hab dein Script vom letzten Donnerstag übernommen und damit experimentiert. Dort war hinter -out und -sign immer erst die XML-Datei und zum Schluss der Schalter -passin angegeben. Auf die Idee, die Reihenfolge der Schalter mal zu ändern, bin ich auch nicht gekommen. Du hast nun den Schalter -passin direkt hinter -sign gesetzt und zum Schluss die zu signierende XML-Datei... und schon geht es.... kleine Ursache, große Wirkung... 1000 Dank, das du so hartnäckig warst... ihr seid echte Profis Beitrag kann erfolgreich geschlossen werden. Grüße Matthias

Hallo Zusammen, ich hab mir das am Wochenende noch mal angeschaut. So wie ich das verstanden habe, wird der Schalter -passin genutzt, um ein Zertifikat mit Kennwort mittels openssl zu erstellen. Zusammen mit -dgst funktioniert das nicht. Ich hab auch keine Möglichkeit und kein Argument gefunden, in dem ich das Kennwort irgendwie automatisiert mitgeben kann. Wenn ich -dgst -sha512 -binary -out $outfile -sign $CertFile $_.FullName normal ausführe, werde ich nach dem Kennwort gefragt. Sobald ich aber irgendein weiteres Argument hinzufüge, in welcher Syntax auch immer, auch wenn es nur ein schnödes -x ist, kommt sofort die Meldung: dgst: Can only sign or verify one file. Wenn der Schnaps demnächst nach Eisen schmeckt, nicht wundern, ich hab die Flinte in den Korn geworfen... Trotzdem besten Dank Matthias

Hmpf... auch mit der Variable hat es nicht geklappt.... :( Aber ich schau mir am Wochenende noch mal die Optionen von openssl an. Unter https://github.com scheint es auch eine Art Forum für openssl zu geben. Vielleicht finde ich da was... Euch schon mal ein schönes Wochenende Matthias

Ich glaub ich gebe auf. Ich habe gelesen, das Microsoft nun endlich die Funktion Strg+C und V in die cmd.exe und Powershell eingebaut hat. Zumindest bei Windows 10 und Server 2016. Dann drück ich halt 1000 mal Strg+V und Enter, aber immerhin besser als 1000 mal das Kennwort einzugeben. Aber das Powershell-Video werde ich mir auf jeden Fall mal anschauen. Vielleicht werde ich ja noch warm damit :) Viele Grüße und Danke für die Hilfe Matthias Hallo Testperson, danke für den Hinweis, wieder was gelernt. Damit passt zwar nun die Signaturdatei, aber es ändert leider nichts an der Tatsache, das ich für jede XML-Datei das Kennwort eingeben muss :( Wie gesagt, unter Windows 10 kann ich das Kennwort zumindest mit Strg+V eingeben...

Hab ich gleich mal getestet: Es kommt zwar keine Fehlermeldung mehr und die Signatur-Datei hat jetzt einen Inhalt, heißt aber nach wie vor Testdatei.sig anstatt Testdatei.xml.sig. Aber das ist nicht so tragisch. Es funktioniert halt nach wie vor nur ohne -passin pass:Kennwort und einer manuellen Eingabe des Kennwortes. Ich glaube fast, das openssl bzw. der Schalter -passin gar nicht dafür ausgelegt ist, um das Zertifikatskennwort automatisiert angeben zu können. Denn das ist das gleiche wie bei meiner for-Schleife in der Batchdatei...

Guten Morgen, hier noch einmal der Code: $SourcePath = 'C:\Test\Signaturdateien\' $CertFile = 'C:\Test\Signaturdateien\Zertifikat.pem' Get-ChildItem -Path $SourcePath -Filter *.xml | ForEach-Object { $outfile = $_.BaseName + '.sig' Start-Process -FilePath c:\test\signaturdateien\openssl.exe -ArgumentList "dgst -sha512 -binary -out $outfile -sign $CertFile $_.FullName -passin pass:""Kennwort""" -wait -nonewwindow } Als Ausgabe kommt die oben genannte Meldung: dgst: Can only sign or verify on file. Wenn ich den Passus -passin pass:""Kennwort"" komplett herausnehme, werde ich nach einem Kennwort für das Zertifikat gefragt. Nach Eingabe des Kennwortes kommt allerdings die Meldung: Testdatei.xml.FullName: No such file or directory Es wird dann eine Testdatei.sig erstellt, die aber leer ist. Erst wenn ich den richtigen Dateinamen in das Script schreibe... Start-Process -FilePath c:\test\signaturdateien\openssl.exe -ArgumentList "dgst -sha512 -binary -out Testdatei.xml.sig -sign $CertFile Testdatei.xml" -wait -nonewwindow ... wird eine Testdatei.xml.sig mit Inhalt erstellt. Aber auch wieder erst nach Eingabe eines Kennwortes. Grüße Matthias

Ich fürchte ich muss mir das wirklich irgendwann mal zur Gemüte führen. Wahrscheinlich mal an einem Wochenende. Denn selbst in der Zeit, in der ich gerade deinen Text gelesen hab, war der Vorstand bei mir, weil die Mails nicht schnell genug auf seinem Blackberry landen und ein anderer mit Papierstau im MFP 2 Etagen über mir. Ich kann manchmal froh sein, wenn ich mal 30 min konzentriert an einer Sache arbeiten kann. Aber ich will auch nicht jammern oder mich beklagen, sind alles liebe Kollegen ;) Aber zurück zum Script... Ich hab also den ganzen Pfad der OpenSSL.exe angegeben und auch die beiden Schalter angehangen. Nun sieht man auch was gemacht wird. Leider kommt wieder die altbekannte Meldung: dgst: Can only sign or verify one file. Ich denke das wird mit dem Schalter -passin zusammenhängen. Das Problem hatte ich schon in der Batchdatei. Dann wird es wohl kein generelles Problem mit Batch oder Powershell sein, sondern eher ein Problem mit openssl....

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 noch etwas Geduld mit mir hast würde ich gern noch einmal zu deinem Script zurückkommen. Nachdem die Hochkommata eingefügt sind kommt zumindest keine Fehlermeldung mehr. Es erscheint nur ganz kurz ein Konsolenfenster. Allerdings wird auch keine Signaturdatei erstellt. Ich hab mal versucht mit > Output.txt eine Ursache zu finden, aber die Datei bleibt leider leer. Wäre auch zu einfach gewesen ;) Gibt es da andere Möglichkeiten herauszufinden, wo es klemmt?

Hallo BOfH_666, es knirschelt noch etwas. Mit dem SourcePath scheint etwas nicht zu stimmen und das Script will das Zertifikat öffnen und fragt nach einem entsprechenden Programm... siehe Screenshot

Hmm, so richtig klappt es mit dem Script aus dem oben genannten Link nicht. Hier noch einmal das Script: @echo off Rem placeholder for cert-file set cert="" for %%g in (*.pem) do ( echo "Certificate found: " %%g set cert=%%g Rem exit loop as we found a cert-file goto :SignFiles ) echo "No cert file found" exit :SignFiles Rem Ask user for Cert-Password set /p password="Please input cert-password: " Rem debug echo %password% Rem sign all xml-files in directory for %%g in (*.xml) do ( echo "Sign XML-File: " %%g Rem sign file and pass saved password for signing openssl dgst -binary -sha512 -out %%g.sig -sign=%cert% %%g < %password% ) pause exit Das Zertifikat wird gefunden und möchte das Kennwort haben. Soweit so gut. Danach kommt die Meldung: Das System kann die angegebene Datei nicht finden. -> Das Problem hatte der User im Link von BOfH_666 (siehe oben) auch gehabt. Mit den Antworten in dem Forum komme ich nicht zurecht: You need to echo %password%| openssl..., that is the redirector should be pipe. Using < expects a file named %password% which probably doesn't exist, so the error messsage you report is generated. After I changed the openssl command to correctly pass the password via -passin parameter it works. Thanks for helping me by showing my syntax errors! Mit dem -passin Parameter hatte ich es auch schon probiert. Da kommt allerdings die Meldung: dgst: Can only sign or verify one file. Und das mit dem "echo %password%| openssl... " hab ich gar nicht verstanden. Hat noch jemand eine Idee?? Grüße Matthias