Tiny Deathstars of Foulness

Troubleshooting push notification communications between OS X Server and Apple’s Push Notification can be a challenge. Especially with Profile Manager. One great tip I’ve learned over the years is that the APNS daemon, apsd, has a debug mode. To enable APNS debug logging, run these commands:

defaults write /Library/Preferences/ APSLogLevel -int 7
defaults write /Library/Preferences/ APSWriteLogs -bool TRUE
killall apsd

Then use tail -f to watch the apsd.log file at /Library/Logs/apsd.log. Be wary, as this can fill up your system. So to disable, use these commands:

defaults write /Library/Preferences/ APSWriteLogs -bool FALSE
defaults delete /Library/Preferences/ APSLogLevel
killall apsd

May 18th, 2015

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

Tags: , , , , , , ,

Just got to do my first troubleshooting for the iBooks app in OS X. Wasn’t a ton of info, so went digging for the debug menu that has become a staple of so many Apple apps. And it turns out that it was there. Looking at the plist for iBooksX prefs:

defaults read

This shows that we can go ahead and deploy a key to suppress the welcome screen (nice little deployment note made there) and a few other things. But what I was looking for is that BKShowDebugMenu key

BKAlreadyDisplayedWelcomeExperience = 1;
"BKBookshelfCategoryManager~012384" = 1;
BKBookshelfViewControllerFilterAction = 5;
BKBookshelfViewControllerSortAction = 1;
BKShowDebugMenu = 0;
BKSimulateCrashDuringMigration = 0;
LibraryCountDate = "2013-11-03 03:26:26 +0000";

Let’s just turn that sucker on:

defaults write BKShowDebugMenu -boolean TRUE

And then viola, the next time iBooks opens there’s a nice little Debug menu. Here, I was able to click Migrate from iTunes again (the option in the File menu didn’t work for me) and before you know it, all the titles that didn’t migrate over the first time magically appeared.

Screen Shot 2013-10-26 at 10.27.06 PM

Hope this helps someone. Also, if you want to suppress the “welcome experience” in iBooks during deployment:

defaults write BKAlreadyDisplayedWelcomeExperience -boolean TRUE

Finally, if you’re looking for a key that you can use to verify that a computer has actually logged in with an iTunes account in iBooks (could be helpful for keying off things in scripts or whatever), note that a CachedStorefrontID key (and a couple of other cached keys) is created when iBooks accesses the store or an AppleID for the first time.

October 27th, 2013

Posted In: Mac OS X, Mass Deployment

Tags: , , , , , , , , ,

I was recently working on a new project developing against Twitter using their JSON interface. Turns out that the Twitter app has an awesome little feature to assist with such a task, a Console. To see the menu for the Console, enable the Develop menu, by putting a true boolean ShowDevelopMenu key into the com.twitter.twitter-mac.plist:

defaults write com.twitter.twitter-mac ShowDevelopMenu -bool true

Once enabled, use the Develop menu to open Console. Here, you can select various buttons and see the GET, POST, PUT or DELETE sent. as well as the entities sent.

To disable the Develop menu:

defaults write com.twitter.twitter-mac ShowDevelopMenu -bool false

August 26th, 2012

Posted In: Mac OS X

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

Autodiscover automatically configures profile settings for Exchange clients. These clients include Microsoft Outlook 2007 or Outlook 2010, Outlook for Mac, 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, this might be:


But note that there’s not a response. This is because 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


Which looks like this:

Non-authoritative answer:

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:

--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: , , , , , , , , , , , , ,

XsanDebugged is a small, quick little tool that copies the Xsan logs to the desktop of the user running it. It’s designed so that an Xsan administrator can leave it in the Dock of a computer and then tell an editor or someone onsite to click on it and not have to step anyone through typing commands to copy logs, compress them and then email them. Another tool that is fairly quick and easy from the command line, but meant to save a bunch of time on the phone when troubleshooting issues remotely.

Click here to Download XsanDebugged

XsanDebugged can be found on the Apps page of this site.

January 25th, 2010

Posted In: Xsan

Tags: , , ,