First-Time Jamf Admin Advice?

Hi,
For Starters think about Departments and Sites, you do not need to use them in the literal mean. We are using them to split Jamfadmin Privileges for different institutions on our University, cause everyone has to live in the same Jamf Instance but not everyone is allowed do administrate all Macs. Oh and if you use Sites you will need to use Groups for the Webinterface Login... Cause if you use Users you can not give people Access to multiple Sites, only one Site or full Access even to the Site None (Globally defined Policies and Profiles should go there). But if you use Groups and a User is in Multiple Groups his Privileges will add up. So multiple Site Access without Full / Site None Access.

Best practices are rather different depending on your Environment or use Cases. Especially Admin privileges for Endusers is always a big discussion.... in the Environment i am working for Users are not allowed to have Admin privileges besides a few exceptions. We are using a script that creates a Daemon to promote this users temporarily and will demote them after a defined time. For 1 to 1 Macs it is possible to Scope this to specific Computers trough the SelfService. If not Scoping it to certain Users in SelfService is a powerful tool to lock things behind a secondary Self-Service Login.
Self-Service in itself is one of the most powerful tools to empower End-users without giving them Admin privileges.

Oh and do your self a Favour and look at this Topic: https://community.jamf.com/t5/jamf-pro/restarting-the-jamf-binary-when-macs-stopping-checking-in/m-p/285539
implementing this mechanism from the get go will help a lot and reduce potential problems.

If SecureToken and BootstrapToken is important (especially if you want it on a local Adminaccount, which is another Discussion in itself) i have written a Topic about it, that you may want to use as an inspiration: https://community.jamf.com/t5/jamf-pro/automatic-secure-and-bootstraptoken/m-p/292944
This does not include ModernAuth or LAPS but with some reading into the API it is possible to do the needed editing.

This are more or less the early pitfalls we had... there are many more things you can pump into but that depends on how you are doing this and want to manage your devices and users.

get profession advice / consultancy..  JAMF is complex and you don't want to build it twice.. three times.. 

and plan it all out ( on paper ) then build it.. in your dev environment if you can.. once happy move to live.. 

seen way too many JAMF instances that were not planned... 

enjoy! 

😃

Definitely the training modules. Previous JNUC (Jamf Nation User Conference) sessions are on YouTube, you might get good ideas from videos on how other universities and companies are deploying it, their tips. Jamf Nation community forums proved invaluable to me. Also join macadmins on Slack, I monitor and search through several channels there, such as #jamfnation. The worst part of setting up Jamf was printers. So much trial and error. That's not Jamf's fault - it's a Windows printing world and Apple's just living in it (barely). Definitely plan out, make a checklist of what you want Jamf to manage. Don't feel like you have to implement everything on day one. We didn't do patch management for a year, and then, we did it using Installomator and liked it so much, transitioned to using Installomator to set up new apps. I would also note that Jamf out-of-the-box won't do a lot of what you want - that's where the community comes in with open source tools to fill the gap (like nudge, erase-install, Installomator, DEP Notify, scripts, etc). Don't bundle too much together - break things out into separate pieces (ie don't have one configuration profile larded up with multiple different payloads, have separate profiles for each payload type). Same for policies. Smartgroups, once you get the hang of them, allow pretty slick automation of scoping and deploying, but beware of smartgroup sprawl. Document as you go along. A lot. "How to X" so you (or whomever comes after you) knows how and why you configured things so. Not sure if you're a cloud or on-premise customer, but cloud (unsure about on-premise) customers, you can request a second "sandbox" cloud environment for testing, it's limited to a handful of devices. Strongly recommend it. Don't test in production. Finally, the most devilishly clever tip I came across in this forum was to create self-service policy that calls the Restart payload, but you present it as a "tune up" tool in Self-Service. "Running this tool will clear temporary files and optimize your Mac. This procedure will reboot your Mac, so save any documents you have open." Because in my organization, employees will go weeks without rebooting, and sometimes a reboot fixes things and saves a Help Desk ticket :) I was in your shoes about two years ago. Good luck!