@amanda.wulff I am seeing some of the same issues. After talking with my TAM, we upgraded the RAM on the DP, thinking it might just not be able to handle the requests. (I'm also having issues with packages failing par-way through sometimes)

I had 5 failures overnight and during that same span, this is the Jamf Server Log:

2016-03-25 23:53:59,351 [WARN ] [Tomcat-184 ] [CRUDHelper               ] - User does not have UPDATE privileges for Package

2016-03-26 01:51:48,641 [INFO ] [oolThread-0] [icKeyInfrastructureHelper] - Refreshing pki information

2016-03-26 07:51:48,641 [INFO ] [oolThread-9] [icKeyInfrastructureHelper] - Refreshing pki information

@mscottblake

Issues with a distribution point (and its amount of RAM) likely have nothing to do with Recon connection failures, so I'd suggest you keep working with your TAM to get them resolved; the error you posted is pretty clear in pointing out the problem you're having, however.

"User does not have UPDATE privileges for Packages" is pretty self-explanatory and points toward there being a permissions problem in your JSS.

Even if the user you're logged in as says it's an Administrator, we've seen permissions go strange sometimes for no good reason.
In those cases, switching the permissions set to Custom, saving, then setting it back to Administrator and saving tends to get it back to where it needs to be.

If the permissions are meant to be custom, just go and check and make sure that user has privileges to update packages.

If the user in question is not supposed to have permission to update packages, then the error is not an error at all and is expected behavior.

In this case, I don't think the problem you're seeing is related to what we're looking for in this thread; the error I was asking about in my post from 3/25 is looking for a very specific error that points to a very specific problem that can cause Recon failures.
If you're not seeing that exact "Exception javax.xml.bind.UnmarshalException" error in the JAMFSoftwareServer.log when a recon fails, then that particular issue isn't affecting you and it's likely something else that I'd recommend continuing working with your TAM on to figure out what's going on.

Amanda Wulff
JAMF Software Support

@amanda.wulff Thats actually the point I was trying to illustrate. I saw a handful of the same policy errors come through overnight, but there was nothing in the JSS Server logs to indicate any problems.

@mscottblake

There are numerous things that can cause Recon failures; the one I was asking about specifically, that contains the "Exception javax.xml.bind.UnmarshalException" is a very specific one that is related to an open issue we're aware of, which is why I'd been asking specifically about that.

If that isn't what you're seeing in your JAMFSoftwareServer.log, then there is something else going on and your TAM will be able to dig into it a bit with you to figure out what's going on. Most times, if you cross-reference the time of failure in the jamf.log with the system.log you can find out what the client machine thinks happened.

The permissions error you'd posted in your comment, however likely doesn't have anything to do with Recon failures, as nothing in a Recon should be requesting privileges to update packages in the JSS. There may be a slim possibility that they're related (for example, if you have an EA that needs to update package information in the JSS), but that would require your TAM digging into it a bit deeper with you to figure it out.

Amanda Wulff
JAMF Software Support

@amanda.wulff Like I said, that's what I was illustrating. I had a handful of recon errors come into my email (I've since deleted them) that matched the description of this thread. To aid in the discovery process, I wanted to show that in my case, there were no errors on the JSS that correspond to the Recon problems I was seeing.

I am not trying to say the errors I copied into this thread are part of the problem, I was simply trying to show that there was nothing coming through at the time of the recon errors.

@amanda.wulff I get from 2-10 recon failures a day. Looking at the past 48 hours, 20 recon errors, I do not see the error you noted in the JSS server log anywhere around the recon error times.

I do however see the error at other times, in this form:

2016-03-22 16:48:51,764 [error] [Tomcat-6974] [JAMFHttpServlet ] - The JSS received an error (javax.xml.bind.UnmarshalException - with linked exception:
[org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1074; cvc-complex-type.2.4.a: Invalid content was found starting with element 'ns2:platform'. One of '{"http://www.jamfsoftware.com/JAMFMessage":reportedIP}' is expected.]) for a request made by device: com.jamfsoftware.communication.beans.DeviceInformation@27e4ae39

2016-03-23 15:54:49,418 [error] [Tomcat-7590] [JAXBMessageMarshaller ] - Exception javax.xml.bind.UnmarshalException - with linked exception:
[org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1624; cvc-complex-type.2.4.a: Invalid content was found starting with element 'ns2:make'. One of '{"http://www.jamfsoftware.com/JAMFMessage":modelIdentifier}' is expected.]

2016-03-23 15:54:49,418 [error] [Tomcat-7590] [JAMFHttpServlet ] - The JSS received an error (javax.xml.bind.UnmarshalException - with linked exception:
[org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1624; cvc-complex-type.2.4.a: Invalid content was found starting with element 'ns2:make'. One of '{"http://www.jamfsoftware.com/JAMFMessage":modelIdentifier}' is expected.]) for a request made by device: com.jamfsoftware.communication.beans.DeviceInformation@540941dd

And, for what it's worth, the recon errors I see as reported in the policy logs are always one of the following:
Connection failure: "The request timed out.”
Connection failure: "The network connection was lost.”
Connection failure: "The host casper.company.com is not accessible."
Connection failure: "A server with the specified hostname could not be found."
Connection failure: "The Internet connection appears to be offline."
Connection failure: "The Internet connection appears to be offline."
Unknown Error - An unknown error has occurred.

I just went live in the last few weeks. Currently have > 200 Macs with another ~100 still to be enrolled. Overall a successful project.

The most common error I get states:

Error Occurred While Running Policy "Policy - Base - Update JSS Inventory" on Computer "foo"

I see ~10-20 of these failures per day. Seems like a high ratio to me for only have ~200 enrolled thus far.

The errors are of the following variety:

-Connection failure: "The request timed out.”
-Connection failure: "The network connection was lost.”
-Connection failure: "The host jss.foo.org is not accessible."

About 1/2 the Macs in question are laptops (on the WLAN and out on the Internet too), so I assume these errors are due to laptops changing networks, sleeping, flakey Wi-fi, etc.

The other 1/2 are Mac desktops on the LAN (a couple are in IT dept). I assume the errors are related to power/sleep etc.

When I see these errors, I get a tad paranoid, and will SSH into the Mac(s) and poke around if I am able to do so. The Macs generally appear to be able to resolve the JSS server(s) and usually can make manual connections via the recon command, etc. So I think my infrastructure is OK.

I'm on JAMF 9.81. I have (2) JSSs (LAN and DMZ) and I run split-DNS.

Question:

When I get these errors, how are they being acknowledged/generated? If the recon/inventory connection failed in the first place, then how does the JSS know it failed? How is it able to inform me of the failure? Chicken-and-egg, right?

FWIW I saw the exact same errors in about the same numbers for awhile, since updating the JSS from v8 to v9, I believe. Recon as part of a policy failed consistently (though not every time) on the same group of Macs, while the "meat" of the policy went through fine. Manual recon was never an issue. Errors included:
Connection failure: "The request timed out."
Connection failure: "The network connection was lost."
Connection failure: "The host jss.whatever is not accessible."

I was never able to resolve the errors with my TAM/support or elsewhere.

Since upgrading the JSS from 9.73 to 9.82 recently, all those recon errors have gone away.

@jonscott

Since upgrading the JSS from 9.73 to 9.82 recently, all those recon errors have gone away

That's mildly interesting as I'm on 9.81.

@mscottblake @tcandela what version JSS you on?

@dpertschi 9.82

I too still see them, but I am also still on 9.81.

so has everyone stopped seeing Connection failure: "The host jss.whatever is not accessible." since upgrading past 9.81 ??

I still see it on 9.9.

An error occurred while running the policy "Reboot Notification" on the computer "BLAHBLAH".



Actions from policy log:

    Executing Policy Reboot Notification

    Mounting Casper to /Volumes/CasperShare...

    Could not mount distribution point "Casper"

    Running Recon...

    Error running recon: Connection failure: "The host jss.blah.edu is not accessible."

    The results of this policy were not logged at the time of execution.

    The actual execution time was Mon Apr 18 07:45:21 PDT 2016.

No, I still see it on occasion. However, it's only occasionally and I have a high suspicion that it's due to either machines being closed (slept) at the end of a policy, or some other minor network issue on our end.

P.S> We're still 9.82 for the moment.

I'm relatively new to JAMF. "Jumpstarted" in November 2015, and went live in March 2016. Have ~250 managed Macs. I have been running 9.81 exclusively, so I have no other version of JAMF to compare to.

I get alerts for various timeout and/or generic recon errors a few times a day from various clients (Speak of the devil - just had an error reported as I was typing this post). The clients appear to be utterly random. Various VLANs and hardware models (desktops and laptops).

When I have time to do so, I QA them by SSHing into the hosts and executing a manual recon via the command line. This works every time. Certainly odd, but I'm not losing sleep over it.

Ill be upgrading to 9.9.1 this Spring.

any fix on this issue? i'm also getting these constant daily recon errors...very annoying! i'm running latest JSS 9.101.0-t1504998263

Just a note, I was having issues similar to these on a couple machines, and it turned out that the DNS settings had been changed from our DHCP delivered addresses to Google DNS entries. That killed the ability of the jamf binary from reaching back to the JSS.