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.

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.

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.

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

New job?

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

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

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

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.

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.