Skip to main content

Hi all,



Am seeing the below on my jamf logs. How do i find the device with the UDID?



Thanks



com.jamfsoftware.jss.exceptions.operations.MDMActionCreationException: com.jamfsoftware.jss.mdm.actions.exceptions.DeviceNotFoundException: Unable to find device with UDID: 9B937110-2A49-5BA5-B2EA-E35381D6BB2A
at com.jamfsoftware.jss.mdm.actions.MDMActionFactory.createActionForRequest(MDMActionFactory.java:326)
at com.jamfsoftware.jss.mdm.enrollment.MDMController.parseRequestAction(MDMController.java:313)
at com.jamfsoftware.jss.mdm.enrollment.MDMController.getMdmRequestAction(MDMController.java:231)
at com.jamfsoftware.jss.mdm.enrollment.MDMController.process(MDMController.java:123)
at com.jamfsoftware.jss.mdm.enrollment.MDMController.doPut(MDMController.java:105)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:664)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.jamfsoftware.jss.frontend.JSSAccessFilter.doFilter(JSSAccessFilter.java:66)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.jamfsoftware.jss.frontend.JSSLoadingFilter.doFilter(JSSLoadingFilter.java:230)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:496)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:803)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:790)
at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1703)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at org.apache.tomcat.util.net.AbstractEndpoint.processSocket(AbstractEndpoint.java:1050)
at org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper$4.completed(Nio2Endpoint.java:630)
at org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper$4.completed(Nio2Endpoint.java:608)
at org.apache.tomcat.util.net.SecureNio2Channel$1.completed(SecureNio2Channel.java:917)
at org.apache.tomcat.util.net.SecureNio2Channel$1.completed(SecureNio2Channel.java:846)
at sun.nio.ch.Invoker.invokeUnchecked(Unknown Source)
at sun.nio.ch.Invoker$2.run(Unknown Source)
at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: com.jamfsoftware.jss.mdm.actions.exceptions.DeviceNotFoundException: Unable to find device with UDID: 9B937110-2A49-5BA5-B2EA-E35381D6BB2A
at com.jamfsoftware.jss.mdm.actions.MDMActionFactory.getAppleMDMCapable(MDMActionFactory.java:721)
at com.jamfsoftware.jss.mdm.actions.MDMActionFactory.getDeviceFromPlist(MDMActionFactory.java:692)
at com.jamfsoftware.jss.mdm.actions.MDMActionFactory.createActionForRequest(MDMActionFactory.java:218)
... 40 more
2018-08-13 08:48:29,149 [error] [Thread-3383] [JAXBPlistParser ] - Error unmarshalling
2018-08-13 08:48:29,149 [error] [Thread-3383] [MDMController ] - Unable to parse device from request
com.jamfsoftware.jss.mdm.actions.exceptions.PlistParsingException: Plist was null when trying to get device UDID

Hey,



Did you ever find out what was causing this error as I am having the same issue



Thank you,



G

@Geelcey



SO, I went through the same issues with Jamf yesterday.



It seems, that even though the device has been deleted from the JSS, it still may exist in the Database as the MDM profile was still there.. confused? Me Too ;-)
Therefor, it's still trying to connect to MDM and causing these errors..



So, what I did was run the following SQL command on the Database itself...



mysl -u root -p



use 'database name';



Delete from computers where udid = "list of affected udid's from log files";  (separate the udid's with a comma)


That'll clear them from the DB.



REMEMBER TO BACKUP the DataBase before running this.



just in case...

We also see plenty of these messages, but we definitely don't have any leftover entries in the DB that cause this.



My understanding is that these are devices that have the jamf framework and regularly contact the MDM server, but they are not known to the server.



Potential reasons are




  • the device has been setup using the Migration Assistant, thus 'inheriting' the framework from the previous device. But of course the MDM knows nothing about the new device, and thus spits out the error.


  • the Mac was setup from TimeMachine backups of another device => unknown device


  • the Mac has had its motherboard replaced, changing Serial Number and/or UDID => unknown device


  • the Mac is running a version of macOS that is not compatible with the current version of the Self-Service app. After not receiving reports from the device for a while we delete it from the MDM => unknown device


  • the Mac has the do_not_upgrade_jamf flag set (has become rare), MDM refuses connection. After not receiving reports from the device for a while we delete it from the MDM => unknown device




There might be other reasons for this, but the ones I listed appear to be the most likely ones.



What I dislike most about this is the full traceback that the MDM creates for some of these cases - it some of the clients try to connect the server quite frequently, thus filling up the log files with the useless garbage from the tracebacks...

We also see plenty of these messages, but we definitely don't have any leftover entries in the DB that cause this.



My understanding is that these are devices that have the jamf framework and regularly contact the MDM server, but they are not known to the server.



Potential reasons are




  • the device has been setup using the Migration Assistant, thus 'inheriting' the framework from the previous device. But of course the MDM knows nothing about the new device, and thus spits out the error.


  • the Mac was setup from TimeMachine backups of another device => unknown device


  • the Mac has had its motherboard replaced, changing Serial Number and/or UDID => unknown device


  • the Mac is running a version of macOS that is not compatible with the current version of the Self-Service app. After not receiving reports from the device for a while we delete it from the MDM => unknown device


  • the Mac has the do_not_upgrade_jamf flag set (has become rare), MDM refuses connection. After not receiving reports from the device for a while we delete it from the MDM => unknown device




There might be other reasons for this, but the ones I listed appear to be the most likely ones.



What I dislike most about this is the full traceback that the MDM creates for some of these cases - it some of the clients try to connect the server quite frequently, thus filling up the log files with the useless garbage from the tracebacks...



Just stumbled upon this post as we had functionality in our jamf cloud instance not working correctly, and when contacting support they complained our logs/database was too large. I did some digging in the logs and came upon this exception filling up over a hundred lines of logs per exception, which totaled nearly 5000 exceptions within the past 3 months. I've tried to delete the 25 unique UDIDs that were in our log files through the Jamf Rest API, but of course the device doesn't exist so I have no way to actually remove it. I'm not sure where Jamf is pulling these identifiers from, but it's definitely annoying to be having this issue, and for the advice why our instance isn't working correctly corresponds to something that I seemingly have no control over.

The amount of garbage due to stack traces in the logs is indeed staggering. I have a hard time understanding why the developers can not handle these errors properly but rather have the software dump the stack traces and make the logs unreadable.

Reply


Terms & ConditionsCookie settings