iOS-Geräte legen Exchange lahm!

In letzter Zeit scheint Apple mit seinem mobilen Betriebssystem einige Probleme zu haben. Erst waren es Verbindungsprobleme mit dem mobilen Netz (3G). Darauf folgte der Rollout von Version 6.1.1. Jetzt gibt es massive Beschwerden, dass iOS-Geräte ganze Exchange-Umgebungen lahmlegen.

Vom Bug zum Desaster

Manche Softwarefehler sind ärgerlich. Noch nerviger wird die Angelegenheit, wenn die Fehlfunktionen ihre Ursache im Betriebssystem haben. Bei Programmfehlern gibt es (meist) Ausweichmöglichkeiten, bei OS-Fehlern nur eine: das Gerät nicht nutzen. Für die meisten Business-User keine echte Alternative. The Verge berichtete zuletzt über die Möglichkeit, den Lock-Screen in Version 6.1 auszuhebeln. Der aktuelle Bug betrifft die Kommunikation mit Microsofts Mailserver.

iOS zwingt Exchange in die Knie

Der jüngste Fehler im Betriebssystem von iPhone und iPad (Version 6.1 und 6.1.1 sind betroffen) verursacht aktuell eine dramatische Überbelastung des Exchangeservers. Die eigentliche Ursache ist nicht klar. Manche Umgebungen verzeichnen keinerlei „Nebenwirkungen“. Wie heikel die Situation wirklich ist, zeigt die Stellungnahme von Microsoft, die zu einer vollständigen Blockade jener iOS-Geräte raten. Über die ActiveSync-Steuerung technisch kein Problem, für die betroffenen Anwender schon.

Symptome des iOS-„Angriffs“

Da sich Apple wie üblich bei Fehlfunktionen und Schwachstellen in Schweigen übt – einzige Ausnahme ist ein mehr als zweifelhafter Workaround -, bleibt nur die Rundfrage in der Anwendergemeinde. Und hier sind die Erfahrungen durchaus gemischt. Manche Exchange-Betreiber sind gar nicht betroffen, andere wiederum berichten von einem de facto Stillstand.

Die wichtigsten Symptome sind:

• ein Anschwellen der Exchange Logdateien im Ausmaß von 50 GB und mehr
• eine vollständige Auslastung der CPU-Performance
• eine Überlastung der Internetleitung aufgrund ständig neuer iOS-Anfragen (Schleife)

Abhilfe und Schnelldiagnose

Wie gesagt, die Erfahrungen sind durchaus divergierend. Manche Administratoren berichten, dass erst der von Apple geratene Workaround die Fehlfunktionen auslöste. Andere wiederum, dass die De- und Reaktivierung überhaupt keine Änderungen im Synchronisierungsverhalten bewirkt.

Verständigung bevor es zu spät ist

Sowohl eine andauernde CPU-Überlastung wie auch der rasante Verbrauch von freiem Festplattenplatz sind extrem kritische Umstände im Produktivbetrieb. Schließlich führt eine Nichtverfügbarkeit der Exchange-Umgebung sehr schnell zu Produktionsausfällen. Der Einsatz eines professionellen Monitoring-Systems hilft vorbeugend. In beiden Fällen erhält der Administrator rechtzeitig eine Verständigung. Sowohl die CPU-Volllast über einen längeren Zeitraum wie auch der grenzüberschreitende Anstieg des verbrauchten Festplattenspeichers sind klassische Kandidaten für das 24×7-Monitoring. Damit ist kein Fehler behoben, aber genügend Zeit für den Verantwortlichen einen Stillstand des gesamten Mailsystems abzuwenden.

Der Quick-Check

Auch für die Schnelldiagnose („Ist mein System betroffen?„) ist der Monitoring-Server ein ideales Werkzeug. Ein Blick auf die Langzeitauswertungen (2 Stunden, 2 Tage, 30 Tage) ermöglichen sofort eine praktische Diagnose auf „Ungereimtheiten“ des laufenden Exchange-Servers. (XXX Abbildung PRTG)

iOS – Kein Zugang!?

Zugegeben, der Rat von Microsoft, die Verursacher auszusperren, ist besser als einen Stillstand der Produktivumgebung zu riskieren. Ist jene massive Beeinträchtigung einmal gegeben, so muss der Admin handeln.

Das Tool erster Wahl ist – so man über keine vorgeschaltete Loadbalancer-Umgebung oder ähnliches im Einsatz hat – die ActiveSync-Verwaltung des Exchange-Servers. Über Zugriffsrichtlinien kann hier auf vielfältige Weise geprüft und blockiert werden, welches Gerät Zugang zum Mailstore erhält und welche Verbindungen abgelehnt werden.

ActiveSync: Richtlinien für Zugriff oder nicht

Punkt 1 jeder ActiveSync-Konfiguration sollte ohnehin die „Quarantäne-Funktion“ für neue Geräte sein. In der Praxis bedeutet dies, dass beim ersten Verbindungsversuch eines neuen ActiveSync-Clients, dieser erst mal geblockt wird. Der Administrator und der Anwender erhalten eine Nachricht über die durchgeführte einstweilige Isolierung des Geräts. Mit wenigen Klicks kann dieser Zustand geändert werden und der neue Exchange-Client ist aktiviert und synchronisiert. Mithilfe dieser Konfiguration bleiben auch unerwünschte Geräte abseits des iOS-Bug vom Netzwerk fern.

Welche iOS-Geräte sind aktiviert?

Um eine Übersicht über alle aktiven Mobilgeräte in einer Exchange-Umgebung zu erhalten, eignet sich die PowerShell am besten. An dieser Stelle wollen wir nicht zu technisch werden und belassen es bei einem Verweis auf die Exchange-Spezialisten. Mithilfe der sogenannten Commandlets ist in Echtzeit eine Liste aller bereits konfigurierten Geräte erstellbar. Über spezielle Parameter (Betriebssystem, User-Agent, etc.) kann die Liste entsprechend gefiltert werden. Gleiches gilt für die entsprechenden Befehle, um genau jenen Geräten den Zugang zu verweigern, die bereits auf iOS-Version 6.1 oder 6.1.1 upgedated wurden.

Ein Plädoyer fürs Monitoring

Auf Fehler in diversen Softwareprodukten haben wir keinerlei Einfluss. Die mangelnde Auskunftsfreude von Apple gibt allerdings Grund zum Ärger. Ein offener Umgang mit eigenen Code-Schwachstellen wäre auch dem Administrator eine große Hilfe. Microsoft macht diesbezüglich einen vorbildlichen Job. Egal ob über diverse Communities und Foren bis hin zur Information über soziale Netzwerke: der Microsoft-Kunde weiß zumindest woran er ist und was – in Kürze – zu erwarten ist. In der Praxis ist das Wann der Problembehebung entscheidend. Nur so kann die interne IT entsprechend reagieren. Heute die gesamte Anzahl an iPhones aussperren und morgen das Problem als behoben melden – so macht man sich zum Idioten. Wir erinnern uns, als vor kurzer Zeit ebenfalls ein iOS-Bug die Exchange-Kalender unbrauchbar machte. Dort lief es ähnlich.

Dem Administrator bleibt nur die bestmöglichste Vorsorge. Die Überwachung aller entscheidenden Ressourcen eines Netzwerks ist mit Sicherheit der entscheidende Schritt in diese Richtung. Wer kann schon voraussagen, wann der nächste Bug schlagartig einen Teil der Produktivumgebung trifft.