Push Notifications can be used in most every service in the Server app, especially in 3.5 for Yosemite (which I still like to call Yosemite Server as it makes me think of Yosemite Sam in a tux, pouring champagne). Any service that requires Push Notifications will provide the ability to setup APNS during the configuration of the service. But at this point, I usually just set up Push Notifications when I setup a new server. To enable Push Notifications for services, you’ll first need to have a valid AppleID. Once you have an AppleID, open the Server app and then click on the name of the server. At the Overview screen, click on Settings. At the Settings screen for your server, click on the check-box for “Enable Apple push notifications.” At the Apple Push Notification Services certificate screen, enter an AppleID if you have not yet configured APNS and click on OK. The Apple Push Notification Service certificate will then be configured. The certificate is valid for one year, by default. Administrators receive an alert when the certificate is due to expire. To renew, open the same screen and click on the Renew button.
Now that we’ve looked at what you get and what you don’t get in Mountain Lion Server, let’s take a little while to look at what the upgrade path itself looks like. Before we start, let’s just say that upgrading to Mountain Lion Server is probably one of the fastest, easiest and most boring upgrades you’ll ever get to do. And I say this more to the credit of the engineers that made the process so simple. Apparently there are bonuses to your Server just being an app. There is a catch, some of the services are gone. Another catch, you’re gonna’ need to have a system that meets the following specs:
- Capable of booting a 64-bit kernel, means a 64-bit Intel Core 2 Duo or better
- The graphics just keep getting better, so you’ll need an Advanced GPU chipset
- The more memory the better, although 2GB is the bare minimum
- The more CPU the better, although 8GB of space is required
- An Internet connection, or a cached Install Mac OS X Mountain Lion, Server app and Server package – much easier to just have a connection to the Internet…
- You should plan on using an Apple ID, although if you don’t supply it at install time, the server can still run
- The source computer needs 10.6.8 or 10.7.x
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/changeip -checkhostnameProvided that the name of the server checks out clean, click on the Server app in the Dock to be guided through the installation process. At the Setup Your Server screen, click on Continue. Agree to the licensing terms (assuming you do agree) by clicking on the Agree button. Provide the administrative username and password to give Server and services permission upon installation and then click on the Allow button. At the Apple Push Notifications screen, provide the Apple ID and password for a valid Apple ID and then click on the Continue button. After a time, you should see a Congratulations screen. Click on Finish and the Server app should automatically open (or the process fails but Server opens anyway, just without some of the stuff working out of the gate). At this point, you should see the services that were running prior to the upgrade running. Check the logs to verify that there’s nothing out of the ordinary. If you were running a firewall then the rules will be migrated and continue running. To disable if you’re going to move your rules to pf, then use the following command to disable the rules and reboot:
sudo mv /etc/ipfilter /etc/ipfilter.OLDYou don’t need to disable these immediately, although a lack of control over them might cause you to want to… Next, install Workgroup Manager, available at http://support.apple.com/kb/DL1567. You’ve now got a functional server, provided that the entire process went smoothly. In my experience so far (there hasn’t been a ton of this at this point), the service migration is far smoother than from within the Lion Server point releases (e.g. 10.7.2 to 10.7.3, etc). Profile Manager, for example, worked like a charm on upgrade, as did Calendar and Contacts services, which had been a bit persnickety at times previously. Now, you can get back to that book and instead of a 3rd Dr. Pepper, switch to Jägermeister!
Autodiscover automatically configures profile settings for Exchange clients. These clients include Microsoft Outlook 2007 or Outlook 2010, Outlook for Mac, Mail.app in Mac OS X, iPhone, iPad and ActiveSync enabled phones. Autodiscover is often made out to be complicated. There’s an Autodiscover service that gets installed when a Client Access Server (CAS) role is setup for Exchange 2010 in the form of a default virtual directory named Autodiscover for the default Web site in Internet Information Services (IIS). You then forward an autodiscover service locater record in DNS in the form of _autodiscover._tcp. The virtual directory handles Autodiscover requests. But what about other vendors, and even for Exchange, how do you verify that it’s working correctly? If clients automatically configure then it’s working, obviously. But when it isn’t, what do you need to do? The most obvious step is to check that the DNS record responds appropriately. To do so, we can use nslookup. To use nslookup, run it from the command line, followed by the DNS name. For me.com, this might be:
nslookup _autodiscover._tcp.me.comBut note that there’s not a response. This is because me.com doesn’t use _autodiscover (why would it, it’s not EWS/ActiveSync after all. But other domains that are configured for autodiscover would respond. For example, look at the output for 318.com:
nslookup _autodiscover._tcp.318.comWhich looks like this:
Non-authoritative answer: Name: _autodiscover._tcp.318.com Address: 188.8.131.52Provided that the answer section is the address of the CAS Exchange server that sits in front of your organization (the one that runs the Autodiscover virtual directory in IIS) then you are more than likely off to a great start using autodiscover. If not, then that’s the first thing that likely needs to get fixed if you actually want clients to use autodiscvoer. Also keep in mind that you’ll want to check internally and externally, as you will likely have different domain names setup for these. I often find that people will configure the _autodiscover records in their public DNS but not in their private views. Also keep this in mind when acquiring SSL certificates for Exchange’s CAS instance. Note: Autodiscover, as its implemented in Office Exchange clients, also has the ability to change configurations in Office on the fly as network settings change on internal networks (e.g. users get moved to different information stores, IPs of servers change, etc). This does not seem to work with Apple’s Mail. One could write a script to check for a change in the records nightly (or more frequently of course) if this is needed. Sometimes the mail clients can interpret things differently than we do manually from the command line, including autodiscover. When the Apple Mail client is attempting to connect to Exchange, you can also get more information about the EWS autodiscovery process by capturing logs about it, not done by default, but invoked by firing up mail using the –LogEWSAutodiscoveryActivity option followed by a YES, as follows:
/Applications/Mail.app/Contents/MacOS/Mail --LogEWSAutodiscoveryActivity YESBy reading these logs, you can learn way more than you ever wanted to know (or thought was possible) about Autodiscover. Given that Autodiscover is similar in iOS, most of this rings true in the Mail app there as well. However, given that you can’t view the activity in as granular a detail by invoking Mail through the command line, you can watch it in the logs in iPhone Configuration Utility while you’re setting up Mail, Contacts & Calendars in the Settings app, which should provide information about any connection failures. While Autodiscover is awesome, you should still be able to connect without it. The only time I really both to troubleshoot Autodiscover itself is when I can install an account but I cannot get Autodiscover to eliminate the need for the second setup screen in Mail on iOS and OS X (possibly with the exception of Lion). If you can setup mail, but it requires two screens then the problem is basically always Autodiscover. If you can’t setup mail at all then the problem is basically never Autodiscover. Good luck, and hope someone finds this useful!
In a previous article I showed how to get and install an SMIME certificate. Now let’s look at installing it into Mail. It’s really, really hard. First, open Mail. Then, click on the Mail menu and select Preferences. Then click on Accounts. Then click on the account you got an SMIME cert for. Then, in the TLS box, select the certificate you want to use. Next, go to compose a new message. You will see the little disclosure triangle to the left of the From dialog. Click on it and then check the box for the lock and the icon to the right of that, meant to look like a Beholder from Dungeons and Dragons. Beholders see well, so they can see if you’re the person who really is the person allowed to send the email. The lock encrypts email (provided you have a certificate for all recipients) and the eye of the beholder icon signs messages. Once you’re happy with your checkboxes, click on OK. Now, in your new email message, use the icons. Sign or encrypt. If you don’t have a certificate for a user, have them sign an email and send it to you. When you read their email you should then have their public key in your Keychain. Now, take your 100 sided dice and take the rest of the day off (after all, you just figured out how to make email more secure for your company). Also, you may notice that in these screens I’m using MobileMe certs. If you use the System Preferences pane to install MobileMe into your account then you’ll be greeted by the cert automatically being installed into your keychain for you. So for MobileMe users, you don’t even need to go get a 3rd party cert. I also use this on my work email, but didn’t want to put those screens in here (after all, I did misplace my tin hat and would hate to get hax0r’d by government goblins before I can track it down).