Mac OS X Server Shortcomings in the Enterprise

Though Apple has made great strides in the consumer computing market, it has lagged in acceptance in one important area: enterprise-level networks.

Don't get me wrong, Mac OS X Server is a good product with many unique features, such as iChat server, Spotlight server, and wiki server. However, Microsoft has a number of superior design features that Apple could learn from to create a more competitive solution with big businesses.

Issues in Apple's Domain

In large corporate networks, directory services are commonplace. In essence, these allow users to store login information and be managed from a central repository. In Windows, this is called Active Directory, and in Mac OS X, Open Directory. Currently, Mac OS X has built-in support for authenticating with either service. However, Mac users cannot be managed as well with an Active Directory system as they can with Open Directory. This is a simple issue of native technology; each system is designed for its consumer OS counterpart. This means that Mac OS X servers are required for maximum functionality with Mac OS X computers.

If a lot of people need to authenticate with the directory service, it makes sense to distribute the load over multiple servers. The ability of a technology to function in both large and small installations is known as "scalability" (the ability to scale up and down to handle the load). Unfortunately, there are four major scalability issues hampering Apple's ability to penetrate into large corporations on a wide scale.

Maximum Number of Servers

First, Apple has imposed a maximum limit of 1,057 servers per Open Directory domain (a domain is a container used to house and partition users and resources based on one or more attributes, such as department or physical location). This may seem like a lot, but with extremely large networks, this limit can become a scalability stopper. Circumventing it would require slicing users into domains based on what server they are closest to - not always a good policy from an organizational standpoint.

Replication

Related to this issue is the method of replication that Open Directory uses (replication refers to the process of transferring directory data between servers to keep them all up to date). In Apple's solution, one central server directly replicates to up to 32 servers, which in turn can replicate to up to 32 servers, creating the limit of 1,057 servers. Of course, this is an improvement of Mac OS X 10.4's model, where every replica replicated directly from the master, creating even more scalability problems. Also, this tree shaped model can be less efficient than a mesh with the same number of servers.

Not only that, but the one "master server", as Apple refers to it, is unfortunately the only one allowed to make changes to directory data; the rest of the servers are read-only copies. Most people can see the issue here - putting all your eggs in one basket. If that server malfunctions, nobody can change anything, not a single password, until a replacement is implemented and introduced as the new master.

Microsoft dropped this model in Windows 2000 Server with the introduction of Active Directory, instead implementing something called "multimaster" replication. In essence, each directory server is exactly the same as any other in a domain: i.e., "multiple masters". Anyone can make changes to directory data on whatever server they are connected to, and if a server goes down, it can simply be replaced with a new one, which will be given a copy of the newest directory data from the other servers. This creates more fault tolerance, a major factor in scalability.

In addition, when servers may be separated by WAN links that are not constantly active, this model allows local administrators to make changes for their group of users while allowing users at different sites to share a single domain; this flexibility in domain design is another factor promoting scalability.

Though the multimaster model can lead to some data conflicts when more than one person is able to change data at the same time, as well as security holes when more people have access to writable copies of the directory, Microsoft appears to have ironed out most of the problems in the years since it introduced this, including allowing some servers to be read-only when full write access is not necessary or even dangerous, such as cases where physical security is weak or nonexistent.

Database Size

The third problem is also one of size. The current version of Berkeley DB, the underlying software storing all of Open Directory's data, can only handle about 200,000 records while remaining efficient. Once again, this seemingly large number can be used very quickly, especially when one takes into account the number of different things that are stored in this database. In contrast, Microsoft has a custom-designed database engine that they say can handle several million records.

This gap also hampers Apple's ability to scale up in large corporations.

Some may point out that, like the solution for the first flaw, one could simply cut the users up into different domains.

Not only does this solution share the same organizational flaws, but it can also present an administration nightmare on a large scale. Though normally a Mac is able to scan for and automatically locate the closest server, in a larger environment this doesn't always happen as planned. In order to balance load on the servers, Apple's solution sometimes requires an administrator to specify the directory server each computer will use. While this can be handled en masse by DHCP (the protocol that automatically configures a network connection), it still requires tuning to ensure optimal configuration for each client: i.e., preventing someone from authenticating with a server three buildings away when the nearest one is down the hall.

Domain Integration

Unfortunately, this can also exacerbate the final major issue, domain integration. Apple's domains are separate entities from each other in pretty much every way, forcing a person to add the domains manually to a "search list" if the correct servers for each domain the Mac needs to authenticate with are not located.

In Active Directory, domains are treated a bit differently. While they are separate entities, they are stilled glued together into what is called a "forest". When a computer is first introduced into the directory structure under Windows, it is placed into a domain. This allows someone with a username in that domain to login easily, and if someone from another domain in the same forest - or even another forest (e.g. another company) if set up correctly - gives their domain name, the system automatically gets login information from those servers. This is because the entire Active Directory is glued together by DNS (the system that turns web and other word-based addresses, like www.apple.com, into IP addresses, which are used by the network to identify computers). When you give your domain, DNS allows you to look up the nearest server for that domain in order to authenticate. Also, this solution requires very little knowledge of the server infrastructure to join a computer to the domain: all one needs is the name of the domain and the credentials of an admin in the domain.

In other words, these two issues can create shaky ground for automatic configuration in larger networks, especially those segmented by routers. This is not an issue in most Active Directory installations, because DNS records are established by direct communications with the server, rather than discovery broadcasts like those used by Bonjour, which are generally not repeated to other network segments by routers.

The Low-end Issue

One big issue that is loosely related to the others is that of low-end support. While clients are taken care of all the way back to Mac OS X 10.1 (and into OS 9 and earlier for some services), the server side is fairly inflexible. Namely, Open Directory servers must be a uniform version of the Mac OS. If the master is upgraded from 10.4 to 10.5, all the replicas must be upgraded. In the same way, a 10.5 server will not act as a replica to a 10.4 server.

Microsoft, on the other hand, has an intricate system of "functional levels" based on what server OSes must be accommodated, with newer features becoming enabled as older systems are eliminated.

Going Apple can create a huge financial burden on a company if they choose to upgrade, especially with Apple's somewhat more radical approach to dropping support for the low-end as of late (i.e., Snow Leopard's Intel-only restriction), possibly forcing companies to buy new servers to reap the software benefits.

The Bright Side

On a much more positive note, there are many advantages that Apple's server technology possesses. The wiki server is just one example of Apple's propensity to quickly embrace new technologies. Not only that, but Apple has extraordinarily good command-line support, allowing everything from installation forward to be run without a GUI. This partnered with the rock solid SSH support that Mac OS X inherits from its Unix roots allows it to wipe the floor with the command-line only version of Windows Server (only introduced with the newest 2008 revision) in terms of command-line administration.

The Future

When Microsoft rose to dominance in the server/network OS field, it wasn't the dominance of Windows that got it there. Indeed, Novell's offering integrated well with Windows and was itself a well-built product. What created Microsoft's victory was their ability to duplicate Novell's functionality and go beyond it.

Apple should try this with their server product. After all, they've done it for years in the consumer field.