Cloud Distribution Point questions

[powellbc]

We are kicking the tires on a cloud distribution point and I had a few things I am unclear on and would love some clarification.

1. Can you run a JSS which uses only a cloud based distribution point without any file share based DPs? My understanding is that yes, this can be the case.
2. If we do elect to have a file based and cloud distribution point, is syncing only able to be done manually or can a schedule be set?
3. Is there a way to have a setup without a master dp (with all content) where content resides on only one distribution point? For example, serve large packages and images from a local file share DP and all other packages from a cloud DP?

Any comments are appreciated. Cheers.

[milesleacy · Accepted solution]

1. Yes
2. Jamf do not provide any automatic sync tools. That said, you can roll your own. Rsync, and robocopy, are among the more popular tools.
3. You must have a master DP if you have any DPs. The rest of what you describe is possible, but not simple.

[powellbc]

Thanks @milesleacy . Any other comments are appreciated, especially with regards to #3.

[alexjdale]

3 would require you to specify which DP a package would be installed from as part of each policy, and you lose out on managing DPs by network segment that way.

You really can't do this with Casper Imaging since it will pull everything from one DP, but I assume the "large package" DP would have everything anyway.

You do need a master DP. It sounds like you'd just make your local file share the master with a copy of every package, use it for imaging, and then for any deployment policy you'd send the client to the cloud DP.

[milesleacy]

@powellbc If I understand the scenario you're trying to solve...

serve large packages and images from a local file share DP and all other packages from a cloud DP

I would...

• Use the cloud DP as the master.
• Use local Linux VMs for the local DPs.
• have local DPs fail over to cloud
• Use filesize as an identifier of which files to sync to local DPs
• Set up a managed Mac as a sync staging server (you'll need the device certs to pull from the cloud DP)
• Script to pull the large packages from cloud DP to staging server
• Rsync script per DP to pull from staging server run at desired interval.

Rough logic to get large packages to the staging server...

For each package in the JSS equal to or larger than $sizeThreshold download $cloudDPPackageLink to $stagingFolder

You may need to use the API a bit here.

[milesleacy]

3 would require you to specify which DP a package would be installed from as part of each policy, and you lose out on managing DPs by network segment that way.

Not necessarily, @alexjdale.

You could have the local DPs as defaults for the local segments with failover to the cloud DP. The clients would then pull the packages that are selectively synced to the local DPs locally, and the smaller packages would then failover to the cloud.

[Anonymous]

@powellbc If you are doing cloud based Jamf administration you can in a way do what you want in regards to you question #3. What you can do is allocate where the policies install the applications from. If you are manually syncing content from distro to distro you can choose your content that resides on them and keep your main DP filled with the larger files. In the latest release you can classify your DP's and where the policies get them. You will always have a "Master" and replicas, its just the way its designed. The screen shot shows you where the options are.

[milesleacy]

Side note: If you're in the process of building your processes and workflows, I would strongly recommend against including legacy processes such as imaging.

[alexjdale]

Right, my point would be that you don't have much flexibility with that setup since you can only have one failover (so if you want a second cloud or local DP as a true failover, you're out of luck because you are using your failovers to route traffic).

And I really don't like systems where you are planning for failovers a large percentage of the time. This might work, but it just feels like bad architecture to me.

[milesleacy]

@Npotter229 A valid option, however I believe this would introduce significant administrative overhead as you would need to select "Cloud distribution point" for all of what I assume would be the more numerous small packages.

Remember that those options are for all computers running the policy.

[milesleacy]

@alexjdale I agree with your points in an ideal scenario. However, this set of requirements does not face an ideal scenario in that (unless I've missed some changes), Jamf do not provide the option to use multiple cloud DPs as such (if you can mount an AFP or SMB share from a cloud service, you could treat that as a file share distribution point).

[milesleacy]

Side note: If you're in the process of building your processes and workflows, I would strongly recommend against including legacy processes such as imaging.

[powellbc]

Thanks everyone for the feedback. This looks like more overhead will be added regardless, which is what we are trying to avoid.

@milesleacy DEP is coming to us soon and I have been making clear imaging is going away. Unfortunately, in an institution with 6 to even 8 year old Macs in service we cannot cut the cord so quickly.

[milesleacy]

@powellbc It is a popular misconception that DEP is required to do away with imaging. This is not the case.

DEP makes Mac deployment workflows better, but there are countries where DEP is not available and where DEP is available, there are Macs that cannot participate in DEP (such as Macs that have been repaired via logic board replacement).

To make imageless deployment work, one needs to:
- never release manual configuration information (wifi, service/server settings, etc.). This forces anyone who wants their computer to help them be a productive member of the organization to enroll that computer.
- provide guidance on using user-initiated enrollment - a single-sheet document taped to the top of the shrinkwrapped Mac box should do.

Even 10-year old Macs could benefit from the above.