World Wide Roll Out - Best Practices

We're international with our support being centralized here in Saint Paul.

For distribution points we take advantage of whatever file server or NetApp device is local to the office (AFP or SMB). I spend days manually copying files ahead of time because I don't manage both endpoints and I don't need everything synchronized from my master to the remote repositories. Not horrible. Just tedious for a new office.

For imaging just a handful of Macs I provide the local support folks a set of instructions for how to partition each Mac hard drive, install a basic OS, create temporary admin account, enable ARD, enable SSH and set the machine not to sleep. This lets me remote control and take over so that I can image the machines.

For a large deployment I'll get an external hard drive built with Mac OS X server and a NetBoot image. I'll pre-stage the Macs and then have a local tech connect the drive to one Mac and image the rest.

We don't ship hardware internationally. Our primary reason is Customs. It can be unpredictable and take machines weeks to clear depending on the receiving country. Also, shipping a Mac overseas is an extra significant cost if you've already got a local reseller that can provide them.

We're also international with our HQ in Cleveland. At one time we were using existing netapps in each remote office to host Distribution Points, but this became extremely tedious when it was time to sync changes from our Master DP. These had to be done manually since we do not have SSH access to the netapps. Additionally it required us to use a Mac workstation accessible by anyone in that office as a "management station" since there is a certain level of autonomy expected of the tech(s) in each office as far as imaging and installation goes. We used to have external imaging HDD's that needed to be separately updated and maintained - it was a mess. Additionally, my IT team did not have control over the netapps, so we were constantly at the mercy of the server group.

Early Last year I made an effort to install a Mac Mini server in each remote location to leverage Casper's automatic sync function as well as perform SUS duty and Netboot duty (my management was not interested in Reposado and the NB appliance was not available at the time). The remote servers are cascaded from our central SUS in Cleveland, and the netboot function is what all remote sites use to image the Macs when they purchase new (all the remote sites have a "single" subnet so all they need to do is hold N on boot. Then our NBI takes over with a script to partition and lay down a base image, and launches Imaging to finish it off). This allows me to control all aspects of our Casper management framework from WHQ and standardize our approach to client management worldwide. Now that the NB/SUS appliance is available, you might want to consider leveraging that if you don't want to purchase additional "servers."

If a site has 5 or more Macs, it gets a Mac Mini server. Some of our sites only have 3 macs, but they'll be getting a server nonetheless because they are 24-hr shops and we simply cannot afford the downtime if a Mac needs to be reimaged. Our largest site has 55 Macs and is purchasing more. We also do not ship computers internationally due to Customs nonsense and cost, and have new Macs drop-shipped to our domestic sites if purchased as part of the annual refresh project. Otherwise they just by them locally.

One comment on imaging systems at your HQ and shipping; we ran into a multitude of problems doing just that, and that was the first and only time it's happened under my stewardship: Our computer naming scheme is based on geographic location (ex: CLEMD for a Cleveland Mac desktop and FAIMD for a Fairfield Mac desktop). Our imaging process automatically adds macs to our AD and moves them to the right OU based on machine name. Additionally network time settings, time zone, etc were all set up for the CLE location, and there'd be a number of headaches after-the-fact once they were shipped. So it may be in your best interest to NOT image them in a central location and then ship them.

We're global (2,000+ Macs) with JSS in California. We are in the process of migrating off the cr@ppy Apple server hardware and onto a virtualized Windows Server 2008. JSS and MySQL will run in California, and there will be Tomcat/DP in all other regions.

The only thing we'll use the Apple hardware for is NetBoot since we haven't won the "configure your switches to allow IP Helper traffic" discussion (yet/hopefully).

We LOVE the NetBoot/SUS appliance, but to be honest, we can't use the NetBoot part since we don't/can't set up a virtual environment in every spot that needs NetBoot (SUS isn't a problem). If JAMF could give us NetBoot solution for Wintel hardware (even if it installs on Ubuntu, etc.), we'd be deploying that and drop kicking the last Apple servers out of the environment.

Once we're done migrating (ie: firing Apple from the server side of things), we'll be circling back to add MDM to the infrastructure (separate JSS for that). That will be virtualized as well. So we'll be able to handle BYOD as well as issued mobile devices.

Don

Thank you all for getting back to me. Nice hearing how you viewed the issues and handle them.

I just realized we will have another issue. Currently, our Macs are binding to:
OU=Mac,OU=Desktops,dc=companyname,dc=com. How are you setting AD? Our AD person thinks we should handle by region - same as the PCs: Mac - North America, Asia, India, Europe. Is this how you are handling AD?

At my previous position, the macs were in there own OU, too, not based on location, but the machines names also included a location reference.

Regarding imaging and netboot - no matter which solution is taken, we are not putting up helper IPs. Seems that pixie boot and netboot will exist only on the same subnet as the local help desk.

If you are willing to chat off the list, I am lennysachs at mac dot com.

We are also handling by region, but each region has a separate OU for the Macs. It does keep things tidy, especially when you have to throw SEP into the mix (it will not sync Mac AD Objects no matter how nicely you ask).