Thanks @Chris_Hafner - will use that to see what we have in there now as a guideline.
We currently manage ~765 Macs globally.

It looks like all the polices are working? its just when it tries to recon that I'm getting the failures across the board.. Laptops Desktops on wireless with network cable bound not bound doesn't matter and its not all the time only a few.

Im going thru all my polices and converting the builtin in update Inventory to - Files and Processes (Execute Command) jamf recon. I will see if that stops the false reporting. By the time I get in I have hundreds of "Failed" Policy's none of which actually failed..

@boettchs as a followup we manage a pretty similar number of units. It's anywhere between 650 and 750 OS X devices. When I talk to other engineers about this particular setup they tend to look at me funny. I do keep a very large number of potential connections and threads. It gives me the overhead to have a runaway process or memory leak so that I can catch it before the service bogs down.

Just upgraded to 9.65 and still having the same issue. Also added a script instead for the "update inventory" and I'm still getting these errors all day. Once I inspect the error the package installed and or the policy worked its only when its running the recon part? any help?

I've been playing with threads, pool sizes, dB connections, changed from every15 to every30... Nothing really seems to make a difference. Still getting:

Error running recon: Connection failure: "The request timed out."
Error running recon: Connection failure: "The host hostname.company.com is not accessible."
Error running recon: Connection failure: "Could not connect to the server."

Yet during this time, there are multiple Macs imaging. The JSS is totally accessible. It's weird. The computer objects in Casper are indeed showing as connected at today's date, but they aren't getting an inventory update (which is obviously critical). Can't get accurate info for Smart Groups if I can't get recons to run.

So, curiously, I might have found the issue, at least on my set up.

I've been through a jillion config on the backend with Tomcat & MySQL, changes to policies, changes to default check in rules, and nothing seemed to help. In going back to the email errors I was getting, it finally dawned on me that 95% of the errors were being generated from an "update inventory" policy that we had running, once a day, "Login, Check-in, Network State Change", All computers. This was a policy that had existed when I started working with this iteration of Casper when it was v8.. I thought nothing of it and it had been migrated into v9.. Since I've disabled it to test, all my errors of this ilk have gone away.

@yellow, if you've disabled that once a day update inventory policy, how are you doing your inventory updates on the computers? Did you create a brand new daily update inventory policy scoped to all computers or are you doing something different?

Most of our policies already include a recon, for the moment I'm playing my odds to see how stale my info gets.

Well... couldn't you try creating a recurring policy that runs "jamf recon" at the same frequency as your former inventory policy? Actually, I'm going to swap the checkbox for the command on my recurring inventory just to test the difference.

Just did.. mainly because the errors have stopped coming so fast and furious.
I deleted the original and created a new one that I limited it to once a day and recurring check in only.
We'll see how that goes.

... eh, scratch that. Looks like I already tried that some time ago and have been running that way for about the past year. I still see these errors FYI. Not a lot, but a few and usually off site.

Anytime I get a connection failure but the JSS is available I just remove the framework and re-enroll and I don't seem to have any more issues with that machine. Running JSS 9.65

Hm, whatever happened here? We just migrated to our brand new Casper 9.72 setup using RHEL servers and JDS distribution.
There are a lot of errors coming in on the recon part, could be that recurring once a day or after running a policy. It's a tad bit annoying that the recon part fails as that makes the computer not leave the smart group and the policy excecuting again. So far nothing bad has happened more than some users asking why the same software might want to update more than once almost at the same time (like java, flash and so where we have user notification).
I have upped our MySQL and Tomcat settings to "a lot" (according to posts found here on JAMFNation) so there should be no memory problems, and the virtual server is on a big pipe so there should be no network problems either.
Did this go away magically for people or are you all just "coping"?

After updates (to JSS) I will go back and see if update inventory works. It still does not. So I am still using a script to do recon. That works. But update inventory is spotty at best so I cannot rely on it.

We are getting similar random failures with the Update Inventory policy.

Although three of the computers sometimes failing are on the same network segment, have to check with the network people to see if anything in the switch logs that show why the dropped connection.

The error we are getting are below:

"Actions from policy log:
Executing Policy Update Inventory...
Running Recon...
Error running recon: Connection failure: "The host jss-server is not accessible."
The results of this policy were not logged at the time of execution.
The actual execution time was Tue Jun 16 16:18:29 EST 2015."

and

"Actions from policy log:
Executing Policy Update Inventory...
Running Recon...
Retrieving inventory preferences from https://jss-server:8443/...
Locating package receipts...
Locating accounts...
Searching path: /Applications
Locating printers...
Gathering application usage information...
Error running recon: Connection failure: "The request timed out.""

Either error will show up on only five out of 150 computers enrolled, but at random times. three of these computers are desktops on wired connections, the other two are laptops that can be either wired or wireless connections. If the update failed all the time i could track iit down, but it seems so random, nothing really shows in the JSS logs server or client.

Considering the quality of the campus network here, I cannot believe that this would actually be a network problem. We have around 800 computers at the moment and I'm seeing around 20-30 reports of failed recons every day.

Agreed here.

I've bumped up the maxThreads in our tomcat instance to 1000 on both the connector/executors. I have also done some work to ensure MySQL's setup is optimal (turn off binary logging, ensure packet sizes are appropriate, etc). One could assume the issue is a network connectivity issue, but then the recon is sending an inventory report to the very same box that is accepting the policy log? ;-)

Our JSS is due for an upgrade to 9.73 this week, including updating Java, etc. I'll check back with you all if this still happens. We're on RHEL6.5, on a VM configured with two cores and 16GB of RAM.

We are getting random computers giving similar errors on "update inventory, usually one of two errors;

"Error running recon: Unknown Error - An unknown error has occurred."
or
"Error running recon: Connection failure: "The request timed out."', any suggestions JSS 9.73

Running "Update Inventory" via Casper Remote on these computers always works.

This is still happening on 9.81, even on computer connected to Ethernet. So far I haven't really been able to catch it as it happens.

Back on my radar here, this issue is now causing me to develop a tic.

During patch management cycles every month, software-installs-but-recon-fails subsequently throws my compliance reporting off by a few percent (and YES it matters).

My inventory collection is pretty sparse, deleted unnecessary EA's but I'm loath to delete the 35 that are left and add them back one at a time. Where is the damn EA disable button anyway!

I can't find a way in the JSS to capture the recon failure and re-run it. Thinking now about a launch daemon that runs periodically looking for the failure in the jamf.log and re-run if found.

Thoughts, comments?

I am so fed up with this issue, was just about to create a new discussion until I seen this discussion already created.

I get this Error running recon: Connection Failure all the time, sporadically, no matter if the computer is on the local network or if the computer is running recon from off the local network (at home).

the package runs successfully but the ensuing 'recon' results in Error running recon: Connection Failure

makes no sense

@dpertschi , @tcandela

When you get this error on the client, if you look at your JAMFSoftwareServer.log, do you happen to see any errors from around the same time as the failure on the client that start with, "Exception javax.xml.bind.UnmarshalException" at all?

Thanks!
Amanda Wulff
JAMF Software Support

@amanda.wulff where exactly is the JAMFSoftwareServer.log ? on the JSS itself ?

on the clients i usually look at /var/log/jamf.log

where do i go to look at JAMFSoftwareServer.log ?

thanks

Syracuse Orange Elite 8 !!

@tcandela logs are on the JSS server

/usr/local/jss/logs