krypted.com

Tiny Deathstars of Foulness

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.

Push1

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.

Push2

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.

Push3

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.

October 18th, 2014

Posted In: iPhone, Mac OS X, Mac OS X Server

Tags: , , , , , , , , , ,

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

Apple’s official specs are here, outlining the models that Mountain Lion can run on. If Mountain Lion can run, OS X Server can run on it. Next, make a clone of your computer. I use Carbon Copy Cloner, like most sane people, but YMMV with other tools that you may be in love with. Once your clone is done, I personally like to do both an archive and an export of user accounts from Workgroup Manager as a final safety net. You should also have a book. Preferably one of mine, although given that the merging of two such boring topics can create a black hole of boringness (which is similar to turning a bag of holding inside out, btw), you might choose to bring something a bit livelier than either of the two, like some Dostoyevsky or the Chem 111 textbook I used in college.

Next, let’s go to the App Store. Search for Mountain Lion or OS X and then click the Install button for the Mountain Lion app. The button will then say Downloading, as follows:

Buy OS X Mountain Lion from the App Store

Buy OS X Mountain Lion from the App Store

Once downloaded, make sure your users won’t chase after you with pitchforks for being down for a couple of hours and then run the installer, following the defaults until the download begins and the system reboots. The installation will take a little while. From the time you start the download to the time that the files are unpacked and replaced on the system can be about an hour or two. This is a good time to grab that book, a bag of Doritos and a Dr. Pepper. Once the Doritos are gone, wash your hands and check the progress of the installation. Read some more. Once that’s done, check the progress again. If you think about a second bag of Doritos, stop – it’s not worth it… A second Dr. Pepper is fine though, I hear it helps you write articles about upgrading to Mountain Lion Server in a way that makes optimal sense.

Once the system reboots again, you should be ready to open Server app. Except for the fact that it isn’t there, which is obvious by the fact that it’s got a big annoying white circle over it in the Dock. Remove the Server app (and Workgroup Manager or Server Admin if they’re in there) and then it’s time to install Server itself.

Go back to the App Store and search for & buy Mountain Lion Server (or install these from Purchases if you’ve already purchased them). Once installed, Server appears in the Dock. Use the following command to verify that the IP address and hostname match:

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/changeip -checkhostname

Provided that the name of the server checks out clean, click on the Server app in the Dock to be guided through the installation process.

Set Up Your Server Screen When Installing Mountain Lion Server

Set Up Your Server Screen When Installing Mountain Lion Server

At the Setup Your Server screen, click on Continue.

Agree to the Mountain Lion Server Licensing Agreement

Agree to the Mountain Lion Server Licensing Agreement

Agree to the licensing terms (assuming you do agree) by clicking on the Agree button.

Provide Administrative Credentials When Installing Mountain Lion Server

Provide Administrative Credentials When Installing Mountain Lion Server

Provide the administrative username and password to give Server and services permission upon installation and then click on the Allow button.

Configure The AppleID for Push Notifications

Configure The AppleID for Push Notifications

At the Apple Push Notifications screen, provide the Apple ID and password for a valid Apple ID and then click on the Continue button.

Congrats, You're A SysAdmin!

Congrats, You’re A SysAdmin!

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.OLD

You 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!

July 28th, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , ,

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.com

But 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.com

Which looks like this:

Non-authoritative answer:
Name: _autodiscover._tcp.318.com
Address: 66.209.67.173

Provided 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 YES

By 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!

January 6th, 2012

Posted In: Mac OS X, Mass Deployment, Microsoft Exchange Server, Windows Server

Tags: , , , , , , , , , , , , ,

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).

July 20th, 2011

Posted In: Mac OS X, Mac Security, MobileMe

Tags: , , , , , , , , ,