Bernard, I strongly suggest sticking with the Calendar Server you have and avoiding MacOS X Server at all expense. At the very least, take a look at some of the critical commentary available for the Server product. I tried that route myself when I became frustrated by some installation issues I was experiencing with CalanderServer and wasted several weeks. I would not recommend attempting to install the Apple Server product; in my experience it does not work at all.
Hi,
It might be useful to qualify this a little. While I don’t doubt your experience, I can’t help but feel like there’s an implied “… for my purposes” at the end of your last sentence. I can confirm that OS X Server and the Calendar & Contacts service therein does actually work for many purposes - but not all purposes :)
Based on my fair amount of sysadmin experience, I will assert that running a server ‘for real’ is going to involve some amount work. By ‘for real’, I mean:
- the service is actually used by real humans other than yourself, whose numbers may be increasing or decreasing, and whose usage patterns may change.
- those humans use the service to create data which they care about. don’t lose, break, or leak this data.
- the service needs to be up, always and forever, notwithstanding planned outages for things like upgrades / migrations / end-of-life.
I’m not aware of any vendor’s non-hosted solution for any service fitting these criteria that doesn’t require the operator to wear a sysadmin hat, at least sometimes. If any of those criteria don’t fully apply, it gets much, much easier. I assume they must all fully apply.
That’s all rather vague, so here are some specific questions I think about when I’m evaluating options for deploying any solution that is at least partially vendor-supplied:
- What’s the startup cost in time and money? How much needs to be built / configured versus acquired ready-to-use?
- What are the different high-level components of the service - the moving parts? This is basically the list of things that can break.
- Where is the demarcation line between things the operator is responsible for fixing and things the vendor is responsible for fixing? What’s the expected level of service for vendor fixes?
- Who owns the responsibility for monitoring, troubleshooting, maintenance, performance / scalability testing? For things the operator is responsible for, what tools are available?
- With the answers to the above in-hand, how much operator knowledge is needed to achieve success in a worst / average / best-case scenario, without relying on luck? What are the means for sourcing that knowledge?
- Do all involved parties understand and agree on all of these points?
There are multiple continuums at play, and making a solid decision requires understanding the tradeoffs involved in each.