Falls Ihr zu den Menschen gehört die in Euren Firmen die Mail-Server administrieren, oder Ihr einfach neugierig seid, welcher interessante Fehlerteufel sich am 01.01.2022 beim Microsoft Exchange Server eingeschlichen hat, dürfte Euch unsere kleine Zusammenfassung interessieren!

Seit dem 01.01.2022 um 0:00 Uhr hat ein Großteil der on premise gehosteten Microsoft Exchange Server ein Problem mit dem Mailverkehr. Daran ist jedoch zur Abwechslung mal nicht der Transport Agent schuld, sondern der Schadsoftwarefilter.

Der Virenscanner FIP-FS Scan Engine meldet einen Fehler mit dem Text „Can’t Convert ‚2201010001‘ to long“.
Der „größte“ Long ist 2.147.483.647, Datumsangaben im Jahr 2022 haben jedoch einen Mindestwert von 2.201.010.001.

Dieser Fehler hat außerordentlich viele Systeme betroffen, da die FIP-FS Anti-Spam- und Anti-Malware-Scan-Engine seitens Microsoft seit dem Exchange Server 2013 standardmäßig aktiviert ist.

Malware Agent deaktivieren – Exchange Management Shell

Zum Glück lässt sich der Fehler schnell kurzfristig umgehen, allerdings leider nur in dem der Malware Agent deaktiviert wird. Zur Behebung des Problems könnt ihr mit den folgenden beiden Zeilen in der Exchange Management Shell den Malware Agent deaktivieren und anschließend den Transport Service neu starten, wonach Euer Microsoft Exchange Server auch im Jahr 2022 wieder ordnungsgemäß arbeiten sollte:

 
Powershell-Befehl Get-Transportagent "Malware Agent" | Disable-Transportagent
Restart-Service MSExchangeTransport

Wenn das sauber funktioniert hat, so seht Ihr bei der nachfolgenden Überprüfung folgende Ausgabe:

In einigen Fällen kann es sein, dass der MSExchangeTransport beim Neustarten Schwierigkeiten hat, in diesem Fall könnt Ihr den Dienst auch über die GUI neu starten, oder den ganzen Server rebooten.

MSExchangeTransport über die GUI neu starten:

Hier sucht Ihr nun den Microsoft Exchange-Transport Dienst heraus und startet diesen neu:

Nun sollte Euer Microsoft Exchange Mailserver wieder funktionieren und gut für 2022 gewappnet sein 😉

Wenn Euch dieser Beitrag gefallen hat schreibt uns oder besucht uns auf einem unserer Social Media Kanäle und lasst einen Like oder Kommentar da!

Der Beitrag MS Exchange 2022 Bug erschien zuerst auf Informatik Guru.

In unserem Beispiel wird ein Zarafa-Mail-Server benutzt, welcher ein älteres Produkt ist, das auf Postfix aufsetzt.

Das funktioniert in unserem Beispiel zweistufig.
Zunächst benötigen wir folgendes Script, um einen Überblick über die Postfachauslastung aller Benutzer zu erstellen:

#Script by C. Caspar
#!/bin/bash
_USER_LIST=$(zarafa-admin -l | grep -v „username“ | grep -v „SYSTEM“ | grep -v „User“ | grep -v „–“ | awk -F‘ ‚ ‚{print$1}‘ | sort)

for _USERS in $_USER_LIST
do
_CHECK_SIZE=$(zarafa-admin –details $_USERS –type user | grep „Current store size“ | awk -F‘ ‚ ‚{print$4, $5}‘)

echo „$_USERS storesize: $_CHECK_SIZE“
done

Hierbei erstellen wir uns zunächst ein Array aus Usern, welche alphabetisch sortiert sind.
Alle Zeilen mit den Strings „username“, „SYSTEM“, „User“ und „–“ lassen wir hierbei aufgrund der Struktur des Standard-Outputs des genutzten Befehls nicht in die Ausgabe.
Unser Output sieht hierbei zunächst so aus:

a_user storesize: 277.54 MB
b_user storesize: 14510.95 MB
c_user storesize: 19.72 MB
d_user storesize: 1748.51 MB
e_user storesize: 7758.81 MB
f_user storesize: 490.84 MB

Mit diesem Script in der Hinterhand können wir folgendes Script für das tatsächliche Monitoring ausführen:

#Script by C. Caspar
#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root
sh /root/zeige_postfachauslastung.sh > postfachauslastung_recent &
sleep 60

echo -e `cat /root/postfachauslastung_recent |sort -n -r -k3 |grep -E '[0-9]{5}' |awk {'print $1"\011"$3"\n\r"'}` | { read body; echo -e $(echo „Subject: IMAP_Monitoring_Postfachauslastung\r\n“; echo „\r\n\r\nFolgende User haben Postfaecher von mindestens 10 GB:\r\n\r\n“; echo -e „${body}“)| sendmail empfaenger_A@Domain.de empfaenger_B@Domain.de empfaenger_C@Domain.de ;}

Was genau tun wir hier jetzt?
Zunächst geben wir dem Script über die PATH-Variable mit, wo es überall nach den entsprechenden Kommandos zu suchen hat, um nicht immer den vollen Pfad zu den Kommandos angeben zu müssen.
Dann geben wir den Output des cat-Befehls aus, wobei wir die Trennzeichen durch tatsächliche newlines ersetzen.
Das wird danach in die neue Variable „body“ gelesen und weiter verarbeitet.
Im Output des Echo greppen wir bereits per regulärem Ausdruck nach 5-Stelligen Zahlen, da uns alle Postfächer ab 10 GB interessieren.
Im Nachgang wird per echo -e der Aufbau der später mit sendmail versandten Mail zusammengesetzt.
Hierbei est es wichtig, dass wir zeilenumbruchgetrennt „Subject“ und anschließend den Inhalt (${body}) angeben, bevor wir den gesamten Output in ein sendmail pipen.

Folgende Mail kommt hierbei bspw. heraus:

Folgende User haben Postfaecher von mindestens 10 GB:

m_user 17333.92
b_user 17311.53
a_user 17193.89

Das Ganze lässt sich selbstverständlich auch über ein einzelnes Script bewerkstelligen, da ohnehin das erste im zweiten lediglich aufgerufen und in eine temporäre Datei geschrieben wird. Allerdings ist es in unserem Fall so gebaut, da Script Nummer Eins in mehreren Fällen auch anderweitige händische Verwendung findet.

Die Einbindung, damit das auch alles automatisiert und ohne unser Zutun läuft, erfolgt einfach via Eintrag im Crontab des entsprechenden Systems.

In unserem Beispiel ist das wie folgt geschehen:


1 6   * * *   root    /root/postfachauslastung_monitoring.sh

Aus diesem Eintrag geht hervor, dass das Script „postfachauslastung_monitoring.sh“ täglich um 6:01 Uhr morgens ausgeführt werden soll.

Der Beitrag Mail-Server Monitoring in Bash erschien zuerst auf Informatik Guru.

Ein Rechnernetz ist grundsätzlich ein zusammenhängendes Netz aus autonomen Rechnern. Im Gegensatz zur früher hauptsächlich verbreiteten Variante, in welcher lediglich große Hauptrechner (mainframes) den Löwenanteil der Rechenlast bewerkstelligten und von Terminals (Anwender-Rechnern) gespeist wurden, bezeichnen ein Rechnernetz ein zusammenhängendes Netz vollwertiger Clients, welche Standard-Aufgaben auch dezentral bearbeiten können.
Zunehmend beschreibt man hiermit auch Netzwerke welche mehr in Richtung der althergebrachten Struktur gehen und bspw. mit Thin Clients an Terminalservern arbeiten.

Protokolle

Protokolle sind Rahmen bzw. Regeln, welche den Datenaustausch oder allgemeiner gesagt das „Verhalten“ von mehreren an einer Kommunikation beteiligten Systeme regeln und steuern („protocols are formal rules of behaviour“).
Werden einzelne Protokolle von einem oder mehreren Kommunikationspartnern nicht eingehalten, so erschwert dies die Kommunikation oder macht sie gar unmöglich.
Um ein Beispiel aus dem täglichen Leben zu wählen, nehmen wir einmal den Funkverkehr.
Der Empfang einer Nachricht wird mit „Roger“ quittiert, der Wechsel der Kommunikationsrichtung wird mit „Over“ initiiert.

Vergleichbare Protokollstrukturen werden auch in der Kommunikation zwischen Computern verwendet.
Diese sind hierbei selbstverständlich weitaus komplexer und die Kommunikation wird nie über ein einzelnes, sondern in der Regel über eine ganze Vielzahl an Protokollen abgebildet.
Diese Protokolle sind zumeist lediglich für einzelne Teilaufgaben im Datenaustausch zuständig und werden in Form von Schichten (Stacks) abgebildet.
Das Beispiel schlechthin hierbei ist das weiter unten kurz beschriebene OSI-Modell.

Historisches

Gegen Ende des Kalten Krieges beauftragte die amerikanische Regierung das Department of Defence (DoD) mit der Entwicklung einer möglichst ausfallsicheren Netzwerkstruktur, welche auch im Falle eines Atomkrieges weiter funktionieren sollte, wofür sich nach mehreren Tests (ohne Atombomben natürlich) das Telefonnetz als untauglich erwies. Hieraus ergab sich eine Zusammenarbeit mit der ARPA (Advanced Research Project Agency), während welcher diese auch gleich aufgrund der militärischen Ausrichtung in DARPA (Defense Advanced Research Project Agency) umbenannt wurde. Diese war 1957 als Reaktion auf den Start des sowjetischen Sputnik gegründet worden.
Die Kooperation der Behörden scharte zunächst Wissenschaftler um sich und eruierte unterschiedliche Arten von Netzwerken.
Um die angestrebte Zuverlässigkeit zu erreichen, fiel die Wahl auf eine paketvermittelnde Netzwerkstruktur (packet-switched network).
Grundsätzlich werden Kommunikationspartner im Rahmen einer solchen Verbindung lediglich virtuell verbunden und „zerstückeln“ die zu übertragenden Informationen, welche folglich auf der Empfängerseite zunächst wieder zusammengesetzt werden müssen.
Ende 1969 entstand hieraus in Kooperation mit vier amerikanischen Universitäten (UCLA, UCSB, SRI, University of Utah) das DARPA-Net.
Da die ursprünglich im DARPA-Net verwendeten Protokolle nicht dafür ausgelegt waren, eine Vielzahl an Teilnetzen zu verbinden oder der steigenden Komplexität der zu übermittelnden Informationen Stand zu halten, wurde 1974 TCP/IP entwickelt.
Nachdem in den darauffolgenden Jahren weitere Entwicklung sowie die erste Integration von TCP/IP in Berkley Unix den Weg für die Technologie ebneten, wurde das DARPA-Net 1984 aufgeteilt in den militärischen Bereich „MILNET“ und den zivilen bzw. Forschungsbrerich „DARPA-Net“.
Das DARPA-Net als solches existiert zum jetzigen Zeitpunkt nicht mehr, Nachfolger des MILNET hingegen sind noch heute aktiv und einsatzbereit.

Die Sammlung von Netzwerken, welche das DARPA-Net darstellte wurde zunehmen als Netzverbund betrachtet.
Dieser Netzverbund ist gewissermaßen der Urvater des Internets.

[Kleiner Seitenhieb am Rande, Horst Seehofer war vermutlich Austauschstudent an der UCLA und war deshalb 1980 bereits online.]

Referenzmodelle

Das Open System Interconnections(OSI)-modell ist ein Modell basierend auf einem Vorschlag der International Standards Organisation (ISO). Der Aufbau ist untenstehender Illustration zu entnehmen.

Das Modell dient derzeit als Rahmen zur Beschreibung der Protokollcharakteristika und -funktionen.
Es besteht aus sieben Schichten und beruht darauf, dass eine Schicht immer der übergeordneten Schicht bestimmte Dienstleistungen bzw. Funktionen bereitstellt.

Es handelt sich hierbei nicht um eine Netzwerkstruktur, sondern lediglich die Beschreibung dessen, welche Aufgaben und Funktionalitäten die einzelnen Schichten abdecken sollen.

Die folgenden Prinzipien, aus denen sich die Schichten ergeben, definierte Tanenbaum 1996:
1. Eine neue Schicht sollte dort entstehen, wo ein neuer Abstraktionsgrad benötigt wird.
2. Jede Schicht sollte genau eine definierte Funktion erfüllen.
3. Bei der Funktionswahl sollte die Definition international genormter Protokolle berücksichtigt werden.
4. Die Grenzen der einzelnen Schichten sollten so gewählt werden, dass der Informationsfluss über die Schnittstellen möglichst gering ist.
5. Die Gesamtzahl der Schichten sollte so gewählt sein, dass keine Notwendigkeit besteht, verschiedene Funktionen auf eine Schicht zu packen, aber so klein, dass die Gesamtarchitektur nicht unhandlich wird.

Anwendungsschicht (Application Layer)[OSI Modell]:

Auf der Anwendungsschicht befinden sich eine Vielzahl von Protokollen, welche einzelne Programme für die Erbringung ihrer Dienstleistung definiert haben.
Namhafte Beispiele sind u.a. ftp, telnet, imap

Darstellungsschicht (Presentation Layer) [OSI Modell] :

Die Darstellungsschicht regelt die Darstellung der übertragenen Daten für die unabhängig hiervon agierenden höherliegenden Protokolle.
Hierbei geht es bspw. um die Codierung von Zeichenketten nach ASCII, Unicode o.ä.

Sitzungsschicht (Session Layer) [OSI Modell] :

Die Sitzungsschicht, oft auch Verbindungsschicht genannt, regelt den Verbindungsauf- und Abbau über die darunterliegende Transportschicht.
Bei unidirektionalen Protokollen wird hierbei bspw. geregelt, welcher Kommunikationspartner wann senden kann und ähnliches.

Transportschicht (Transport Layer) [OSI Modell] :

Die Transportschicht übernimmt, wie der Name vermuten lässt, den Transport der Kommunikationsteilnehmer.
Sie hat die elementare Aufgabe, den Datenfluss zu steuern sowie die Integrität, respektive die Unvefälschtheit, der Informationen zu gewährleisten.
Beispiele für Protokolle der Transportschicht sind u.a. TCP und UDP.

Netzwerkschicht (Network Layer) [OSI Modell] :

Die Netzwerkschicht, auch Vermittlungsschicht genannt, hat die primäre Aufgabe, die Verbindung zu Knoten im Netzwerk herzustellen, um somit die darüberliegenden Schichten von der tatsächlichen Übertragung im Netzwerk zu befreien. Eine der Hauptaufgaben ist die Auswahl der Paketrouten vom Sender zum Empfänger.
In der Netzwerkschicht ist das Internet Protokoll (IP) einzuordnen.

Sicherungsschicht (Data Link Layer) [OSI Modell] :

Die Aufgabe der Sicherungsschicht ist die gesicherte Übertragung der Daten vom Sender zum Empfänger.
Hierbei werden die Daten in Frames aufgeteilt und sequenziell versendet, wonach ihr Empfang vom Sender durch sogenannte Bestätigungsrahmen quittiert wird.
Ein Beispiel für in Layer 2 beheimatete Protokolle ist das Point-to-Point-Protokoll (PPP).

Bitübertragungsschicht (Physical Layer) [OSI Modell] :

Die Bitübertragungsschicht regelt die Übertragung von Bits über das zugrundeliegende Übertragungsmedium.
Dies betrifft vorrangig die Übertragungsgeschwindigkeit und die Bit-Codierung.
Die weiteren Festlegungen diese Schicht betreffend ergeben sich hierbei aus dem genutzten Medium.
Ob ich hierbei auf 100Base-TX oder Buschtrommeln setze ist für die übergeordneten Schichten unerheblich.

TCP-IP-Referenzmodell

Nachdem wir im vorangegangenen Abschnitt alle Unklarheiten zum Thema ISO-OSI-Referenzmodell beseitigt haben sollten, gehen wir im weiteren auf das TCP-IP-Referenzmodell ein.
Dieses Referenzmodell ist nach den beiden primären Protokollen TCP und IP benannt.
Des Weiteren sei gesagt, dass das TCP-IP-Referenzmodell zeitlich vor dem OSI-Referenzmodell entstanden ist.
Dementsprechend sind auch hierbei gemachte Erfahrungen in das OSI-Modell eingeflossen.
Im Gegensatz zum OSI-Modell hat man beim TCP-IP-Modell nur vier Schichten:
Application Layer
Transport Layer
Internet Layer
Network Layer

Die im Rahmen der Entwicklung definierten Ziele sind die folgenden:

=>Unabhängigkeit von der verwendeten Netzwerk-Technologie
=>Unabhängigkeit von der Architektur der Hostrechner
=>Universelle Verbindungsmöglichkeiten im gesamten Netzwerk
=>Ende-zu-Ende-Quittungen
=>Standardisierte Anwendungsprotokolle

Applikationsschicht(Application Layer)[ TCP-IP-Referenzmodell]:

Die Applikationsschicht umfasst alle höherschichtigen Protokolle des TCP/IP-Modells.
Zu den ersten Protokollen der Verarbeitungsschicht gehörten u.a. TELNET, SMTP und FTP.
Hierzu gesellten sich später bspw. HTTP und DNS.

Transportschicht (Transport Layer) [ TCP-IP-Referenzmodell] :

Wie im OSI-Modell ermöglicht die Transportschicht im TCP/IP-Modell die Kommunikation zwischen Quell- und Zielhost.
Im TCP/IP-Modell wurden hierfür zwei Protokolle definiert: TCP & UDP.
TCP ist ein verbindungsorientiertes Protokoll, dessen Hauptaugenmerk auf Zuverlässigkeit und Nachvollziehbarkeit liegt.
UDP ist ein schnelleres, dafür aber unzuverlässigeres, verbindungsloses Protokoll, welches vorwiegend für Abfragen verwendet wird und für Übertragungen, bei denen es mehr auf Geschwindigkeit als auf die hundertprozentige Zuverlässigkeit ankommt, wie bspw. Übertragung von Bildern und Sprache.

Internetschicht (Internet Layer) [ TCP-IP-Referenzmodell] :

Die Internetschicht definiert in diesem Modell lediglich ein Protokoll und zwar das namengebende Internet Protokoll IP, dessen Aufgabe es auch wie bei der Implementierung im Rahmen von OSI ist, die Pakete im Netzwerk korrekt zuzustellen.
Das Internet Control Message Protocol (ICMP) ist hierbei ein fester Bestandteil in jeder IP-Implementierung und dient der Übertragung von Diagnose- und Fehlerinformationen für das IP.

Netzwerkschicht (Network Layer) [ TCP-IP-Referenzmodell] :

Unterhalb der Internetschicht hat das TCP/IP-Referenzmodell ein klares Definitionsdefizit. Es legt nicht all zu viel fest, was auf dieser Ebene passieren soll. Es beschreibt lediglich, dass zur Übermittlung von IP-Paketen ein Host über ein bestimmtes Protokoll an das Netzwerk angeschlossen sein muss.
Dieses Protokoll ist im TCP/IP-Referenzmodell allerdings nicht nähergehend definiert, da es von Netz zu Netz und von Host zu Host abweicht.
Zumeist machte man unter Anwendung dieses Referenzmodelles Gebrauch von bereits vorhandenen Protokollen wie bspw. Ethernet (IEEE 802.3) oder Serial Line IP(SLIP).

TCP/IP im Detail

Da die vierschichtige Betrachtung des TCP/IP-Referenzmodells bzgl. der tatsächlichen Datenübertragung einige Definitionslücken hat und Fragen offen lässt, wird es auch oft als fünfschichtige Darstellung verwandt.
Hierbei werden die im ISO-OSI-Referenzmodell beschrieben unteren Schichten „Data Link Layer“ und „Physical Layer“, welche im klassischen TCP/IP-Modell als „Network Layer“ zusammengefasst sind, wieder unterteilt in „Network Layer“ und „Physical Layer“.
Diese Darstellung ist ebenfalls bekannt als hybrides Referenzmodell.
Diese erneute Auftrennung ist notwendig, da das TCP/IP-Referenzmodell nicht zwischen Bitübertragungs- und Sicherungsschicht separiert.
Diese beiden Schichten erfüllen jedoch grundsätzlich völlig verschiedene Aufgaben.
Die Bitübertragungsschicht hat mit den mediumspezifischen Merkmalen von Kupferdraht, Glasfaser und drahtlosen Kommunikationskanälen zu tun, wohingegen die Sicherungsschicht darauf beschränkt ist, den Anfang und das Ende des Kommunikationsrahmens einzugrenzen und Daten mit der gewünschten Zuverlässigkeit von einem Ende zum anderen zu befördern.
Somit sollten diese Aufgaben auch in separate Schichten unterteilt werden, was das klassische TCP/IP-Referezenmodell jedoch nicht tut.

Schichtung

Die Schichtung beruht auf dem Prinzip, dass eine Schicht die von der darunterliegenden Schicht angebotenen Dienste in Anspruch nehmen kann, ohne Details selbiger Implementierung bzw. Erbringung zu haben. Auf diese Art wird auch die in den obenstehenden Abschnitten beschriebene Teilung der Aufgaben erreicht. Daten, die von einer beliebigen Applikation über Netzwerk versendet werden, durchlaufen den TCP/IP-Protokollstapel (TCP/IP-Stack) von der Applikationsschicht zur Netzwerkschicht, wobei von jeder Schicht Kontrollinformationen in Form eines Protokollkopfes (Headers) angefügt wird.
Dieser Prozess wird als Einkapselung(Encapsulation) bezeichnet.

Stack

Innerhalb des TCP/IP-Stacks werden die Daten mit unterschiedlichen Termini benannt, da auch jede Schicht ihre eigenen Datenstrukturen hat.
Applikationen, welche das TCP benutzen, bezeichnen Daten als Strom (stream). Applikationen, welche hingegen das UDP benutzen, bezeichnen die Daten als Nachricht (message).
Auf dem Transport Layer spricht man bei TCP von Segmenten (segments) und bei UDP von Paketen (packets).
Auf der nächsttieferen Ebene, also dem Internet Layer, spricht man in beiden Fällen von Datagrammen (datagram), auf dem Network Layer, bzw. dem Physical Layer, gilt die Bezeichnung Frame.

Hat Euch er Beitrag gefallen? Schreibt uns!
Habt Ihr offene Fragen oder Anregungen zum Thema? Schreibt uns!
Themenvorschläge/-wünsche? Schreibt uns!

Lasst uns gerne einen Besuch, einen Like oder eine Markierung auf einem unserer Social Media Kanäle auf Facebook oder Instagram da.

Der Beitrag ISO-OSI & TCP/IP – Referenzmodelle – Wissenswertes erschien zuerst auf Informatik Guru.