Enrollment Issues: Error Code 2

[sepiemoini]

I noticed that my MacBookPro13,2 (10.13.2-17C88) wasn't successfully sending inventory reports to Jamf Pro (v10.0.0). I tried to remedy this by initially running a sudo jamf manage command and then escalated to full-on framework removal via sudo jamf removeFramework and re-enrolling. When doing so, I received Enroll return code: 2 in the /var/log/jamf.log file. I repeated these steps by trying to enroll into our development Jamf Pro instance running the v10.2.0 beta release but receive the same error. FWIW I've tried a QuickAdd package and also user-initiated enrollment through the web interface. Neither work and I've rebooted and deleted the asset/device from Jamf each time. DEP is a non-issue as they aren't any PreStage enrollments scoped to this particular device. Any thoughts?

[sepiemoini · Accepted solution]

Yeah, macOS High Sierra 10.13.2 Supplemental Update is the culprit here. Following the update, I'm back in business. Enrollment and recon are both functioning properly again. If you're on 10.13.2, be sure to apply the macOS High Sierra 10.13.2 Supplemental Update that came out earlier today.

[sepiemoini · Accepted solution]

There's more here from @scafide if folks are interested. Looks like this'll be patched in an upcoming Jamf Pro release!

[scafide · Accepted solution]

Hey folks!

See my thread (which'll be stickied soon) otherwise, here's the post:

Hey Jamf Nation!

As some of you have noticed, if you're Collecting Available Software Updates during a recon, your 10.13.2 Macs that have not yet ran the Supplemental update released today may not be submitting inventory.

To resolve the issue either:

Update your 10.13.2 Mac to the supplemental update.

or

Turn off collect available software updates from inventory collection preferences within your Jamf Pro Server (if you are collecting them) until your 10.13.2 Macs have updated to the supplemental updates.

[sepiemoini · Accepted solution]

Reposting my post from this thread which applies to the 10.13.3 update as well:

I've received the following from Jamf Support as a fix to this issue:

Step 1: Create database backup of the current data using the JSS Database Utility. We can navigate to our JSS Database Utility found in: Mac OSX Server: /Library/JSS/bin/JSSDatabaseUtil.jar Windows Server: C:Program FilesJSSinJSSDatabaseUtil.jar Linux: /usr/local/jss/bin/JSSDatabaseUtil.jar Step 2: We will then want to grab a backup of the current JAMFSoftwareServerDatabaseSchema.xml file by pasting it to the desktop or any other location. macOS - /Library/JSS/Tomcat/webapps/ROOT/WEB-INF/xml/ Windows - C:Program FilesJSSTomcatwebappsROOTWEB-INFxml Linux - /usr/local/jss/tomcat/webapps/ROOT/WEB-INF/xml/ Step 3: We will want to modify that file and replacing what is currently there with the new data. Specifically the <type>varchar</type> value in the <table_name>available_software_updates</table_name> section. Old <name>version</name> <type>varchar</type> <size>31</size> New Data <name>version</name> <type>varchar</type> <size>255</size> Step 4: Once we have saved the changes we will want to restart Tomcat, and that can be done by using the JSS Database Utility again.

Here's a screen capture of a computer reporting the new 10.13.3 update successfully:

[Dr_Jones]

Seeing the same exact issue as of this morning on my machine, this doesn't seem to be an issue for every user

[alexjdale]

Is today's new supplemental update already installed? It was breaking recon for our 10.13.2 systems.

[sepiemoini · Accepted solution]

Yeah, macOS High Sierra 10.13.2 Supplemental Update is the culprit here. Following the update, I'm back in business. Enrollment and recon are both functioning properly again. If you're on 10.13.2, be sure to apply the macOS High Sierra 10.13.2 Supplemental Update that came out earlier today.

[emily]

We've noticed an error in the jamf server logs around the same time as attempting recon:

2018-01-08 16:23:09,500 [ERROR] [Tomcat-1060] [SqlExceptionHelper ] - Data too long for column 'version' at row 1
Query is: insert into available_software_updates (computer_id, display_name, name, recommended, restart_required, version) values (?, ?, ?, ?, ?, ?)
Query is:
insert into available_software_updates (computer_id, display_name, name, recommended, restart_required, version) values (?, ?, ?, ?, ?, ?)

Looks like the way the update information is formatted is not being accepted by the database due to length or something. This appears to be causing the failure.

Recommend y'all open cases with your Jamf Support team if you've seen this as well.

[sepiemoini · Accepted solution]

There's more here from @scafide if folks are interested. Looks like this'll be patched in an upcoming Jamf Pro release!

[scafide · Accepted solution]

Hey folks!

See my thread (which'll be stickied soon) otherwise, here's the post:

Hey Jamf Nation!

As some of you have noticed, if you're Collecting Available Software Updates during a recon, your 10.13.2 Macs that have not yet ran the Supplemental update released today may not be submitting inventory.

To resolve the issue either:

Update your 10.13.2 Mac to the supplemental update.

or

Turn off collect available software updates from inventory collection preferences within your Jamf Pro Server (if you are collecting them) until your 10.13.2 Macs have updated to the supplemental updates.

[sepiemoini]

More symptoms that you may see in your Jamf Pro instance that are related to this issue include the following return when a recon is performed at the command line.

computerName:~ administrator$ sudo jamf recon
Retrieving inventory preferences from https://myjamfproserver.com:8443/...
Finding extension attributes...
Locating applications...
Searching path: /Applications
Locating accounts...
Locating package receipts...
Locating hard drive information...
Locating software updates...
Locating printers...
Locating hardware information (Mac OS X 10.13.2)...
Gathering application usage information...
Submitting data to https://myjamfproserver.com:8443/...

There was an error.

     Unknown Error - An unknown error has occurred.

[brunerd]

FWIW It's not broken in 9.101 :]

Looking at the output of the CLI softwareupdate I appears the lack of version in the parentheses is the culprit
Perhaps a quick report to Apple could fix this up too: https://bugreport.apple.com/web/

Expected result: Version number in parentheses Actual result: Nothing Burger ( )

$ sudo softwareupdate -l
Software Update Tool

Finding available software
Software Update found the following new or updated software:
   * macOS High Sierra 10.13.2 Supplemental Update- 
    macOS High Sierra 10.13.2 Supplemental Update ( ), 138293K [recommended] [restart]

Here's what a 10.13.2 machine without patch inventory looks like in 9.101 as you can see the version column is all messed up...

As a test I went in Recovery mode and replaced /usr/sbin/softwareupdate with a script that output the same data but with "(1.0)" instead of "( )" ... but it seems the jamf binary was not having any of that and inventory now says "No Updates Available" - pfeh! Anyway I think that's it...

File your bug reports with Apple: https://bugreport.apple.com/web/

[grahamrpugh]

Not solved, I'm afraid.

After the 10.13.3 update became available, I got the Unknown Error - An unknown error has occurred. error when trying to sudo jamf recon a machine. We have collect software updates enabled. After updating the Mac to 10.13.3, the error goes away.

It looks, therefore, like the problem was not specific to the Supplemental Update. The Mac already had that update, and the error only started after 10.13.3 became available. So it may be that whenever any update, or any point release update, is available, the error returns.

FYI this is on JSS 9.101.4.

[grahamrpugh]

The 10.13.3 update also has a blank version number in parentheses:

Software Update found the following new or updated software:
   * macOS High Sierra 10.13.3 Update- 
    macOS High Sierra 10.13.3 Update ( ), 1925876K [recommended] [restart]
   * iTunesXPatch-12.7.3
    iTunes (12.7.3), 180272K [recommended]

I guess that is why the problem with recon is back.

[tinsun]

Thanks, good find. Just noticed the problem with recon on 10.13.2 machines, quite bad, actually.

[sepiemoini · Accepted solution]

Reposting my post from this thread which applies to the 10.13.3 update as well:

I've received the following from Jamf Support as a fix to this issue:

Step 1: Create database backup of the current data using the JSS Database Utility. We can navigate to our JSS Database Utility found in: Mac OSX Server: /Library/JSS/bin/JSSDatabaseUtil.jar Windows Server: C:Program FilesJSSinJSSDatabaseUtil.jar Linux: /usr/local/jss/bin/JSSDatabaseUtil.jar Step 2: We will then want to grab a backup of the current JAMFSoftwareServerDatabaseSchema.xml file by pasting it to the desktop or any other location. macOS - /Library/JSS/Tomcat/webapps/ROOT/WEB-INF/xml/ Windows - C:Program FilesJSSTomcatwebappsROOTWEB-INFxml Linux - /usr/local/jss/tomcat/webapps/ROOT/WEB-INF/xml/ Step 3: We will want to modify that file and replacing what is currently there with the new data. Specifically the <type>varchar</type> value in the <table_name>available_software_updates</table_name> section. Old <name>version</name> <type>varchar</type> <size>31</size> New Data <name>version</name> <type>varchar</type> <size>255</size> Step 4: Once we have saved the changes we will want to restart Tomcat, and that can be done by using the JSS Database Utility again.

Here's a screen capture of a computer reporting the new 10.13.3 update successfully:

[scafide · Accepted solution]

Hey Folks,

We've got this one fixed in Jamf Pro 10.2 as well, which is currently in beta.

[grahamrpugh]

Will that fix be back-ported to 9.101? It is breaking any macOS software installation workflow that uses software inventory collection, and that could affect people who aren't ready for the upgrade to 10.2 just yet.

We hope to be able to upgrade to 10.2 but will still need to do some testing, since 10.1 was broken for us due to API problems. And the Self Service is currently broken in the 10.2 beta 2, so we will need to be sure that this is solved in the production version before we can consider the upgrade.

[scafide]

Hey @grahamrpugh,

Please reach out to Jamf Support if you'd like to go with other available workarounds, which will be the workflow @sepiemoini posted above - and remember your Beta Program NDA. =)

Thank you!

[grahamrpugh]

I didn't say how it was broken :-)

But, noted. And thanks, I can probably deal with the workaround if necessary.

[grahamrpugh]

I can report that the workaround worked. Now I just need to repeat the XML edit on all our instances :)

[grahamrpugh]

If anyone has a bunch of tomcat instances to patch, I wrote this script which could help. I'm sure there's a better way, but at least it worked for me.
The paths here assume RedHat Enterprise Linux 7.
Substitute your instance names in the list_of_OUs variable, and change the path if your tomcat webapps are elsewhere:

#!/usr/bin/python

# Fix for file /usr/share/tomcat/webapps/[OU]/WEB-INF/xml/JAMFSoftwareServerDatabaseSchema.xml

import sys
from xml.etree import ElementTree as ET

list_of_OUs = [ "instance1", "instance2", "instance3", "instance4", "instance-test" ]

for OU in list_of_OUs:
    sourcefile = "/usr/share/tomcat/webapps/%s/WEB-INF/xml/JAMFSoftwareServerDatabaseSchema.xml" % OU

    print "File to change: %s" % sourcefile

    table_name = "available_software_updates"

    column_to_replace = "version"

    element_to_replace = "size"

    replacement_value = "255"

    tree = ET.parse(sourcefile)
    root = tree.getroot()

    for table in root.findall('.//table'):
        for table_name_value in table.findall('.//table_name'):
            # print table_name_value.text
            if table_name_value.text == table_name:
                for column in table.findall('.//column'):
                    column_name = column.find('.//name')
                    if column_name.text == column_to_replace:
                        element = column.find('.//%s' % element_to_replace)
                        orig_element_value = element.text
                        if element.text != replacement_value:
                            element.text = replacement_value
                            print "Table '%s' %s value changed: %s => %s" % (table_name, element_to_replace, orig_element_value, element.text)
                            new_contents = ET.tostring(tree.getroot())
                            with open(sourcefile, 'w') as file:
                                file.write(new_contents)
                        else:
                            print "Value of '%s' matches replacement value. Nothing to do." % element_to_replace