Skip to main content

JSS 9.73 and OS X 10.10.3 or higher.



This is rather strange behavior and I'm curious if others are seeing this and if so what they are doing to work around it.



Basically, I have a brand new Mac that has never been enrolled to the JSS. I netboot it and use Casper Imaging. I use a config that is 'thin' and I am not wiping the drive but rather just putting a few packages that run on first boot. On my first boot package, I have the following in the postinstall script.



Note: the computers in question are 2015 MacBook Airs using Thundetbolt to Ethernet adapters that I'm noticing this on.



jamf="/usr/sbin/jamf"



# Detects the ethernet adapter

/usr/sbin/networksetup -detectnewhardware

sleep 30



#########

#Create a check so that a connection to the JSS is established before proceeding.

#########

"$jamf" checkJSSConnection



#If the exit code of the JSS connection check is 1 then we'll try again for 5 minutes (5secs*60=300)

if [ "$?" != "0" ]; then

    "$jamf" checkJSSConnection -retry 60

fi



if [ "$?" != "0" ]; then

    /bin/echo "JSS cannot be contacted."

    #Check JSS Connection again

    "$jamf" checkJSSConnection



    if [ "$?" != "0" ]; then

        #Forcing a reboot so that computer can re-attempt to do Casper Enrollment successfully.

        /sbin/reboot

    fi

fi


Without the JSS check the computer NEVER enrolls. However with the JSS check built-in the computer does enroll (I'm guessing because it tries to check the connection for 5 minutes), but it does not show up as managed. If it doesn't show up as managed in the JSS the computer cannot run policies which obviously becomes a problem.



The weird thing is that other computers that have been enrolled into the JSS do not exhibit this problem if they are being re-imaged. And in fact, if I take the same machine and netboot and do the same image config a second time it works fine.



Later on in the script, I have it doing the following with the idea that this would cause the computer to be managed, but no cigar:



#Enable management of computer by JSS

"$jamf" manage


Unless I'm missing something, shouldn't this cause the computer to be managed within the JSS?



Let me know if you have any questions.

Just in case, I'm thinking out loud here, but would I need to use the API to set the management account/password for the computer if the command "jamf manage" does not actually work to set this on the computer in the JSS.

Hey @bpavlov . We actually just deployed 250 Macbook Air's to our Teachers and used the exact same method using a Computer Configuration, doing Netboot to "thin" image with installing a few packages, and getting the machine enrolled. 10.10.3 was out of the box from Apple for our 2015 Macbook Air's, and we are running JSS 9.72.



What I found was this thread to enable the external network adapters. As I'm sure you are aware, the bug is still there for computers not getting enrolled after Casper Imaging using a Thunderbolt Adapter. After finding this thread, I used this script and set it to "At Reboot." for the Configuration, and it worked --Which saved a lot of headache!

@pchang I thought it might be related to that but the fact that it finally does communicate with the JSS tells me that it just takes a long time to connect (more than 30 seconds, but less than 5 minutes). And I know that I can do a recon and assign a computer name and user name as well during that first boot process so it's definitely communicating. It's just not getting set to 'managed' which is the last piece I'm trying to take care of. I can't do much testing right now until next week, but I'm curious what the best way to set a computer to managed would be. I thought "jamf manage" would do it, but have you tried using the API to do this?

So messing with the API. I did a GET on an existing computer got the following:



<?xml version="1.0" encoding="UTF-8"?>

<computer><general><remote_management>

<managed>true</managed>

<management_username>account_name_goes_here</management_username>

<management_password_md5 since="9.23">long_string_here</management_password_md5>

<management_password_sha256 since="9.23">long_string_here</management_password_sha256>

</remote_management></general></computer>


Unfortunately, I could not upload that same XML file back to the JSS via the API. The password tags weren't valid. I'm guessing you can't upload the same hash back to the JSS because it can't decode it. On a crapshoot, I tried XML tag <management_password>password</management_password> and it worked.



Uploading the following XML to the computer in the JSS the following does the trick:



<?xml version="1.0" encoding="UTF-8"?>

<computer><general><remote_management>

<managed>true</managed>

<management_username>account_name_goes_here</management_username>

<management_password>password_goes_here</management_password>

</remote_management></general></computer>


So I'm making some progress, but feel uncomfortable scripting the management account password in clear text. I'll seek out some assistance from JAMF because I think it would be great to be able to simply upload the same hash via the XML file using the API. And it also wasn't immediately clear that the XML tag <management_password>password</management_password> would even work and it would have been great if that were a bit more obvious rather than through wild guessing. And I'll probably make a feature request or two in the near future if these aren't things that are currently implementable.



If anyone has any other ideas to enable the management of a computer in the JSS, I'm open.

Terms & ConditionsCookie settings