Codejock Developer Community : Exchange Server

Exchange Server : Hah! you put it in. I feel all...

Fri, 19 Oct 2007 18:55:57 +0000

Author: JohnCrenshaw
Subject: 6737
Posted: 19 October 2007 at 6:55pm

Hah! you put it in. I feel all warm and fuzzy now. Thanks.

Exchange Server : Not to be a pest or anything,...

Fri, 24 Aug 2007 16:29:04 +0000

Author: JohnCrenshaw
Subject: 6737
Posted: 24 August 2007 at 4:29pm

Not to be a pest or anything, but this didn't make it into 11.1.3 either. Could we make sure this gets in before 11.2.0? It's kind of rough when you install a new version of the toolkit and find that an old nemesis has returned. I avoided 11.1.3 until now for that reason (silly huh?) This should really only take 1 minute to fix, just paste my code in. The change has had plenty of testing in our software so you shouldn't really even need to test it.

John

Exchange Server : John,Thanks a lot for your solution....

Sat, 12 May 2007 09:13:36 +0000

Author: sserge
Subject: 6737
Posted: 12 May 2007 at 9:13am

John,

Thanks a lot for your solution. We'll include it into the next update.

--
WBR,
Serge

Exchange Server : Just downloaded and installed...

Tue, 24 Apr 2007 18:42:09 +0000

Author: JohnCrenshaw
Subject: 6737
Posted: 24 April 2007 at 6:42pm

Just downloaded and installed 11.1.0 and this fix still isn't in. I guess I posted this bug a bit too late to get it in. Just wanted to be sure this didn't get forgotten forever.

Exchange Server : Found the bug. To fix it I had...

Wed, 11 Apr 2007 20:36:27 +0000

Author: JohnCrenshaw
Subject: 6737
Posted: 11 April 2007 at 8:36pm

Found the bug. To fix it I had to modify Codejock code in 1 place, I need to make sure this change gets migrated into the toolkit for the next release.

The problem was apparently limited ONLY to recurring appointments with no end date. We finally discovered that Exchange Server was spitting back some cryptic, undocumented, error code that suggested it didn't like something about the data in the local record. Further examination revealed that when the toolkit writes this out, the "no end date" status causes an end date of 1 Jan 9999 for both the appointment, and the pattern end dates. When Outlook writes out these same dates in this situation, the appointment end date is set to the end date/time for the first instance of the appointment, and the pattern end date/time is set to 31 Aug 4500, 11:59:00 PM. Further testing shows that exchange server just doesn't like the insane appointment end date, and doesn't care about the recurrence end date

Since this is only an issue when the code writes the data to outlook, the solution is to check for this condition when we write and nowhere else.

Inside CXTPCalendarMAPIDataProvider::UpdateMAPIEvent we find the following code:

  //- recurrence Start/end ----------------------------------------------
  nPropTag = m_MapiHelper.GetPropTagByID(pMessage, xtpMAPIpropEvent_RecurrenceStart);
  VERIFY(_setPropTagVal_UtcTime(pMessage, nPropTag, stUTCstart));  nPropTag = m_MapiHelper.GetPropTagByID(pMessage, xtpMAPIpropEvent_RecurrenceEnd);
  VERIFY(_setPropTagVal_UtcTime(pMessage, nPropTag, stUTCend));

Just after it, insert the following:

      if (((CXTPCalendarRecurrencePattern*)ptrPattern)->GetUseEndMethod() == xtpCalendarPatternEndNoDate)
      {
         // the end date set above was for 1 Jan 9999, which is fine for Outlook
         // but at least some versions of exchange server don't like it. Outlook
         // sets the end date to the end date/time of the first instance of the
         // pattern in this case, so that should work fine for us.
         // ------- Fixed EndTime --------
         int nDuration = RCData.dwOccEndTime - RCData.dwOccStartTime;
         dtTmp = pEvent->GetStartTime() + COleDateTimeSpan(0, 0, nDuration, 0);
         stUTCend = xtp_TimeToUtc(dtTmp);
         ASSERT(stUTCend.wYear);
         nPropTag = m_MapiHelper.GetPropTagByID(pMessage, xtpMAPIpropEvent_EndTime);
         VERIFY(_setPropTagVal_UtcTime(pMessage, nPropTag, stUTCend));
      }

Exchange Server : We are experiencing a bizzare...

Mon, 26 Mar 2007 17:13:16 +0000

Author: JohnCrenshaw
Subject: 6737
Posted: 26 March 2007 at 5:13pm

We are experiencing a bizzare bug with the MAPI data provider that we can isolate to computers using exchange server with Outlook.

After making a change (like renaming or moving) to an instance of a RECURRING appointment using the calendar the change shows in both the calendar and Outlook properly. Less than a minute later, the folders will sync with exchange server and the change is lost. This is ONLY an issue for instances of recurring appointments, but the instance does NOT have to be an exception already.

This bug may be related to the recent daylight savings changes and if so, will disappear in a couple of weeks and not be reproducable until next fall. I have verified that our exchange server and all computers affected by this bug are running the latest daylight savings patches for Windows AND Outlook.