It has been around a year since I moved from offering Jamf Pro Jumpstart services to troubleshooting issues within the Support realm, and during this period I’ve been handling a wide variety of issues and roadblocks a MacAdmin can run into.
By troubleshooting the same issues over and over again, you kind of develop a 6th sense for common issues, allowing you to have an idea about what is going on even before looking closer into the matter. And while this can be handy in view of quick resolution, it also lays down a risk to be horribly wrong and waste precious troubleshooting time. We all know that assumption is the mother of all… problems.
This is why, regardless of the issue, a detailed set of information is required to rule out or confirm the specific root cause of the problem, which brings us immediately to the most important 4-letter word within the support realm: LOGS.
And this is actually a bit funny, and I love the irony in this, because I’ve been working in other roles, finding myself in trouble and thinking I can could quickly ask subject matter expert for an easy fix… ending up with the dreaded reply “Sure, I’ll have a look, give me the logs!”. Now, being back into a support role again for over a year, I realise I became one of those guys always replying with “Sure, I’ll have a look, give me the logs”…
So, as this might feel like the support agent is unnecessarily delaying the support or come across like he/she doesn’t have a clue about what’s going on, it’s actually quite the opposite. The last thing you want would be a support engineer trusting his/her guts because he or she thinks ‘I’ve seen this issue before’. Sidetracking on the wrong path due to a bad gut feeling will for sure cause more delay than taking a moment to gather all required info to confirm this gut feeling, and applying the wrong workaround following a bad assumption can make things go south very fast!
So let’s have a look at where and how to find those logs for a variety of Jamf products!
Let’s start with Jamf Pro.
One first very important thing to mention is that you have to be careful with grabbing or checking the logs through the Web Gui of a Jamf Cloud or clustered/loadbalanced on-prem Jamf Pro instance. You might have noticed that in those type of Jamf Pro setups, depending your browser and open tabs, the tab sometimes shows one or two stars next to the title:
What are those? Well, it shows you if the load balancer sent you to the Primary or a Secondary node of the cluster. See it like military grades, the more stars the better, so ** is the Primary, * is the Secondary web app.
And this is important in view of the logs, because as you might know the Primary and the Secondary nodes have different responsibilities within the Jamf Pro framework! Depending the responsibilities, the logs will obviously be different. So, if you are looking at the logs in the Jamf Pro settings, you might be looking at the Secondary web app and miss valuable information you need!
Understanding the Primary and Secondary web App responsibilities: https://www.jamf.com/jamf-nation/articles/420/understanding-primary-and-secondary-web-application-responsibilities
So, where should you get the correct logs? Well, you can try to trick your browser to flip to the other node, but if you are using JamfCloud, your support agent can request the logs from the Jamf Cloud server for you. So you’re good. If however you are hosting your own on-prem server the logs of each server in the cluster can be found at:
Windows: C:\Program Files\JSS\Logs\ Mac: /Library/JSS/Logs/ Linux: /usr/local/jss/logs/
And for the Jamf logs on the client macOS computer:
Depending the issue, you might be asked to enable debug mode. As this would bring us a bit to far off the main purpose of this post, I’ll limit this sidetrack to dropping the following article here: https://www.jamf.com/jamf-nation/articles/454/enabling-debug-mode
Please note that there are additional debug modes which can be enabled to get more verbose logging on SCEP, VPP, DEP, HTTP, … but I plan to make another post on that later. Where needed support will ask and help you to enable those anyway.
Next, Jamf Connect!
As you know I’ve been writing a lot of posts on the subject, and those who have been touching the configuration of Jamf Connect know that there really are a lot of features that can be configured in Jamf Connect. It’s an awesome product, but it requires precise configuration.
By spending quite some time with the product by now, I kind of developed that 6th sense or gut feeling whenever I see a Jamf Connect issue, however, as explained above, assuming “I’ve seen the error before” has bitten me a few times already, so when it comes to Jamf Connect I really became the “Sure, I’ll have a look, give me the logs” type of guy… No logs, no truth.
To grab the logs of Jamf Connect Login we have a few options.
First of all you can monitor the logs stream while logging in through Jamf Connect and use SSH from another machine to run the following command:
log stream --predicate 'subsystem == "com.jamf.connect.login"' --debug
Alternatively, you can grab the logs locally after replicating the behaviour you are troubleshooting:
log show --predicate 'subsystem == "com.jamf.connect"' --debug
or specify a timeframe, for instance the last 30 minutes:
log show --predicate 'subsystem == "com.jamf.connect.login"' --debug --info --last 30m
For Jamf Connect Verify / Sync, you’ll have to quit the app and launch it in verbose mode via Terminal, and capture the output in Terminal:
/Applications/Jamf\ Connect\ Sync.app/Contents/MacOS/Jamf\ Connect\ Sync -v
/Applications/Jamf\ Connect\ Verify.app/Contents/MacOS/Jamf\ Connect\ Verify -v
Finally you can do the same with the Jamf Connect Configuration tool:
/Applications/Jamf\ Connect\ Configuration.app/Contents/MacOS/Jamf\ Connect\ Configuration -v
Jamf Infrastucture Manager
When troubleshooting the Jamf Infrastructure Manager, logs can be found at:
Linux: /var/log/jamf-im* Windows: C:\Program Files\Jamf\Logs
All three of the Jamf Infrastructure Manager logs will be located at these directories:
Apart from that, you might also want to have a look at the config file which Jim downloads when getting the LDAP setup from Jamf Pro:
C:\Program Files\Jamf\Infrastructure Manager\config\ldap-proxy\lpsServerSettings.json
Jamf ADCS Connector
The Jamf ADCS Connector runs on Windows IIS, so the logs you need are located at:
Apart from that, and depending the issue, that you might also want to have a look at the “failed requests” in the Certificate Authority tool of your Windows CA.
Jamf as SCEP Proxy
When configuring Jamf as SCEP Proxy, the Jamf Pro logs should give you enough information, where needed additional SCEP debugging can be enabled. As mentioned I plan on dedicating another post on special Jamf Pro debug modes.
Apart from that, you might want to have a look a the “failed requests” in the Certificate Authority tool of you Windows CA.
Jamf SCCM Plugin
I haven’t seen many usage of the SCCM plugin lately, so I’ll just drop the troubleshooting article here: https://docs.jamf.com/plug-ins/sccm-jamf-pro-server/3.70.0/Troubleshooting_the_Jamf_SCCM_Proxy_Service.html
I hope the above helps to find the relevant logs to speed up your journey when seeking support for a Jamf related issue.
Apart from the logs there is however one more thing you can do to speed things up even further: provide concise and useful information. Here is an example of a little template you can use. It will make your first interaction with support so much easier, and you’ll be a rockstar!
Jamf Pro Instance URL: https://myjamf.mydomain.com:8443 or https://myjamf.jamfcloud.com Jamf Pro version: For on-prem: OS Jamf Pro is installed on: Windows/Linux/macOS Java version: mySQL version: Clustered: yes/no Loadbalanced: yes/no For Jamf Connect: Issue with: Jamf Connect Login / Sync / Verify ? JC Login version: JC Sync version: JC Verify version: iDP used: If Azure: ADFS federated yes/no ? For JIM: OS JIM is installed on Using LDAP or LDAPs ? For all the above: - Exact issue summary: - Exact error message observed: - Screenshots attached - Logs attached
That’s it! I hope this post helps to reduce the back and forward interactions with support and fast track your journey towards resolution.
As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!