jamf enroll during imaging - not actually enrolling

[acdesigntech]

So I'm futzing around with Casper Imaging and the firstRun script that it creates and have run into some frustration with Configuration Profiles and enrolling on OS X client. My test lab is at JSS 8.6 and OS X 10.8.1.

There are two scenarios:

1. I specify all of my "must be installed to the boot volume" packages to install at boot time during imaging so they get copied to the firstRun script. I also have a script that runs at reboot that names the Mac, binds it to AD, and runs a jamf enroll command. When the Mac is finished and does it's final reboot, it does not receive any device profiles. I have to log in as a local admin and run a sudo jamf enroll. jamf enroll sees that the Mac is already enrolled, deletes the entry, repushes it's certificate, enrolls it, and device profiles come down immediately. One more reboot and logging in as an end user gets user profilesto come down. Prior to running the enroll command, there isn't even a "profiles" system preference.

2. I "suppress" the jamf firstRun script, using my own jamfHelper fs script to install the "at boot time" packages. I have a dummy package set to install at reboot that runs a postflight script that calls this post-imaging script I wrote to install packages and then run this naming script (same script as in #1). Doing it this way results in an enrolled Mac with device profiles already being applied.

Any ideas? I'm kinda stumped, though I think it's in the order I have things running.

This is the syntax of the post-image script I wrote:

PostInstallTrigger=( 'InstallAdbeDesStd' 'InstallFlashPlayer' 'InstallFlip4Mac' 'InstalliPhoto' 'InstallMSOffice' 'InstallComboUpdate' 'InstallJava' 'InstallUTC' 'InstallSEP' 'ConfigureSystemSettings' )

fJamfHelper ()
{
/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType fs -heading "American Greetings ISD is finishing the imaging process" -description "We are finalizing the image on this computer. It will send a completion email to you and reboot when finished. Now performing action: ${PostInstallTrigger[$i]}." -icon /Library/Application Support/JAMF/EndUserSupport/AGRose.icns > /dev/null 2>&1 &
}

/usr/sbin/jamf policy -trigger InstallISDToolset &  
## Get the Process ID of the last comand run in the background ($!)
PID=`echo "$!"`
wait $PID

## For each PostInstall trigger above, trigger the corresponding JAMF policy. We are going to do some magic by sending the trigger text to jamfHelper as a way of providing feedback to the imaging tech on what the imaging process is actually doing. 
for (( i = 0; i < ${#PostInstallTrigger[@]} ; i++ ))
do
    /usr/sbin/jamf policy -trigger "${PostInstallTrigger[$i]}" &
    ## Get the Process ID of the last comand run in the background ($!)
    PID=`echo "$!"`
    fJamfHelper
    wait $PID
done

And the naming/joining/enrolling script that is applied with both methos one and two:

LOGPATH="/var/log/jamf.log"
NAME=`grep "Set Computer Name to" $LOGPATH | tail -1 | sed -e 's/.*Name to //'`
/usr/sbin/jamf setComputerName -target / -name "$NAME"
...AD OU Stuff ...

## Bind to AD in the appropriate OU based on IP segment where the computer is imaged
dsconfigad -f -a "$NAME" -u  -p  -ou "$ADOrgUnit" -domain agna.amgreetings.com

## COnfigure no UNC home path, enable mobile accounts quietly, force local home directories
dsconfigad -useuncpath disable -mobile enable -mobileconfirm disable -localhome enable

jamf enroll

[bentoms · Accepted solution]

I've been seeing a similar issue with a MacPro that is our test mac & it's rebuilt almost daily atm..

is the offending mac being rebuilt frequently?

Try removing it completely from the JSS, then rebuilding.

[Kumarasinghe]

Remove jamf enroll command from your custom script and let JSS do the enrollment by default.

Casper has an enroll script which enrolls the computers so if you have another in your script might conflict the process. So please remove it from your script and leave everything else.

[bentoms · Accepted solution]

I've been seeing a similar issue with a MacPro that is our test mac & it's rebuilt almost daily atm..

is the offending mac being rebuilt frequently?

Try removing it completely from the JSS, then rebuilding.

[cbrewer]

I had an enrollment at imaging time issue that Casper Imaging 8.61 fixed.

[acdesigntech]

@cbrewer Ok, I'll try updating to 8.6.1. You know come to think of it, if that DOES fix it, it might be related to the naming bug introduced with OS X 10.8 that was also fixed in 8.61..

@bentoms It was happening on an iMac that was rebuilt FAIRLY frequently, but this is also happening on brand new macs that the JSS knows nothing about.

@Kumarasinghe I actually added the jamf enroll line AFTER noticing the problem with casper's own enroll command. Doesn't seem to affect anything negatively if I control the process on post-imaging (casper still runs its own enroll command). AFAIK multiple enroll command will just cancel out the preceding enrollment, so SHOULDN'T cause problems.

[Kumarasinghe · Accepted solution]

@acdesigntech
I know it should cancel out the preceding enrolments but we had "jamf enroll" command in our PostImage script and had the similar issue you described.
As soon as we remove our jamf enroll command from the script at reboot, everything is working fine now.

[acdesigntech]

well so far so good. An initial test of taking out my jamf enroll line resulted in a client enrolling itself properly the first time.

I'm going to do a few more tests today and will let you know my results.

[rob_potvin]

Maybe feature request something like an archive option. That way the record is still there but it doesn't effect the reporting.

Good idea??

[acdesigntech]

Well, it seems that I do need to remove the client from the JSS before it will enroll properly on re-imaging. Doesn't seem to be a problem for new clients, just reimaged ones.

Though it's spotty, sometimes I do not need to remove it from the JSS, but it seems to always work if I do. In that case I do not need the jamf enroll line from the script above.

Thanks for the help everyone!

[curullij]

I also had jamf enroll in my setup script and when it was present I had many issues with machines enrolling.
I removed it and found I had to leave my machines for about 15 to 20 minutes for them to enroll, bind to the AD and receive their policies.
I had been thinking it wasn't working, but it just needed time.

[acdesigntech]

I used to have an email script send an email to the imaging tech when the Mac was finished. It used to wait on softwareupdate to finish, but now I'm thinking that I should have it wait for profiles to apply before sending an email.

Do you know what directory or file mod I need to wait for in /var/db/ConfigurationProfiles? I was thinking it was MDM_ComputerPrefs.plist, but that just has the APNs token. It's not .profileSetupDone, is it?

[bentoms]

Ok.. so i've been finding inconsistencies with profile delivery & macs that have been reimaged..

It looks like the profiles are trying to install BEFORE recon is run, our profiles & MCX settings are scoped via smart groups.. without recon being run their membership is not updated & therefore the correct profiles/mcx are not received..

This is on 10.8.2 & 8.6.1

[rhysforrester]

We've just had a dozen or so similar imaging issues; 8.62 & 10.8.2.

For us, the work around turned out to be a case of removing the HD partition, saving, then creating another HD partition upon which to install an OS to. 80% of the time machines would simply not be recon'ed; and would refuse to take enroll commands via any method.

We have flawlessly produced consistent imaging results since making this change to our imaging workflow.

[bentoms]

Support advised that we should add the quickadd to the macs post imaging.

I added mine to our first run policy & seems better.

Also, works better out of hours.. So mine might be more of a server/nw load thing too.