Oh boy. You have opened up a can of worms!
First, there is no best way. I've struggled to find it and it is an elusive mythical beast. Your environment, needs, device issuance policy, and about 400 other factors will influence the methods (not the plural) that you use. Here are some thoughts and options. And, by the way, I really believe Apple is listening to the community and they are working on solving these challenges. But, when it comes to imaging/deployment/etc topics, there is always exceptions to the rules. Let's start with some topics to sink your teeth into.
First, you should be checking out Apple's DEP and VPP programs. If you don't know about them, head on over to https://deploy.apple.com. Ok, how does this help you? In a perfect world, IT creates an infrastructure of infinite efficiency and everything resonants with hints of harmony. With DEP and VPP this is closely achievable for initial deployments. Let's go through the process. You set up an MDM solution (Profile Manager, JAMF, AirWatch, etc). You enroll your company in DEP and start buying direct from Apple or from a DEP capable authorized reseller. No Apple Stores allowed here unless you are working with the business teams. Now, all devices that you purchase are linked to your organization. Through the DEP portal, you can assign these devices to your MDM(s). Now, logging into your MDM you see the devices, allowing you to set on enrollment policies. This allows you to do some magical things. For example, you get a stack of new laptops. Simply hand them out to the end user. Let the user unwrap the unit and get the power on rush. Setup Assistant will ask to join a network. Once it does, it will reach out to Apple, realize the device is part of DEP, discover the URL for the assigned MDM server, and then route to the MDM server asking the user to enroll the device. The user enters a domain credential set (more on this later) and the device will then receive all policy and packages defined on the enrollment policy. IT is removed from the actual device setup and configuration. All you need to do is build the foundation. End users do the rest. Ah, harmony.
Ah, but this method has some obvious holes. They can be overcome, but it is more work. Here are a few. First, the user is the local admin account. Many organizations prohibit users from being admin. Next, while the units are enrolled by using domain credentials, the device is not bound to a domain. Now, if the user account is local, this obviously is useless, but you are now managing policies on local accounts on a per machine basis instead of doing in one place on the domain server. Now, on the flip side, for companies deploying mostly laptops, binding to a domain only ends up being a pain anyway. After all, who reboots their Mac? The domain is only truly negotiated during login window. This is the Apple push to a domain-less deployment world. But as usual, Apple is about a year or more ahead of the rest of the world. Right now, this is being met with resistance (yet the resistance is easing, partly due to the "success" being promoted by IBM).
Whoa you say. I can let my end users have at it on machines. I need to control them and I want to do imaging. There are a few ways you can pull this off. You can do full blown monolithic imaging. You sit down, craft a master machine to be everything you want for your workforce. You install the OS, patch it, manage core AppStore apps, install print drivers, define printers, install and serialize 3rd party apps, and customize the initial user experience by customizing the User Template. You capture this pristine work of art to a DMG and you start cloning it to your other devices. Life is great. Cloning on modern gear takes less than 10 minutes so you are feeling pretty good about going from shrink-wrapped box to user's desk in about 20 minutes. And then Apple releases updated hardware. The hardware runs on a newer version of the OS and your image kernel panics the machine. Argh. Time to start all over again. Monolithic imaging is great when deploying tens or hundreds of machines during a narrow deployment windows. Monolithic requires a lot of management if you are deploying one or two machines at a time. Because, the minute you finish it, some one (Adobe Flash, Firefox, Chrome, Acrobat, iTunes...) will release an update, rendering your perfect image not so perfect.
Ok, so those are two extreme ends of the spectrum. There are many places to stand in between these polar opposites. For example, with JAMF you can achieve a hybrid thin imaging process. One argument Apple always uses against monolithic imaging is "why replace perfectly good bits with the same bits." Meaning every machine ships with an OS and a bunch of apps. Cloning an image over the OEM OS is effectively overwriting what is already there. With tools like JAMF, you can take a hybrid approach, allowing the shipping OS to remain in place while adding only your changes, including a consistent initial local admin, User Template modifications, core application installation, etc. By doing this method, you avoid the constant creation or management of a monolithic image and instead focus on managing the application versions. Now, when you have to prep a machine in the first week of the month, the machine gets Flash 21.0.0.123 but when you prep a machine in the final week of the month it will get Flash 21.0.0.999. You maintain the menu of options, delivering a consistent set of tools to the unit regardless of the shipping OS. So that new laptop that will only boot 10.11.5 will be fine (assuming no application incompatibilities...) because you are not trying to overwrite an OS.
Next this goes into the topic of setting preferences. I am all about the "initial user experience." Maybe because of the education deployments. Maybe because of complying with never-ending corporate device policies. However, there is comfort in knowing that every user will start off with the same experience. This make documentation and self help document easier to create. By crafting a consistent initial user experience you can also guide usage of the device. Don't want users discovering devices via Bonjour... Hide Bonjour Computers in the side bar. Don't want anyone Air Dropping... Hide Airdrop. Don't want .DS_Store files littering the enterprise Windows server... Prevent creation of the files. Want to stop every user from being prompted to login with her Apple ID... suppress Setup Assistant. Ah, but these are no configurable outside of some defaults commands and the customization of the User Template.
And finally (Sorry, you got me on a free afternoon and I just don't feel like starting something new) there is the question about lifecycle management. A Mac issued to a user may come back to you. And then what? If you are using DEP and the user set up the machine initially, you can't just hand the machine to the next user. You need to reset the machine. But how? Let's say it was purchased in 2015 and shipped with Yosemite. Since, it was updated to El Cap. You get it back and... Reinstall from recovery partition? Now you are missing your iApps. If you converted them to VPP license, then fine, let the next invited user install them. If you are not using VPP, then you need to go and get them using which Apple ID? Yours? A generic "enterprise" ID? And then how do you update them later?
On the flip side, maybe you built the machines with monolithic images. You bought/leased a fleet of devices in 2015 and your image is Yosemite 10.10.5. You have not purchased any new gear but since purchase, everyone is not on El Cap. A machine comes back to you. Do you re-image using the 10.10.5 image that you built nearly a year ago and then go through the process of upgrading everything to get it back up to date? Ouch, there goes a whole day.
Once again, sorry for the rant. I think, all this above is just saying there really is no one way to do this. You likely should employ a number of strategies to satisfy different phases on the Mac's life. Using an MDM like JAMF can make things a lot easier. But managing the environment with a monolithic image can be fast and simple when it is time to image or reset. You need to analyze the needs of your deployment and also look at what type of infrastructure you want to build. Monolithic can be accomplished with a bootable external volume. Anything from an SD card to a Thunderbolt drive will work. Thin and zero touch needs infrastructure. Monolithic is great for initial consistency but you need to make up the continuing management on your own. Thin can provide continued management efficiently.
Ok, I need to stop. I think I can go on about this for hours. Hope this helps. The only way you will know is to start experimenting and trying out different methods. See which works best for you, your business, and your users.
Reid
Apple Consultants Network
Author - "El Capitan Server – Foundation Services"
Author - "El Capitan Server – Control & Collaboration"
Author - "El Capitan Server – Advanced Services"
:: Exclusively available in Apple's iBooks Store