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