- Reference 4.1 OS X Server Benefits
- Reference 4.2 OS X Server Setup
- Reference 4.3 TLS/SSL Certificates
- Exercise 4.1 Prepare Your Mac for OS X Server for Yosemite
- Exercise 4.2 Install OS X Server for Yosemite
- Exercise 4.3 Configure OS X Server for Yosemite
- Exercise 4.4 Configure Server on Your Client Computer (Optional)
This chapter is from the book
This chapter is from the book
This chapter is from the book
Reference 4.2 OS X Server Setup
This section outlines the system requirements for OS X Server and presents suggestions for scoping server hardware. Recommendations for network configuration of an OS X Server are also covered.
Verifying Server Hardware Requirements
OS X Server is an app that runs on a Mac running Yosemite; if your Mac can run Yosemite, it can run OS X Server. Before you install OS X Server, confirm that your system meets at least the minimum hardware requirements. You can find this information on the label attached to the box of every Mac sold, or you can find it with the About This Mac and System Information applications.
)
You can install the OS X Server application on any Mac computer running OS X Yosemite, with at least 2 GB of RAM and 10 GB of available disk space.
To run Yosemite, your Mac must be one of the following models or later:
- iMac (mid-2007 or later)
- MacBook (13-inch Aluminum, late 2008; 13-inch, early 2009 or later)
- MacBook Pro (13-inch, mid-2009 or later; 15-inch or 17-inch, mid/late 2007 or later)
- MacBook Air (late 2008 or later)
- Mac mini (early 2009 or later)
- Mac Pro (early 2008 or later)
- Xserve (early 2009)
Some features of OS X Server require an Apple ID, and some features require a compatible Internet service provider.
Server Hardware Considerations
For the purposes of the exercises in this guide or any other deployment testing, you can run OS X Server on just about any contemporary Mac. In practice, however, consider the size of your Apple deployment and select hardware appropriate for your production needs:
Memory—In general, more system memory results in better system performance, but exactly how much memory is ideal for your situation is impossible for this guide to prescribe. You can, however, get a good idea of system memory usage for an existing server from the Memory Usage and Memory Pressure statistics found in the Stats pane of the Server app. Obviously, if you observe extremely high memory usage, upgrading the Mac computer’s system memory is a good idea.
- Storage—Be sure you have enough disk space to hold the data for the services you plan to offer. If the services you plan to offer are disk intensive—for example, the Wiki service with a high volume of user content—consider using a faster physical disk or even an external disk system. An external disk is especially useful for the Caching service since it can potentially fill an entire disk, and the more items that are cached, the more effective the service.
- Backup—You cannot re-create a lost MDM database because of the security architecture of the MDM service. Thus, if the data store for Profile Manager is lost, you will lose the ability to manage your Apple devices. The devices will retain existing management settings but will accept new management only when enrolled into a new MDM service. In short, you really need to back up your management server. OS X Server is fully supported by the Time Machine backup built in to OS X.
- Network interfaces—Be sure to consider the speed of the network interface when making a server hardware decision. Most Mac computers support Gigabit Ethernet. All Mac computers capable of running OS X Yosemite that include built-in Ethernet interfaces support Gigabit Ethernet. If your Mac is equipped with Thunderbolt interfaces, you can use Apple Thunderbolt to Gigabit Ethernet adapters to add additional Ethernet interfaces. All services, except for Caching and NetInstall, can operate from the Mac system’s Wi-Fi interface. But for performance reasons, it’s not recommended that you provide services via a Wi-Fi interface.
- Availability—To help ensure that OS X Server stays up and running, you can turn on the Energy Saver system preference setting “Start up automatically after a power failure” (not available on all Mac systems). It’s also recommended that you use an uninterruptible power supply (UPS) for your server, including any external volumes, to keep your server up and running in the case of a brief power outage.
)
Server Network Considerations
Again, for the purposes of completing exercises in this guide or for general testing, you can configure your server using whatever Internet Protocol (IP) address was set via Dynamic Host Control Protocol (DHCP) and even use the computer’s local Bonjour name. However, some services may be negatively affected if the server’s IP address or host name is changed.
For example, your MDM service must be resolvable on all managed devices to a single Domain Name System (DNS) host name. Managed devices communicate with the MDM service only via the single host name used during enrollment. In other words, if you want to change the DNS host name clients use to resolve the MDM service, you will have to reenroll all your devices with the new host name.
Given that changes to a server configuration can dramatically affect device management, it’s obviously best to select network settings that will remain appropriate throughout the duration of your deployment. Consider the following factors when configuring network access for your management server:
- IP address—Configuring a static IP address for your production OS X Server is highly recommended. The primary reason for this is to prevent accidental changes that would prevent the DNS host name of the server to become unreachable.
- Subnets—With the exception of two specific issues, most OS X Server services aren’t affected by subnet settings. First, if you don’t use a DNS host name and instead rely on the Bonjour local host name (often defined as something like computername.local), only devices on the local subnet will recognize your server’s local host name. Obviously, this issue can be resolved by configuring a “real” DNS host name. Second, the NetInstall discovery service broadcast doesn’t travel beyond the local subnet by default. Resolving this issue is detailed in Apple Support article PH15509, “Set up NetInstall service across subnets.”
- Computer name—The server’s computer name affects access to the server only from the local subnet. The computer name is often used to define the Bonjour local host name, which again is resolvable only on the server’s local subnet. For any server that needs to be reachable beyond the local subnet (that is, most servers), the computer name doesn’t really matter.
- DNS host name—A server’s DNS host name is how most clients will resolve access to almost all the services hosted on your server. You must coordinate with your DNS network administrator to make sure the server’s DNS host name is properly configured. Remember that OS X Server requires both a forward and reverse DNS host name record for proper setup.
Network ports—The variety of services offered by your server use a range of both User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) network ports. A properly configured firewall should allow traffic only for the necessary network ports. Thus, newly configured services often require changes to established network firewalls. You will likely have to work with the network firewall administrator to open additional ports for managing Apple devices. Throughout this guide, when a specific service’s architecture is detailed, the required network ports will be included with the documentation.
Simple Mail Transfer Protocol (SMTP) relay—A variety of services in OS X Server will send email messages as part of their function. If your organization relies on an SMTP relay service for sending email messages, then you need to configure OS X Server to take advantage of this service.
External Access and Reachability Testing
Managed devices can receive management changes only if they can access your MDM service. Thus, if you require that devices are able to receive management changes when they are outside your network or on the Internet, your network infrastructure will have to be properly configured to allow connections from outside your network to reach your server.
If your server is on an internal network that uses private IP addresses, as is the most common case, your network routing will need to be configured so that it forwards traffic from a public Internet IP address to your server. If this is the case, only the required specific TCP ports will likely be forwarded to your server. Obviously coordinating with a network administrator will be required to properly configure network routing and firewall rules.
Another consideration if your server is to be accessed from the Internet is that the DNS host name must be resolvable to any host on the Internet. As covered previously, in most of these cases, your server will be accessible via an external public IP address that forwards to an internal private IP address. This type of IP forwarding also requires a DNS configuration—commonly known as split DNS —where a single host name resolves to the proper IP address both externally and internally.
In other words, even though your server uses a single DNS host name, devices in your network will resolve this host name to a private IP address; devices outside your network will resolve the same host name to a public IP address. Again, coordinating with a network administrator is required to properly set up this type of DNS configuration.
Properly testing external service reachability can be tricky because it requires that you have access to a test external network. Fortunately, OS X Server for Yosemite introduces a new feature, reachability testing, that will help you determine whether your server is accessible to Internet clients. This testing service is turned on by default, and you can find the results in the server Overview tab in the Server app.
)
You can further verify reachability for specific services by clicking the Details button to the right of the reachability information. The reachability service works by instructing automated servers at Apple to try to contact your server. In the reachability detailed view, you can see what external IP address, public host name, and specific services are available. This information will be valuable for any network administrator who is trying to help you facilitate external access for your server.
)