I'm a new system admin

@binjali See if your org will purchase a Jamf Training Pass for you. This will give you a year to take all of the Jamf certification courses, and besides improving your knowledge about how the Jamf Pro system works they will provide you a lot of ideas on how to improve your environment.

I would also strongly recommend macOS Monterey (specifically 12.2.1 or later) as your macOS baseline. macOS Big Sur had a lot of teething issues, and I believe you'll find Monterey a much more stable version.

You mention that you get errors in Self Service for some app deployments. What specifically are the errors shown in the policy logs? 

Thanks for the response!

The behavior I'm seeing is that the app install will fail (it shows Failed in Self Service) and instead Self Service will redirect the user to the App Store.

I don't see/know where the policy logs are kept.  I don't know how to set up getting free apps from the app store inside of self service.

If you're talking about an App Store app install is failing that is a different thing than a standard policy which would typically be installing a package from your Jamf Pro Distribution Point. For info on those installs look at the computer record in your Jamf Pro console and see the Mac App Store Apps section on the History tab.

So, that seems to only be showing me if it succeed or failed. I'm still not finding any information as to WHY i'm getting one or the other. Where do I find WHY?

I also picked 11.6.4 as an accommodation to older computers in the environment, especially when we don't have Monterey deployment in an acceptable zero-touch state.

Hi binjali,

Did you happen to watch this from the JAMF Nation User Conference (JAMF) 2020:

This JPS is a mess: practical advice when inheriting a Jamf infrastructure 

The suggestion is to wait at least two weeks (which you've done already) and up to a month or more to make any big changes. And the first step is to start with documentation.

Another JNUC session I'd recommend is the best practices one from 2021:

Between Two Jamfs 

We're currently doing some category cleanups and process overhauls -- renaming categories that are no longer meaningful, retiring some old policies, replacing scripts that set preferences in plist files with configuration profiles, etc. I'm also testing Graham Pugh's erase-install script for getting our baseline up to 10.15 (before we try to tackle the next leap to Monterey over the summer). We've already standardized our policy and configuration profile names -- updating names can be something that is low risk but can give you big improvements in clarifying what's happening in the JSS.

Hope this is helpful.

Thank you for the links to those videos! they have been helpful in organizing my work.  Does JSS in this message mean Jamf Self Service? (I really wish the abbreviations wouldn't get tossed around so much. its hard to figure out what everyone is talking about)

Hello,

I saw your other post.

Few pointers if I may:
- Document the existing configuration.
- Document changes you make.
- Communicate changes / wait for approvals for actions affecting end users (example: Self Service categories, existing policy triggers and schedules) - Think of the impact on your users.
- If you find a policy no longer needed, disable it instead of deleting it, create a category called z-for-reference as you may use it for reference later.
- If you find a profile no longer needed, remove all devices from scope instead of deleting it, use for reference

- do not stack multiple settings into one profile, keep things separated and simple (sort of master image to rule them all vs enrollment)
- Create a test environment using a spare computer or two for new policies and/or changes (this may grow into a virtual machine(s) in the future)
- Gather feedback from your users, and your team of what's working and what's not
- Create a naming convention for policies and scope
- Create multiple policies (triggers) for action policy that does something
- Ask for a test/sandbox instance of Jamf. You will need to setup the ABM links, Automated enrollment, Volume Purchase Program, APNS, etc.
- Use the test/sandbox to learn the behavior of APNS and Jamf Pro. Leverage what's in your existing Jamf environment to create one from scratch to establish a baseline.
- Down the road use your sandbox for early testing
- Make Self Service Simple for your users. Empower them to use it; "it's OK if behind the scenes things are dirty"

- TEST TEST TEST
- Reach out to your users and ask if they want to be testers of new apps, settings, etc.

Ask the community. We are here to help, learn from each other, and grow.

Keep a firm grip on expirations of tokens and certificates.

VPP, DEP, APNS, etc.
If possible do not use personal email accounts, instead use service level accounts for management tasks.

Document the config.
Don't let them lapse.

How do you document Jamf: https://www.jamf.com/blog/how-to-document-jamf/
(while this may be too much now, it might help you with the naming convention mentality)

For the app install issue, i needed to upload a new VPP token from Apple Business Manager to Jamf Cloud Pro