Skip to main content

We have several offices around the globe, in NA, EU, AUS, etc.

I've got the Master JSS server externally accessible in AWS N.Virginia. There is vpn connectivity between this VPC environment and our intranet. For each building, I have a JDS instance setup to serve the network ranges...easy enough. What's the best practice for roaming users, say at home or elsewhere?

I've seen the approach for setting up a "default" network segment that internet users would fall into, and I can default that to an externally accessible JDS in AWS alongside the JSS Master. The thing is, people at home from the sydney office will be connecting to the US-East based JDS in that scenario, same for employees in Ireland, etc.

Is there a method I can use to leverage geo-distribution? I don't mind having a web accessible JDS in each global region.

As you can imagine, you can't feasibly network segment global IP ranges. However, I am able to leverage anything about the machine, including AD attributes of enrolled users, hostnames, file configuration, anything. It would be great to put together a solution to solve for enterprise like this.

If there was a method that allowed client machines to decide which globally accessible JDS was closest to them (whether by registering a list of FQDNs and pinging them, having an explicit configuration "default" network segment setting that is region specific (based on system clock timezone, configuration in a file on the filesystem, configuration on the computer object in JSS, anything).

I struggle somewhat with defining distribution points and network segments as well, also a large global infrastructure.

@JoshS from Expedia showed us their solution at JNUC, they came up with a programmatic method for the client to find the closest (fastest responding) distribution point, on network state change I believe.

Have a look: https://github.com/Expedia-IT-CTE/radar

The downside to radar was it did not work for JDS currently.

@rderewianko There are notes for a workaround to include JDS support (and subsequently, failover support).

I can't speak to RADAR's reliability or effectiveness, but @dpertschi - that link was fantastic. Thanks for sharing that information! I'm going to give a try and see how well it works. Will report back.

I looked into RADAR as well...
I'm looking for informations how the correct DP will be mounted once a policy is running.
All ideas are welcome.

If you're using radar, It'll connect to the JSS every time the network changes.. Pinging whatever has the lowest ping time for the correct DP. (which in theory the closest should almost always have the lowest ping)

When you're outside the LAN your machine won't be able to ping the interal DP's and will default to the external dp.

@maik.sanftenberg You can also use network segments to set the correct DP's for each External IP.

You could also give all your JDSes the same "JDS URL" (like https://globaljds.pretendco.com) in the JSS; they still can have different values for "Hostname" and "Reported IP Address".

Then set up some kind of Geo-Balanced DNS service (like Amazon Route 53) to hand out the IP address of the nearest JDS for that URL. That way you do not have to mess with Network Segment scoping and just give every client the geolocated "virtual" JDS URL.

The only thing is that you cannot easily cascade those JDSes without overriding that special JDS IP in the appliances' hosts file.

@cvgs Sounds great!
Do the certs of the JSS CA still work? JDS URL https://globaljds.pretendco.com and Hostname oneofmanyjds.pretendco.com will not match... or how is the cert business solved?

Terms & ConditionsCookie settingsAccessibility statement