+1Hello all,
I just started with an existing system that isn’t really documented. This means I have to do a lot of jumping around to determine what something does, where it applies, and even if it is working.
I want to create some good documentation for this, but I’m don’t know what the best method for doing this would be.
Thank You in advance,
-Pat
Best answer by atomczynski11
Step 1.
Document expiration of the Push Certificate, VPP, etc as well as credentials used, and detailed steps needed to renew.
Create calendar reminders for well ahead of the expiration date.
Step 2.
Share the steps with a Team member and test the documentation if they can follow along to complete.
Step 3.
Audit what you have.
I use app named Jamf Migrator, to get a snapshot of the current groups, settings, configurations.
Step 4.
Create a new category and name it ZZ_not in use, and put there items for reference use only.
Step 5.
Leverage the description fields for Smart Groups, Policies, Profiles
Step 6.
Use Categories
Step 7.
Make your own naming convention for smart groups, policies, etc.
I use a numbering system for policies.
Step 8.
Make a policy that does the thing, and additional policies that act as triggers.
Document what you have before ripping things out.
You got this!
+4Obviously, what worked for me may not work for you, but when I took over an existing system that also lacked documentation, I found it was best to go through and inventory everything. I just used spreadsheets and went through each section. For instance, I would go through all the Policies and note things like the name, scope, and what it does. Once that was done, I’d move on to Configuration Profiles, extension attributes, groups, etc. For me, that was the best way to get a bit of a handle on an environment that was setup by someone with whom I’ve never any interactions. This was especially important with Smart Groups, since those can lead to sprawling changes throughout the environment; ours were really out of control.
Once I had an understanding of everything that was running and their dependancies, then I started going through and removing anything that no longer seemed necessary. For that, I would disable or de-scope items, see if any unintended consequences arose, and then go back at a later date and actually remove those items.
This was a rather time consuming process and not fun at all, but for me, it was the best way to get a handle on what initially seemed overwhelming.
+15What is this “documentation” of which you speak? 🤓
Seriously, we are trying to accomplish much the same goal. If we have any success, I will be sure to share it.
+21When our Jamf instance was on-prem I created a spreadsheet similar to what
Since moving to an on-prem instance I’ve taken the approach of documenting within Jamf Pro. I use Categories extensively. For example, all of our Adobe apps are in the Adobe Apps category, in both Self Service and in Jamf. Any mobile device configuration profiles with restrictions are in a Restrictions category. Profiles that apply to Apple TVs are in their own category. Then in the description field, I also document the purpose of the profile including who it should be scoped to. Polices are also grouped in categories and I give them very descriptive names so that anyone could determine the purpose of the policy by looking at the name.
I also have a summer checklist that I go though each summer to look at what isn’t needed any longer, groups, polices, extension attributes, etc, and clean up what isn't needed and add what is needed for the next school year.
+18Step 1.
Document expiration of the Push Certificate, VPP, etc as well as credentials used, and detailed steps needed to renew.
Create calendar reminders for well ahead of the expiration date.
Step 2.
Share the steps with a Team member and test the documentation if they can follow along to complete.
Step 3.
Audit what you have.
I use app named Jamf Migrator, to get a snapshot of the current groups, settings, configurations.
Step 4.
Create a new category and name it ZZ_not in use, and put there items for reference use only.
Step 5.
Leverage the description fields for Smart Groups, Policies, Profiles
Step 6.
Use Categories
Step 7.
Make your own naming convention for smart groups, policies, etc.
I use a numbering system for policies.
Step 8.
Make a policy that does the thing, and additional policies that act as triggers.
Document what you have before ripping things out.
You got this!
+13If you are thinking of deleting Configuration Profiles - Don’t.
First create 2 categories
ZZ_Not in use
ZZZ_Not in use
Any Config you want to get rid of, un-scope it, then move it to one of the above. If it is still out there on a device, because it hasnt checked in, you will get a warning and you click the Send to All.
Wait a week, and move the Config to the next category...
No warning? - Every device it was on has checked in and picked up that the scope has been dropped. It is safe to remove the config.
If however the warning shows up? - There is still a device out there that has the config and has not checked in yet. Thats a problem. The fail to check in needs investigating.
Keep swapping them across between the two categories, until there is no warning.
Once you un-scope it the number of devices listed against it will fall to 0, but it will remain on devices until they check in.
If you delete a Config, before it has been naturally removed from a device, you will find it will be stuck. The Config will never uninstall from the device, because it does not exist in the JAMF serrver to be removed from the device.
Your only fix is to erase the device, and start again with it.
The absolute hardest part of documenting your Jamf setup is maintaining that documentation and keeping it up to date. I find that even harder because I am the only one managing the server, I know what it all is.
Document all devices, policies, profiles, and scripts clearly. Use consistent naming, explain each policy’s purpose and scope, and track changes with version control. Review and update documentation regularly to keep it accurate.
+1Thank you all for the advise and support. I used co-pilot to help build me a template excel file to gte started. Thanks for the naming convention advise. I’ll start will documenting and organizing before I begin making naming changes. That will be phase 2.
Excellent advise about the Configuration Profiles. I have the same opinion about auditing and pruning those, but I thought it would be good to draw attention to how important it is to be extremely careful when deleting Configuration Profiles.
I have to check with my new employer if I can post the template file. The prompt I used for co-pilot was relatively simple. “I need an excel template for documenting JAMF Pro policies, configuration profiles, and other settings.” I had it do some changes after the initial file was generated. Thats a good way to customize it to your preferences and organization.
-Pat
+21Awesome notes above
• Zoom out and get the Big Picture Infrastructure
• Observe and see how your Jamf actually talks to the world
🖥️ Enrollment Methods: Are you using Automated Device Enrollment (Apple Business Manager), User-Initiated (URL), or both? Note the PreStage Configurations
🖥️ Network/DPs: Where do the installers live? Cloud Distribution Point (CDP) or local file shares?
🖥️ Identity Provider (IdP): How is it integrated? (e.g., Okta, Azure AD, Google)
🖥️ Apple Certificates: Check the expiration dates for your Push Certificate (APNs) and Volume Purchase Program (VPP) tokens
• Wipe test Apple Devices. Attempt enrollment. Then wipe again.
• This will tell you about all the handshakes the devices are making. How the previous admin set things up. It may give you a roadmap of where you’d like to take things ...
• Did they use a macOS Onboarding system? Does your devices use SCEP? ADE? Microsoft Platform SSO Registration Banner? Got 802.1x, or proxy concerns?
• Are we using DDM for updates, blueprints, or other 3rd party tools like Nudge or Superman?
• Open Terminal and type: sudo jamf policy. Document obeservations.
• How do our users do work once a device is provisioned? Are we connecting to SMB shares? VPN? Do I need a Kerberos ticket?
• What is the customer experience like? DockUtil, or desktoppr?
+4What a wonderful thread of ideas ! 🤩
Might be a bit redundant with what has been told already but in my previous position I had a category named Ze_Archive in which I was dumping policies and configuration profiles that weren’t in use anymore but I didn’t want to simply delete for some reasons (you never know !). Plus it was a great way to make sure it was properly unscoped 👌🏻
I second the need to document the expiration date of your tokens + which credentials were used !
+11
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.