We had this issue recently as well. In our case it turned out that some of the hidden hash value files on the CasperShare drive were corrupted and holding up the JDS from registering or even reporting inventory back to the JSS.

On your JDS browse to the CasperShare and look for any of the hidden hash files that have the word filepart in the filename.

Example:

.JetBrainsIntelliJ_13.1.3_B01.dmg.filepart.D4FFE3A12CCD31F485A0D8E70F11B8A2

If you have any of these files with .filepart. in the name, delete the incomplete JDS from the JSS and then delete the filepart files and re-register the JDS to see if it shows up properly in the JSS.

Good Luck!

Hey, thanks for the response.

When I browse there, since the JDS has never been able to sync back to the root, there are no files in the CasperShare. So I don't think this is the issue. But I appreciate the idea. :)

Just make sure you checked for hidden files as well. You could always enable debug logs on the JDS by creating a folder named Debug in the /jds/conf folder, re-register the JDS with the JSS, wait 5 minutes, and then take a look at the jamf.log file in /jds/logs to see if there is anything it's complaining about.

If that doesn't work, check with your JAMF support rep to get a case opened.

Good Luck!

Edit: Make sure to delete the debug folder you created to disable the extended logging when you are done.

This appears to be happening because for some reason or another when the JDS is communicating with the JSS there is a failure. If you can sign into the JDS machine and execute "sudo jamfds policy", I expect you will see an error of some sort. Many times what I would see is something like a certificate error. Doing something like re-running the installer could resolve this issue. But I would start with the jamfds policy to see what error you get.

Steve

Yep, when I try to update policy, I get:

TypeError - 'NoneType' object is not iterable

I am curious. If you do a "sudo jamds inventory" if it resolves the issue that you are experiencing. If you can run that command with out the same error, it may resolve the issue where the JSS doesn't know what it is yet. That should in turn allow you to run a policy again and have your inventory.

Steve

Oddly enough, every other jamfds command works except pulling policy.

Did you see that inventory showed up correctly in the JSS after the inventory command? If it does, maybe the policy works after that. My thought is the command failed and never was executed again. Which when the JSS does not have inventory of that device, it then would not send back a response because it doesn't effectively trust it.

Steve

Ran into the same issue. Were you able to resolve it?