Self Hosted to Managed JAMF Pro

If you know me or have read enough of my ramblings you’d know I work in education administrating close to 1,000 iPads. The logical solution for managing this amount of devices is an MDM and the one we leverage is JAMF. I’ve known about the adoption and widespread conversions to cloud since the last JAMF conference I attended, I think the statistic was 70% and when I saw the benefits I was sold; who wouldn’t want to lose the headaches associated with keeping another vital system up and running. Windows updates, Java updates, SQL updates, not to mention the overhead and resources allocated (despite being virtualised it’s still cranking power), maintaining backups, proxies, SSL certificates and more. The only thing holding us back was the cost which thanks to subsidization, this renewal period was brought below on-premises price.

The first step was to collaborate with our reseller and get some quotes. After the red-tape and being given the green light from leadership the wheels were set in motion. I had an initial Zoom with a technician from JAMF who would be overseeing the migration and we covered various scenarios and ways to proceed. My first decision was which type of migration we wanted; greenfield or brownfield – basically a clean installation starting over or keeping things relatively intact. I chose the prior because the prospect of re-enrolling that amount of devices and potential data loss was unacceptable. I was advised this was the most common scenario and felt relief in my choice, even if it meant more technical challenges ahead. This was at the end of 2020.

I tried to schedule the migration for late January and got close with the 4th Febraury, today was the day. The process went well and today’s 3 hour Zoom saw a semblance of success. The first thing I had to do was dump the database and upload it to a the technicians Dropbox. Behind the scenes their people set us up on Amazons AWS, I had to confirm ownership of the domain to validate the SSL certificate through our oft-unused admin email account and they brought it online.

There’s some magic in this process though because the iPads (and everything really) will be looking at the existing address which I turned off. I deleted the A record in our DNS and created a CNAME record redirecting to the new jamfcloud domain. We did some testing with an enrolled iPad (it received the commands and went into lost mode), did an enrollment, tested app pushing, made sure all the certs were in place and working… everything* worked! Except…

We couldn’t connect to the instance from within our own network… what the heck? Surely this is DNS right? It’s always DNS. I bid farewell to my new friend from JAMF and was left with this conundrum to solve on my own as it was beyond the SoW. I must have tried everything on our poor DNS servers to no avail, it wasn’t happening. nslookup was showing the correct details, I checked the ACLs and white-listed all of the JAMF domains, nope. But I could access the instance on the wrong port, and the CNAME was working as it should. Why? I finally figured out the reason – the downstream proxy dumps any SSL traffic which isn’t on port 443 (JAMFs rocking 8443 from Apache’s Tomcat). I’m at home now and thinking of how best to deal with this, I might just bypass the entire domain, it’s not like we would want to cache or inspect any of the management traffic anyway, and y’know, every iPad has the proxy within their mobileconfig.

Leave a comment