Heute stelle ich mal wieder eine kleine Erfahrung aus der Praxis vor, die vielleicht andere Administratoren treffen kann. Mich erreichte die Woche ein Hilferuf eines IT-Mitarbeiters, der einen Microsoft Exchange Server (on-Premises) wohl wegen End Of Support auf Exchange Online migriert hatte. Plötzlich beschwerte sich der Kunde, dass die Kalenderfarben "falsch" seien. Inzwischen liegt mir die Erklärung für die Ursache vor.
Microsoft Exchange Server Migration zu EO
Blog-Leser Maximilian hat sich die Woche bei mir gemeldet und schrieb in einer E-Mail, dass er bei einem Kunden im Rahmen einer Exchange-Migration auf einen Fehler beim Kalender gestoßen sei, für den er "ad-hoc" keine Lösung finde.
Es gab eine Exchange Migration
Er schrieb, dass er einen "Umzug von Exchange on-Prem 2012 auf Exo" vorgenommen habe. In diesem Kontext ergibt das aber keinen Sinn, denn einen Exchange Server 2012 gab es meines Wissens nicht. Gemeint ist wohl, dass er einen Microsoft Exchange Server (2016 oder 2019, die beide im Oktober 2025 End-of-Life erreicht haben), der unter Windows Server 2012 installiert war, auf Microsoft Exchange Online (EO) migriert hat.
Es gibt Kalender-Probleme
Der Leser schrieb, dass er beim Kunden anschließend in Probleme gelaufen sei. Bei der Migration von "Exchange 2012 (on-Prem) auf Ex" habe er die Kalender über eine .pst-Datei exportiert und später importiert habe. Nun bemängelt der Kunde aber, dass bei ihm selber die Farben (Kategorisierung) passt jedoch bei seiner Kollegin nicht. Hier der Kalender der Kollegin.
Beim Kunden selbst zeigte der Kalender dagegen die nachfolgenden Farben bei der Darstellung an.
Die Farben für Termine stimmen nicht. Aber was ist die Ursache? Bevor ich das Problem hier im Blog einstellen konnte, kam der Leser aber mit einer Erklärung.
Erklärung für das Verhalten
In einer Nachtragsmail schrieb er, dass ein Kollege meinte, dass die Kategorisierung bei so einer Übernahme verloren geht. Und sie lokal nur angezeigt wird, da sie da ja auf der lokalen .pst-Datei liegt.
Das habe zwar funktioniert, aber plötzlich seien nur waren die Farben komplett andere gewesen. Er interpretierte es so, dass sich der Outlook Client irgendwie anscheinend lokale Kategorien und die Kategorien von Microsoft "gezogen" habe. Und da die Farben für die Microsoft Kategorien (englische Sprache) nun "vergeben" waren, haben sich die lokalen Kategorien (deutsche Sprache) halt irgendwelche anderen Farben genommen.
Seine Lösung: Alle englischen Kategorien löschen und den deutschen Kategorien die richtigen Farben zuweisen. "Natürlich ist dass Problem nun gelöst jedoch schwirren in meinem Kopf noch viele Fragen zu dem Vorfall" schrieb der Leser in seiner Folgemail. Er hofft auf ein paar Meinungen aus der Leserschaft, ob seine Annahmen nicht doch falsch sind, und ob es bessere Lösungen zur Migration gibt.
MVP: 2013 – 2016
Naja, wenn man Postfächer per PST-Datei exportiert und dann wieder importiert, geht so einiges verloren.
Das ist keine Postfachmigration im klassischen Sinne, da muss man halt Abstriche machen, Stand der Technik.
Hybridstellung einrichten, hochmigrieren, dann sollten die Kategorien auch sauber sein.
Hat auch den Vorteil, dass die X500-Adressen, Posteingangsregeln, Archivregeln usw. erhalten bleiben…
Das Portieren von on-premise Kalendern auf die Outlook M365 Cloud erinnert mich sehr an das Problem in SharePoint Dateien, die beim Hochladen von lokalen Dateien auf Bibliotheken das Erstelldatum "vergessen", weil sie beim Hochladen für die Cloud "neu erstellt" wurden.
Bei Outlook sind Kalenderelemente ebenfalls auf dem individuellen Outlook Client mit Farben (Metadaten) einrichtbar und bei Outlook 2016 hatte ich bei meinen Kunden auch das Metadatenproblem, dass in Terminen in Outlook plötzlich nur noch auf die Verwaltung der Clients in Outlook zurückgestellt wurde und die Farben nur noch auf das Standardgrün zurück gestellt wurden.
Outlook online wusste dann nur, dass da ein Termin mit Farbe drin war, eben im Standard. Und jetzt mischt auch noch die KD (Künstliche Dummheit) – oh pardon, KI in Form des Copilot – mit. Der Copilot weiß nicht, was im Server an Farbregeln mal für alle Clients eingestellt war und stellt hald mangels online Regeln für die angeschlossenen Geräte online nur die Standard-Metadaten zur Verfügung. Diese Metadaten werden wohl nicht portiert, ähnlich bei PC nach SharePoint Dateien. Es ist in meinen Augen dummdreist, dass die KD überall in Microsoft Systemen und Servern jetzt rumpfuschen und Prozesse "anpassen" muss. Wahrscheinlich gibts dann demnächst ein weiteres kostenpflichtiges Zusatzfeature, was dann auf die ursprünglichen Terminfarbverwaltungseinstellungen wieder zurückstellen kann. Kostet dann aber.
Moin,
also irgendwie steht hier zu viel Exchange 2012 völlig alleine, wo anscheint Exchange 2019 auf Server 2012 gemeint ist?
Das mit den Kategorien ist mehr oder weniger normal und passiert auch bei einem Umzug von On-Prem zu On-Prem Exchange wenn das keine Migration ist.
Nach meiner Erinnerung war es am einfachsten auf dem alten System eine neue Notiz zu erstellen, dieser dann ALLE vorhandenen Kategorieren zu zuweisen und diese Kategorie dann auf dem neuen System zu importieren und dann gibt es da dann einen Befehl der Art Kategorien neue einlesen oder so ähnlich.
das ist ein Problem das immer schon bestand, sobald aus dem alten System exportiert und im neuen System wieder importiert wurde. die Termine kennen zwar ihren Kategorien, aber es gibt keine Farben mehr dazu da die namentliche Kategorie nicht mehr bekannt ist. Lösung ist eigentlich einfach: am alten System ein leere Notiz erstellen und dieser alle Kategorien zuweisen, diese Notiz dann auf den Desktop als .msg Datei ziehen, am neuen System diese msg Datei wieder in die Notizen ziehen, Rechtsklick auf die oberste Ebene des Postfachs – Datendateieigenschaften, hier gibt's unten eine Punkt irgendwas mit Farbzuordnungen wiederherstellen, und alle Kategorien sind wieder da, oft müssen dann aber nochmals die Farben entsprechend abgeändert werden.
Problem hatten wir auch bei Kalendermigrationen bei on-prem von 2013-2019.
Workaround bei uns: als Kalender-Nutzer anmelden und die Kategorien bei Hand wieder ändern.. lief danach wieder´.
Man hat also nicht "migriert" sondern .PST Jongleur gespielt! Da sollte einem halt klar sein das.pst eben nicht alles enthält… und das ist schon immer so!
"Umzug Exchange '2012' auf Exchange Online" … vermutlich ein simpler Tipfehler … ?
Exchange 2013 gab es ja und ist inzwischen auch aus dem Support, soweit ich weiß … ?!?!?
Wenn man (ich) diesen Blog so verfolgt und die üblichen Meldungen so liest … Windows, egal ob Server oder Client-OS sowie die Server-Dienste wie Exchange und Client-Anwendungen sind "komplett kaputt".
Bei all den "Code-Leichen" und vor allem Code-Umfang hat keiner mehr einen echten Überblick und m.E. ist es einfach Zeit, mal ein "Reset" zu machen, wie auch immer das bei wem aussehen mag.
Ich war lange Jahre seit den Neunzigern (damals auch noch Novell Netware und Novel-DOS) als Techniker & Admin im MS-Server und Client-Bereich unterwegs und ehrlich!
ICH bin HEILFROH", das ich DIESEN "Zirkus" NICHT MEHR mitmachen muss und den Kopf für den Software-Schund, den andere (aktuell) verzapfen, vor "meinen Kollegen und vor allem Chefs und Finanzcontroller" hinhalten und begründen zu müssen.
Dank einer Erbschaft habe ich mich beruflich komplett aus der IT zurück gezogen und kümmere mich um meine Finca auf Malle. Das ist echtes LEBEN!
Der einzige "Goldene Käfig", den ich noch "beackere", ist Google-Android …
Meine privaten Rechner bleiben auf Win10. Alle anderen Nutzer sollen zusehen, wie sie klarkommen.
Ich hab einfach keinen Bock mehr auf IT!
32 Jahre IT an vorderster Front reichen, sagt auch meine Haarfarbe.
Vielen Dank an dieser Stelle an Microsoft, Broadcom sowie alle anderen ehemaligen guten Software-Firmen, die u.a. von "Heuschrecken" … äh "Finanzinvestoren" übernommen wurden und die Produkte zwar profitabler, aber diese auch kaputt gemacht haben (Teamviewer, Kerio, VMware u.v.a.m.)
Aber IT Blogs ließt du schon noch!?
> Aber IT Blogs ließt du schon noch!?
Das glaube ich nicht, denn *liest* und *ließt* sind zwei verschiedene Dinge.
> Bei all den "Code-Leichen" und vor allem Code-Umfang hat keiner mehr einen echten Überblick und m.E. ist es einfach Zeit, mal ein "Reset" zu machen, wie auch immer das bei wem aussehen mag.
Gibt es doch. Nennt sich Linux. Die Code-Basis steht ständig unter globaler Prüfung.
Exchange 2019 auf Server 2012 war es sicher nicht, denn Exchage 2019 lässt sich nicht auf Server 2012/2012R2 installieren.
Da geht nur Exchange 2013 und 2016.
Exchange 2019 erfordert mindestens Server 2016.
Daher gehe ich von einem Tippfehler aus und es war Exchange 2013, 2016 oder 2019 gemeint.
Und was die Migration angeht:
Das über eine .pst zu machen ist von Microsoft nicht empfohlen.
Es wird auch allgemein davon abgeraten.
Warum? Gerade bei Kleinstunternehmen < 20 Personen ist doch eine Hybridstellung viel zu aufwändig, vor allem wenn man in diesem Zug auch gleich noch vom AD komplett weg möchte, weil man das eigentlich nicht braucht.
Habe ich dieses WE erst wieder gemacht und funktioniert mit etwas Vorbereitung relativ gut.
Weil in einer .pst nicht alle Informationen und Daten drin stecken!
Eine .pst ist ein Postfachspeicher.
In der wird z.B. nicht die Konfiguration von Outlook und OWA gespeichert.
Sieht man ja am Beispiel, das die Konfiguration der Kalenderfarben nicht übernommen wurde, weil diese Info eben nicht in der .pst gespeichert wird.
Und bei Benutzung einer .pst ist immer eine Downtime nötig.
Und genau deshalb ist auch eine .pst nicht zur Datenmigration geeignet.
Auch bei der On-Prem-Migration von einer Exchangeversion auf eine neuere Exchangeversion ist die Benutzung einer .pst nicht empfohlen und war es auch noch nie.
Ich nutze für Exchange Migrationen immer die Software von CodeTwo. Insbesondere für die Delta Migration ist das eine saubere und schnelle Lösung. Keine Ahnung ob damit die Kalenderfarben übernommen werden, aber bisher hat sich kein Kunde bei mir beschwert.
Ich würde niemals PST Dateien rüber ziehen.
Betr. Jan sagt 2. November 2025 um 19:57 Uhr: "Insbesondere für die Delta Migration ist das eine saubere und schnelle Lösung.":
Pfff! Arbeitest Du für die Bude?
Da schenke ich den von deutlicher Kritik geprägten Ausführungen von Frank Carius (1), dann doch mehr Glauben. Zitat (u. a.): " DeltaSync kopiert nur Elemente aus der Quelle ins Ziel, die noch nicht in der Datenbank liegen.
Bereits migrierte Elemente werden nicht mehr migriert, selbst wenn diese geändert wurden. Das hat umfangreiche Auswirklungen:
Löschen in der Quelle -> wird im Ziel NICHT entfernt
Änderung in der Quelle -> Wird im Ziel NICHT aktualisiert, z.B. geänderte Termine, „Gelesen"-Status von Mails etc.
Verschobene Elemente werden im Zielordner als neu erkannt -> Dubletten"
Für eine Schwimmbadkiosk-Migration mag das verschmerzbar sein, bei Jahresumsätzen > 1 Mio braucht 's ausgereiftere Lösungen.
_
(1) https://www.msxfaq.de/cloud/exchangeonline/migration/3rd_party_migration_mit_codetwo.htm
nein ich arbeite nicht für "diesen Laden".
Die Lösung muss zum Kunden passen. Ein Kunde mit 1000 oder mehr Mitarbeitern braucht eine andere Lösung als Kunden mit 30 oder weniger Mitarbeiter.
Wie auch andere geschrieben haben, ist eine Hybriedstellung für KMU oft overkill.
Ich habe im Artikel nichts von Großunternehmen gelesen und habe mich daher auf kleine Unternehmen bezogen. Hätte ich vlt. dazu schreiben sollen. Und dafür eignet sich CodeTwo sehr gut. Besser als PST Dateien hin und her zu kopieren.
Gerade bei kleinen Kunden spielt das keine Rolle, ob in der Quelle etwas gelöscht wurde und dann im Ziel nicht.
Die übliche Migration für solche kleine Kunden sieht wie folgt aus:
Freitag ab 17 Uhr arbeitet keiner mehr. Man startet die 1. Migration, stellt die DNS Einträge auf den vorbereiteten Tenant um und lässt 24 Stunden später noch mal das Delta syncen. Sonntags Abends checkt man mit dem Firmeninhaber noch mal kurz ob alles gut ist und Montags können alle normal arbeiten.
Ein Unternehmen das Rund um die Uhr arbeitet mit vielen Mitarbeitern, wird das nicht reichen. Aber wenn jemand PST Dateien kopiert, wird das wohl nicht der Fall gewesen sein.
Deine Wortwahl "Schwimmbadkiosk-Migration" kommt ziemlich Hochnäsig daher. Vermutlich weißt du das nicht, aber es gibt halt auch noch was anderes als Konzerne ;)
Verwenden wir auch sehr häufig das Tool. In unseren meist KMU Umfeldern passt das auch gut.
Bis ich da eine Hybrid aufgebaut und vor allem danach aufgelöst habe ist das die schnellere Lösung.
Hat sicher schon 50x tiptop funktioniert.
Da reicht die EXO Migration allemal aus, denn da kannst sagen wann es los geht und der Synced die ganze Zeit weiter, bist jemand entscheidet wann Ende ist und macht dann den Abschluß. Das klappt mit CSV Import ohne weiteres in 100er Häppchen jeden Tag usw. :-)
Betr. "Insbesondere für die Delta Migration ist das eine saubere und schnelle Lösung.":
Pfff! Arbeitest Du für die Bude?
Da schenke ich den von deutlicher Kritik geprägten Ausführungen von Frank Carius (1), dann doch mehr Glauben. Zitat (u. a.): " DeltaSync kopiert nur Elemente aus der Quelle ins Ziel, die noch nicht in der Datenbank liegen.
Bereits migrierte Elemente werden nicht mehr migriert, selbst wenn diese geändert wurden. Das hat umfangreiche Auswirklungen:
Löschen in der Quelle -> wird im Ziel NICHT entfernt
Änderung in der Quelle -> Wird im Ziel NICHT aktualisiert, z.B. geänderte Termine, „Gelesen"-Status von Mails etc.
Verschobene Elemente werden im Zielordner als neu erkannt -> Dubletten"
Für eine Schwimmbadkiosk-Migration mag das verschmerzbar sein, bei Jahresumsätzen > 1 Mio braucht 's ausgereiftere Lösungen.
_
(1) https://www.msxfaq.de/cloud/exchangeonline/migration/3rd_party_migration_mit_codetwo.htm
Dies passiert sogar bei aktuellen M365 Systemen und freigegeben Kalendern.
Die Sekretärin hat Zugriff auf den GL Kalender und darf bearbeiten und setzt auch die Kategorien.
Letzte Woche dann alles einfarbig und keine Berechtigung mehr. Haben den Kalender entfernt und neu hi zugefügt, da gingen immerhin die Bearbeitungen. Aber die Kategorien waren erst 2 Tage später wieder da.
Ursache unbekannt, aber das sind quasi fast tägliche Microsoft Spielereien
Gut, zunächst mal. Exchange kenne ich 2010 oder 2013. 2012… unbekannt.
Bei kleineren Umgebungen kann man dann z.B. eine Cutover Migration machen:
https://learn.microsoft.com/en-us/exchange/mailbox-migration/cutover-migration-to-office-365
Schlank und vielleicht an einem Wochenende möglich.
Wichtig, GENAU nach Anleitung vorgehen… weist man die Lizenzen vorher zu, hat man Mailboxen in der Cloud – vielleicht ist das hier passiert und daher der Weg über PST.
Wichtig, vielleicht machst Du dazu noch einen Beitrag.
Exchange 2016/19 bekommen ein ESU für 6 Monate, wenn man es bucht.
Nach Umstellung auf Exchange SE wird mit dem nächsten CU von Exchange SE die Unterstützung für Exchange 2019 und früher OnPremis sterben. Wer also noch etwas OnPremise behält, braucht auch da SE.
Endlich stirbt der Zopf – aus Sicherheitssicht ein Gewinn.