Posted on 10-29-2015 09:44 AM
I have installed the JDS package on multiple JDSs with no issue, but I have one machine that refuses to work. I have gone as far as restoring it back to factory and starting from scratch, but it will not work. I have attached the screen shots of what I get when it shows up in my JDS screen every time I run the JDS installer on it. Any thoughts would be appreciated.
Posted on 10-29-2015 10:37 AM
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.
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.
Posted on 10-29-2015 10:45 AM
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. :)
Posted on 10-29-2015 10:57 AM
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.
Edit: Make sure to delete the debug folder you created to disable the extended logging when you are done.
Posted on 10-29-2015 12:42 PM
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.
Posted on 10-29-2015 01:01 PM
Yep, when I try to update policy, I get:
TypeError - 'NoneType' object is not iterable
Posted on 10-29-2015 02:51 PM
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.
Posted on 10-30-2015 10:44 AM
Oddly enough, every other jamfds command works except pulling policy.
Posted on 10-30-2015 11:47 AM
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.
Posted on 12-08-2015 02:38 PM
Ran into the same issue. Were you able to resolve it?