EWS Managed API - update appointment - 'At least one recipient isn't valid.' during update item with invitation mode set to SendToNone on Exchange 2013

Hi All,

My team works on a managed EWS API based solution but we've found a behavior of the managed EWS API that we can't explain based on dev documentation (maybe we've missed or misunderstood something). 

The problem is that the following piece of code throws 'At least one recipient isn't valid.' error in the line "up.Update"

I don't have any recipients for the appointment so that's true that there is no valid recipient but on the other hand I set the invitation mode to SendToNone so the update changes shouldn't be sent to any recipient.  That's is also interesting why  the behavior is different when SendToNone is used during creation and SendToNone during updating (the commented out lines). The update works fine in this case.

try
{
    var ap = new Appointment(service);
    ap.Start = new DateTime(2014, 1, 31, 10, 0, 0);
    ap.End = new DateTime(2014, 1, 31, 11, 0, 0);
    var r = new Recurrence.RelativeYearlyPattern();
    r.DayOfTheWeek = DayOfTheWeek.Friday;
    r.DayOfTheWeekIndex = DayOfTheWeekIndex.Last;
    r.Month = Month.January;
    ap.Recurrence = r;
    ap.Recurrence.StartDate = new DateTime(2014, 1, 31, 23, 30, 0);
    ap.Subject = "abc";
    // ap.Save(WellKnownFolderName.Calendar, SendInvitationsMode.SendToNone);
    ap.Save(WellKnownFolderName.Calendar, SendInvitationsMode.SendOnlyToAll);
    var up = Appointment.Bind(service, new ItemId(ap.Id.UniqueId));
    up.Recurrence = new Recurrence.DailyPattern(new DateTime(2014, 1, 29), 3);
    up.RequiredAttendees.Add("Administrator@DevExch2013.local");
    // up.Update(ConflictResolutionMode.AlwaysOverwrite, SendInvitationsOrCancellationsMode.SendOnlyToAll);
    up.Update(ConflictResolutionMode.AlwaysOverwrite, SendInvitationsOrCancellationsMode.SendToNone);
}
catch (Exception e)
{
    Console.WriteLine(e.Message);
}

The problem seems to only occur on Exchange 2013. We have also two test boxes with Exchange 2013 and the behavior also slightly differs between the boxes. On the first test box the problem occurs always but on the second one the problem only occurs in  specific appointment configurationd. I've never configured exchange 2013 myself so I don't know if there is any parameter during set up that may impact this behavior.

Does anybody see any problem with the above code?

Thanks in advance for help