I'm a new system admin

[binjali]

Hello Jamf Nation!

I'm a newly hired system admin for my organization. I have a lot of experience with Macs from with a desktop support background. I used to be a Genius.  I know how things used to be.

But I just started a new job as a Systems Admin, and one of my areas of responsibility is the care and feeding of our Jamf instance on behalf of our end users. and our Jamf isn't very happy.

I spent the 2 weeks before I started watching a lot of JNUC keynotes and 100 videos on Jamf's youtube channel. I feel like I have a handle on the possibilities of Jamf and I know that I can be successful!

But my environment is dysfunctional, and not very well documented and I don't know how to fix all the broken things without breaking my environment more.

How did all of you go about assessing your environments, and making plans on how to implement fixes.

Facts:

-Our prod environment is hosted on jamfcloud.

-We run Active Directory

-We have Exchange

-We have Apple Business

-We use Okta for ID/SSO (i think)

-There is Citrix products (pretty sure for VPN, not sure what else)

-We are working on an Office 365 migration

-There is a goal of getting all possible Macs onto 11.6.4 as a baseline for compliance and security.

-Jamf Self Service has some apps that succesfully deploy to some users, but not others and I don't know why

-Categories in Jamf feel/look messy and I don't think they are being used well

I just need some idea of next steps. How hard is it to get help from someone who knows what they are doing? are Jamf Environment audits a thing?

[sdagley]

@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? 

[binjali]

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.

[binjali]

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

[binjali]

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.

[sdagley]

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.

[binjali]

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?

[bethjohnson]

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.

[binjali]

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)

[atomczynski]

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.

[atomczynski]

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)