AD Bind after Imaging doesn't always apply.

Have you checked the standard AD-related issues like;

Time set on Mac,
Computer name set on Mac hasn't changed,
What happens when you bind manually using the same setup?
Is the account you use to bind locked in AD?

Also, I'm assuming you don't have any binding issues with 10.7 or 10.6 etc?

What's the difference between your 10.7 and 10.8 builds?

Andrew

Time set on Mac is correct. Computer name set is accurate. Binding manually works. The account is not locked. I'm finding that the first-run script is not working as it seems the "Update Inventory" piece is also not happening.

Does this only happen if you have the "Reboot Now" option selected during imaging?

I have them successfully binding with a policy scoped to computers that have Active Directory Status set to "Not Bound" or "N/A".

I have been struggling with this (or something very like it) for this entire week. "Reboot Now" doesn't make a difference for me, so far.

FACTS:
This was never a problem previously.
We had an 8.64 JSS and upgraded to 8.7 a couple weeks ago.
We have moved from the 8.6 Casper Imaging app to the 8.7 Casper Imaging app.
I've verified that the entries in the postinstall.sh & enroll.sh are correct.
New OoB MacBook Pros with 10.8.3 pre-installed from Apple.
The config we're using is a config only, we don't reinstall the OS.
Between Restores to vanilla OS X & Casperization, I remove the object from the JSS & AD.
Nothing major has changed with the packages installed via the configuration. The only changes are for application installs (Chrome, Flash, Citrix, Firefox, MS Office Patch)

PROBLEMS:
Now, for some reason, the previously functional automatic binding to our AD has stopped working correctly. It BINDS to AD, but does not correctly set our pre-defined settings (mobile account, etc). To date, I've not been able to nail down a true reason or source of the issue. As noted above, sometimes it works (bind + settings) but most times it doesn't (bind only).
When it works, there's only one bind (presumably from the enroll.sh script).
When it fails, there's 2 binds. One that I'm not sure where it comes from and then another that complains about fails in the jamf.log. On those, I don't know if it's running the enroll.sh script twice (this last time I tested, it appears that it was invoked twice). I also don't know why it fails the correctly set the AD settings the first time.

TESTS:
I've stopped the auto-reboot to look at the FirstRun scripts.
I've added logger entries into the scripts at each command entry to try and narrow what is happening when.
I've tried to compare the logs for successes and failures, both the jamf.log & the syslog and at this point it's becoming forest for the trees.

SPECULATIONS:
I don't know if the 8.6 CI app works and 8.7 doesn't. I'm still slowly working thru the progressions of testing.
It SEEMS as if on the successful ones, the enroll.sh script runs AND finishes first and then the postinstall.sh script runs and finishes.
It SEEMS as if on the failures, both scripts run simultaneously and it becomes a race condition?
It SEEMS as if on the failures the adobeinstall user is getting undercut before enroll.sh finishes?

ADDENDUM:

Comparing the 8.6 CI version of the enroll.sh script to the 8.7 CI version of the enroll.sh script...
The latter has:

## Set computer name
/usr/sbin/jamf setComputerName -name 'FOOBAR'

Whereas, the former does not.

Try adding a large package to the imaging config with "This package must be installed to the boot volume at imaging time" selected to delay the imaging process and see if it fixes.

Are those machine MacBook Airs?

I will try that.
No, they were both new MBPs, 13" regular and 15" retina. Though we did have the issue with one of the new 2013 MBAs, it then died with an unrelated hardware issue.

Ours are Macbook Airs. We're experiencing similar, you think adding a few packages like Office and Final Cut to Boot Volume at Imaging Time will do the trick? I've found a few different goofs. Some computers get enrolled fine, others don't seem to enroll and when you try to manually enroll it later you get a 401 unauthorized error. Only 11 of the 30 ran all policies fine.