Newsroom Update

Beginning in May, a special Today at Apple series titled “Made for Business” will offer small business owners and entrepreneurs free opportunities to learn how Apple products and services can support their growth and success. Learn more >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

viellen Author

Level 1

0 points

CalDAV Wiki Calendars Reverting to User Calendars in Lion Client

My business runs the iCal service with SSL in Snow Leopard Server (10.6.8) for our user calendars. That's been running fine for quite a while and we support ~50 users. Some users had created subcalendars that they would then share out with their teams using deligation. We found this is not a good long-term plan because when that individual leaves the company we have to move their calendar to a different user. To make this easier we decided to start using the group calendar function under the wiki server. Both the wiki and iCal service are running on the same server. We use a separate FQDN for the wiki, but obviously the IP is the same.

I've been able to successfully get people who need to edit the group calendar(s) access in iCal using CalDAV (thanks to tips from other discussions on here) and others that just want to view the calendar subscribe to it (note for other people using SSL, I did have to modify the "click here to subscribe in iCal" link to do that). Now I'm running into an issue that's only effecting Lion users so far but it's a BIG issue. For those who have their account set up in CalDAV, *sometimes* when they switch between our private LAN and their home networks or our VPN their wiki group calendar account will automatically change the "Server Path" from the group account to their individual user account. The only way to change it back is to delete and re-add the account (or edit the server path, but that takes most of my end-users longer to do).

Is this happening for anyone else? I can't find other instances in Googling this issue. I realize Apple's wiki server doesn't technically support editing group calendars in iCal but what is actually making it revert the path?

Bonus question: How the heck do you fully delete accounts in iCal? As a troubleshooting step I blew out the following files on my local machine:

~/Library/Calendars

~/Library/Caches/com.apple.iCal

~/Library/Preferences/com.apple.iCal.plist (multiple plists, incl. the helper file)

~/Library/Preferences/Saved Application State/com.apple.iCal.savedState

Deleted all keychain access files related to iCal

After deleting those when I open iCal->Preferences->Accounts there's nothing there, and as soon as I blink my eyes all of my CalDAV accounts come back (both my company ones and iCloud). My co-worker running 10.5.8 did the same thing (minus the Saved Application State, obviously) and he sees the same thing. Where the heck are those settings kept?!

Thanks SO much for any help!

MacBook Air, Mac OS X (10.7.2), 11", i7, 4GB RAM

Posted on Dec 20, 2011 8:26 AM

22 replies

willhaus

Level 1

114 points

Jun 20, 2012 1:15 PM in response to viellen

OMG!!!

I can't believe I finally found a group of people suffering from this issue. We have the same symptoms in our office. Occasionally, and seemingly randomly, in Lion iCal clients, the server path for a wiki calendar will be reset to a user's path and iCal will delete that wiki calendar's data and download a duplicate of that individual's calendar data. It's fairly simple to correct that path in the accounts pane in preferences, but ugh, what a pain.

I have absolutely no answers, but a few observations to throw out there:

This morning it happened to my colleague, just after iCal was doing one of its periodic (and also seemingly random) requests for a password (as if it suddenly disappeared from the keychain). And that lead me to https://discussions.apple.com/thread/3869865 which makes me wonder if maybe the auth issue then somehow makes clients reset some wiki calendar paths?

And a few minutes ago I noticed something else. When I go to https://server.local/principals/wikis/wiki-that-lost-its-calendar/ there's an entry {DAV:}current-user-principal where I can see my uid as the value. This is there b/c I had to authenticate to get to the page. If I authenticate as a different user in the browser, that user's uid is there. I guess that's not surprising given that the iCal service has to know which user is asking for wiki calendar data, but I was surprised to see it listed on that page.

So I guess I'm wondering if the root of the problem is that occasionally, an iCal client tries to authenticate for wiki calendar data, isn't successful for some reason (perhaps due to the auth errors mentioned above), switches that wiki calendar's path to the one for the "current-user-principal" and then gets a second copy of that users data.

Anyway, please keep posting here if you find any solutions, comrades!

Thank you,

Willy

madhonk

Level 1

0 points

Jun 22, 2012 1:17 AM in response to viellen

Hi,

same problem here - really annoying....

MacOS 10.7.4

Annyone a solution found?

Any response by Apple?

regards

Markus

JackPo

Level 1

0 points

Jun 27, 2012 2:00 PM in response to madhonk

Hi All,

I've finally managed to fix my problem on this and it took me a while, so I'll share what I did.

#1, make sure that your caldev hostname is setup properly, I believe caldav tries a number of addresses in series, and if it turns out that it tries a "user address" that doesn't work, it'll just default to the user calendar.

The way you check what caldav actually thinks its hostname is would be to check this link:

https://SERVERNAME/principals/wikis/WIKINAME

You should scroll down and see "Calendar user addresses: " and make sure those actually look reasonable to you.

Now, I also took the draconian step of going to /etc/caldavd and then using caldavd.plist.default to completely rewrite the existing caldavd.plist. I also turned off HTTP entirely and now my wiki calendar has actually been stable for all my users in the last 48 hours (fingers crossed).

Hopefully this will help others!

Cheers,

Jack

viellen Author

Level 1

0 points

Jun 28, 2012 6:58 AM in response to JackPo

Thanks, Jack. Please let me know how it goes.

I noticed that the calendar paths in https://SERVERNAME/principals/wikis/WIKINAME are different than the ones we've been using, but when I try the ones there they only bring up a blank calendar. It does seem like I'd have to edit that plist file. I'm hesitant to do that right now because we currently moved our Lion clients to BusyCal, which does a beautiful job of working with both the user and group calendars (and looks much more like iCal in Snow Leopard).

While I'm not a huge fan of using a third party app in lieu of iCal (since we are an AASP), I'm also concerned that if I edit the file I'll screw up the folks who have it working properly. Can you tell me how you edited the file? Did you just add in the calendar paths that work initially in iCal and did you delete the existing ones?

Please do follow up. We've noticed it can take 2 weeks for the calendars in Lion to revert so I'd love to know this is a real fix before mucking with the plist.

Thanks so much!

-Rebecca

viellen Author

Level 1

0 points

Jul 26, 2012 6:38 AM in response to viellen

Just an FYI to anyone who's still watching this thread. I loaded Mountain Lion (10.8.0) on my tester machine yesterday to see if `Calendars` did any better than `iCal` in Lion. Less than 24 hours later and my calendars reverted to my user account. Same exact issue.

BusyCal is still working beautifully for us, just wish I didn't have to steer my company towards a third party solution.

Jul 26, 2012 6:43 AM in response to viellen

sigh I was hoping it would fix it.. oh well, the 20 bucks will be put to good use for my users that wil just decide they want the upgrade and get caught up in issues. At least I will have a platform for debugging and troubleshooting.. Thanx for the update.

Aug 24, 2012 12:04 PM in response to madhonk

My testing has shown this so far:

The problem only happens when a Lion iCal client switches network connections while iCal is open or is connected to both Ethernet and Wi-Fi networks while iCal is open. It's pretty repeatable.

We tell our users to get in the habit of closing iCal when they're finished using it. Most of our laptop users were in the habit of closing their lids and unplugging from our corporate network at the end of the day while iCal is still open. Of course when they go home and connect to their home wireless network or hotel network, iCal will exhibit the behavior that is being discussed here. Also we tell them to turn off Wi-Fi when they'e connected to a wired Ethernet connection. That also causes the same issue with iCal.

--Joe

CalDAV Wiki Calendars Reverting to User Calendars in Lion Client