In our environment, we have had two significant and persistent issues. Our primary devices are MacBook airs, and we image them using external drives. The image has consisted of an 1.) an OS and 2.) a package which installs a firstRun script and it's associated launchDaemon. The script takes care of wireless authentication, local admin account creation, binding to AD, and enrollment in Casper. The wireless and the local accounts always deploy successfully, but the bind and the enrollment have been less consistent. The bind occasionally fails at imaging but devices also can become unbound while in use.
I implemented Rich Trouton's caspercheck script (http://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/) last week, with positive results. I am now including this script/LaunchDaemon as a package at imaging time.
I decided to use his process (and a lot of his code) to tackle our AD binding issue as well. The process is the same, but is sped up slightly to ensure consistent binding. The script is called at boot and every four hours afterwards. It verifies that the device is on the network, forces a check-in with the timeserver, then verifies the bind using a lookup. If successful, it exits; if not, it binds the computer. This is now also being deployed as a package at imaging time.
Having these self-healing components inherent in the image means that the imaging process is no longer even dependent on the network being available. We have been dealing with these two issues for a few years, and it was a near-religious experience to watch a device both enroll and bind itself.
The binding script and the launch agent are here: https://github.com/LWindram/adBind
Note: the credentials for the AD account are stored in the script. When I build the deployment package, I set the permissions to 750 for the script, which is enough to prevent our users from viewing them.