Error running recon: Connection Failure

[johnnasset]

With every policy that installs a package, we always have a handful of machines that will successfully install the package but fail to run a Recon post-install. These are not the same machines each time. Here is a sample log:

Executing Policy Adobe Flash 11.9.900.170...
Downloading Adobe Flash Player_11.9.900.170.pkg...
This package is a PKG or an MPKG, and the index.bom file is not found. Attempting to open the package as a flat package...
Downloading http://xxx.xxx.org/CasperShare/Packages/Adobe%20Flash%20Player_11.9.900.170.pkg...
Installing Adobe Flash Player_11.9.900.170.pkg...
Successfully installed Adobe Flash Player_11.9.900.170.pkg.
Running Recon...
Retrieving inventory preferences from https://xxx.xxx.org:8443/...
Locating accounts...
Searching path: /Applications
Locating package receipts...
Gathering application usage information...
Locating printers...
Locating software updates...
Locating plugins...
Error running recon: Connection failure: "The host xxx.xxx.org is not accessible."

If it was a network issue I would assume that the package would fail to install as well. Anybody else seeing this? We are on version 9.22.

[mscottblake]

@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.

[dpertschi]

@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.

[dstranathan]

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?

[jonscott]

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.

[dpertschi]

@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?

[mscottblake]

@dpertschi 9.82

[yellow]

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

[tcandela]

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

[yellow]

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.

[Chris_Hafner]

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.

[dstranathan]

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.

[tranatisoc]

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

[jwolf]

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.