They sure are working them real young these days...

Is the time correct on the machines after they finish imaging? Time drift is always something that gets initially overlooked when binding fails. It may not be that, but I would check, just to rule it out.

If I'm not mistaken, there is no local imaging log stored on the Mac when using Casper Imaging, so I don't think there's anything you can check for there. But the JSS has an imaging log, and it may reveal something.

Just curious, but have you tried a test of using a binding script instead of the built in bind commands? When you set up a bind object in Casper Admin that CI uses, its calling the jamf binary's built in binding commands if I recall. Try using a custom script to see if it binds that way. If so, then somehow the jamf bind isn't doing what it needs to.

So I have had some interesting problems with binding and 10.10.3 myself. Possibly related.

My new environment does not have Casper yet (luckily we are in the process of purchasing it now). So I have setup a custom .pkg that configures all of our settings post imaging to make things easier for our techs. On 10.9 machines this .pkg binds the machines just fine (via script)... but on 10.10.3 machine it not only fully locks up the machine, but totally corrupts the hard drive. I have to FSCK it just to get it to boot normally afterwards. I have also found the exact same effect if I try and run my bind script via ARD. Lock up > HD corrupt. It's 100% weird.

So I broke the bind portion of the .pkg out to a .command file, and when you run that... everything binds normally like the package (or remote script from ARD) did. It also binds just fine if the script is run locally or from the GUI bind process. But .pkg or ARD... womp womp. Fail>Lock Up>Corrupted HD.

I have not yet tested whether I get similar behavior from Deploy Studio since my predecessor had us working from a monolithic image - Disk Utility Restore process (and I'm only just now getting modular imaging setup here), and as we don't have Casper yet I obviously can't test that. But I thought maybe this odd behavior might be part of what you are experiencing so maybe it might help one of the genii out there solve your issue.

Or maybe I've just diverted the conversation... in which case please ignore me and cary on. :)

@sanaumann this write up may or may not help you...

https://derflounder.wordpress.com/?s=10.10.3

@sanaumann How did you create your 10.10.3 base OS? AutoDMG?

We already know that you're not getting binding... when you image, do you at least have the MDM profile in place? If not... you have two issues.

Can you look at the /var/log/jamf.log on the machine and see what is happening post-imaging? A first boot script will run, that should be taking care of the enrollment/profiles as well as the AD binding. Somehow that script may be failing.

What version of the JSS? What version of Casper Imaging?

Also how is the machine being named? https://support.apple.com/en-us/HT203193

Hello, all.

That's my daughter, but she's 11 now. :)

The time is correct on the new images. That was the first thing I read about and checked off the list of possibilities.

We looked at the derflounder site but it did not apply in this situation. We have zero connectivity to our network pre-binding. And when we manually bind in 10.10.3, it works fine. Thanks for the information. :)

I thought about writing a script but I don't know enough about scripting in this environment to be sure I won't kill something important. I'm a native Windows scripter. I wasn't sure if I'd need to write something to unbind the machine first since some of these machines will be reimages, and then what logic to use to tell the script how to recognize when a machine was new, etc. #mightbeoverthinking

Hi, Robert.
Yes, I used AutoDMG.
No, we are not getting ANY profiles. If we manually bind a machine, we can also enroll it manually. However, it does not pull any down by itself until we enroll it. Self-Service is missing on the initial image as well.
I don't know if there's a script in the image that runs post-first boot.
Our JSS is 9.63, Casper is 9.5.

Have you tried creating a new AD bind policy? We had an issue with a "corrupt" profile that worked on 10.9 but not on other versions.

Trying a new bind now just for giggles. I'll let you all know.

Pete, we are naming them by their SNs (without the S in front).

I would also first try recreating it. if that doesn't work, you can attempt a scripted process, if just to see if it works as opposed to the built in function, which would point to some issue maybe with the built in binding function.

But, just so you know, If the Mac is re-imaged, its not typically necessary to first unbind, then rebind. Some places do that in order to keep the AD records more tidy, since just re-imaging without first unbinding will leave a record in AD for that Mac that doesn't match up with anything.

If a Mac gets re-imaged and ends up with the same computer name, for example if its a lab Mac and it always gets named with the serial number or something, when binding manually, it will ask if you want to overwrite the existing computer record in AD. This is typically OK as well, as long as you're certain its the same Mac (i.e, you aren't clobbering the AD record of another valid system) and the service account used for binding has the rights to actually overwrite an existing record. You'd need to check on that, because a lot of times binding accounts have the rights to create new records, but not update existing ones, for obvious reasons.

As for a scripted binding method, here's an example of that. On OS X you use dsconfigad to bind a Mac to AD (unless you are using a custom solution like Centrify)

#!/bin/bash



## Use your domain name between the quotes, usually something like "com.domain.pretendco"

dsconfigad -add "your.company.domain" 



        ## A username with binding authority (must have rights to add computer objects to the OU listed further down the script)

    -username "binding_username" 



        ## Password for the above user

    -password "binding_password" 



        ## Enter the computer name, or direct the script to pull the computer name with 

        ## something like "scutil --get ComputerName"

    -computer "COMPUTERNAME" 



        ## Set to disable if you don't want mobile accounts

    -mobile enable 



        ## Goes in hand with the above setting, warns on mobile account creation (enable), or not (disable)

    -mobileconfirm disable 



        ## Use disable if you don't want a locally cached home directory

    -localhome enable 



        ## Set to enable or disable based on whether the HOME should mount based on UNC path. Recommended to set to "disable" if you have users logging into their Macs away from domain controllers

    -useuncpath disable 



        ## Leave this as is unless you have a good reason to change the default user shell

    -shell /bin/bash 



        ## Set your OU to join the Mac to here (binding account used above must have rights to create/edit objects in this OU)

    -ou "OU=Macs,OU=Computers,DC=org,DC=company,DC=com" 



        ## Add any AD groups here that you want to allow local admin access on the Macs

        ## (while in range of your DC)

    -groups "ORGmac administrators"

Hope the above helps. Its just a template and I'm sure others will have different versions, or other recommendations.

One other thing. If you think you'll need to join to existing AD records, you need to add in -force after the dsconfigad -add "your.company.domain" part of the script. This forces the bind (join to existing)

I've seen the same problem with our Yosemite image. However, I think there's actually a shift in WHEN the computer joins Active Directory. With Mavericks, it would join during the imaging process. With Yosemite, i've noticed that if I wait long enough (anywhere form 5 to 30 minutes) it will join AD after or during the post-imaging enrollment policy executions. I don't know why it waits until that point to join AD because our Yosemite image is basically identical to our Mavericks image with the exception of the OS. See if after a machine is imaged and it reboots, wait half an hour before even laying your hands on it to see if it did eventually join on its own.

TL;DR

A couple thoughts, have you checked to see if the computer is disabled in AD? If so delete it and then (re)bind.

Also if you're using a service account, make sure the password that JSS is using matches the one you're using when manually binding.

I'm struggling with the same problem too. I am creating a Yosemite image for the first time and cannot get it to bind to AD or to enroll with the JSS. The same bind package works fine with 10.9.

check time on computers too if the time is off by >5 mins binding will fail.

I got mine to bind and enroll! I was using an older version of Casper Imaging in my netboot server. I updated it to 9.72 and everything is working.

I did a different bind, no change.

I tried the 9.72 tools in netbook, no change.

I recreated my OS X image, no change.

One thing I have noticed is that between the Casper screen and the black screen where it installs everything, it briefly pops up the Setup Assistant screen with the Yosemite background, which is really weird. It's like a second and then right to the black screen. Also, the dock is coming up with question marks for a bunch of apps that we don't allow, like FaceTime, Messages, etc. Something is seriously jacked up and all I originally did was replace the OS file.

Sad me.

Also, we left one machine sit about 45 minutes and it did not bind.

I'm a little leery of using a script with a plain text password in it. Unfortunately, my company gets audited a lot and that's the kind of thing that could get me into trouble . . . ;)

@sanaumann Not sure what may be going on in your case. You mentioned that the Setup Assistant pops up for a second and I wonder if somehow in your configuration, its not suppressing that Setup Assistant and the Mac is actually sitting there waiting for that to be dismissed and eventually times out. Since you can bind manually using all the same information, we know its possible for a bind to occur, but something is interfering.

Another possibility is that the jamf bind command isn't making it into your firstrun script, or maybe there's a timing issue on your network. There's a way to capture the firstrun script before the Mac reboots, but it escapes me how to do that at the moment. Maybe someone else can chime in on how to do that when using Casper Imaging.

As for the script and passing usernames/passwords in the clear, good point. My script was just posted as an example and not intended to be used as-is. You can pass almost all important items to the script as parameters so they aren't hardcoded into the script. For example, $4 becomes the domain, $5 becomes the bind username, $6 becomes the bind password and $7 can be the OU to bind the Macs to. If the script was ever located/intercepted, all anyone would see for those items are those parameters or variables instead of actual data.

@mm2270 Yeah, something's strange but I'm still knocking around.

All of your help is appreciated, everyone! :)

@sanaumann did you try searching for and deleting the computer from AD? Also is the computer disabled in AD?

I'm actually an AD admin, so I went in and found one of the test MacBook Airs. It was not disabled. I deleted it out of the domain and after a while, readded it. I also compared all of its attributes with my machine to verify nothing weird was going on. It looked ok.

Maybe find/delete the computer object from AD, and then let the JSS policy re-bind?

So update time:

I was striking out on all of the suggestions I could implement from the JAMFnation, so I tried using a post flight script and put all of our scripts in it, set up a trigger, and let it loose. The result was better, we got profiles this time but still no bind (and a few of the scripts did not run but I'm sure I could fiddle with it and fix those).

I also tried putting a 10.10.3 update into a 10.9.5 image but that didn't work. I got our very pretty Mavericks image but the Yosemite piece didn't show up at all.

I decided to pull the InstallESD.dmg out of the Yosemite Installer, throw THAT into AutoDMG, and make a new OS DMG to put in the Yosemite build. It's about the only thing I haven't tried and the DMG is the only variable in this equation. I'll update again later . . . unless this also fails miserably, in which case you will all hear me screaming from wherever you're located because it will be loud.

~SGN

@sanaumann when you say "setup assistant" do you meant the "iCloud" assistant?

If so.. That's fine.

But seems like a clean OS.dmg might behave better, I've not heard much screaming so guessing so?