Posted on 02-22-2023 02:45 PM
Hi - I have inherited a Jamf Pro environment with 1118 packages and 700-800 policies - maybe around 35% are actually being used. What is the best way (or some ways) to figure out what can be deleted and what can't? Is there a best-practice way to delete packages and policies?
Similarly, there are around 550 computers that are probably out of service but still in Jamf. What is the best way to figure out which computers can be deleted and which can't? Is there a best-practice way to do something that will temporarily remove them so that I'm not exceeding my device count while I figure out if they indeed have been removed from service and can be deleted from Jamf?
02-22-2023 06:26 PM - edited 02-22-2023 06:31 PM
@jconrod Download Prune and have it identify anything unused in your Jamf Pro instance which will give you a good idea where to start removing things. You might want to run the Jamf Migrator to download a copy of the initial contents before actually removing anything though.
As for the Macs that are possibly no longer in service you _could_ temporarily un-manage them by un-checking the "Allow Jamf Pro to perform management tasks" when editing the Computer record but if you don't know what the management account name and password were you're going to have problems putting them back under management without re-enrolling them.
02-22-2023 10:21 PM - edited 02-24-2023 09:19 PM
Review all existing packages and policies to determine their relevance and usefulness.
Delete any packages and policies that are outdated or no longer needed.
Consolidate redundant packages and policies.
Organize the remaining packages and policies into logical groups.
Create documentation or notes on each package and policy to ensure they are properly labeled and easily searchable.
Consider creating a standardized naming convention for packages and policies to aid in organization and searchability.
Regularly review and clean up the environment to ensure it remains organized and relevant.
Posted on 02-23-2023 05:38 AM
@jconrod , I wanted to say first that I commend you for taking this on. I, too, inherited an existing Jamf instance in my company when our Jamf guy simply up and left one day in 2021. I was nominated the new Apple guy and here I am and I feel your pain. It's like you've been given a puzzle and have no picture to go by and told to assemble it. Here are some things I can tell you to do first to try and clear the noise this situation brings.
Once you understand your staging process, see what profiles are pushed and used, then you can know which ones you can delete or disable. Same for policies.
Lastly, make sure your Jamf Success manager knows you and that you know how to open tickets with Jamf Support should anything go sideways. Then, if you're not already a member of the MacAdmins group in Slack, join up, it's free and it's like having 60K co-workers who can help. Good luck.
Posted on 02-23-2023 09:51 AM
Thanks @Dennistopps , @sdagley, and @steve_summers. Very helpful.
@steve_summers - Nice to know I'm not the only person this happens to and feels this way! :-) Thanks for the APN warning. I got to deal with that earlier (and only made one mistake in the process!).
@sdagley - Thanks for the warning about the Jamf management password. The previous Jamf admin didn't document it so I'm thinking that I shouldn't temporaliy unmanage them. Do you have a recommendation of what I should do to machines that I don't *think* are in use anymore (but don't want to delete from Jamf until I'm sure)? My goal is to not have computers that aren't being used in Jamf and to not have computers that are being used not in Jamf. In other words, I don't want people using unmanaged computers and I don't want to pay Jamf to manage computers that have been removed from service. Any ideas of how to best do that? (Steve Summers and anyone else - feel free to chime in if you have ideas!)
Posted on 02-23-2023 10:15 AM
@jconrod Are you ok with re-imaging and re-enrolling any Mac that hasn't checked in with your Jamf Pro instance since a date you pick to be the threshold for "active"? If so, you could use a Smart Group to identify all of your Macs that haven't checked in since that date, and then use the Action button when viewing that Smart Group to do a Send Remote Commands->Lock Device with a Lock Message something like "This Mac has been declared inactive. If it is still required please contact <Contact Info>". Once the command is sent you can turn off the "Allow Jamf Pro to perform management tasks" setting in their computer record. Once that flag is turned off the record will remain in Jamf Pro although it will no longer appear in Smart Groups, or count as an active Jamf Pro license. It can still be found by using an Advanced Computer Search, and if it responds to a Loki command you should see that in the Management History section of the computer record.
Posted on 02-23-2023 01:35 PM
@jconrod also look at tools like Kmart and Jamf Ecosystem Analysis which can help you better understand the environment you inherited. Hope this helps!
Posted on 02-24-2023 05:43 AM
As others have suggested Prune is probably the best tool out there. However be very careful. I strongly recommend waiting 6 months or so before doing anything. Going in too quickly before you have a good understanding of the environment could lead you to deleting something you need.
As far as temporarily removing devices. That is now how apple has MDM setup. Once you remove the device it will need to be reprovisioned, you will have no management over the devices anymore until its been reprovisioned. Have a conversation with your IT governance folks before doing this.
Posted on 03-01-2023 03:15 PM
Good advice, @AJPinto . I've already waited close to a year to understand the environment better. Now it is time to renew our contract with Jamf so I need to get out-of-service computers out of Jamf so we aren't paying for a license for them!
Here is my plan to do that...I'll uncheck the "Allow Jamf Pro to perform managment tasks on this computer" box for the computers that I don't think are still in service. That should reduce the number of Jamf Pro licenses that I'm using and thus need to pay for (right?). I'll then push a small file to all the computers that Jamf can contact. This file will go to the computers that I think are being used and not to the ones that I don't think are being used (which are the ones that I just told Jamf to not send managment commands to - since Jamf isn't managing them, they won't get the small file). I'll then create a Smart Group that contains computers that have checked in recently and that don't have the small file I pushed. Computers that are no longer being managed but that are still in use will still check in but they won't get the file from Jamf Pro, so this Smart Group will help me find computers that should still be managed even though I thought they weren't being used. I'll re-enable managment on computers in the Smart Group which will cause them to get the small file, move out of the Smart Group, and increase the number of licenses that I need to pay for. After a month I should have a good idea of how many licenses are being used and that is what I should pay Jamf for. (I predict I'll reduce my license count by around 500 computers.)
Anyone see a flaw in my logic? @alanwest @sdagley @steve_summers - thoughts?