For this weeks blog, I’d like to touch the topic of on-premise Jamf Pro installations, and to be more specific, some consideration to make when making your on-prem server reachable outside your network.
First of all: the thoughts and statements in this article are my own. Please feel free to comment, correct and make suggestions, but just remember to refer to docs.jamf.com (and other Jamf KB’s, white papers and tech articles) for official guidance on supported installations of Jamf Pro.
That said, more and more people are choosing for Jamf Cloud over on-premise Jamf Pro installations, and this for multiple reasons. With Jamf Cloud you don’t need to manage your own server, keep it up to date, make it secure, etc… which frees up a lot of time you can use for other things, like managing your devices instead of managing servers or just use the time to enjoy a cold beer, nice cup of coffee or whatever you fancy doing instead of maintaining servers.
But some environments are not ready to move to cloud services (yet), because their type of business doesn’t allow it, or whatever other valid reason. Hosting an on-premise Jamf Pro server might sometimes be the only option. That’s fine, but hosting your own server comes with big responsibilities (which would otherwise be taken care of by Jamf when using Jamf Cloud), and apart from organising the required ressources, keeping your servers up and running, and investing time in maintenance, there are multiple network and security considerations to make.
I’m not going to dive into all the requirements for the Jamf Pro server, as those can easily be found on: Jamf Pro System Requirements
Instead, I’d like to touch one specific part of the on-premise setup: how to allow your devices to communicate with your internal Jamf Pro server, when they are outside your internal network, roaming the beautiful but sometimes hostile internet?
Continue reading “A public Jamf Pro server, DMZ or Reverse Proxy?” 
