El Capitan 10.11.3 Partially Enrolled During Imaging

[MTFIDjamf]

All -
Have begun testing with El Cap 10.11.3.
Created my AutoDMG base with the latest version and imported it into the JSS. Began imaging process of a test device using just a few scripts (set preferred domains on Ethernet devices, set our proxy setting, dropped our root cert and installed it) and no applications to see what would happen.

What I am seeing is new to me, the device will not enroll all of the way at first. When it actually does it can be up to 60-90 minutes after it started. Happening if I enroll during imaging with a management account creation or using the Enroll URL.

When I run a sudo JAMF Enroll -verbose or a sudo jamf recon -verbose it seems to plow through applications and EA's but then gets stuck at 'checking AD settings...'

Logged in as a local admin only, not an AD account.

This happens whether the device is bound to AD or not at this time.

I have disabled all Extension Attributes thinking that one of them might not like El Cap but the issue persists.

This is not happening with any 10.10.5 devices which we are pretty heavily imaging daily.

Any thoughts? Ideas?

[mpermann]

@MTurnerFMRCO if you are using Casper Imaging, you'll want to be using 9.8 or later to image the computers. Can you provide the specifics (i.e. version of JSS, Casper Imaging, NetBoot Set OS version, etc.) of your environment so we can try and help out.

[MTFIDjamf]

@mpermann Apologies. This has had me pulling my hair out most of the day as I have tried different imaging steps and may be delirious.

JSS 9.82.
Casper Imaging 9.82 installed on USB boot media. All packages/scripts on network DP's.
Trying first run at El Cap 10.11.3 on various test models. Unable to enroll anything or update inventory with this OS in less than an hour.
Rest of environment on Yosemite 10.10.5.

[mpermann]

@MTurnerFMRCO have you tried just putting the AutoDMG created base OS down without anything else just to see if one of the things you are installing is interfering with the enrollment? Can you post a sanitized image of your Casper Imaging workflow that you are currently testing?

[MTFIDjamf]

@mpermann I have tried exactly that and the result is the same.

For El Cap, once I started testing and ran into this issue I have mainly been imaging with just the DMG either bound or not bound to AD. Sometimes creating the management account at imaging time and sometimes utilizing the enrollment URL or QuickAdd after the fact. Basically each test is the same, enrollment or recon after enrollment, takes 60-90 minutes. Will work on getting a screenshot up here.

[mpermann]

@MTurnerFMRCO I've attached a screen shot of my test 10.11 workflow. I'm not having any problems with computers enrolling in a timely fashion with this workflow. I am adding a local admin account using the Accounts tab under the Show Custom option.

[mhasman]

@MTurnerFMRCO
Matt, does block-copy work for you in Casper Imaging? We have simillar JSS setup here - 9.82, 10.11.3 AutoDMG image - and imaging process is broken now. Casper Imaging installs 10.11.3 image instead of block-coping

[MTFIDjamf]

@mhasman I am seeing no issue with block copy at all. So far, everything that I have done seems to be working fine, with the exception of enrolling the device. No matter what method we try, it does not take less than 40 minutes to finish the enrollment process. After that, everything seems ok as well, policies, config profiles, etc.
Frustrating to say the least. Most likely will open a case if I cannot figure it out on my own or with help from here.

[MTFIDjamf]

@mpermann Here is a shot of this basic test setup. There is a block copy of my DMG, a drop of a root cert file. The a few test scripts that are also in our Yosemite image. This process pictured is not creating a management account as I have been testing after this quick image process with a URL enrollment or QuickAdd.

[mpermann]

@MTurnerFMRCO we are using an AFP rather than SMB distribution point but it shouldn't really matter. If you've tried to image a computer with only the base OS and nothing else (including any scripts or binding) and it doesn't work correctly then you really should contact your JAMF TAM. There must be something weird going on to prevent just a base OS not enrolling properly.

[MTFIDjamf · Accepted solution]

So....was able to finally figure it out with help from my JAMF TAM. Details below.

Saw the slowness when running sudo jamf recon -verbose. The log would hang at random locations but the step after the hung state was always the same: submitting info to JSS at address https://casper.mycompany.com:8443

Started mulling over why it seemed to stop at random places but the next step was always a submittal of info to the JSS. Seemed odd when a domain bind was no issue, but sending data to the JSS apparently was delayed.

After a bunch of rebuilding and testing I found the issue. It does not make much sense to me but I am able to enroll and run inventory in a normal, timely fashion.

Root cause seems to be the fact that the El Cap devices were coming out of the imaging process without a proxy config URL file specified. - This is odd to me because as far as I know the proxy setting we put into place is only needed for external site access and should not matter internally, looking further into this.

My image test was using the 10.11.3 AutoDMG file being block copied, then a root certificate file placement. After that I had a few scripts in place, some legacy, some new. - Detect and enable all external Ethernet (new). - Set AD search domains for all variations of our internal domain name (legacy). - Set some basic AD settings specific to internal setup (legacy). - Disable the iCloud setup/diag screens (new). - Install the earlier placed root cert (legacy). - Set the proxy file URL (legacy).

While all scripts seemed to be running as needed, I observed some odd behavior with the two scripts that were interfacing with the network adapter: search domains and proxy.

We image all laptop devices exclusively with USB to Ethernet adapters.

What I found was that in OSX Yosemite the external USB to Ethernet adapter is called 'USB Ethernet' in Network Settings.

However, this has apparently changed in OSX El Cap. In the new OS it is called 'Apple USB Ethernet Adapter' in Network Settings.

I am not sure if this was a change with 10.11.3 or not. I had imaged 10.11 device after the JSS was upgraded to v9.82 in mid-January and did not see these delays.

Our legacy script did not know of this new adapter name and was not applying the settings correctly to the adapter.

I revised the search domain script first, no change in enrollment or inventory.
I revised the proxy script, enrollment and inventory worked as expected, both running in under one minute.

I merely added the line for the new adapter name to the script and it seemed to work fine.

[isradame]

At MturnerFMRCo, could it possible to share the proxy script?, I am having kind of the same problem.

[MTFIDjamf]

@isradame Here you go. As I said above, this is a pretty old script that we still use. Not sure if all of this can be done in one line but this still works.

#!/bin/bash

# Filename: setProxy_R2.sh
# Purpose: Set the proxy URL on the Wi-Fi and Ethernet interfaces

networksetup -setautoproxyurl USB Ethernet http://wpad.yourURL.com/wpad.dat
networksetup -setautoproxyurl Apple USB Ethernet Adapter http://wpad.yourURL.com/wpad.dat
networksetup -setautoproxyurl Wi-Fi http://wpad.yourURL.com/wpad.dat
networksetup -setautoproxyurl Display Ethernet http://wpad.yourURL.com/wpad.dat
networksetup -setautoproxyurl Ethernet http://wpad.yourURL.com/wpad.dat
networksetup -setautoproxyurl Thunderbolt Ethernet http://wpad.yourURL.com/wpad.dat