7
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
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 312274
Url: https://administrator.de/contentid/312274
Printed on: April 26, 2024 at 00:04 o'clock
7 Comments
Latest comment
Hallo DIeter,
was für eine CRM?
was für eine CRM?
Hallo certifiedit.net
Es handelt sich hier um LogoCRM von LogoConsult
VG Dieter
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:
Gruß Krämer
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:20100922T081500Gruß 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
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 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
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
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 ignoriertdeine 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.
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
