Mavericks Server: Enable APNS Debug Logging

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

Debugging and Deploying iBooks

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.

Debugging Twitter

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

How Exchange's Autodiscover Works With

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: nslookup 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 nslookup Which looks like this: Non-authoritative answer: Name: Address: 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/ 
--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!

Xsan Log Generator

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.