Exchange 2013 Zeitversatz 2 Stunden bei Termin mit invite.ics

Hallo Forum,

ich habe ein Problem bei einem Kunden in Verbindung mit Exchange 2013 und Terminen aus einer CRM-Anwendung.

Bei meinem Kunden läuft auf einem Linux-Server eine CRM-Anwendung. Mails und Termine werden über mittels SMTP (smtp.1und1.de) versendet.
Die Mail mit Einladungen gehen an die externen Kunden oder Partner, Weiterhin werden die Mails auch an den Kundeneigenen Exchange-Server gesendet.

Auf allen Systemen ist eine korrekte Zeit mit Zeitzone (UTC+1) und Sommerzeit eingestellt.

In der Datei invite.ics ist folgender Inhalt enthalten:
BEGIN:VCALENDAR
VERSION:2.0
CHARSET:UTF-8
METHOD:REQUEST
PRODID:-Octet CloudvPim 13.11.11//EN
CALSCALE:Gregorian
BEGIN:VEVENT
SUMMARY:Test Termin
DTSTART:20160811T210000
DTEND:20160811T213000
DTSTAMP:20160810T205536
LAST-MODIFIED:20160810T205536
CREATED:20160810T205536
LOCATION:Bei Dieter
UID:20160810205536LOMDMQUDNXCCYBPVKDNBOMFBYKKNSURLAKVWMBAUSLHLAFHQBKMNXSDKD
IDMGGVKDPMMVAMNKAJLVIWBGWRVPEVMANTLXPRJBIW
SEQUENCE:1
DESCRIPTION:Ich habe 21:00 uhr eingestellt\n
CATEGORIES:Extern
ORGANIZER;CN="Kunde1":mailto:crm@Kunde1.de
ATTENDEE;CN="Kunde1";RSVP=true:mailto:name1@Kunde1.de
ATTENDEE:mailto:partner@partner1.de
ATTENDEE:mailto:partner@gmail.com
ATTENDEE:mailto:administrator@Kunde1.de
ATTENDEE;CN=Cis.Web Sync:mailto:crm@Kunde1.de
END:VEVENT
END:VCALENDAR

Bei den Mail name1@Kunde1.de und Administrator@Kunde1.de kommt die Mail mit einer versetzten Zeit (23:00 statt 21:00) an.
Bei der Mail Partner@partner1.de kommt die Mail mit der korrekten Zeit (21:00) an.
Bei Partner@gmail.com wird die Zeit mit 9:00 PM (UTC) angezeigt.

Der Exchangeserver von Kunde1.de läuft mit Exchange 2013 CU12 und Windows 2012 R2
Der Exchangeserver von Partner1.de läuft mit Exchange 2013 CU7 und Windows 2012 R2

Die Termine, die der Kunde mittels Outlook erstellt und intern verteilt, werden mit korrekter Zeit dargestellt.

Ich hoffe, ihr könnt mir hier helfen eine Lösung zu finden. Der Softwareentwickler steht auf dem Standpunkt, dass seine Software nicht die Ursache für das Problem sein könnte.

Vielen Dank im Voraus für Eure Ideen und Gedanken.

Dieter

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 312274

Url: https://administrator.de/contentid/312274

Ausgedruckt am: 21.11.2024 um 22:11 Uhr

7 Kommentare

Neuester Kommentar

Hallo DIeter,

was für eine CRM?

Hallo certifiedit.net

Es handelt sich hier um LogoCRM von LogoConsult

VG Dieter

Morgen,

meiner Meinung nach liegt der Fehler doch beim Hersteller - obwohl mich das wundert. Ist schließlich eine Software für Logistik.

In der .ics fehlt die Zeitzone. Da müsste etwas in folgender Art drin stehen:

DTSTART;TZID=Europe/Berlin:20100922T073000
DTEND;TZID=Europe/Berlin:20100922T081500

Gruß Krämer

Hallo Zusammen,

ich habe gestern das Thema nochmal geprüft. Hierzu habe ich ein Pythonscript verwendet, welches eine Mail mit Terminen erstellt.
Dort konnte ich die verschiedenen Varianten von Zeitzone prüfen.

Version1:
DTSTART:20160811T210000
DTEND:20160811T213000
DTSTAMP:20160810T205536
Diese Zeitangabe werden bei Exchange 2013 CU 12 als UTC Zeit behandelt während Exchange 2013 CU 7 dieses als UTC+2 (unsere Zeitzone) interpretiert.

Version2:
DTSTART:20160811T210000Z
DTEND:20160811T213000Z
DTSTAMP:20160810T205536Z
Diese Zeitangaben werden bei Exchange 2013 CU 12 und CU7 als UTC Zeit behandelt.

Ich gehe somit davon aus, dass der Softwarehersteller ran muss.
Das Thema ist somit gelöst.

Danke für die Gedanken und Ideen.

VG Dieter

Zitat von @Dkuehlborn:

Hallo Zusammen,

ich habe gestern das Thema nochmal geprüft. Hierzu habe ich ein Pythonscript verwendet, welches eine Mail mit Terminen erstellt.
Dort konnte ich die verschiedenen Varianten von Zeitzone prüfen.

Version1:
DTSTART:20160811T210000
DTEND:20160811T213000
DTSTAMP:20160810T205536
Diese Zeitangabe werden bei Exchange 2013 CU 12 als UTC Zeit behandelt während Exchange 2013 CU 7 dieses als UTC+2 (unsere Zeitzone) interpretiert.

Version2:
DTSTART:20160811T210000Z
DTEND:20160811T213000Z
DTSTAMP:20160810T205536Z
Diese Zeitangaben werden bei Exchange 2013 CU 12 und CU7 als UTC Zeit behandelt.

Ich gehe somit davon aus, dass der Softwarehersteller ran muss.
Das Thema ist somit gelöst.

Danke für die Gedanken und Ideen.

VG Dieter

Liest du eigentlich auch die Antworten auf deine Fragen oder bist du so extrem von dir selbst überzeugst, dass du deine Halbgare Lösung eher als Lösung ansiehst, obwohl eine Lösungsansatz auf dem Tisch liegt, der dir aufzeigt wo der Fehler liegt?

Hallo Kraemer,

deine Posting ist schon etwas heftig. Du solltest überlegen, ob man hier im Forum die Kollegen so angeht. Das gehört sich nach meiner Meinung nicht. Aber Schwamm drüber.

Ich gehe davon aus, dass deine Lösung auch funktioniert. In beiden Fällen wird eine referenzierte Zeitangabe angegeben, die es dem Zielsystem ermöglicht diese Zeit mit der lokalen Zeitzone korrekt anzuzeigen.

Mein Ansatz basiert auf diesem Beitrag in Wikipedia.

Ich danke dir für Deine Gedanken und Anmerkungen.

VG Dieter

Zitat von @Dkuehlborn:
deine Posting ist schon etwas heftig. Du solltest überlegen, ob man hier im Forum die Kollegen so angeht. Das gehört sich nach meiner Meinung nicht. Aber Schwamm drüber.

Jup stimmt. Werde ungerne ignoriert

Ich gehe davon aus, dass deine Lösung auch funktioniert. In beiden Fällen wird eine referenzierte Zeitangabe angegeben, die es dem Zielsystem ermöglicht diese Zeit mit der lokalen Zeitzone korrekt anzuzeigen.

Angegeben ja aber: Auch wenn beide Angaben RFC-Konform sind, wird dein Lösungsansatz von diversen Systemen ignoriert bzw. falsch interpretiert.

Fakt ist aber: Der Programmierer hat gepennt