No Policies Found for the ID 1

Why not just run sudo jamf recon?

Do you have the execution frequency set to anything other than 'Ongoing'? This would explain why the computer could run the policy in the past, but not now.

We've run into this in our Self Service policies for some computers. In other threads, I believe the quick fix was to uncheck "Enabled" in the policy and save. Then Enable it again and click save. Test.

sudo jamf policy

will run the check in policy without -id 1. Also if you go to the policy click the address in the address bar and see what the actual id number is. If the policy was deleted and moved or cloned and the old one deleted it will have a different policy id. Also to what @mschroder said is it set to on going.

@Morningside, I would look at what @mschroder mentioned, because that may be the issue. Once a policy runs on a device, such as the built in inventory collection, it's not going to run again until the frequency set in the policy has been reached. So if for example, it's set to once per day and it ran at 9 am, trying to call it again at 12 pm manually on the same day is going to fail because 24 hours has not expired yet. Scope isn't just a function of whether the device is in the scope list for the policy, it also applies to the frequency set for said policy.

Also, like @wmehilos stated, if the goal is to manually collect inventory, why not just call sudo jamf recon since that isn't tied to any scope or frequency? You should not really ever need to call sudo jamf policy -id 1 in my opinion.

Thanks everyone for your comments. I discovered my error and it was this: I incorrectly believed that running the command 'sudo jamf policy -ID 1' would execute the policy in question. This is not the case. All that will do is check to see if the policy has run according to its frequency. @mschroder was absolutely correct. Setting the policy to 'Ongoing' was the answer. I will say tho, that the error you get is very misleading. "No policies found for the ID 1" implies that the computer doesn't think the policy is in scope. I would encourage Jamf to improve that message some. Thanks again everyone!

@Morningside Maybe we're not getting the whole picture here, but I still don't quite know why you're using that policy, calling it by it's id, when, if all you want/need is an inventory collection, a simple jamf recon will suffice. Again, you really shouldn't need to call that specific policy manually. It's the initial policy created during the Jamf Pro setup, designed to run on check-in at whatever frequency it was set to, like once per day or once per week.
I guess it's none of my business really, but just a word of warning. I would be cautious about changing the frequency of that policy to Ongoing, unless you switched out the trigger to something other than Recurring Check-in, because if not, it means that you're going to end up collecting a lot of unnecessary inventories, on every machines check-in, which is generally considered a Bad Idea. It's going to hammer and bloat the database over time.

If you really need a policy that collects inventory that you can call manually, you can create a new policy with just the Maintenance payload and the collect inventory option enabled, and then set up a custom trigger as the "trigger" and set the frequency to "ongoing" This would enable you to call that policy in script with something like sudo jamf policy -trigger updateInventory or whatever custom trigger you set for it.

Just my 2¢ on this.

@mm2270 It isn't about taking inventory, that policy also resets computer names as one of its maintenance items and that is what I was trying to do. Thanks!