Worum es in diesem Teil geht: wie man in eine Umgebung eingreift, die tagsüber und nachts gebraucht wird, ohne den Betrieb anzuhalten – und warum SharePoint langsam war, obwohl an SharePoint nichts kaputt war.
- Rolle: kommissarische Intervention
- Erneuert: Netzwerk, WLAN, Firewall-Technik
- Umgebung: Microsoft 365, Microsoft Entra ID, Entra-Anwendungsproxy, DATEV
Eingreifen, während gearbeitet wird
Die Beratung arbeitete Tag und Nacht. Ein Wartungsfenster, in dem niemand arbeitet, gab es kaum. Jeder Eingriff musste deshalb so geplant sein, dass er den Betrieb nicht unterbricht – oder nur für Minuten, zu einer Zeit, in der es am wenigsten trifft.
Das gelingt mit einer einfachen Regel: Das Neue wird neben dem Alten aufgebaut, getestet und erst dann umgeschaltet. Für jede Umschaltung steht vorher fest, wie man zurückkommt, wenn sie nicht greift. So haben wir das Netzwerk komplett erneuert, das WLAN ersetzt und die Firewall-Technik gegen leistungsfähigere Systeme getauscht – Schritt für Schritt, ohne dass das Haus stillstand.
Warum SharePoint langsam ist, obwohl SharePoint funktioniert
Wer SharePoint aus Microsoft 365 nutzt, erreicht es über das Internet. Jede Datei, jede Liste, jede Seite nimmt denselben Weg: vom Arbeitsplatz über WLAN oder Kabel, durch Switches und Firewall, über die Internetleitung zum Dienst und zurück. Ist einer dieser Abschnitte überlastet oder fehleranfällig, wird SharePoint langsam oder bricht ab – obwohl der Dienst selbst einwandfrei läuft.
- WLAN, das bei vielen gleichzeitigen Nutzern einbricht
- Switches, die Datenverkehr nicht schnell genug weiterleiten oder falsch verbunden sind
- Eine Firewall, die den Durchsatz einer modernen Umgebung nicht schafft
- Eine Internetleitung ohne Reserve, über die alles läuft
- Ein Zugriffsweg auf interne Anwendungen, der von all dem abhängt
In dieser Umgebung kam ein Punkt hinzu: Interne Anwendungen wurden über den Microsoft-Entra-Anwendungsproxy von außen erreichbar gemacht. Das ist eine saubere Lösung, solange das Netzwerk darunter trägt. Trägt es nicht, wirkt jede Schwäche doppelt.
Die Reihenfolge des Eingriffs
Wir haben dort begonnen, wo die meisten Ausfälle entstanden: im Netzwerk. Erst als es trug, haben wir an WLAN und Firewall weitergearbeitet, und erst danach an den Feinheiten der Microsoft-Umgebung. Diese Reihenfolge ist kein Zufall. Wer oben anfängt, behebt Symptome. Wer unten anfängt, beseitigt Ursachen – und oben verschwinden die Symptome von selbst.
Parallel lief der Betrieb weiter, und mit jedem Schritt wurde er stabiler. Das ist der Unterschied zwischen einem Eingriff und einem Umbau: Der Kunde merkt ihn an weniger Störungen, nicht an einer Baustelle.
Was das für Ihr Unternehmen bedeutet
Wenn SharePoint, Teams oder eine andere Cloud-Anwendung langsam ist, lohnt der Blick nach unten: auf WLAN, Netzwerk, Firewall und Internetleitung. Und wenn eingegriffen werden muss, dann so, dass das Neue neben dem Alten entsteht und jede Umschaltung einen Rückweg hat. So bleibt der Betrieb stehen, wo er hingehört – im Alltag, nicht im Umbau.
Verwandte Themen: Wer hier weiterdenkt, liest bei Serverraum-Kühlung, Microsoft 365 Copilot und Netzwerksegmentierung weiter.
