I've seen the errors too. Currently at Casper Suite v9.32.

I haven't gotten my hands on a system, but have tracked the logs in JSS. The computers do check-in later. And since the computer will report just fine at the next 24 hour cycle, I've made the assumption it's because the network disconnects as some point between the start of recon and the end. Almost all have been laptops on wireless connections or systems at home while the user has a VPN connection to our network.

We had been having a number of related issues along the lines of.
Recon fails
Deployment fails
Software Update fails
In our case I managed to narrow it down to a bunch of machines that had updated to either 10.9.2 or 10.9.3 and there appears to be some issue with these versions of OSX clearing cache files or something.

I found emptying out /var/folders/ ( very carefully running something like rm -rf /var/folders/* ) and then restarting the machine seemed to resolve the issue (this fix was originally for the unauthorised caller error that was around a while back).
The restart appears to be an important part of the resolution and I believe that you may get unexpected behaviour if you don't do this.

Anyway after doing this pretty much every machine appeared to come right and once they successfully updated to 10.9.4 the issue hasn't returned.

If it's not consistently the same machines it might be something else at play though.

I'm still getting hundreds of policy (software push and inventory) failures a day.

I got a client in my hands Friday, and I realized the failures to reach the distribution points and the JSS happened at 1am, when the laptop lid was shut and presumably the NIC was powered off.

When I talked to JAMF, they said error reporting is much improved with 9, but this seems more like a bug than an improvement.

I was also concerned about how many notifications i received daily of inventory update failures. But then i ran a report to show the entire log of failures and completions of the policy and found that i was only hitting a 1.7% failure rate. For the most part, these were all MacBooks that were failing. So, the likelihood is that the user only opened the laptop long enough to trigger the inventory update policy and then closed it before it completed.

I'd suggest running a report and see what the failure rate looks like.

We've run into this quite a bit and it's usually caused by one of these things:
1- The user has a network state change, interrupting the connection. It then takes too long to get a new IP from the DHCP to reconnect to the JSS or just doesn't get back on the connection in time. This usually throws either "The host jss is not accessible," a "connection error" message, or a "timeout" message.
2- Similar to 1, a user closes their computer lid/puts their computer to sleep/etc. and terminates the connection. Usually for me the message ends up being "The host jss is not accessible" or "A server with the specified hostname could not be found" or "The network connection was lost."
3- Recon only allows for, like, 5 minutes to run before it times out. You may want to manually trigger recon from the machine in question and see if it takes longer than 5 minutes.

@denmoff What's a report of total log of failures look like? Or did you mean just look at the update inventory policy log? I don't doubt it's successful most of the time, which is great, I just wish I could stop machines from trying to run policies when lids are closed.

@emilykausalik - it's not just a few machines, it's all the machines in carts (thousands). I don't know why machines in carts are trying to inventory or run policies with kids shut at 1am, for example, causing the connection failures to happen.

What is the last time students are using those computers, and how frequently are they set to check in to inventory? It may be possible that if the machines only check in every 3 hours, and students aren't touching the machines after a certain time, then the machines all fall asleep around 1am… that may be why you get a ton of errors because it just lines up correctly. But I'm not sure what your environment is like or where the machines are.

Check in is every30, inventory 1x a day. Hard for me to generalize the last time students use the computers, varies greatly.

Didn't have this deluge of errors in 8.x series. Just wish it wouldn't try to run policies if JSS is unavailable (lid closed).

@CasperSally, when is your JSS backing up? Daily @ 1AM?

@bentoms - yes daily at 1pm.

I think I tracked down at least part/most of my problem. Our macbook airs are waking up every hour (even with lid closed in a cart) and for that second JSS tries to run it's policies and NIC isn't powered on long enough, and thus it fails... on a few thousand machines.

From system log

Oct  7 00:40:32 TD-TESTAIR-02 kernel[0]: Wake reason: RTC (Alarm)
Oct  7 00:40:32 TD-TESTAIR-02 kernel[0]: RTC: SleepService 2014/10/7 04:40:32, sleep 2014/10/7 03:40:36
Oct  7 00:40:32 TD-TESTAIR-02 kernel[0]: AirPort_Brcm43xx::powerChange: System Wake - Full Wake/ Dark Wake / Maintenance wake
Oct  7 00:40:32 TD-TESTAIR-02 kernel[0]: Previous Sleep Cause: 5
Oct  7 00:40:32 TD-TESTAIR-02 kernel[0]: AppleThunderboltNHI::prePCIWake - power up complete - took 0 us
Oct  7 00:40:32 TD-TESTAIR-02 kernel[0]: Thunderbolt Self-Reset Count = 0xedefbe00
Oct  7 00:40:32 TD-TESTAIR-02 kernel[0]: IOThunderboltSwitch<0xffffff8034b62a00>(0x0)::listenerCallback - Thunderbolt HPD packet for route = 0x0 port = 11 unplug = 0
Oct  7 00:40:32 TD-TESTAIR-02 kernel[0]: IOThunderboltSwitch<0xffffff8034b62a00>(0x0)::listenerCallback - Thunderbolt HPD packet for route = 0x0 port = 12 unplug = 0
Oct  7 00:40:32 TD-TESTAIR-02 kernel[0]: TBT W (2): 0x0100 [x]
Oct  7 00:40:32 TD-TESTAIR-02 kernel[0]: wlEvent: en0 en0 Link DOWN virtIf = 0
Oct  7 00:40:32 TD-TESTAIR-02 kernel[0]: AirPort: Link Down on en0. Reason 8 (Disassociated because station leaving).

trying to research now if anything with pmset could help stop this behavior without unintended consequence.

Thanks to a @rtrouton blog post about powernap and FV, I am sending out following and has taken care of this nagging problem with machines trying to do policy updates during their powernap

sudo pmset -a darkwakes 0 standby 0 standbydelay 0 womp 0

thanks to everyone above who tried to help, too!

@CasperSally @rtrouton - After adjusting the pmset, has it changed the behavior of running the daily, weekly, and monthly maintenance scripts?