26.05.2025
1074
8
0Packets received discarded im HealthChecker
Hallo,
seit der Migration von Exchange 2016 auf 2019 kommt beim HealthChecker Script immer die im Titel geschriebene Warnung, dass anscheinend Pakete verworfen wurden. Es handelt sich bisher nur um ein paar wenige, aber ich befürchte, dass das mit der Zeit nach oben geht. Im Betrieb mit Outlook sind keine Auffälligkeiten aufgetreten(kein Cached Mode).
Ich habe in PRTG mal den Netzwerkadapter mit ins Monitoring genommen, um das besser sehen zu können. Dieser verzeichnet aber seit mehreren Tagen keine fehlerhaften oder verworfene Pakete. Also hab ich die Messung auf den Hypervisor und den Switch ausgeweitet. Auch hier nichts. Es ist mir ein absolutes Rätsel, wo diese verlorenen Pakete herstammen können.
Beim 2016er hatte ich diese Warnung nie. Ich habe mal testweise den Wert für Receive Buffers auf 16MB(Maximum beim Hyper-V Adatper) gestellt, das Ergebnis ist aber das Selbe.
Der Exchange läuft auf Hyper-V als version 2 VM. 4 vCPUs, 16 GB RAM. Auslagerungsdatei 4GB. Es laufen 7 User Mailboxen und 7-8 Shared Mailboxes drauf. Kein DAG.
Gibt es ein paar spezielle tuning Tipps bei Exchange 2019, welche bei 2016 noch nicht notwendig waren?
Gibt es ein paar tuning Tipps für Exchange 2019 auf Hyper-V, welche man unbedingt machen sollte?
Danke
seit der Migration von Exchange 2016 auf 2019 kommt beim HealthChecker Script immer die im Titel geschriebene Warnung, dass anscheinend Pakete verworfen wurden. Es handelt sich bisher nur um ein paar wenige, aber ich befürchte, dass das mit der Zeit nach oben geht. Im Betrieb mit Outlook sind keine Auffälligkeiten aufgetreten(kein Cached Mode).
Ich habe in PRTG mal den Netzwerkadapter mit ins Monitoring genommen, um das besser sehen zu können. Dieser verzeichnet aber seit mehreren Tagen keine fehlerhaften oder verworfene Pakete. Also hab ich die Messung auf den Hypervisor und den Switch ausgeweitet. Auch hier nichts. Es ist mir ein absolutes Rätsel, wo diese verlorenen Pakete herstammen können.
Beim 2016er hatte ich diese Warnung nie. Ich habe mal testweise den Wert für Receive Buffers auf 16MB(Maximum beim Hyper-V Adatper) gestellt, das Ergebnis ist aber das Selbe.
Der Exchange läuft auf Hyper-V als version 2 VM. 4 vCPUs, 16 GB RAM. Auslagerungsdatei 4GB. Es laufen 7 User Mailboxen und 7-8 Shared Mailboxes drauf. Kein DAG.
Gibt es ein paar spezielle tuning Tipps bei Exchange 2019, welche bei 2016 noch nicht notwendig waren?
Gibt es ein paar tuning Tipps für Exchange 2019 auf Hyper-V, welche man unbedingt machen sollte?
Danke
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673031
Url: https://administrator.de/forum/packets-received-discarded-im-healthchecker-673031.html
Ausgedruckt am: 18.07.2025 um 03:07 Uhr
8 Kommentare
Neuester Kommentar
Ja, den Beitrag kenne ich. Es handelt sich aber nicht um VMware, also kann ich diese Einstellungen auch nicht setzen ;)
Es geht ja nicht um VmWare sondern dem vmxnet3 Adapter unter Winblows im Gerätemanager.
Dort die 4 Buffer entsprechend vergrößern löst das Problem.
Dort die 4 Buffer entsprechend vergrößern löst das Problem.
Vmxnet3 ist ein VMware Treiber. Der existiert nicht bei Hyper-V ;)
Vielleicht hilft ja dann beim Hyper-V Geraffel Treiber auch das Vergrößern dieser Buffer... Versuch mach klug?! 
Ansonsten Bug mit dem Microsoft TAC aufmachen!
Ansonsten Bug mit dem Microsoft TAC aufmachen!
Zitat von @aqui:
Vielleicht hilft ja dann beim Hyper-V Geraffel Treiber auch das Vergrößern dieser Buffer... Versuch mach klug?!
Vielleicht hilft ja dann beim Hyper-V Geraffel Treiber auch das Vergrößern dieser Buffer... Versuch mach klug?!
Habe ich schon gemacht. Steht alles in meinem initialen Post ;)
Wenn es das als Lösung war bitte deinen Thead dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Lösung wurde gefunden.
Es handelt sich hier in Wirklichkeit um ein Problem von Server 2022 nicht des Exchange Servers. Also nochmal alle Optimierungstipps für den Server durchprobiert und tatsächlich war am Ende die Funktion "RSC (Receive Segment Coalescing)" im Netzwerkkartentreiber der Übeltäter. Diese Option haben bei uns nur die Server 2022 VMs. Das sind alles Gen 2 VMs und wurden neu auf dem Hyper-V Host erstellt. Die Server 2016er Maschinen haben wir damals von VMWare migriert(inkl. dem Exchange 2016). Hier gibt es diese Option nicht im Treiber.
Lange Rede kurzer Sinn: Die Option muss sowohl am vSwitch oder in unserem Fall am SET Team deaktiviert werden und zusätzlich innerhalb aller VMs, welche diese Option im Treiber haben. Es gibt dazu Powershell Befehle. Das einzige, was man dazu wissen muss ist, dass dies am vSwitch/SET Team im laufendem Betrieb ohne Unterbrechung geht. Innerhalb der VMs kommt es hier zu dem üblichen kurzen Disconnect.
Der Exchange läuft jetzt seit über eine Woche ohne einem einzigen verworfenen Packet.
Es handelt sich hier in Wirklichkeit um ein Problem von Server 2022 nicht des Exchange Servers. Also nochmal alle Optimierungstipps für den Server durchprobiert und tatsächlich war am Ende die Funktion "RSC (Receive Segment Coalescing)" im Netzwerkkartentreiber der Übeltäter. Diese Option haben bei uns nur die Server 2022 VMs. Das sind alles Gen 2 VMs und wurden neu auf dem Hyper-V Host erstellt. Die Server 2016er Maschinen haben wir damals von VMWare migriert(inkl. dem Exchange 2016). Hier gibt es diese Option nicht im Treiber.
Lange Rede kurzer Sinn: Die Option muss sowohl am vSwitch oder in unserem Fall am SET Team deaktiviert werden und zusätzlich innerhalb aller VMs, welche diese Option im Treiber haben. Es gibt dazu Powershell Befehle. Das einzige, was man dazu wissen muss ist, dass dies am vSwitch/SET Team im laufendem Betrieb ohne Unterbrechung geht. Innerhalb der VMs kommt es hier zu dem üblichen kurzen Disconnect.
Der Exchange läuft jetzt seit über eine Woche ohne einem einzigen verworfenen Packet.
