macOS Server 5.4, running on High Sierra, comes with a number of alerts that can be sent to administrators via servermgrd and configured since the 5th version of the Server app. To configure alerts on the server, open the Server app and then click on Alerts in the Server app sidebar.

Next, click on the Delivery tab.

At the Delivery screen, click on the Edit button for Email Addresses and enter every email address that should receive alerts sent from the server. Then click on the Edit button for Push Notifications. Here, check the box for each administrator of the server. The email address on file for the user then receives push notifications of events from the server.

Then, check the boxes for Email and Push for each of the alerts you want to receive (you don’t have to check both for each entry). Alerts have changed in macOS Server, they are no longer based on the SMART status of drives or capacity; instead Delivery is now based on service settings.

OS X Mountain Lion Server comes with the /usr/sbin/serverinfo command. The serverinfo command can be pretty useful when you’re looking to programmatically obtain information about the very basic state of an OS X Server.
The first option indicates whether the Server app has been downloaded from the app store, which is the –software option:
serverinfo --software
When used, this option reports the following if the Server.app can be found:
This system has server software installed.
Or if the software cannot be found, the following is indicated:
This system does NOT have server software installed.
The –productname option can be used to determine the name of the software app:
serverinfo --productname
If you change the name of the app from Server then the serverinfo won’t work any longer, so the output should always be the following:
Server
The –shortversion command returns the version of the Server app being used:
serverinfo --shortversion
The output will not indicate a build number, but instead the version of the app on the computer the command is run on:
2.0.23
To see the build, use the –buildversion option:
serverinfo --buildversion
The output shows the build of server, which doesn’t necessarily match the OS X build number:
12S307
Just because the Server app has been downloaded doesn’t mean the Server setup assistant has been run. To see if it has, use the –configured option:
serverinfo --configured
The output indicates whether the system is running as a server or just has the app installed (e.g. if you’re using it to connect to another server:
This system has server software configured.
You can also output all of the information into a single, easy to script against property list using the –plist option:
serverinfo --plist
The output is a list of each of the other options used:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>IsOSXServerVolume</key>
<true/>
<key>IsOSXServerVolumeConfigured</key>
<true/>
<key>IsServerHardware</key>
<false/>
<key>LocalizedServerProductName</key>
<string>Server</string>
<key>ServerBuildVersion</key>
<string>12S307</string>
<key>ServerPerformanceModeEnabled</key>
<true/>
<key>ServerVersion</key>
<string>2.0.23</string>
</dict>
</plist>
The Server Root can reside in a number of places. To see the path (useful when scripting commands that are relative to the ServerRoot:
serverinfo --prefix
By default, the output is as follows:
/Applications/Server.app/Contents/ServerRoot
You can also see whether the system is running on actual hardware desgnated by Apple for servers using the –hardware option:
serverinfo --hardware
The output simply indicates if the hardware shipped with OS X Server on it from Apple:
This system is NOT running on server hardware.
The –perfmode option indicates whether or not the performance mode has been enabled, dedicating resources to binaries within the Server app:
serverinfo --perfmode
If the performance mode has not been enabled then the output will be as such:
Server performance mode is NOT enabled.
To enable performance mode, you can also use serverinfo. This is the only task that the command does that can make any changes to the system and as such is the only time you need to elevate privileges:
sudo serverinfo --setperfmode 1
Finally, set the boolean value to 0 to disable.
sudo serverinfo --setperfmode 0

File Services are perhaps the most important aspect of any server because file servers are often the first server an organization purchases. There are a number of protocols built into OS X Mountain Lion Server dedicated to serving files, including AFP, SMB and WebDAV. These services, combined comprise the File Sharing service in OS X Mountain Lion Server.
File servers have shares. In OS X Mountain Lion Server we refer to these as Share Points. By default:

File Sharing has some built-in Share Points that not all environments will require.

Each of these shares is also served by AFP and SMB, something else you might not want (many purely Mac environments might not even need SMB). Or if you have iOS devices, you may only require WebDAV sharing.

Each share has permissions that Apple provides which will work for some but not all.

In short, the default configuration probably isn’t going to work for everyone. Therefore, before we do anything else, let’s edit the shares to make them secure. The first step is to create all of your users and groups (or at least the ones that will get permissions to the shares). This is done in Server app using the Users and Groups entries in the List Pane. Once users and groups are created, open the Server app and then click on the File Sharing service in the SERVICES list in the List Pane. Here, you will see a list of the shares on the server.
In our example configuration we’re going to disable the Groups share. To do so, click on Groups one time and then click on the minus button on the screen.
As mentioned, shares can be shared out using different protocols. Next, we’re going to disable SMB for Public. To do so, double-click on Public and then uncheck the SMB protocol checkbox for the share.
When you’ve disabled SMB, click on the Done button to save the changes to the server. Next, we’re going to create a new share for iPads to be able to put their work, above and beyond the WebDAV instance automatically used by the Wiki service. To create the share, first we’re going to create a directory for the share to live in on the computer, in this case in the /Shared Items/iPads directory. Then from the File Sharing pane in Server app, click on the plus sign (“+”).
At the browse dialog, browse to the location of your iPad directory and then click on the Choose button.
At the File Sharing pane, double-click on the new iPads share.
At the screen for the iPads share, feel free to edit the name of the share (how it appears to users) as it by default uses the name of the directory for the name of the share. Then, it’s time to configure who has access to what on the share. Here, use the plus sign (“+”) in the Access section of the pane to add groups that should be able to have permission to access the share. Also, change the groups in the list that should have access by double-clicking on the name of the group and providing a new group name or clicking on the plus sign to add a user or group.
The permissions available in this screen for users that are added are Read & Write, Read Only/Read and Write. POSIX permissions (the bottom three entries) also have the option for No Access, but ACLs (the top entries comprise an Access Control List) don’t need such an option as if there is no ACE (Access Control Entry) for the object then No Access is assumed.
If more granular permissions are required then click on the name of the server in the Server app (the top item in the List Pane) and click on the Storage tab. Here, browse to the directory and click on Edit Permissions.
As can be seen, there are a number of other options that more granularly allow you to control permissions to files and directories in this view.
Once you have provided all of the appropriate users access to the share, go back to the settings for the share and scroll to the bottom of the screen.
Here, you have the option to set which protocols the share is accessible through (AFP, SMB & WebDAV) as well as make the share accessible to guests (only do this if the share should be publicly accessible) and make the share an option for home folders. Click Done once you’ve configured the share appropriately.
Once a share has been made an option for home folders it appears in both Workgroup Manager and the Server app as an available Home Folder location for users in that directory service.
Once you have created all the appropriate shares, deleted all the shares you no longer need and configured the appropriate permissions for the share, click on the ON button to start the File Sharing service.
The File Sharing service can also be controlled from the command line. Mac OS X Server provides the sharing command. You can create, delete and augment information for share points using sharing.
To create a share point for AFP you can use the following command:
sharing -a -A
So let’s say you have a directory at /Shares/Public and you want to create a share point called PUBLIC. You can use the following command:
sharing -a /Shares/Public -A PUBLIC
Now, the -a here will create the share for AFP but what if you want to create a share for other protocols? Well, -F does FTP and -S does SMB. Once created you can disable the share using the following command:
sharing -r PUBLIC
To then get a listing of shares you can use the following command:
sharing -l
You can use the sharing command to enable FTP for various share points. To do so, enable FTP using the Server app and then use the instructions at this site to manage FTP on shares: http://krypted.com/mac-os-x/ftp-on-lion-server.
You can also use the serveradmin command to manage file shares as well as the sharing service. To see settings for file shares, use the serveradmin command along with the settings option and then define the sharing service:
sudo serveradmin settings sharing
To see settings for the services use the serveradmin command with the settings option followed by the services: afp and smb:
sudo serveradmin settings afp
To see a run-down of some of the options for afp, see this article I did previously. Additionally, for a run-down of smb options, see this one.

The software patching configuration built into most operating systems is configured to open a box at home, join your network and start using the computer right away. As environments grow from homes to offices and then offices grow into enterprises, at some point software updates and patches need to be managed centrally. Mountain Lion, as with its OS X Server predecessors has a Software Update service. The service in the Server app is known as Software Update and from the command line is known as swupdate.
The Software Update service, by default, stores each update in the /var/db/swupd directory. The Software Update servie is actually comprised of three components. The first is an Apache server, invoked by the /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.host.plist LaunchDaemon. This LaunchDaemon invokes a httpd process and clients access updates from the server based on a manifest of updates available in the sucatalog. These are synchronized with Apple Software Updates via /Applications/Server.app/Contents/ServerRoot/usr/sbin/swupd_syncd, the LaunchDaemon for swupdate at /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.sync.plist. The Apache version is now Apache/2.2.22.
Clients can be pointed at the server then via a Profile or using the defaults command to edit the /Library/Preferences/com.apple.SoftwareUpdate.plist file. The contents of this file can be read using the following command:
defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist
To point a client to a server via the command line, use a command such as the following:
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://updates.krypted.com:8088/index.sucatalog
But first, you’ll need to configure and start the Software Update service. Lucky you, it’s quick (although quick in a hurry up and wait kind of way). To get started, open the Server app and then click on the Software Update service.
By default, updates are set to simply mirror the Apple servers, by default, enabling each update that Apple publishes, effectively proxying updates. You can use the Manual button if you would like to configure updates to either manually be approved and manually synchronized or just manually approved but automatically copied from Apple. Otherwise click on the ON button and wait for the updates to cache to simply mirror the Apple servers.
If you would like to manually configure updates, click on the Manual option and then click on the Updates tab.
The first item in the Updates tab is the “Austomatically download new updates” checkbox. This option downloads all of the updates but does not enable them. The Updates tab also displays all available updates. click on one and then click on the cog-wheel icon towards the bottom of the screen to configure its behavior (Download, Enable, Disable, Remove and View Update).
Note: The only option for updates in an Automatic configuration environment is disable.
The service can be managed using serveradmin. To start Software Update, use the start option, followed by the swupdate service identifier:
sudo serveradmin start swupdate
To stop the service, replace start with stop:
sudo serveradmin stop swupdate
To see the status of the service, including the location of updates, the paths to log files, when the service was started and the number of updates running, use the fullstatus option:
sudo serveradmin fullstatus swupdate
The output of which appears as follows:
swupdate:state = "RUNNING"
swupdate:lastChecktime = 2012-08-04 17:04:45 +0000
swupdate:syncStatus = "DONE"
swupdate:syncServiceState = "RUNNING"
swupdate:setStateVersion = 1
swupdate:lastProductsUpdate = 2012-08-04 17:07:10 +0000
swupdate:logPaths:swupdateAccessLog = "/var/log/swupd/swupd_access_log"
swupdate:logPaths:swupdateErrorLog = "/var/log/swupd/swupd_error_log"
swupdate:logPaths:swupdateServiceLog = "/var/log/swupd/swupd_syncd_log"
swupdate:readWriteSettingsVersion = 1
swupdate:checkError = no
swupdate:pluginVers = "10.8.91 (91)"
swupdate:updatesDocRoot = "/var/db/swupd/"
swupdate:hostServiceState = "RUNNING"
swupdate:autoMirror = no
swupdate:numOfEnabledPkg = 0
swupdate:servicePortsAreRestricted = "NO"
swupdate:numOfMirroredPkg = 0
swupdate:autoMirrorOnlyNew = no
swupdate:startTime = 2012-08-04 17:04:45 +0000
swupdate:autoEnable = no
There are also a number of options available using the serveradmin settings that aren’t exposed to the Server app. These include a feature I used to use a lot in the beginning of deployments with poor bandwidth, only mirroring new updates, which is available to swupdate via the autoMirrorOnlyNew option. To configure:
sudo serveradmin settings swupdate:autoMirrorOnlyNew = yes
Also, the service can throttle bandwidth for clients. To use this option, run the following command:
sudo serveradmin settings swupdate:limitBandwidth = yes
And configure bandwidth using the syncBandwidth option, as follows:
sudo serveradmin settings swupdate:syncBandwidth = 10
To automatically sync updates but not enable them (as the checkboxes allow for in the Server app, use the following command:
sudo serveradmin settings swupdate:autoEnable = no
The port (by default 8088) can be managed using the portToUse option, here being used to set it to 80 (clients need this in their catalog URL from here on out):
sudo serveradmin settings swupdate:portToUse = 80
Finally, administrators can purge old packages that are no longer needed using the PurgeUnused option:
sudo serveradmin swupdate:PurgeUnused = yes
One of the biggest drawbacks of the Software Update service in OS X Mountain Lion Server in my opinion is the fact that it does not allow for serving 3rd party packages, from vendors such as Microsoft or Adobe. To provide those vendors with a manifest file and a quick little path option to add those manifest files, a nice middle ground could be found between the Mac App Store and the built in software update options in OS X. But then, we wouldn’t want to make it too easy.
Another issue many have had is that users need administrative passwords to run updates and don’t have them (technically this isn’t a problem with the OS X Server part of the stack, but it’s related). While many options have come up for this, one is to just run the softwareupdate command for clients via ARD or a similar tool.
Many environments have used these issues to look at tools such as reposado or third party patch management tools such as JAMF Software’s the Casper Suite (JAMF also makes a reposado-based VM that mimics the swupdate options), FileWave, Absolute Manage and others. Overall, the update service in Mountain Lion is easily configured, easily managed and easily deployed to clients. It is what it needs to be for a large percentage of OS X Mountain Lion (10.8) Server administrators. This makes it a very viable option and if you’ve already got a Mountain Lion computer sitting around with clients not yet using a centralized update server, well worth enabling.
Note: Managing multiple Software Update Servers has changed in OS X Mountain Lion Server, see my previous post for more information on these changes.

Forgot the admin password in Mac OS X? Well, Apple let’s you boot computers into what is known as Single User Mode. To boot a Mac into Single User Mode, boot the machine holding down Command-S. Once the system boots up, you should see a command prompt. Here, run fsck:
fsck -fy
Then mount the file system:
mount -uw /
Then reset the password using the passed command
passwd <username>
For example, if the user is root:
passwd root
When prompted, provide the desired administrative password.