Outlook – Geburtstage von Kontakten um einen Tag falsch

Nach dem Import einer PST-Datei in Outlook oder direkt am Exchange stimmen plötzlich die hinterlegten Geburtstage der Kontakte nicht mehr. Teilweise sind sie um einen Tag nach vorne gerückt, teilweise sind sie aber noch korrekt. Dieses Problem besteht seit einigen Jahren, Microsoft wurde darüber bereits mehrmals informiert und trotzdem gibt es seitens Microsoft noch keine nachhaltige Lösung. Daher schauen wir uns in diesem Artikel an, wie das Problem überhaupt entsteht und wie wir es als Administratoren selbstständig lösen können.

 

Disclaimer

Das Problem, dass ein Geburtstag um einen Tag verschoben wird, existiert in unterschiedlichen Ausprägungen und in unterschiedlichen Szenarien. So kann es beispielsweise passieren, dass das Phänomen auch auf einem Apple Endgerät auftritt und alle Kontakte nach dem erstmaligen Sync betrifft (siehe Apple Support).

In diesem Post möchte ich explizit auf folgende Problemstellung eingehen:

  • Problem tritt nach dem Import/Verschieben von bestehenden Kontakten in ein Exchange Postfach auf
  • Es müssen nicht, es können aber alle Kontakte betroffen sein
  • Erstellt man einen neuen Kontakt, ist dieser in der Regel nicht betroffen

 

Problembeschreibung

Schauen wir uns zuerst an, wie sich das Problem überhaupt zeigt und reproduzieren lässt. Im Grunde ist es aber sehr einfach. Beim Import einer PST-Datei in ein Exchange Postfach werden neben Mails natürlich auch Kontakte importiert. Hat man bei diesen Kontakten ein Geburtsdatum hinterlegt, wird dieses ebenfalls übernommen. In einigen Fällen stellt man anschließend allerdings fest, dass der hinterlegte Geburtstag plötzlich um einen Tag nach vorne verlegt worden ist. Das Phänomen lässt sich aber meist nicht durchgehend bei allen Kontakten feststellen. Bei manchen Kontakte scheint auch nach dem Import das korrekte Geburtsdatum auf, bei anderen hingegen nicht.

Setzt man anschließend über Outlook das korrekte Geburtsdatum, so kann man folgende zwei Probleme feststellen:

  • Im Outlook Kalender hat man nun für einen Benutzer zwei Geburtstagstermine hinterlegt.
  • Im OWA scheinen beim Benutzer zwei Geburtstage auf, wobei man beide nicht löschen kann.

Von diesem Problem betroffen sind zum Zeitpunkt der Verfassung des Artikels (03.2025) mindestens folgende Versionen:

  • Exchange Server 2016
  • Exchange Server 2019
  • Exchange Online

Ein erneutes Importieren des PST-Files bringt keine Abhilfe. Auch lässt sich das Geburtsdatum direkt im OWA nicht editieren und wird mit der Fehlermeldung „Der Kontakt kann momentan nicht aktualisiert werden“ quittiert.

 

Analyse

Outlook, bzw. Exchange speichert die Daten auf dem Client in einer Art „Datenbank“. Innerhalb dieser Datenbank hat jedes Objekt eigene Schemas, Attribute und Werte, die das jeweilige Objekt und dessen Inhalt definieren. Das gilt natürlich auch für Kontakte. Outlook greift genauso auf diese Datenbank zu, abstrahiert die Attribute und stellt sie visuell dar. Dabei gibt es im Informationsspeicher Attribute (bzw. Properties), die zwar in der Datenbank existieren, von Outlook allerdings nicht exposed werden. Doch wie greifen wir darauf zu?

Microsoft stellt dafür den MFCMAPI Editor bereit. Dieser ist open Source, kann kostenlos heruntergeladen werden und bietet eine optimale Möglichkeit zum Debuggen solcher Probleme.

 

Schauen wir uns also mithilfe des MFCMAPI Editors einen Kontakt an, bei dem der Import erfolgreich war und es zu keinem Fehler kam. Hier stellt man fest, dass dieser Kontakt zwei Properties besitzt, die auf seinen Geburtsdatum hinweisen:

Im nächsten Schritt müssen wir die Properties nur noch mit einem defekten Kontakt vergleichen. Dabei wird man feststellen, dass dieser nicht zwei Geburtstags-Properties besitzt, sondern nur noch eins und genau hier entsteht das Problem.

 

Ursache

Client (Outlook)

Bei der Analyse konnten wir feststellen, dass sich die Properties der Kontakte dahingehend unterscheiden, dass der defekte User nur ein Geburtsdatum-Property besitzt – der funktionierende hingegen zwei unterschiedliche. Schauen wir uns daher die Properties genauer an.

Property Name Other Names Funktion
PR_BIRTHDAY PidTagBirthday Das Attribut spezifiziert den Geburtstag des Kontakts um 00:00 in UTC
PidLidBirthdayLocal Das Attribut spezifiziert den Geburtstag des Kontakts um 00:00 in der lokalen Zeit des Clients

Wir bewegen uns meist in der Zeitzone CET (Central European Time) und diese ist je nach Jahreszeit 1, bzw. 2 Stunden UTC voraus. Legt man also das Geburtsdatum für einen Kontakt auf den 06.02 und befindet sich in der CET Zeitzone, so wird das Datum im Attribut „PR_BIRTHDAY“ mit dem 05.02 abgelegt. Schauen wir uns zum besseren Verständnis weitere Beispiele an:

Hinterlegen des Geburtstags am 06.02.1998 in unterschiedlichen Zeitzonen
Timezone PR_BIRTHDAY PidLidBirthdayLocal
UTC 12:00:00.000 AM 06.02.1998 12:00:00.000 AM 06.02.1998
UTC+1 (CET) 11:00:00.000 PM 05.02.1998 12:00:00.000 AM 06.02.1998
UTC-1 01:00:00.000 AM 06.02.1998 12:00:00.000 AM 06.02.1998

Hingegen bezieht sich das Attribut „PidLidBirthdayLocal“ auf die lokale Zeit des Clients und somit wird dort das Datum auch immer korrekt mit dem 06.02 hinterlegt.

Soweit so so gut, doch warum besitzen die fehlerhaften Kontakte nur eine Property und nicht beide? Die Ursache ist so einfach wie traurig: Das Attribut „PidLidBirthdayLocal“ wurde erst mit Outlook 2010 eingeführt. Wenn ein Kontakt bereits in Outlook 2007 oder einer früheren Version angelegt wurde, existierte diese Property schlichtweg noch nicht.

 

Server (Exchange)

Steht beim Import am Exchange also nur das Attribut „PR_BIRTHDAY“ zur Verfügung, nimmt dieser einfach den Wert aus dem Attribut und speichert es als Geburtsdatum ab. Dabei honoriert der Exchange nicht, in welcher Zeitzone der Wert gesetzt wurde. Somit sind zwangsläufig alle Geburtsdaten falsch, die östlich des Nullmeridians (also UTC >=1) und in Outlook 2007 oder älter gesetzt wurden. Warum Microsoft trotz mehrmaliger Beschwerde diesen eindeutigen Bug nicht behebt, ist mir allerdings ein Rätsel.

 

Problemlösung

Da Microsoft nicht gewillt ist das Problem zu beheben, schauen wir uns im nächsten Artikel (COMING SOON) eine Variante an, wie wir es selbst fixen können.

You may also like...

Abonnieren
Benachrichtige mich bei
guest
1 Kommentar
Älteste
Neuste Meist bewertet
Inline Feedbacks
View all comments
Hans Vader
Hans Vader
2 Tage zuvor

Endlich eine Erklärung für dieses Mysterium.
Vielen Dank!

1
0
Hinterlass' doch deine Meinung zu diesem Artikelx