Hello all, I have been tasked to document our JAMF server configuration. Mainly things like policies, groups and scripts. I could do a terrible spreadsheet easily, but that would be counter to the intuitive theme of JAMF's design. What do you suggest?
Thanks in advance, -Pat
Since I have jumped into an place that has not documented anything, I understand the need to document everything Jamf related. I assume that you are looking to document why a policy was created and what it does?
If you click on the History button for the policy, there is an Add Note button. I have made it mandatory to put the details of the Policy here. I also require the Description field in Extension Attributes and Notes in Scripts. Minimum required information: what this does, why it was created, who created it and for Apps, version number.
I'm self admittedly not the greatest at documentation, so I aim do to it more through organized implementation than anything else. Policies, smart/static groups, config profiles all follow a particular naming convention that makes them easily identifiable when read and grouped accordingly. Scripts should be as descriptive with title as possible, including category, and comments there will always help. Round this all out with regular - usually weekly cursory and quarterly in-depth - reviews and it's all pretty well descriptive.
@ferrispd the idea is you copy down policies, profiles, EAs, and scripts, and have them committed to an internal Github repository. Our attitude about it, loosely, is that the code is the documentation. You can include readme files in the repos that have an overview of where they data comes from, how it's used, etc., so it's all centralized.
Once comfortable with the concept of using GitHub with your Jamf instance, you can integrate git2jss with a CI/CD tool so that changes go through pull requests and reviews, rather than just making changes directly in the webapp. It'd be nice if Jamf had a built-in integration with GitHub, but for now git2jss is a nice alternative.
Like many organizations, we've been using Slack for internal communications. I've build channels like #scripts, #extension-attributes, and #profiles on our local Slack, where I can drop these downloaded files, or paste in as code snippets. Allows for commentary, threaded and contextually-aware discussion of said policy, script, etc. This isn't as flexible as Git, but since I'm the only one writing any of these profiles, scripts, that collaborative type of versioning isn't really necessary in my environment. Using channels in Slack was a natural extension of the communication my team has already been doing.