Address Book

Now that we’ve spent what seems like an eternity on the ins and outs of OS X Server’s directory and management capabilities, the rest of the review will go by pretty quickly - most of the services are pretty simple to setup and don’t have a lot of moving parts.

The Address Book service, for example, is basically a giant on/off switch with an option to include your directory users’ information in the address book search.

To connect your client computer to the Address Book, go to Mail, Contacts & Calendars in System Preferences, click Other, and then elect to Add a Mac OS X Server account. Either select your server or type in its address, authenticate, and you’ll be asked which services you want to use (based on what services your server offers, and which ones you have permissions to use). If you’ve configured everything correctly, OS X will handle the rest.

You now have a shared, centralized address book for every computer on your network that requests it.

iCal


As with Address Book, the iCal service can begin to be used after the flip of a switch in Server.app, but this time around there are a couple other configurable options.

Mostly, these come in the form of “locations” (like particular buildings or rooms) and “resources” (like computers or projectors) - adding these to your server will make them available as separate calendars, allowing people to schedule time to use them. Designating users or user groups as “delegates” for each location or resource allows the user or users to approve (or disapprove) scheduled meetings.

Otherwise, it’s a pretty standard server for a pretty standard calendaring service: every user on your server gets his or her own calendar, and they can all share them with each other to see what they’re doing. No surprises here.

Connecting OS X clients to iCal servers is accomplished in the Mail, Contacts & Calendars section of System Preferences, just like Address Book. There’s also a simple web interface for the service that becomes available when you turn it on.

iCal web interface

iChat

The iChat service is another on/off switch service, for the most part - your only configurable options are to log chats to the server, and allow users on your server to communicate via iChat with users on another OS X Server (which Apple calls “server-to-server federation” - it’s enabled by default, though you can restrict it if you want).

Connecting to your iChat server is, like iCal and Address Book, accomplished via Mail, Contacts & Calendars in System Preferences.

 

Mail

 
Mail is one of the few services managed by Server.app that retains more advanced configuration options in Server Admin - we’ll go over Server.app first.

In Server.app, you have a few options after you flip the switch: your first is to choose your domain name (what appears after the @ in your users’ email addresses), and your second is to specify a relay server for your outgoing mail if your configuration requires it.

The next two are a bit more universally applicable - one is to set a quota on your users’ mailboxes, and the next is to enable a Webmail interface for your service - this is accessible by default by typing [your server’s name]/webmail into your address bar, and brings up a webmail interface that is quite usable, though it’s nothing special.

 You can also access your Mail service through Mail.app using the Mail, Contacts & Calendars preference pane (the last service for which this is true), or any ol’ POP or IMAP-enabled email client (since POP, IMAP, and SMTP are all supported protocols).

Your last option in Server.app relates to virus and junk mail filtering - there’s a checkbox for the former and a slider for the latter - and blacklisting of known malicious email servers.

If you go into Server Admin you’ll get much more advanced options for configuring and monitoring your mail server. You can view logs and setup email alerts, configure more advanced filtering options, control quotas and maximum message size, enable mailing lists, and control authentication options.

Mail Server is reasonably full-featured, but there’s no getting around the fact that there are better solutions out there - big, established organizations considering adding Mac servers to their fleet are already going to be using competing systems like Exchange (and Microsoft is going to offer support for Exchange that far surpasses whatever Apple provides for OS X Server, from the point of view of most enterprises).

On the other hand, smaller organizations with fewer resources are likely going to be better off going with Google Apps for Business or another equivalent, something that offers the Mail service’s functionality while outsourcing the backend headaches to someone else. However, if you’re a small organization that insists on maintaining full control over all its data and aren’t willing to outsource, the Mail service could be useful to you.
Profile Manager: Managing Lion and iOS File Sharing, Podcast, and Time Machine
POST A COMMENT

87 Comments

View All Comments

  • HMTK - Wednesday, August 03, 2011 - link

    OK so you can definitely run a Mac OS X vm on vSphere 5 but only on Apple hardware. What a joke! Probably Apple idiocy rather than a technical limitation. Reply
  • Spazweasel - Wednesday, August 03, 2011 - link

    Apple is a hardware company. OS/X and iOS exist to make hardware sales possible (thus the cost of development is included in the pricing for Apple hardware, something the Apple haters conveniently overlook) Allowing the running of OS/X on non-Apple hardware reduces Apple hardware sales, so they don't do it.

    "Idiocy"? Yeah, sure, whatever.
    Reply
  • HMTK - Wednesday, August 03, 2011 - link

    Not allowing Mac OS to run under a hypervisor on non-Apple branded hardware won't help them either. Or do you think a halfway decent IT-department would put a desktop machine or a hard disk posing as a server in a data center? They'd rather pay a few 100 € more for a license if they could run it on ESXi/XenServer/Hyper-V and reliable hardware. Reply
  • Spazweasel - Wednesday, August 03, 2011 - link

    Apple makes its money on the desktop, not the server room. I doubt it's worth the effort. OS/X in the server room is a niche product, and Apple know it; it's much more suited as a workgroup/small office server, and those environments do not have ESX or Xen installations.

    Apple has no incentive to support OS/X in a VM, and plenty of reasons not to. Really, I don't see why this is a surprise.
    Reply
  • HMTK - Thursday, August 04, 2011 - link

    I'm not saying it's a big surprise, I'm saying it's stupid. why not make good manegement tools for their iOS available in a way that companies can integrate better in their infrastructure?

    You might be surprised as to how many small shops are going the virtualization route. Even if you have only a single server it makes sense in the long run when the time comes to replace the hardware. Just import the VM on the hypervisor on the new hardware and you're done.
    Reply
  • GotThumbs - Tuesday, August 02, 2011 - link

    This is an interesting article and I enjoyed the depth of detail. As a builder of my own systems for years, does the use of this software bind you to using only a ready built Apple system? It seems Apple is slowly trying to create a close proprietary system where you have to use apple hardware and apple software. I know their are hackintosh systems but it seems its still going to be quite a bit of effort and so far seems to be a waste of time for me. As the article mentions, there are lots of alternatives available. Apples MO seems to be offering zero options for using outside sources. Apple consumers are being channeled to Itunes and the Mac App Store for all purchases. I'm personally not a fan of that trend and have no intentions of bowing down to that kind of control. I can see where the general consumer who has very little technical knowledge is quite accepting of Apples controls as its a very simple and somewhat brainless system packaged in a slick looking package. Reply
  • GrizzledYoungMan - Tuesday, August 02, 2011 - link

    Or is it still something we're all going to pretend works, when it very clearly doesn't out in the real world (If it worked, why would DAVE exist)? I'm referring here to the myriad of permissions issues and oodles of useless garbage sidecar files that pop up after a few days of operation in a mixed environment.

    Haven't read the article. Probably won't. Sorry. Apple is a joke at anything that designing anything that doesn't fit in your pocket/surrogate vagina of choice.

    I get this feeling, deep in my angry muscle, every time some imbecile waves around his iThing, raving about Apple's genius, while I'm thinking about all the time that has been wasted trying to get OS X desktop clients to do things that have worked out in the real world for years now.
    Reply
  • blueeyesm - Tuesday, August 02, 2011 - link

    Not in Lion, as Samba moved to GPL3 licensing.

    http://www.appleinsider.com/articles/11/03/23/insi...
    Reply
  • GrizzledYoungMan - Tuesday, August 02, 2011 - link

    You know what's wild? I should actually be excited they're moving to a new standard - the NAS' I often recommend to clients support SMB2, and see useful performance gains from it.

    But then I read "Windows networking software developed by Apple" and my heart sinks. Realistically, what are the odds this is going to work?

    Honestly, I don't really blame the design teams over there so much as a closed corporate culture that both ignores the feedback of their customers and denies any complaints exist.

    They're really missing out on the sorts of improvements that most big software developers make using the information gathered during large, open betas and the like.
    Reply
  • repoman27 - Tuesday, August 02, 2011 - link

    As the article you linked to points out, since version 10.2 Mac OS X has shipped with Samba, an open-source, reverse engineered version of SMB 1.0. With Lion, Apple dropped Samba and added native support for SMB2 while maintaining the ability to connect with SMB 1.0 machines as long as they use UNICODE and extended security. This means Mac OS X 10.7 can no longer connect out of the box with some SMB 1.0 or Samba machines (which it had done for the last 9 years), but it does have full support for SMB2.

    As for GrizzledYoungMan's "oodles of useless garbage sidecar files," it's not like Mac users have any use for a thumbs.db file either. Just hide the metadata files, or don't allow write permissions on the folder if you don't want to see that kind of stuff, but these types of files are most likely only going to become more prevalent as time goes by.
    Reply

Log in

Don't have an account? Sign up now