I've been tasked with the pain staking job of documenting JAMF, how each policy works, what are it's dependancies like Smart Groups, EAs, Packages etc.
I'm intrigued how others have done it and whether anyone would be willing to share a template perhaps?
Obviously we use Code commit which is fine for techies but I need to cater for non techies too.
In Brief, I create color coded flowcharts to present the deployment process. ie different colors for Package, Policy, Script, etc.
Policy contains said Package & Scripts. The flowchart details in which order they are deployed and where they are deployed to on the computer. I then use, in tandem with the flow chart, a text document containing the same information as the flowchart except it is all spelled out and highly detailed, includes the scripts in full as well as what the scripts do, the packages that are deployed & files contained in the package, where they go, what they do & why.
This is all compiled into a library of documentation. Looks great & Easily observed by both Technical & Non-Technical readers.
Your timing @Cayde-6 is pretty incredible. I just finished documenting our basic workflow for os recovery. This entire document is very long but what I did was start with our automated workflow to either wipe and install a new OS on an existing computer or a new computer via DEP. I moved onto breaking this workflow down into specific policies and naming conventions to get this working. I then did the explaining of policies and each available payload along with the same for configuration profiles. Finally, to get all of our policies and profiles documented, as of today at least, I did a copy and paste from the JSS summary that would typically be sent to Jamf. I did explain our smart groups as well. If you'd like to see it, feel free to send me an email at firstname.lastname@example.org.
Unless there is something I am missing, Excel for Mac is extremely inadequate for serious data. But that doesn't seem to be the case on Windows if you have access to a VM or Windows box.
I give that preface, because I have been leveraging Excel to import data from the classic JSS API. Makes it easy to keep a "database" of all policies, config profiles, groups, computers that other admins have access to. It automatically updates every time it is open, and I have it on a sharepoint site as well. I have some legacy documentation on a OneNote notebook that I keep intending to update with these excel sheets as well
Hello @jgsims, @mickgrant, @fneidhardt and @ematos, if I missed someone else, my apologies. Just fire off an email to email@example.com if you already haven't done so. My entire goal in this documentation was to help others get into my thought processes. I am by no means an expert on all things Jamf, but what I have developed works really well for us. Sometimes, we can see the end results and revel in it, but to share with others on HOW or WHAT I was thinking can be enlightening.
As I have mentioned to others, empowering others to be empowered only strengthens our community as a whole.
I find it inspirational when my colleagues at our college in the Windows environment using SCCM are trying to figure out how I have done things so well with Jamf. Using Jamf has freed up some of my time and because of it, I have been afforded a luxury this summer to put all of this together.
If it is at all helpful, provides guidance or generally useful in any way, I am happy to share.
Thanks @musat I have been getting a lot of responses. Quickly frankly, I have no problem helping people out. I don't have everything documented. Things like scripts and packages haven't been touched yet. I hope to round out things this winter in these terms. When I go to JNUC this year, I am meeting up with a couple of Jamf folks to get their ideas on how to tweak things. Thanks for the interest.
I have build an 'all encompassing' wiki for my Jamf Pro installation. I'll attach a few screenshots here.
The wiki documents (nearly) everything in and about jamf.
From architecture, setup, configuration, management and solutions. Content is documented and cross referenced when possible.
This wiki is open, in read only, to a wide group of people. There are a few restricted pages, with sensitive info.
Although this represents a significant effort it allows documentation to be linked and cross referenced. For example, A policy may have a couple scripts and a package in it and may have been initiated by a service request from SecOps. All aspects are documented. The Solutions section describes particular items that will be helpful when someone asks "How does that work?" "Why is that in there?", or the helpdesk techs want to know why an item doesn't show up for one user but does for another.
@PeterG Hey I like what you've done there... but are you manually updating that beast or have you set some automation in place? To some extent as discussed in my team we feel that to some extent Jamf documents itself, however it requires too much digging in to find details and connections, there are some weird gaps. For example, why does a Policy not links to any scripts or packages used? One could use the API to extract a lot of that, and the explanation of the why, well, that's really the tough part of documentation isn't it?
@Sterritt My documentation is all done manually. Documenting is integrated into the processes as jamf 'elements' are being created. I have found that if you 'intend to go back and document' you just don't do it so we do it inline with the jamf work itself. If you consider the external benefit that the Helpdesk staff, Security Operations or even the general public get from complete documentation, it becomes worth the effort. It also allows for documenting changes over time, to a package or policy.