Troubleshooting computer problems over the phone can suck. Help Desk staff know this all too well. They frequently need technical information from someone who may be technically challenged on top of already being frustrated and in a hurry. Walking that person through finding an IP address or verifying Active Directory connectivity can be… painful.
How can a Jamf Pro admin make this suck less? For everyone?
Over the course of a few visits with my customers at a large school district in Texas, I’ve helped them put together a tool to display technical information in an easy-to-read window to their end users. We developed it, though, for their Help Desk. They’ll frequently ask their end users to run it from Self Service and relay the information on the screen. In less than a minute, a technician can often determine that a Mac is offline, connected to the wrong Wi-Fi SSID or just needs to be rebooted.
Here’s what the end user sees on their screen.
Why should you do this?
I asked Trudy, one of the designers of the script with the school district, to tell me the value she sees using the script. She said:
“Users are already familiar with accessing Self Service, so this provides an easily accessible location to gather device information… It is a time saver for experienced users as well because everything you need is right there and can be customized to suit your needs.”
When Trudy responded with those remarks, she added that she’d already used the script twice that morning.
The script I developed with Trudy is on our Jamf Professional Services GitHub page. Download or copy the Computer Information.bash script and open it an application that supports plain text such as BBEdit from Bare Bones Software or the open-source code editor, Atom. Avoid using Apple’s TextEdit if possible. Its default auto-correct features can make a script unusable.
The script has four parts to it.
The first part is just information about the script: who wrote it, what it does and instructions for how to use it.
The second part is a long list of script snippets I’ll call “modules”. We’ll cover those in a bit.
Next is the section that actually formats or designs what the end user will see on the screen. It’s rearrangeable and easily changed.
And the last part of the script displays all the information to the end user in a window and offers a button to do something more if we want.
Each piece of information the script collects and presents to the end user is just a short snippet of code. A module can be as short as two lines or up to 10 or more lines. It’s just long enough to collect a piece of information we think is important or useful.
If you’re not familiar with scripting, that’s fine. The modules are spaced apart in the script to make them easily viewable. Here’s the first one. Its purpose is to get the computer name.
# Display computer name runCommand=$( /usr/sbin/scutil --get ComputerName ) computerName="Computer Name: $runCommand"
The first line with the hashtag ( # ) at the beginning does nothing. It’s just a description. The second and third lines do the magic.
Open the Terminal application found in the /Applications/Utilities directory. Copy the second line and paste it into Terminal and hit return. Do the same for the third line.
That’s all it does. It outputs:
Computer Name: MooseBook Pro
That’s the first piece of information we see in the Computer Information window. Every other line of information is collected in a similar manner — one module at a time. Each piece of information is stored in a variable such as computerName. (Variable names should describe what kind of information they contain.) We’ll use these variables next.
Displaying the information
Toward the end of the script is this section. Compare it to the picture of the window above. Does it look familiar?
## Format information ##### displayInfo="---------------------------------------------- GENERAL $computerName $serialNumber $upTime ---------------------------------------------- NETWORK $activeServices $SSID $SSH $timeInfo $timeServer ---------------------------------------------- ACTIVE DIRECTORY $AD $testAD ---------------------------------------------- HARDWARE/SOFTWARE $diskSpace $operatingSystem $batteryCycleCount ----------------------------------------------"
This is where we format the information we’re collecting. We’ve added some long rows of dashes to act as visual dividers and followed them with section headers (GENERAL, NEWORK, ACTIVE DIRECTORY and HARDWARE/SOFTWARE) to logically divide the content into easy to read chunks of information.
To display each module, add a $ to the beginning of the variable name and list it in whatever order makes sense to you.
The rest of the script takes the formatted information above and displays it to the end user. Additionally, note the window also displays an Enable Remote Support button. That’s customizable too.
I’ve added three sample actions that this button can perform if clicked. The first sample command opens TeamViewer, a popular remote-control application. The second runs a policy from Jamf Pro. And the third takes the computer information we’ve generated and creates a new mail message to the Help Desk.
Locate the following section in the script.
# open a remote support application # /usr/bin/open -a "/Applications/TeamViewer.app" # run a policy to enable remote support # /usr/local/bin/jamf policy -event EnableRemoteSupport # email computer information to help desk /usr/bin/open "mailto:email@example.com?subject=Computer Information ($serialNumber)&body=$displayInfo"
The first line of each of these groups is just a description of what the command below it does. The second line of each group is the actual command that does the work. (Note: the last command may be wrapping onto the next line, but it’s still just one line.)
The first two commands have hashtags ( # ) in front of them because we don’t want them to run. The third one to send an email is currently enabled. To enable one of the other two commands, remove the hashtag in front of it and then add a hashtag in front of the email command at the end to disable it. Or remove all of these and add your own command to do something else.
Add to Self Service
Once you’ve customized the script, add it to a new script in Jamf Pro under Settings > Computer Information > Scripts. Name the script something like “Computer Information” and save.
Then choose Computers > Policies and create a new policy. Name it something like “Computer Information” and add the “Computer Information” script. Be sure to set the frequency of the policy to Ongoing to allow end users to run it as often as needed.
Enable the policy for Self Service. You may want to change the “Install” button to “Run” or “Get Info” and add an icon such as this one found here: “/System/Library/CoreServices/CoreTypes.bundle/
Contents/Resources/ToolbarInfo.icns”. (Don’t forget you can use the Preview application to convert it to a PNG graphic file before uploading to the policy.)
I need help with a module
Not everyone knows how to script. The best way to begin learning is to create modules. They’re very similar to creating extension attributes, which collect pieces of information from each computer and add them into the computer record in Jamf Pro. Look for code snippets for creating your own modules under the Settings (cog wheel) > Computer Management > Extension Attributes > New From Template button. You’ll find nearly 200 items to get started.
And don’t forget to search the Jamf Nation community, too. The Discussions area has a wealth of user-contributed information. And I’ve created a Computer Information Modules discussion for everyone who’d like to ask or help answer questions about creating modules for their Computer Information windows.
The best challenge you can give yourself when learning how to script is to learn how to take something in the macOS Finder and do the same thing as a command in Terminal. And basic scripting is nothing more than running one command after the other, just like this Computer Information script.
Not already a Jamf customer and want to see some of these workflows in action? Request a free trial.