Global Distribution Points

[jarednichols]

Hi-

So, started my new job (first day, yay!) and their installations are spread across 3 continents. I'm interested in seeing what folks do for distribution points in their remote offices.

I'm actually thinking of some manner of "piggy backing" on their SCCM distribution points. Has anyone done this? It would be super awesome to use existing infrastructure as they've got heaps of it.

Thoughts?

Thanks
j

[jhbush]

Jared, congratulations on the new job. The SCCM replication won't work the same in the next version due to the packages being in a sql database. I use robocopy on smb shares that host packages and rsync on mac servers that host afp and http shares. I have users in North and South America, Australia, China, Hong Kong, India, and most of Europe. The hardest part for me is getting the public facing jss so my remote users can check in. We are moving to a clustered jss this year hopefully.

[jarednichols]

Perhaps I should have clarified... I wouldn't rely upon SCCM to do the replication. I just meant using some of the space on the boxes, that's all. I would assume that IIS would be set up and I could use HTTPS for package distribution. I'd still want the JSS to handling the replication.

[talkingmoose]

New job? Congrats, Jared!

We have about a dozen sites with some of those being international. In all cases we use what's already there. If ExtremeZ-IP is available then we use AFP for local distribution. If a Windows server then we use SMB. Even have a few NetApp devices using SMB.

No, we don't have replication. That's not so bad because we don't need every package in every site and some of our WAN links are slow or have high latency. I just copy manually as needed. Hasn't been a hassle.

[donmontalvo]

We have 3 main regions. Americas (AMER), Europe/Middle-East/Africa (EMEA) and Asia/Pacific (APAC). We are in the middle of a global expansion, during testing we'll decide if we will replicate this way:

AMER > EMEA
AMER > APAC

...or this way:

AMER > EMEA > APAC

Hopefully the former, but most likely the later. This assumes one database (hello Tomcat clustering).

Don

[jarednichols]

New job?

Yup, see:
https://jamfnation.jamfsoftware.com/discussion.html?id=3848

[tlarkin]

Got a quick second to respond here. Have you thought of HTTP/HTTPS downloads from a central data center world wide? I know there are caveats for it, but that allows you to have physical access to where you are hosting shares from, and allows clients on a global level to get policy. You can use thin imaging for deployment and I guess for break/fix imaging you would need a local box to net boot/image from, unless you did drive to drive imaging with onsite techs.

Anyone who is doing global deployments please add in your 2 cents.

Thanks,
Tom

[rockpapergoat]

if the remote sites use dfs file replication, that might be a good option for jss repos coupled with http downloads on the client side. if each remote site has adequate bandwidth, a central, publicly available repo would be better in some regards. take a look at what google's simian project does in conjunction with munki (management and repo hosted on google app engine): http://code.google.com/p/simian

[quade]

We are currently investigating this same setup (use a different drive letter on our SCCM secondary site servers to host a Casper DP share). We are still working on the configuration and sync details. It looks like we'll at least have 30 DP's globally on this method.

[williape]

I work for a Fortune 500 company distributed around the world. We leverage the SCCM shares for our distribution points. The SCCM team simply created SMB file shares on the various sites and gave our Casper service accounts access to read/write. This has worked really well for us.