Exchange: Microsoft.Exchange.ManagedLexRuntime.MPPGRuntime fehlt

Ich hatte auf einem Exchange-Management-Host das Problem das nach der Installation manche Befehle nicht funktionierten und folgende Fehler geworfen haben:

Der Parameter "RecipientFilter" kann nicht an das Ziel gebunden werden. Ausnahme beim Festlegen von "RecipientFilter": "Die Datei oder Assembly<br>"Microsoft.Exchange.ManagedLexRuntime.MPPGRuntime, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Das System<br>kann die angegebene Datei nicht finden."

oder

Get-CASMailbox : Cannot bind parameter 'Filter' to the target. Exception setting "Filter": "Could not load file or assembly 'Microsoft.Exchange.ManagedLexRuntime.MPPGRuntime, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of it\ s dependencies. The system cannot find the file specified."

Auf dem Exchange Server direkt trat der Fehler nicht auf.

Die Lösung war relativ simpel:

Man muss nur die Microsoft.Exchange.ManagedLexRuntime.MPPGRuntime.dll aus dem Verzeichnis C:\Program Files\Microsoft\Exchange Server\V15\Bin von einem Exchange Server in das gleiche Verzeichnis auf dem Mangement-Server kopieren.

Danach gingen alle Befehle auch vom Management -Server 🙂

Linux: iperf3 als systemd-Deamon

Will man unter Linux (in meinem Fall Debian) iperf3 als Deamon laufen lassen geht das relativ einfach wie folgt:

Erstmal installieren wir iperf3

sudo apt install iperf3

Danach erstellen wir die Service-Datei für den systemd-Deamon:

sudo vim /etc/systemd/system/iperf3.service

Dort kopieren wir folgendes rein und speichern die Datei:

[Unit] 
Description=iperf3 

[Service] 
ExecStart=/usr/bin/iperf3 --server 

[Install]
WantedBy=multi-user.target

Jetzt können wir den Deamon aktiveren:

sudo systemctl enable iperf3

Jetzt können wir den Deamon starten:

sudo systemctl start iperf3

Überprüfen ob der Dienst läuft:

sudo systemctl status iperf3

Jetzt läuft immer der iperf3-Dienst – auch nach Restart des Severs 🙂

Quelle: https://willhaley.com/blog/iperf3-server-client/

Windows PowerShell: Installation von NuGet schlägt fehl

Wenn man auf einem Windows-Server – in meinem Fall ein Windows Server 2016 – den NuGet Paketmanager nachinstallieren will – z.B. um die Azure PowerShell-Module zu installieren – schlägt dies seit geraumer Zeit (Seit April 2020) fehl:

Die Fehlermeldung von Install-PackageProvider -Name NuGet lautet:

Install-PackageProvider : Für die angegebenen Suchkriterien für Anbieter „NuGet“ wurde keine Übereinstimmung gefunden.
Der Paketanbieter erfordert das PackageManagement- und Provider-Tag. Überprüfen Sie, ob das angegebene Paket über die
Tags verfügt.

Der Grund ist vermutlich ein „Upgrade“ des Azureedges, der den Lookup-Provider stellt (onegetcdn.azureedge.net/providers). Der Endpunkt lässt seit etwa April 2020 keine TLS1.0 und TLS1.1 Verbindungen mehr zu und wurde auf „TLS1.2 min“ konfiguriert. Die PowerShell (< 14393.3474) spricht per Default aber nur TLS1.1.

Lösung

Mit folgendem Befehl stellt man die PowerShell auf TLS 1.2 um:

[Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12

Danach funktioniert die Installation:

Quelle: https://www.zueschen.eu/

Nginx: Ältere Client-Zertifikate erlauben

Wenn man am Nginx die SSL-Ciphers updatet und danach gehen manche ältere Client-Zertifikate nicht mehr, liegt das daran das auch für die Client-Zertifikate die Ciphers gelten die unter ssl_ciphers konfiguriert sind – und ist das z.B. sha1RSA nicht mehr drin (hoffentlich 😉 ) werden auch Client-Zertifikate die mit sha1RSA nicht mehr akzeptiert.

Im Log taucht dann folgender Fehler auf:

client SSL certificate verify error: (68:CA signature digest algorithm too weak)

und der Client bekommt

400 Bad Request The SSL certificate error

Um das Problem zu lösen muss man @SECLEVEL=0 an seine ssl_ciphers anhängen – z.B. :

ssl_ciphers 'HIGH:!aNULL:!MD5@SECLEVEL=0';

Danach werden die Client-Zertifikate wieder akzeptiert – die Sicherheit der eigentlichen SSL-Verbindung ist hiervon nicht betroffen 🙂

Quelle: stackoverflow.com

Nginx: proxy_pass mit älteren TLS-Versionen

Ich verwende ja recht gerne den Nginx als ReverseProxy. Aktiviert man allerdings TLS 1.3 in den ssl_protocols – so will der Nginx auch mit dem Backend immer mit TLS 1.3 sprechen. Das kann allerdings z.B. mit älteren IIS-Servern zu Problemen bzw. zu keiner Verbindung führen.

Das Problem kann man mit

proxy_ssl_protocols TLSv1 TLSv1.1;

verhindern. So verwendet der Nginx in diesem Beispiel eben TLS1 oder TLS 1.1 um mit dem Backend zu kommunzieren – mit dem Frontend (also dem Client-Browser) wird dann trotzdem TLS1.3 gepsorchen 🙂

macOS: HEIC und HEIF nach JPEG konvertieren

Unter iOS speichert man ja mittlerweile seine Fotos im HEIC-Format.

Will man aber seine Fotos weitergeben und weiß nicht ob das Betriebssystem des Empfänger HEIC bzw. HEIF unterstütz empfiehlt es sich die Fotos in das JPEG-Format umzuwandeln.

Auf dem Mac geht das wunderbar mit Imagemagick.

Zuerst Installieren wir Imagemagick per brew:

brew install imagemagick

Danach kann entweder ein einzelnes Foto konvertiert werden:

magick convert foto.HEIC foto.jpg

Oder alle Fotos in dem aktuellen Ordner

magick mogrify -monitor -format jpg *.heic

Quelle: https://blog.wplauncher.com/convert-heic-to-jpg-on-mac/

Hyper-V: Nested Virtualization aktivieren

Will man auf einem Hyper-V-Host ein VM mit aktivierter Virtualisierung – z.B. einen Server mit der Hyper-V-Rolle – installieren, muss man die VM erstellen und dann das Nested Virtualization-Feature für die VM mit folgenden Befehlen per Powershell aktivieren:

get-vm VMNAME | Set-VMProcessor -ExposeVirtualizationExtensions $true
get-vm VMNAME | Set-VMNetworkAdapter -MacAddressSpoofing On

Hier als Beispiel mit der VM mit dem dem Namen 55_HyperV:

get-vm 55_HyperV | Set-VMProcessor -ExposeVirtualizationExtensions $true
get-vm 55_HyperV | Set-VMNetworkAdapter -MacAddressSpoofing On

Danach lässt sich – in dem Fall HyperV – der Hypervisor installieren/aktivieren

Aruba Instant On

Ich mache bei meinen WLAN-Projekten eigentlich fast alles immer mit der UniFi-Serie von Ubiquiti. Ich war bzw. bin da eigentlich auch immer zufrieden gewesen.

Jetzt hatte ich für ein Projekt mir das Aruba Instant On System (in dem genauen Fall die AP11) angesehen – und wollte kurz über die AccessPoint bzw. das System berichten.

Aruba Instant On ist komplett Cloud-managed -> ohne Account bei arubainstanton.com geht gar nix. Die Einrichtung erfolgt über die App (iOS und Android) oder über die Webseite unter portal.arubainstanton.com. Wer hier also Bedenken hat -> leider das falsche System.

Das Instant On System ist auf Einfachkeit und für schnelle Bereitstellung konzipiert. Auch gibt es Limits – sowohl die maximale Anzahl (25) an AccessPoints pro Standort und auch an Optionen zur Konfiguration – z.B. keine Möglichkeit zur Kanalwahl etc.

Die Geräte supporten alles was man so braucht – natürlich Mesh-fähig, support von DFS, ARM, Band Steering, Airtime Fairness, 802.11ac Wave 2 mit 802.11v. Leider kein Wifi 6 :-/

Das Setup ist sehr einfach gehalten – man kann eigentlich nix falsch machen. Hier kann man den ganzen Prozess mal in einem Video anschauen: Youtube

Das Setup sieht so aus : die AccessPoints anstecken damit die AccessPoints online sind. Sie werden automatisch geupdatet und geben durch blinken dann Bescheid wenn sie ready sind – das kann dauern…

Danach in der App oder im WebPortal einen Netwerk einrichten – hier werden nur die wichtigsten Sachen abgefragt : SSID (Name des WLANs), Passwort oder Radius, WPA3 an oder aus (WPA2 oder WPA2+WPA3-Mix-Mode) und VLAN. Danach gibt man noch die Seriennummer eines oder mehreren AcessPoints an -> fertig. Dauer des Setups: wenige Minuten.

Danach hat man in der App und im Webportal folgende Ansicht:

Unter Netwerke befindet sich die Verwalrung der WLAN-Netzte.

Unter IP und VLAN-Zuweisung zwischen Standard und NAT-Modus wählen. Bei Standard macht der lokale Router, Firewall oder DHCP-Server die Adressvergabe -ausserdem kann man bei Bridge-Modus ein VLAN vergeben. Beim NAT-Modus werden alle Clients in ein eigenes Netz gelegt. Ausserdem kann hier die Bandbreite beschränkt werden – falls das benötigt wird.

Ausserdem kann ein Zeitplan gesetzt werden

Und noch ein bischen Statistik

Mehr Optionen gibt es nicht – alles andere regelt der Controller bzw. die AcessPoints selbst.

Unter Clients sieht man alle verbundenen Geräte

Unter Anwendungen gibt es eine Katogerosierung sowie einen kleinen WebFilter. Hier können Kategorien pro Netwerk zugelasen oder verboten werden.

Unter Inventar sind die Geräte. Hier können Namen vergeben werden. Mehr Konfiguration ist nicht möglich – ausser neustarten über das Werkzeugschlüssel-Tool

In der Standortverwaltung kann man noch rudimentäre Optionen wie Name, Zeitzone, etc setzen – und ein Portal anlagen:

Das Portal erscheint wenn beim Netzwerk der Netwerk-Typ Gast ausgewählt wurde:

Fazit

Das Instant On ist ein gutes Fire-and-Forget-System das gut gegen das UniFi-System konkurrieren kann (die AP11 gegen das AC-Lite, der AP12 gegen den AC-LR und der AP15 gegen den AC-HD). Die Performance ist einen Ticken besser – die Reichweite ähnlich. Stabilität des Wifis war besser als ein vergleichbares Unifi-System (ca. 4 Wochen jetzt am laufen).

Bei UniFi kann ich halt alles mögliche einstellen und selber meinen Controller betreiben – das kann ich hier halt nicht -> der das nicht will oder braucht bekommt ein super System – den man merkt schon das Aruba weiß wie Wifi geht. Mit dem Verhalten out-of-box war ich sehr zufrieden. An einigen Stellen merkt man zwar noch dass das System sehr jung ist (Markteinführung Mitte 2019) -> aber wer keine Angst vor der Cloud hat und sich keinen Controller selbst hosten will/kann bekommt mit dem Instant On von Aruba ein kostengünstiges, stabiles Wifi-System für Zuhause und kleine Büros/Geschäfte.

Ich werde jetzt mal weiter testen und wohl noch den einen oder anderen beim nächsten kleineren Projekt verbauen 🙂