Distribution Point considerations

I don't have a global setup, however I have distributed cores across our town for our network, and I have a distribution point at each, with all of the schools coming back to talk to our JSS for information and then using the distribution point closest to them for packages and scripts.

@tsd25108

What was the consideration for having a DP? Were your links between sites slow or low volume?

We have a globally distributed network, and if a remote site has a Mac and is connected to our intranet, it gets a DP since all company Macs are to be identically managed. We purchase Mac Mini servers to act as our DPs. This works well since they can also pull double duty as Netboot and SUS. Somer sites are high volume and require their own DP. Some are low volume overall, but are 24-hr shops with specific apps on the Mac workstations that are heavily used, so we couldn't afford the downtime if a machine needed reimaging or updating.

Casper's built-in syncing runs nightly for us, the SUS's are cascaded. The only problem I run into is when a change to our NBI(s) is made. That's a manual copy right now.

Something I'm considering is "piggy-backing" on SCCM distribution points. I'm curious if I could run IIS or Apache on an SCCM distribution point that had some dedicated storage carved out for the purpose. It seems a bit silly to stand up a box just for winging out packets when there's likely a perfectly good one in the same rack hardly breathing.

Though, the box goes down and DPs for both services go down...

Just talking out loud here.

@jarednichols I really decided on it mainly because it would just help reduce traffic back to my datacenter. The links are all a gig with a gig backup link on private fiber, but our plan is eventually to move our network to layer 3, which since one of the advantages is less traffic traveling across the network, I figured it wouldn't hurt. However, its funny you mention SCCM. We use SCCM for our windows imaging, and I'm looking to put distribution points at each of the cores for that as well. I really didn't like the idea of having 2 machines there doing essentially the same purpose for 2 different systems. However, because SCCM really needs Windows distribution points to work in a supported setup, and my JSS is running on Mac OS, with my distribution points on Ubuntu Server so that it's all uniform (My biggest reason to stay with unix based systems was permissions).

we were originally piggy backing on local windows servers, but got tired of not being able to automatically sync (at the time there was no move to develop an rsync or similar method to do so). If i had to do it over again, I'd still pick the same methodology of standing up another Mac, even though there are other options (NB appliance, Reposado, and rsync). I like being able to leverage the existing hardware/software I deploy in order to keep a tidy and sane management framework (JSS's built-in syncing features, Apple's built-in cascading SUS). ALso like you mentioned Jared, I like the idea of one server going down NOT meaning the entire operation goes down, at least as far as package management goes.