Problem with a Stuck ML Calendar Client using Server Calendar

Question

Level 1

6 points

Problem with a Stuck ML Calendar Client using Server Calendar

I set up group Wikis on our server, which seem to work fine (as long as everyone remembers to log in with "https:" not "http:".

On my ML client however, after cleaning out old Calendar accounts with the server, using System Preferences to create a Calendar account with the server, and then reopening Calendar, I can see the Server as a calendar source on the left pane but always get a message that says:

"The URL https://<server URL>/principals/__uids__/0D06B83A-D825-4318-816C-097904CB4886/ encountered HTTP error 404. Make sure the URL is correct."

I suspect that the hex code for my user ID is wrong (or maybe it is a group ID). But I can't seem to fix this. There is no place in the application to edit this URL. I can delete the server account from Calendar and try to start again and I still get the same message.

Is there a configuration file where I can kill this and start over? I suspect some of my other clients to the server will also have this problem as I migrate them over.

Thanks!

Mac mini, OS X Server

Posted on Nov 26, 2012 9:17 AM

Reply

Answer 1

Morris Zwick Author

Level 1

6 points

Dec 2, 2012 11:58 AM in response to Morris Zwick

I am still trying to debug this problem.

I have tried removing the Server account from Calendar Preferences as well as System Preferences, then readding. Did not work.

I tried doing the remove again, this time removing everything in Keychain associated with the Server Calendars. Did not work.

I tried going to ../<User>/Library/Calendars and navigating to the caldav directory associated with the server (this takes some poking around as the directory name is based on the server's hex identifier), then renaming the Info.plist file, then deleting the account from System Preferences, then recreating. Did not work. In fact the renamed Info.plist file was gone, but a new one was there.

The Info.plist file contained the bad entry in several places. This is what mine looks like (with specific servers and user names replaced):

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<dict>

<key>AccountIsEnabled</key>

<true/>

<key>AutoDiscovery</key>

<key>AutoScheduleSupport</key>

<true/>

<key>CalendarHomePath</key>

<string>/calendars/__uids__/0D06B83A-D825-4318-816C-097904CB4886/</string>

<key>CalendarProxySupport</key>

<true/>

<key>CalendarServerPrivateEventsSupport</key>

<true/>

<key>CalendarUserAddresses</key>

<array>

<string>/principals/users/<user short name>/</string>

<string>mailto:<user mailing address></string>

<string>/principals/users/<another short name>/</string>

<string>/principals/__uids__/0D06B83A-D825-4318-816C-097904CB4886/</string>

</array>

<key>Color</key>

<key>Delegate</key>

<key>DropBoxPath</key>

<string>/calendars/__uids__/0D06B83A-D825-4318-816C-097904CB4886/dropbox/</stri ng>

<key>Enabled</key>

<true/>

<key>ExpandPropertyReportSupport</key>

<true/>

<key>Expanded</key>

<true/>

<key>FullName</key>

<key>InboxAvailabilitySupport</key>

<true/>

<key>InboxPath</key>

<string>/calendars/__uids__/0D06B83A-D825-4318-816C-097904CB4886/inbox/</string >

<key>KeepOffline</key>

<key>Kerberos</key>

<key>Login</key>

<key>ManagedAttachmentSupported</key>

<key>NotificationCollectionPath</key>

<string>/calendars/__uids__/0D06B83A-D825-4318-816C-097904CB4886/notification/< /string>

<key>Order</key>

<key>OutboxPath</key>

<string>/calendars/__uids__/0D06B83A-D825-4318-816C-097904CB4886/outbox/</strin g>

<key>PrincipalURL</key>

<string>https://<server URL>:8443/principals/__uids__/0D06B83A-D825-4318-816C-097904CB4886/</string>

<key>PrivateCommentsSupport</key>

<true/>

<key>PushDisabled</key>

<key>RefreshDate</key>

<key>RefreshInterval</key>

<key>RequestCompressionSupported</key>

<key>ShareDefaultAlarmSettings</key>

<true/>

<key>SupportsDefaultAlarms</key>

<true/>

<key>SupportsSharing</key>

<true/>

<key>SupportsSubscriptionCalendars</key>

<key>Title</key>

<string>CalDAV</string>

<key>Writable</key>

<true/>

<key>isInSeparateWindow</key>

<key>isManuallyConfigured</key>

</dict>

</plist>

This tells me that my client is pulling this information down from the server. Annoying. Where is the configuration file on Mountain Lion Server? Why does it use the Hex address??? Short name would be infinitely better!

Reply

Answer 2

Morris Zwick Author

Level 1

6 points

Dec 2, 2012 12:33 PM in response to Morris Zwick

I should also note that if I put the URL in question in the browser:

https://<server URL>:8443/principals/__uids__/0D06B83A-D825-4318-816C-097904CB4886/

I get a configuration page from the server, which I think is the correct behavior.

I have looked in the Wiki, Web and Calendar logs on the server and I do not see the error in any of them.

Reply

Answer 3

Morris Zwick Author

Level 1

6 points

Dec 30, 2012 10:29 AM in response to Morris Zwick

<bump> Am I the only person who has seen this issue?

Reply

Answer 4

Jan 8, 2013 11:48 AM in response to Morris Zwick

iCal Server setup and configuration is convoluted, and the manual is vague. If you get it wrong the Server does not answer, giving no clues as to where the problem might be. SSL? DNS? local account setup? Server setup? Certificates?

I read a suggestion of creating a Self-signed cerificate on the Server, and testing by having iCal Server proffer that certificate. I then started an ical client, accepted the self-signed certificate once, and found that everyhting worked as advertised.

This was extremely helpful for me, because it told me 8443 port-forwarding and iCal account setup, and everything else was fine. Everything was working all the way through except the "real" certificate.

Reply

Answer 5

Morris Zwick Author

Level 1

6 points

Jan 14, 2013 10:21 AM in response to Grant Bennet-Alder

So I can't use a certified SSL certificate for Calendar? I have a wildcard certificate that is loaded on the system and works fine for Mail, for example.

Reply

Answer 6

Jan 14, 2013 11:05 AM in response to Morris Zwick

So I can't use a certified SSL certificate for Calendar?

My suggestion above was to Debug using a self-signed certificate, so that you could figure out whether the failure was ONLY in the handing of certificates, or in more fundamental things. If you get ANYTHING wrong the Server does not answer, giving no clues as to where the problem might be.

I found that mine was fully working when I used a self-signed certificate. This allowed me to focus my energy on getting a Trusted Certificate Authoritry established, and isssuing a certificate off the Certificate Authority I created, and proffering that certificate through iCal Server.

Then I carried the Certificate Authority certificate around on a CD and installed the Certificate Authority Certificate on all the Computers I wanted to be able to access the iCal Server.

I do not know what a wldcard vertificate is.

Reply

Answer 7

Morris Zwick Author

Level 1

6 points

Jan 24, 2013 9:40 AM in response to Grant Bennet-Alder

Thanks Grant for the replies:

Other users can connect the Calendar application to the server using exactly the same setup, so this seems to be a problem with a single user ID. Therefore I don't think SSL is the problem or the certificate.

I noted the following console dump on the client computer:

1/24/13 12:31:19.808 PM CalendarAgent[8843]: [com.apple.calendar.store.log.caldav.queue] [Account refresh failed with error: Error Domain=CoreDAVHTTPStatusErrorDomain Code=404 "The operation couldn’t be completed. (CoreDAVHTTPStatusErrorDomain error 404.)" UserInfo=0x7f8f1bed8490 {AccountName=<server>.<domainname>.com, CalDAVErrFromRefresh=YES, CoreDAVHTTPHeaders=<CFBasicHash 0x7f8f1bc4eb50 [0x7fff72b5cfd0]>{type = immutable dict, count = 6,

entries =>

0 : Case Insensitive Key: Strict-Transport-Security = <CFString 0x7f8f1bc39780 [0x7fff72b5cfd0]>{contents = "max-age=600"}

1 : Case Insensitive Key: Date = <CFString 0x7f8f1bc2cfc0 [0x7fff72b5cfd0]>{contents = "Thu, 24 Jan 2013 17:31:18 GMT"}

3 : Case Insensitive Key: Content-Length = <CFString 0x7fff72b462f0 [0x7fff72b5cfd0]>{contents = "100"}

4 : Case Insensitive Key: Content-Type = <CFString 0x7f8f1bc093a0 [0x7fff72b5cfd0]>{contents = "text/html;charset=utf-8"}

5 : Case Insensitive Key: Server = <CFString 0x7f8f1a4d99f0 [0x7fff72b5cfd0]>{contents = "CalendarServer/4.2(CalendarServerv19.0.95) Twisted/12.0.0 TwistedWeb/9.0.0"}

6 : Case Insensitive Key: DAV = <CFString 0x7f8f1c0ab1f0 [0x7fff72b5cfd0]>{contents = "1, access-control, calendar-access, calendar-schedule, calendar-auto-schedule, calendar-availability, inbox-availability, calendar-proxy, calendarserver-private-events, calendarserver-private-comments, calendarserver-sharing, calendarserver-sharing-no-scheduling, calendar-query-extended, calendar-default-alarms, addressbook, extended-mkcol, calendarserver-principal-property-search, calendarserver-principal-search"}

}

}]

Reply

Answer 8

Jan 24, 2013 10:38 AM in response to Morris Zwick

Is this really a single user or a single computer? can this user get satisfaction on a different computer?

If it is limited to a single user, I would tear out the account setup for that user and set it up again.

Reply