Tools: TerminPatch

Wie Sie aus Termine mit Outlook sicher wissen, ist die Einstellung der Zeitzone und die automatische Umstellung von Sommerzeit auf Winterzeit ein wichtiger Faktor bei der Arbeit mit Outlook. Und genauso oft stellen wir immer mal wieder fest, dass es Anwender gibt, die es entweder nicht wissen oder den vermeintlich "einfachen" Weg wählen und die automatische Sommer/WinterzeitUmstellung deaktivieren oder gar die falsche Zeitzone eingestellt haben. Dies ist aber sicher der falsche Weg, da damit Termine aber auf Mails und das Datum von Dateien etc. in der Sommerzeit um eine Stunde verschoben sind. So offenbart TZEDIT die aktuellen umschaltzeiten der Zeitzone

Zeitzonen

Stimmt die Zeitzone nicht und ist vor allem die automatische Umstellung auf Sommerzeit deaktiviert, dann werden die "falschen" Zeiten im System gespeichert.

Kurz: Es passiert immer wieder, dass Benutzer ihre Termine in Outlook speichern und bei der nächsten umschaltung fällt auf, dass die Termine alle um eine Stunde verschoben sind. Meist wird dies zuerst bei ganztägigen Terminen bemerkt, die dann eben von 23:00 uhr bis 22:59 uhr oder von 01:00 uhr bis 00:59 uhr im Kalender auftauchen.

Die Lösung und deren Einschränkungen

Das Problem ist klar: Termine wurden mit einem Outlook auf einem PC gespeichert, der die "falsche" Zeitzone hatte und damit sind die GMT-Zeiten im Termin falsch. Analog zu den Skripten Feiertage und MBReport kann ich also durch ein Skript nun alle Termine aller Postfächer einfach lesen und sogar "verschieben". Allerdings kann das Skript natürlich nicht erkennen, ob der Termin nun mit einer falschem uhrzeit oder richtigen uhrzeit angelegt wurde.

Der Einsatz ist also nur dann effektiv, wenn Sie genau wissen, welches Postfach bis wann welche falsche Termine angelegt hat. Fein raus ist natürlich derjenige, dessen Client alle die "falsche" Zeitzone haben und dann nachts einmal die Termine verschoben werden und am nächsten Tag alle PCs umgestellt werden. Das ist aber auch nicht sicher, da Anwender ja auch über PDAs, OWA etc. Termine eintragen können oder von anderen Personen eine Einladung mit der "richtigen" Zeit erhalten haben. Es bleibt also immer ein "Restrisiko".

Letztlich läuft es daraus hinaus zu fragen: Sind 90% Termin falsch und 10% richtig oder nach dem "Move" dann 90% richtig und 10% falsch.

Weitere Probleme gibt es noch, die nicht verschwiegen werden sollen:

  • Einladung von Extern
    Wenn ich mit einem "richtigen" PC einen Termin am 1. Mai um 11:00 (MESZ +2) plane und jemand mit falscher Zeitzone einlade, dann geht eine Mail mit 09:00 (GMT) beim Empfänger ein und wird bei ihnen zwar falsch um 10:00 (MEZ+1) angezeigt aber im Kalender "richtig" mit 09:00 GMT eingetragen. Dieser Termin wird dann durch die Verschiebung "falsch".
  • Einladungen nach Extern
    Wurde ein Termin als Einladung versendet, dann wird dieser zwar "richtig" verschoben aber kein Update der Einladung versendet. Das ist sogar von Vorteil, das der Termin am 1.Mail 11:00 als 10:00 gespeichert und versandt wurde aber der Empfänger diesen sowieso als Termin mit falscher Zeit erhalten und diesen wohl selbst schon korrigiert hat.
  • AddOns
    Zugriffe auf Exchange wie OWA, ActiveSync, Blackberry etc. nutzen teilweise eigene Zeitzonen bzw. die Einstellungen der Server. Es kann also sein, dass über diesen Weg angelegte Termine "richtig" in der Datenbank stehen und nun "falsch" verschoben werden.
  • Ganztägige Termine
    Diese Einträge haben ein eigenes Bit und keine "Zeit". Hier steht nur das Datum und sie werden nicht verschoben.
  • Wiederkehrende Termine
    Diese Elemente sind besonders zu behandeln, da hier kein Start/Endetermin vorliegt, sondern ein Zeitplan enthält. Diese Termine werden aktuell übersprungen. Man kann zwar das "Recurrence Pattern" auslesen (http://msdn.microsoft.com/en-us/library/ms526361(v=exchg.10).aspx) aber per CDO kann man nicht die "Exceptions erfassen. Ein Verschieben eines solchen Termins überschreibt alle Ausnahmen. Der Teil ist im Code enthalten aber per Default auskommentiert.

If any change is made to the recurrence pattern after one or more individual recurrences have been instantiated, some or all of them may be automatically deleted. Microsoft® Outlook® deletes all individual recurrences, while Microsoft® Schedule+ deletes only those that are earlier than the new PatternStartDate or later than the new PatternEndDate. CDO determines what your active calendar store is and deletes recurrences in the appropriate manner.
Quelle: http://msdn.microsoft.com/en-us/library/ms526361(v=exchg.10).aspx.

  • Free/Busy
    Die Termine werden einfach nur verschoben. Da dazu allerdings kein Outlook verwendet wird, werden die Frei/Belegt-Zeiten nicht aktualisiert. Erst wenn der Anwender das nächste mal Outlook startet, erfolgt eine Aktualisierung. Die Anzeige der Einladungen ist daher einige Zeit lang unstimmig.

Zeitzonen, Umstellung en und die Probleme

Um Sie etwas für die Problematik zu sensibilisieren, ist die Änderung der Sommerzeit/Winterzeit-Umstellung in den uSA im Jahre 2007.

Periode DST-Anfangstermin DST-End-Termin

Neue DST-Periode

11. März 2007

4. November 2007

Vorherige DST-Periode

1. April 2007

28. Oktober 2007

Das kann dann zu folgender Problematik führen:

Zeitpunkt Aktion Ergebnis

10.Januar

Mitarbeiter trägt einen Termin ein:
Start: 20. März 2007: 12:00 uhr Lokalzeit

Outlook errechnet anhand der alten Zeitzoneneinstellungen im Betriebssystem die GMT-Zeit auf  (-0800)
Start: 20. März 2007: 04:00 uhr GMT

1. Februar

Windows Update installiert das Zeitzonenupdate. Windows weiß nun, dass die Sommerzeit früher anfängt

Termin im Exchange Server ändert sich erst mal nicht

2 Feb

Mitarbeiter trägt noch einen Termin ein:
Start: 21. März 2007: 12:00 uhr Lokalzeit

Outlook errechnet anhand der aktuellen Zeitzoneneinstellungen im Betriebssystem die GMT-Zeit auf  (-0900)
Start: 20. März 2007: 03:00 uhr GMT

3. Februar

Mitarbeiter schaut sich beide Termine an

Outlook liest den Termin von Exchange und nutzt die aktuelle Zeitzoneninformation. Entsprechend der Zeitzone errechnet Outlook aber nun +0900.
Ein Termin ist um eine Stunde verschoben

Allee Termine , die vor dem Zeitzonenupdate angelegt wurden und zwischen dem 11. März und 1.April liegen, sind daher um eine Stunde verschoben. Allerdings ist es für eine Software nicht möglich zu erkennen, welcher Termin vor und welcher Termin nach dem Update der Zeitzone auf dem Client angelegt wurde.

Wenn Sie also automatisch die Termine verschieben, dann darf eine Software nur die Termine anfassen, die im fraglichen Zeitraum liegen aber vor dem Update auf dem Client erstellt wurde. Leider werden die wenigsten Firmen diese Kombination sicherstellen können.

Aus meiner Sicht ist es am einfachsten, wenn Sie die Anwender diese Problematik selbst lösen lassen. Vermutlich werden wenige Personen so weit in die Zukunft "stundengenauer" Termine eintragen. Eine manuelle Korrektur NACH dem Zeitzonenupdate ist vermutlich problemlos. Ansonsten würde ich den Anwendern direkt nach dem Zeitzonenupdate das Hilfsprogramm an die Hand geben, um die Termine zu verschieben oder diese zentral zu verschieben.
Probleme haben nur die Firmen, die das Update der Zeitzonen nicht zeitlich steuern können. Zum Glück betrifft diese Problematik aktuell eher die uSA. Aber das Problem ist sehr ähnlich, wenn Sie die automatische Sommerzeit/Winterzeit-Umstellung z.B. deaktiviert hatten

Aufgrund dieser Problematik hat Microsoft zwei Programme entwickelt, die in den uSA die Termine mittels Outlook oder auf dem Exchange Server zentral verschieben

Serientermine und Abweichungen

Das Verschieben von Termine könnte so einfach sein, wenn es auch nur "einfache Termine" wären. Nun können Outlook und Exchange aber auch "Serientermine, d.h. die zwar nur einmal im Exchange Store abgelegt sind, aber ein Wiederholungsintervall haben. Das führt dazu, dass die Startzeit des Termins selbst nicht mehr relevant ist, sondern die Startzeit des "RecurrencePattern-Object".

Und damit ist es nicht genug. Wenn Sie dann nachträglich einen Termin der Serie verschieben, dann wird daraus eine Exception, die per Outlook noch einfach zu lesen ist aber mit CDO und VBScript scheinbar nicht erreichbar ist. Zumindest ist es mir nicht gelungen.

Leider gibt es genau die "Exceptions" nicht unter CDO, sondern nur im Outlook Objektmodell. Ken Slovak (MVP Outlook) hat das in einem Forenbeitrag auch schön beschrieben:

It's pretty much the same in CDO 1.21 code as in Outlook object model code, except you can only work with a CDO AppointmentItem if the item lives in a default Calendar folder. There also is no Exceptions collection or GetOccurrence method as there is in the Outlook object model.
http://www.winserverkb.com/Uwe/Forum.aspx/exchange-apps/850/Exceptions-to-recurring-appointments-with-CDO-not-CDOEX

Die gleiche Quelle enthält auch den Versuch, die Binärinformation des entsprechenden Felds zu decodieren. Ich habe mir erlaubt, die Infos als Textdatei hier mit einzubinden, da einige Der Links schon wieder nicht erreichbar waren.

MAPI Recurrence Pattern and Exception Data Structure Reference
Quelle: Newsgroup: microsoft.public.exchange.applications im Jahre 2004

Die folgenden Zitate beschreiben gut die "Besonderheiten" bei der Betrachtung von "Wiederkehrenden Terminen"

If you make this appointment recurring by calling its GetRecurrencePattern method, its StartTime, EndTime, and AllDayEvent properties are disabled, and any attempt to access them returns CdoE_NO_SUPPORT
http://msdn.microsoft.com/en-us/library/ms528308(v=exchg.10).aspx

The appointment's StartTime and EndTime properties are always held internally in uTC (Coordinated universal Time, also known as GMT). By contrast, the RecurrencePattern object's StartTime and EndTime properties are always held internally in the organizer's current time zone. However, all these properties are converted to the local messaging user's current time zone whenever they are displayed or read programmatically.
http://msdn.microsoft.com/en-us/library/ms528308(v=exchg.10).aspx

The original appointment's StartTime, EndTime, and AllDayEvent properties are disabled whenever its IsRecurring property is True. Any attempt to access them while in this state returns CdoE_NO_SUPPORT. You must use the recurrence pattern's PatternStartDate, PatternEndDate, StartTime, and EndTime properties to edit a recurring series.
Quelle: Exchange Server 2003 - AppointmentItem Object http://msdn.microsoft.com/library/default.asp?URL=/library/en-us/cdo/html/aa155812-5908-4304-a855-3e9199df252a.asp

Wenn Sie z.B. in Outlook die "Serie" nachträglich verändern, dann werden aber genau diese Abweichungen wieder gelöscht.

Terminanfragen und Teilnehmer

Wenn Sie mit Outlook einen Termin erstellen und andere Personen einladen, dann sendet Outlook an die Teilnehmer eine "Terminanfrage", die diese auch bestätigen können. Wenn Sie solch einen Termin per Outlook verschieben, dann wird an die Teilnehmer eine "Aktualisierung" gesendet.

Das passiert beim Verschieben mit CDO leider nicht. Die anderen Teilnehmer bekommen also nicht mit, wenn TerminPatch den Termin verschiebt.

Dieser Fall ist noch nicht getestet

Erinnerungen

Und zuletzt kann es passieren, das Erinnerungen an Termine erneut hochpoppen, da der Termin ja "geändert" wurde. Wann das passiert, konnte ich noch nicht genau eingrenzen.

Funktionsweise

Ein Flussdiagramm verdeutlicht vielleicht am schnellsten, wie das VBScript die verschiedenen Fälle behandelt.

Alle Aktionen, die mit einem "Grünen Haken" bedient werden, sind fehlerfrei. Aktuell knifflig sind die Serientermine, die durch die Existenz von Anlagen mir den Hinweis geben, dass es "Ausnahmen" gibt. Enden diese Serientermine in der Vergangenheit, dann werden sie nicht verschoben (SkipRecOld) und wenn diese in der Zukunft enden, dann werden Sie aktuell nur "gemeldet". Der Anwender kann diese Termine dann immer noch selbst verschieben. Die Bedeutung der Aktionen, die auch in der Protokolldatei verwendet werden, sind:

  • Skipallday
    Das ist ein ganztägiger Termin und muss nicht verschoben werden. Er hat keinen Start oder Endezeitpunkt
  • MoveCal
    Ein ganz normaler Termin, der in der fraglichen Sommerzeit "falsch" ist und entsprechend verschoben wird
  • SkipOutDate
    Alle restlichen Einzeltermine. Es bleiben ja nur „Einzeltermine“ außerhalb des Zeitfensters
  • SkipOutofDateRec
    Der Startzeitpunkt Serientermin ist außerhalb des Sommerzeitfensters und daher korrekt und wird nicht verschoben.
  • MovRec
    Dieser Serientermin beginnt in der Sommerzeit und hat keine Ausnahmen und kann daher gefahrlos verschoben werden.
  • SkipRecAtt
    Der Serientermin hat Anlagen, d.h. aktuell ist das das Kriterium um Ausnahmen zu erkennen. Er sollte nicht verschoben werden (Verlust der Ausnahmen). Statt dessen Kann der Anwender hingewiesen werden, dass diese "wenigen" Termine von ihm manuell zu bearbeiten sind.
  • SkipRecOld
    Der Serientermin ist „zu alt“, d.h. er endet in der Vergangenheit. Er ist unkritisch, aber wird nicht verschoben, da dann die Ausnahmen verloren gingen. Dann lassen wir ihn lieber "falsch" in der Vergangenheit.

Terminen haben den netten Vorteil, dass die Termine der Vergangenheit eigentlich nicht wirklich "kritisch" sind, kaum jemand wird das wirklich bemerken. Und in der Regel sind die Termine in der Zukunft niciht allzu umfangreich. Wer plant schon Jahre im Voraus, während man schon Jahre in die Vergangenheit zurückblicken kann.

Parameter

Anfangs wurde das Skript allein über Konstanten im Header gesteuert bzw. war statisch. Mittlerweile gibt es zwei Parameter, die in VBScript mit übergeben werden können

  • /mode:write
    Aktiviert den Write-Mode ohne im Code was ändern zu müssen.
  • /samaccountfilter:"username"
    Erlaubt bei der LDAP-Suche einen Filter auf das Feld "SamAccountname", z.B. Um die Logik auf nur ein Postfach anzuwenden.

Wichtig: VBScript ist sehr penibel bei der Auswertung der Parameter. ein "/samaccountfilter=filter" funktioniert z.B.: nicht. Es muss ein "Doppelpunkt" sein.

Download

Das Script ist auf dem Server gestartet und benötigt daher keinen Client. Es eignet sich daher für massenhafte Änderungen einer großen Anzahl von Postfächern ebenso wie für wenige Anwender, die trotzdem nicht am Arbeitsplatz gestört werden sollen.

Dieses Skript ist kein öffentlicher Download

Das Skript ist auf der MSXFAQ nicht zum Download verfügbar, da es vor langer Zeit bei einem Kunden eingesetzt wurde und nun mehrere Jahre quasi "verstaubt" ist. Wie Sie vielleicht auf der MSXFAQ gesehen haben, gibt es noch einige andere Tools, die eine vergleichbare Rahmenfunktion haben (z.B. Um Feiertage in allen Kalendern zu ergänzen) Letztlich sind all diese Skripte sehr ähnlich, da sie mit einem privilegierten Benutzer durch alle Postfächer laufen und mit den Objekten etwas verändern. Bei Terminen ist aber das Problem, dass es hier kein "Automatismus" geben kann, d.h. eine 100% funktionierende Lösung für jedermann, sondern dann man den inneren Teil der Schleife durch alle Postfächer dann doch individuell anpassen muss. Schließlich soll das Skript ja nicht alle Termine verschieben, sondern nur die, die mit einer falschen Zeitzone eingegeben wurde. Das kann man den Terminen aber nicht "ansehen", da sie alle mit GMT gespeichert wurden. Knifflig sind auch Sonderfälle wie wiederkehrende Termine und Termine mit Einladungen. müssen hier dann auch die Einladungen neu versendet werden oder darf nur der Termin geändert werden ?. Schließlich weiß das Skript ja nicht, ob die Gegenseite alles "richtig" hat.

Also muss individuell ein Verfahren entwickelt werden, welche Termine in welchen Bereichen wie verändert werden sollen.

Unterstützung durch Net at Work:
Sollten Sie daher das Problem haben, dass Termine "verschoben" sind, so können wir Sie zuerst bei der korrekten Konfiguration ihrer Clients unterstützen und dann die schiefen Termine wieder gerade rücken. Sprechen Sie uns einfach an.

Wenn Sie alleine die Verschiebung von Terminen entwickeln wollen, dann schauen Sie sich einfach mal mein einfaches VBScript Feiertage an. Es trägt in jeden Kalender die Feiertage ein und kann als Basis für eine eigene Weiterentwicklung sein. Um die erforderlichen für zentrale Änderungen zu haben, sollten Sie die Seite Mailboxrechte gelesen haben.

Zeitzone auf PC umstellen

Wenn dann alle Termine im Postfach umgestellt sind, dann sollten Sie natürlich sehr schnell dafür sorgen, dass auch alle PCs nun die Sommerzeit auch richtig errechnen. Ansonsten legen ihre Mitarbeiter neue Termine wieder "falsch" an und die bereits korrigierten Termine erscheinen um eine Stunde verschoben. Die Einstellungen sind "pro Maschine" in der Registrierung gespeichert. 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"Bias"=dword:ffffffc4
"StandardName"="Westeuropäische Normalzeit"
"StandardBias"=dword:00000000
"StandardStart"=hex:00,00,0a,00,05,00,03,00,00,00,00,00,00,00,00,00
"DaylightName"="Westeuropäische Sommerzeit"
"DaylightBias"=dword:ffffffc4
"DaylightStart"=hex:00,00,03,00,05,00,02,00,00,00,00,00,00,00,00,00
"ActiveTimeBias"=dword:ffffff88
"DisableAutoDaylightTimeSet"=dword:00000000

Diese REG-Datei können Sie z.B.: über die Gruppenrichtlinien (Startup-Skript) importieren. Ein Import durch das Anmeldeskript ist nur da möglich, wo die Benutzer auch lokale Administratoren sind. Alternativ können Sie aus der REG-Datei natürlich auch eine ADM-Vorlage für die Gruppenrichtlinien machen.

REG-Datei zum Import per Skript oder Softwareverteilung
terminpatch-sommereinterzeitumstellen.reg
(Vielen Dank an Herrn Roschinski, ulm, welcher mir die REG-Datei überlassen hat)
ADM Vorlage für Gruppenrichtlinien.
terminpatch-sommerwinterzeitumstellen.adm

Hilfsmitteln von Microsoft: MSEXTMZ

Dieses Programm verschiebt die Termine mehrerer Postfächer auf dem Server:

Microsoft Exchange Calendar Update Tool
http://www.microsoft.com/downloads/details.aspx?familyid=a9336886-4b28-4010-9416-36d38429438d&mg_id=10107&displaylang=en
oder
http://go.microsoft.com/?linkid=6294107

Siehe auch

  • 933185 A virtual machine is available to help you deploy daylight saving time 2007 calendar Updates in an Exchange organization
  • 941018 How to address daylight saving time by using the Exchange Calendar Update Tool
  • Exchange Calendar Update Tool package
    http://www.microsoft.com/downloads/details.aspx?FamilyId=27BB0EE2-03AC-4E5B-AEC5-3E878490FCE1&displaylang=en

Primär ist das Tool wohl dazu, die Änderungen der amerikanischen Zeitzonen im Jahr 2007 umzusetzen. Voraussetzungen sind z.B. .NET 2.0  Framework und der Einsatz auf einem "englischen Betriebssystem". Wenn man sich dann die Beschreibung des Tools durchliest, dann wird man das Gefühl nicht los, dass da jemand ohne Exchange Erfahrung ein Tool geschrieben hat.

  • Postfachrechte
    Die Rechte kann man auch einfach über einen Eintrag auf den Store erhalten. Da muss man nicht per VBScript bei allen AD-Objekten die Rechte addieren.
  • MAPI-Profilerstellung
    Das MAPI-Profil muss man auch nicht mehr mit PRF-Dateien erstellen, wenn man CDO nutzt.
  • Profilauswahl
    Es wird erklärt, wie man einstellt, dass Outlook beim Start MAPI-Profils nicht nachfragen, welches Profile genutzt wird. Dies ist bei passender Programmierung nicht relevant
  • Zweistufigkeit
    Das Tool muss einmal erst eine Liste der Postfächer erstellen und im zweiten Schritt diese dann bearbeiten. Ein einfacher LDAP-Filter wäre hier sicher eleganter gewesen.

TZMove

Auch für den Einsatz auf dem Client gibt es von Microsoft ein Hilfsprogramm, welches leider nicht Deutsch verfügbar ist. Das Programm erlaubt das Verschieben von Terminen für EIN Postfach. Es ist also eher für den Einsatz auf dem Client geeignet denn für den Server

Time Zone Data Update Tool für Microsoft Office Outlook (8 MB)
http://go.microsoft.com/?linkid=6294071
http://www.microsoft.com/downloads/details.aspx?familyid=%20E343A233-B9C8-4652-9DD8-AE0F1AF62568&displaylang=en (EN/ES/FR)
931667 How to address the daylight saving time changes in 2007 by using the Time Zone Data Update Tool für Microsoft Office Outlook

Wenn Sie die herunter geladene Datei starten, dann packt sich das Programm nicht nur aus, sondern startet sich auch sofort. In dieser Betriebs erreichen Sie aber nicht ihre Ziel. Sie sehen folgendes Fenster.

TZMOVE1

 

Brechen Sie daher das Programm hier ab und starten es manuell über die Kommandozeile mit einem besonderen Parameter:

"%PROGRAMFILES%\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool\tzmove.exe" /PHYSICALMOVE

Sie erkennen die Funktion des Schalters, wenn Sie zwei Zeitzonen (Alt und neu) auswählen können. 

TZMove Physicalmove

Sie sehen gut, dass das Programm hier alle Termine in meinem Postfach von einer Zeitzone in eine andere Zeitzone verschieben kann. Hier kann man auch manuell eingreifen. Ich habe es noch nicht selbst experimentell nachgestellt aber ich könnte mir folgendes vorstellen:

  • Keine Sommerzeit/Winterzeit
    Stellen Sie sich vor, Sie betreiben ihr Netzwerk aktuell so, dass Sie die automatische Umstellung deaktiviert haben. Entsprechend sind ja alle Termine im Sommer um eine Stunde "falsch" gespeichert worden.
  • andere Zeitzone anpassen
    Sie könnten ja nun eine andere Zeitzone, z.B. "GMT+0100 Zentralafrika" mit TZEDIT so verändern,  dass Sie der eigenen Zeitzone entspricht, aber gar keine Sommer/Winterzeit-Bereiche kennt. Damit hat die Einstellung, dass die umschaltung deaktiviert wurde, keine Auswirkung.
  • Umschaltung aktivieren
    Nun könnten Sie auf dem PC die automatische Sommerzeit/WinterzeitUmstellung aktivieren.
  • TZMove Ausführen
    Nun könnten Sie mit TZMOVE einfach die Termine derart ändern, dass Sie TZMOVE sagen, dass die Termine alle als "GMT+0100 Zentralafrika" eingestellt wurden und nun nach "GMT+0100 Berlin" verschoben werden müssen
  • "GMT+0100 Zentralafrika" wieder korrigieren
    Nach der erfolgten Verschiebung sollten Sie natürlich wieder die temporär geänderte Zeitzone auf die richtigen Werte setzen.

Vielleicht ist das ein denkbarer Weg für Personen, die wirklich viele Termine haben.

Weiterentwicklung

Wenn ich zu gegebener Zeit dazu kommen, würde ich gerne noch folgende Dinge ergänzen

  • Wiederkehrende Termine
    Aktuell werden diese einfach übersprungen. Ich habe aktuell das Problem, dass ich noch nicht dazu gekommen bin, die RecurrentPatterns zu verarbeiten. Zudem scheint es CDO-Versionen zu geben, bei denen das Feld "IsReccurent" leider nie true wird, selbst wenn es ein wiederkehrender Termin ist. Könnte sein, dass dies ein unterschied der CDO auf einer Workstation und CDO auf dem Server ist.

Weitere Links