Shared resources not working with davmail and iOS 7

Help
2013-10-04
2013-10-17
  • Brett Randall
    Brett Randall
    2013-10-04

    Hi all

    Many of our users are now on iOS 7 on their iPhones/iPads. Those on iOS 6 can still access their Exchange 2010 public folder calendars by adding a CalDAV calendar and pointing at:

    https://webmail.mydomain.com:8443/principals/public/Shared%20Calendars/This%20Calendar

    However, iOS 7 users cannot access it. If I try and add a CalDAV shared resource from scratch on the iOS 7 device, it complains that it cannot connect via SSL, try via non-SSL. Obviously that won't work. It DOES with with my OWN calendar, just not with a shared calendar.

    I found this forum post:

    http://www.gossamer-threads.com/lists/davical/general/3336#3336

    Which I have kind of seen happening with the iPhone I'm testing on. It keeps changing the URL I enter but it doesn't make sense. Sometimes it drops the 8443 and makes it port 0, sometimes it drops everything after ":8443/" in the URL, sometimes it changes "/public/..." to "/users/me@mydomain.com". So I believe it is probably an iOS bug (lovely). But is there anything that might be able to be done within DavMail to fix it? If you look in the above thread which relates to the davical product, there are workarounds for that product. Hoping something can be done in DavMail as well.

    Thanks!

    Brett.

     
  • cavagan
    cavagan
    2013-10-07

    we are experiencing this same issue in our organization. Can any one provide some insight into getting this function working again?

     
  • Sure, submit a bug report to Apple, this is an iOS bug.

    Anyway, the davical workaround will probably not work in our case: we can't bind all public folders under current user namespace !

     
  • Brett Randall
    Brett Randall
    2013-10-07

    The last time I submitted a bug nothing happened, but I've submitted another one in this case to see if it gets a response!

     
  • cavagan
    cavagan
    2013-10-11

    Update: I grabbed a snapshot from trunk 2186 today and compiled for windows. This resolves the iOS 7 access to shared calendars in an exchange 2007 environment, but not for our Exchange 2010 server.

    When connecting to 2010 I'm getting the following in error log:

    2013-10-11 13:49:38,833 WARN [CaldavConnection-52858] davmail - Item AAMkADQwMDY1OWU5LTlhMDktNDZhNC1iYzFhLWY1NDkzNDQ5Nzk3MABGAAAAAAA2ejom181sR5gfvDc7ppwnBwAJ9mtCCkvbR49ZXMEykPCCAAAAldrHAAAJ9mtCCkvbR49ZXMEykPCCAAAAuiqyAAA=.EML not available: /users/username/calendar/AAMkADQwMDY1OWU5LTlhMDktNDZhNC1iYzFhLWY1NDkzNDQ5Nzk3MABGAAAAAAA2ejom181sR5gfvDc7ppwnBwAJ9mtCCkvbR49ZXMEykPCCAAAAldrHAAAJ9mtCCkvbR49ZXMEykPCCAAAAuiqyAAA=.EML

    This discussion seems to be similar issue: http://sourceforge.net/p/davmail/discussion/644057/thread/8c53abb4/?limit=25#b6b4

    am I missing something in my build to account for 2010?

     
    Last edit: cavagan 2013-10-11
  • /users//calendar means empty email => DavMail is unable to determine current email address ?

    => try to connect with an email address instead of simple login

     
  • cavagan
    cavagan
    2013-10-15

    Thanks, Mickael, for the input and pointers. While I can get both personal and public shared calendars to work in an Exchange 2007 environment with iOS7, I seem to get the above error no matter the DavMail version or config in an Exchange 2010 sp1 environment.

    Perhaps we'll have to wait on Apple on this one after all.

     
  • If the issue is a difference between Exchange 2007 and 2010 we should manage to make it work.

    Could you please provide a log file at mguessan@free.fr ?

     
  • cavagan
    cavagan
    2013-10-17

    Logs sent.

    Currently: if I manually enter the principal url into CalDav account on iOS 7 it will work.

    It will NOT work connecting to personal calendar, or when I push a profile with the principal URL via our Mobile Device Management software (MobileIron.com). Pushing the CalDav profile via this software seems to want to connect to personal calendar instead of the public specified in principal URL. This may be an issue with the thirdparty software & server, MobileIron, I suppose.