Overall Installation Experience

As a newbie to setting up an web and mail server I naturally thought that the new Mac mini server was the right way to go. Hardware wise and cost wise I was right. Software wise however I'm afraid even the great Apple (and I am a long term fan) has a long way to go before making this technology easily accessible to small companies.

I already had a domain, fixed IP address and MX records pointing to an older Windows server at my site, so expected the installation of OSX Server to go like a dream and on first blush the software looked great, with the server set up tool seemingly taking you through all the steps to set it up. However the first result was far from what I wanted and I was surprised at how much to and fro was required between the various server applications and DNS, in particular, to get the thing working. Not very Apple-like, I would have expected the server to take care of keeping the various applications linked.

I didn't like my first attempt but found no way to fall back to a clean installation without a reload of the disks. Searching the Apple Forum showed a few different Terminal type ways of getting there but none of them seemed to work with the confidence that I wanted and there seemed to be a fair bit of debate on the forum as to how to do it. So clean install from DVD was performed (actually this was done several times over my few days of learning) and yes, this is a long way around of removing root details from a server.

My simple objective was to make a multi-service web, mail and fileserver. The following is an outline spec:

• email addresses of the form firstname.lastname@domain.com• email servers of the form smtp.domain.com, mail.domain.com and imap.domain.com• ichat and address book servers of similar form• automatic application configuration in clients• web server accessed via www.domain.com

My first big lesson was the naming of the server itself. This name will re-appear inside a number of other applications (mail, ichat, addressbook etc) so make sure you chose something that works for all. As far as I can tell it is not possible (through Server Admin) to chose different names for each of the services. This could be frustrating later on if the site grows and I want to split different services to different servers as it will mean reconfiguring all the clients. Perhaps someone on the Forum knows a way of doing this. I eventually chose the name "services" which seems to fit most applications.

Second big lesson was trying to get the email address down to firstname.lastname@domain.com. If you follow the instructions in MacOSX Server Essentials or the manual that comes with the Server you will end up with email addresses that look like firstnamelastname@services.domain.com - yuck!

Server Admin seems to use the combination of the Users shortname plus the Host name setting for the email address.

Firstly, for Host name, instead of entering services.domain.com, enter simply domain.com, same as the Domain name entered in the field above. This seems to fix the last part of the address - and is much simpler than the Terminal commands for Squirrel mail suggested elsewhere in the Forum.

Secondly, for the username, I'm afraid you can't just enter a dot in the middle of the automatically generated shortname within Server Preferences-Users. Well, in fact, you can do that - (turning FirstnameLastname into Firstname.Lastname) and it will work in email, but unfortunately the presence of the dot inside the username seems to screw up the automatic client application configuration - and will frustrate users somewhat.

The best solution I found to this was a convoluted method for creating user identities. 1) Create the username within Server Preferences - Users.2) Leave the shortname as automatically generated.3) Go to the Contact Info tab and now enter the extra dot in the email address that has already been generated.4) Now go to WorkGroup Manager and add a new shortname in the form firstname.lastname and Save. This results in each user having 2 shortnames.5) Don't forget whilst in WorkGroup Manager to set the Mail quota for the user up to something reasonable like 500Mbytes. Apple's default setting of 0MB ain't not good to man nor beast. Why didn't they set a more sensible starting position?

For some reason, trying to do all the User creation within WorkGroup Manager didn't allow the email addresses to be populated correctly, whilst trying to do all the User creation within Server Preferences - Users, didn't allow addition of extra shortnames.

But doing the convoluted method does seem to allow email address and application set up using a common set of User details - though right now I am having problems with automatic application set up - but I hope that is a client issue.

Next issue was adding users into WorkGroup manager. This requires that you log on to the LDAP server, however what is not so obvious is that the username/password is not the root username/password that you use for administering the rest of the server, but it is diradmin/password (where the password is the same as the root password). I think just that one issue caused a couple of re-installs of the system with me thinking that I'd lost or forgotten a password somewhere.

Another significant issue was DNS configuration. Eventually the addition of Primary Zones, Machine Records and Aliases becomes a bit clearer (after about 20 attempts and reading 3 books on the subject). I do believe this could be made much simpler with the server applications and server itself automatically populating with the right information. I seem to remember using the Server Install programme and having a primary zone name inserted automatically of server.domain.com, whereas what is really needed in my situation is simply domain.com. Once that was done the rest became much simpler.

Another problem area was receiving incoming mail from the WAN. Apples Mail server seems to include some quite useful SPAM and Virus detection tools - but unfortunately they don't tell you (until you go searching through the user forums) that SPAM uses both BlackListing and GreyListing. GreyListing is well described on Wikipedia but the impact on your testing is that incoming mails will be rejected by your mail server and will rely on repeated submissions back again from the source smtp to try to avoid spammers. Whilst this may sound good, the result is that your test mails may not be received for hours, or even days - not good for real time testing purposes. Again, someone on the forum suggested a Terminal method of removing the GreyListing function but my checking the results show that this is functionally equivalent to turning off Junk Mail within the Filters section of Mail Settings inside Server Admin. For the moment I have removed both Junk Mail and Virus Mail filtering and this allows for a more responsive throughput of mails during the testing period. I yet have to work out how to train the Junk Mail filter so that I can put it back on again without causing unacceptable delays to mail delivery.

Of course these are just some of the issues and problems associated with setting up the Server. Any installation like this also seems to have tons of problems with the ADSL router (if that's what you are using in a small business) - making sure it is set to bridge mode and terminating the public IP address directly onto the Airport Extreme in my configuration. I don't know many telcos that really know how to have DSL Modems set up in a way that helps a small business get going. Prior to achieving bridge mode for the modem I suffered for a long time with problems associated with double NAT'ing. At least doing it this way around allows me to leave the OSX Server to administer the firewall in the Airport Extreme though it may make it harder for me to install a more secure firewall later on.

What surprises me, as a small, single site, business is that that Apple had not set up some very simple pre-configurations that would get me going more quickly. The only real variables needing user entry should be username, password, domainname, email address format and perhaps fixed IP address - the server should be able to populate everything else without user intervention. Perhaps, Apple, in your work in various standards committees, you could suggest the standardisation of a small set of DSL/LAN configurations that we could all use and could always rely on working.

So whilst this implementation might be a very significant improvement over having to administer a series of server programmes through CLI type interfaces it is still far from the Apple-like experience I had expected. It is certainly not for the uninitiated in the world of IP - but it could be so much better!

That said - some of the other web related stuff, wikis, blogs and the like, do look to be quite good - but early days there for me.

I hope these few comments on my user experience are of use to others setting up their OSX Servers.

Thanks for sharing your thoughts. I too just set up a brand new Xserve running OS X Server 10.6. I was migrating from a 10.3 (yes, 10.3!) server so I didn't encounter some of the frustrations that you did, given that I already has a passing familiarity with +the way thing work+.

I too was dismayed that OS X Server comes pre-configured to do gray listing. I find gray listing an offensive perversion of the MTA RFCs--even if it does reduce the amount of spam. I was further dismayed to find that there was no easy way to turn this off. Like you, I ultimately searched the forums and edited my postfix config file.

The biggest problem for me has been out-of-date documentation. I spent the better part of the day trying to figure out why Tomcat wouldn't start, when (in fact) it was running the whole time. The problem is the documentation says to check to see if Tomcat is running by HTTPing to port 9006. Apparently Apple changed this port to 8080 and never updated the docs.

The 10.6 documentation is also full of references to options and procedures that no longer exist or are different in 10.6. It's starting to look like Apple just updated the titles of many of it's manual PDFs from 10.5 to 10.6 without taking a close look at the content. I've filed feedback on some of the more egregious errors, but the whole suite of 10.6 manuals needs a good technical review.

Lots of issues here. While I'm generally a fan of Mac OS X Server it does have its flaws, but I don't know that I entirely agree with all your conclusions. It's not perfect, for sure, but I don't think it's quite as bad as you think...

I didn't like my first attempt but found no way to fall back to a clean installation without a reload of the disks.

That's a fair point - it isn't obvious, but it's also not something that many people need to do. A little pre-planning (which, granted, benefits from experience) avoids the need for most cases. Given the relatively small number of cases where people need to do this, should Apple spend engineering time on doing this, especially when a complete reload is rarely warranted, anyway (often individual services can be reconfigured as needed).

My first big lesson was the naming of the server itself. This name will re-appear inside a number of other applications (mail, ichat, addressbook etc) so make sure you chose something that works for all.

Not at all. The name is largely irrelevant - certainly if you're using DNS.

All my servers have totally generic names - appsn for application servers, datan for database servers, etc.The actual name that a) users connect via, and b) each service knows itself as is completely independent of what the servers name is - that's what CNAMEs in DNS are for.

If you're relying on Bonjour for local name service then the server name makes a little more difference, but you already seem aware of DNS, so that doesn't seem to be the case here.

I agree - it would be nice to be able to template secondary email addresses off the users' name in Workgroup Manager, however, the shortname is always going to map to the user's primary email address - that's true on any system I've ever used.

Server Admin seems to use the combination of the Users shortname plus the Host name setting for the email address.

You mean Workgroup Manager, right? That's where you create user records.Really the issue here is that you want a better (automated?) way of assigning additional email addresses separate from the user's shortname. I'm sure with a little creativity it could be handled via the command-line.

No, this is fundamentally wrong. The server's hostname should be unique within the domain and should rarely, if ever, be the domain name itself.

Secondly, for the username, I'm afraid you can't just enter a dot in the middle of the automatically generated shortname within Server Preferences-Users. Well, in fact, you can do that - (turning FirstnameLastname into Firstname.Lastname) and it will work in email, but unfortunately the presence of the dot inside the username seems to screw up the automatic client application configuration - and will frustrate users somewhat.

I've never tried this but it sounds reasonable to me (as in, your description sounds like what I could expect, not that it's necessarily correct, per se. )

4) Now go to WorkGroup Manager and add a new shortname in the form firstname.lastname and Save. This results in each user having 2 shortnames.

Whatever happens here, for sure you're going to end up with two email addresses per user. The shortname will always map to a user's email address. All you're doing is adding secondary email addresses in the first.last format.

5) Don't forget whilst in WorkGroup Manager to set the Mail quota for the user up to something reasonable like 500Mbytes. Apple's default setting of 0MB ain't not good to man nor beast. Why didn't they set a more sensible starting position?

I don't understand this statement at all. Why is 0 unreasonable?Remember, in this context 0 means no limit (not zero MB which would make no sense for sure).

Who are you to say how much mail any user can have? I would personally fire my mail administrator if quotas were set because you can't predict what an appropriate level of mail is for any user. This is especially true of IMAP users whose mail is retained on the server. Why should a users' mail bounce just because he's storing old messages on the server? It makes no sense. My CEO would have a fit if his mail started bouncing for such a pointless reason.

I had this discussion with a software vendor recently - I replied to a meeting confirmation request and the mail bounced because their mailbox was full. That could have been an important sales meeting they missed because of some stupid quota policy on their (Windows Exchange) mail server.

IMHO, quotas are evil, disk space is cheap.

For some reason, trying to do all the User creation within WorkGroup Manager didn't allow the email addresses to be populated correctly, whilst trying to do all the User creation within Server Preferences - Users, didn't allow addition of extra shortnames.

I've never used Server Preferences on any of my servers, so can't comment on this.

This requires that you log on to the LDAP server, however what is not so obvious is that the username/password is not the root username/password that you use for administering the rest of the server, but it is diradmin/password

The diradmin account creation and use is covered in the Open Directory Admin Guide.

Another significant issue was DNS configuration. Eventually the addition of Primary Zones, Machine Records and Aliases becomes a bit clearer (after about 20 attempts and reading 3 books on the subject). I do believe this could be made much simpler with the server applications and server itself automatically populating with the right information.

Correct DNS is critical to any server setup. I don't know that Server Admin could (or should) auto-populate the DNS based solely on the services you're running. While there are some common hostname standards - www, mail, etc. - there's nothing to say that any machine is running your domain's web site just because you enable Apache, or that it's handling your domain's mail just because you're enabling SMTP.In short, the mapping of DNS hostnames to servers/IP addresses is best done by an admin.

I seem to remember using the Server Install programme and having a primary zone name inserted automatically of server.domain.com, whereas what is really needed in my situation is simply domain.com. Once that was done the rest became much simpler.

I can't say I've seen this, but it's been a long time since I've installed a new DNS server in Mac OS X Server.

Any installation like this also seems to have tons of problems with the ADSL router (if that's what you are using in a small business) - making sure it is set to bridge mode and terminating the public IP address directly onto the Airport Extreme in my configuration...

If that's the way you run your network, that's fine, but you can't assume that's the way everyone's going to do it. In most cases I'd expect the ADSL Router to handle NAT, with the base station running in Bridge mode within the network. Of course, that eschews the possibility of using auto-config of the AirPort but I've been configuring port forwarding and firewalls for so long that doesn't phase me. IMHO if you're running a business-critical network you probably should be configuring some of these things manually - that way you know exactly which ports are setup where, and aren't just trusting that the software's configured the right ports (and hasn't opened other ports that you really don't want exposed).

Prior to achieving bridge mode for the modem I suffered for a long time with problems associated with double NAT'ing

Double-NAT is evil, for sure. That's why I'd suggest putting the base station into bridge mode, rather than running double-NAT or turning the ADSL router into a bridge.

It is certainly not for the uninitiated in the world of IP - but it could be so much better!

There's the crux of it. You're right that even a MacMini/Snow Leopard Server doesn't make a one-click install, but there are so many variables involved it would be hard to find a single checkbox option that would fit everyone's needs - it's always going to fall short for some user or other.I'd argue that if you're running a server you should need to understand some of the elements of server setup and administration. Treating Snow Leopard Server as just Mac OS X with a few extra apps is not appropriate.

to focus on the positive, i hope you've gained some experience and insight into how some basic services work now. as for any platform, there's a learning curve associated with configuration and ongoing maintenance. os x server and apple hardware is no different.

camelot addressed your points in much the same way any experienced mac admin on these boards would. if you're just beginning this journey — either in an admin or occasional tech support role — you need to spend the time learning the fundamentals. take notes, read the docs, learn from the support fora (like this one), and you'll be in a better position to plan a deployment.

most of the issues you mentioned are either on my mental or written checklists for new server deployments. we've all seen these things and know how to deal with them. you'll get there. double-nat is one of the first things i check for with new clients, and you'll get the hang of communicating this to the ISP in a way that resolves the issue in minutes (or knowing to switch ISPs).

apple is a consumer-oriented company, thus many long time consumers assume they'll treat their server offerings with the same "set it and forget it," internet toaster experience. this hasn't been true and most likely won't be. apple's focus is on consumer products — period. they also happen to make some decent hardware and a server version of their os, both of which require a bit of experience to configure properly.

i'd say stick with it, learn from the folks here and elsewhere online, and try to attend a class or workshop if you're serious about os x/*nix administration.

oh, also don't be afraid to call in reinforcements when you're stuck. that's how consultants like me stay in business, after all. there's nothing wrong in admitting you need some help. if it will save you the time taken to reinstall the os 20 (or even 2) times, it's probably worth it.

related: always ask for documentation, though you might have to pay more for it.

Thanks for taking the time to address some of these issues - appreciated.

Overall I guess I expected a little more from Apple this time, especially based on their advertising for the Mac mini server being easy to set up etc. I guess it is if you are an OSX Server admin, but not if you are their target market of small business, dentists, lawyers etc.

I wouldn't have thought it was beyond the wit of man, or a handful of good OSX server admins, to come up with some pre-configured LAN set ups that meet the needs of the target market for the mini - and have those to call upon as examples or even final setups that could be used to guide newbies through. The manuals, whilst clear and usually well written, tend to be general purpose manuals covering all eventualities rather than specific to a small number of configurations required by the target market.

On some of your answers, if you'll permit, I'd like to dig a little deeper.

*Server naming*. I think my main point here was that if you follow through the guided set up provided by Apple you will end up with that server name everywhere, particularly if you use LDAP to configure the clients applications. The result (at least in all my attempts) was that you end up with ugly email addresses ( firstnamelastname@server.domain.com ), and equally ugly server addresses each of the account settings in the clients Mail, ichat, addressbook and iCal apps.

What I would like to find is a method by which those names could be set through the set up process or in Server Admin such that a more succinct and easily read naming convention resulted. Guidance here would be useful.

Yes, DNS gets you there in a way, but as far as I found even if you change the DNS settings you still end up with the ugly email and server addresses when auto-configuring clients.

*Email addresses*. I don't actually have a problem with using multiple shortnames for each account - my challenge again was how to ensure the auto-configuration process would result in the desired email address being populated.

*Server Admin vs. WorkGroup Manager*. Yes you're right I did mean WorkGroup Manager. But no, I don't expect Apple to send me to the Command Line.

*0MB Mail Quota.* Ah, penny drops, thanks for pointing that out - I had wrongly assumed that "0MB" meant "zero megabytes" - silly of me! Of course I should have realised that Apple means unlimited when they write 0. I agree with you interms of not limiting email quotas - but its also bad practice by users not to do some form of regular archiving. I used to run a company that had multi-terra bytes of email - that did start to become expensive.

*Hostname as domain.com instead of server.domain.com.* I fully agree with your view and this had me really confused. I had expected to use the form server.domain.com but again it resulted in ugly email addresses and the like - it was only by using domain.com that I could rid myself of the ugliness. Can you point out another way of achieving this?

*Use of Server Preferences for Users*. You point out that you don't use Server Preferences and rely entirely on WorkGroup Manager which is great. Can you point out for me where in Workgroup Manager you chose the services that each user gets access to as this would seem to make more sense. Can you also point out how to get WorkGroup manager to self populate the email addresses, ichat addresses etc (in the right format) so that I don't have to type all this in for each user.

*ADSL routers and double NAT.* Yes, I agree there are lots of potential configurations here - I had struggled with both but liked the idea of the server managing the NAT and firewall for me, at least in the initial configuration so went that route. Very often ISP's don't allow full access to the modem so its not always you get the choice. With my particular router I had stuggled to get the configs to work properly with NAT in the modem. Again, it is here that I wish ISP's and LAN providers could get together and do a little (just a little) standardisation. I know it might remove some work for the admin consulting community but it might also make the market much larger.

WRT to your last point, it is Apple themselves that point to this server being easy to set up "perfect for people who've never run a server before". Having gone through the pain I don't think this quite describes the situation, but I do think the objective could easily be met with a little more thought for their target market of the mini server.

Grateful for any guidance you can provide on the questions raised above.

More Like This

Retrieving data ...

This site contains user submitted content, comments and opinions and is for informational purposes only.
Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Apple can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums.
Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.