Questions on clustered JSS in DMZ

What @johnkitzmiller said. This is our exact setup at UAL.

@johnkitzmiller: thanks, this cleared up a few things :)

I wanted to ask a follow-up question to this thread. We are looking at adding external access to our JSS for our iPads and understand the guide to the JSS in the DMZ but still am not sure about the URL question. If we add a new JSS in the DMZ with an external address such as jss.external.com and we currently have our devices deployed with an internal address for our internal JSS server that does not have an Internet facing domain such as jss.internal.com. We are unable to match the two addresses since the internal domain is not Internet facing, what are the steps necessary to make this work if anyone knows? Do we need to rename all the internal URL's to match the external and if so, how do we update the devices already deployed? Thanks in advance.

johnkitzmiller summed it up with #3

3. The clients are only able to check in to one DNS name. Ideally you'd have "split horizon" DNS so when clients are inside your network, jss.mycompany.com points to your internal server, and when clients are outside your network, jss.mycompany.com points to your DMZ server.

@Potter has it exactly right. It's how we've set things up. Your mileage and infrastructure will vary according to it's existing design.

Hi @mkempster][/url

There are a few things you would need to do.

First, you'll want to make sure the new, public external DNS name is used internally to point to your JSS, so that the JSS URL matches both internally and externally. You'll want to keep the original URL also pointing at your JSS for now (we'll need it in a later step).

Second, you'll need to update the JSS URL within the JSS. In version 9, this can be found in Settings > Global Management > JSS URL.

Third, replace the Tomcat SSL certificate to reflect the new URL. If you're using a cert signed by a third party CA, you'll want to follow their instructions to create a new certificate. If you're using a certificate signed by the JSS Built-In CA, you can update it by going to Settings > System Settings > Apache Tomcat Settings, and choosing the option "Change the SSL certificate used for HTTPS" followed by "Generate a certificate from the JSS's built-in CA." You'll need to restart Tomcat (https://jamfnation.jamfsoftware.com/article.html?id=117) to use the new certificate.

The last thing we'll need to do is get all your devices pointing to the new URL.

For OS X, you can do this one of two ways. The first is to update the jss_url in /Library/Preferences/com.jamfsoftware.jamf.plist. You could do this by modifying the plist, capturing it with Composer, and deploying it with a policy. You could also use a more surgical approach by running a defaults command in a policy, similar to the following. ```
defaults write /Library/Preferences/com.jamfsoftware.jamf.plist jss_url https://new.jss.url:8443
``` Make sure you keep your old JSS URL pointing to your JSS until all your computers are checking in with the new URL.

For iOS, the answer is a lot shorter, but far more labor intensive. You have to re-enroll all iOS devices to the new JSS URL. Unfortunately, there is no other way around it.

If you get stuck, feel free to reach out to your account manager for more support.

Alternatively, if you'd like some hands on help, a member of our Professional Services team would be more than happy to work side by side with you until all of your devices are migrated to the new URL. For more info on JAMF Software Professional Services, you can view this link: http://www.jamfsoftware.com/services/. JAMF Software Professional Services can be engaged through your account manager.

I hope that helps!

Take care,
John

@mkempster.. Just to add.. That if you're looking at changing the URL.. I'd maybe create a new JSS with this URL.

The macs can then be enrolled onto the new JSS using a quick add deployed from the old, but you'll still need to re-enrol the iPads.

This process just allows you to transition.

Thanks for all the great responses. Can the iPad users simply go to the new user-initiated enrollment page once we have made the change and step through the process or would we need to remove the existing "old named" enrollment prior to that step? Obviously we will have to coordinate this change to re-enroll all the currently dispersed iPads either way but if we could have the users simply go through the webpage enrollment again and get connected that would be great.

@johnkitzmiller is it not possible to run one JSS for external (with separate URL) and one internal? Our DNS is all publicly announced so we can't have split horizon set up.

Hi @dwest,

That's a great question! Unfortunately, no, that is not possible. Devices are only able to report to a single management URL, so we have to use the same URL for all servers.

Hi @mkempster,

Sorry for the late response. I only just noticed you replied to the thread.

Unfortunately, the existing MDM profile would have to be removed before the users would be able to go through enrollment into the new JSS. iOS won't allow an MDM profile to be overwritten by another MDM profile.

@dwest

There are other options as well. You could go the route of not having any web apps in the DMZ, but instead setup a load balancer and some proxy servers (with proper network ACLs in place) that will forward traffic into your internal load balancer and into your JSS infrastructure. However, the client itself will still have to phone home using that single management URL to the JSS.

You could start with just one DMZ proxy server if you wanted to. I only mentioned the load balancer in the DMZ so you can cluster proxies behind it for scalability and redundancy. That way if a proxy goes down, others are still up to direct traffic to your JSS.

Hope this helps,
Tom

Thanks for the ideas and info. I think we will go down the route of having all try and check into our external facing jss, but then tweak our internal resolvers so when they are inside it connects to our internal full jss. Our external will only have a few things on it for security reasons.