Archive

Posts Tagged ‘Mac Admin’

How To Quickly Open a Policy in Jamf Pro

January 9, 2019 Leave a comment

We have a lot of policies. I mean over 1,000 policies in our Jamf Pro Server. Don’t ask. Part of it is out of necessity, but I’ll bet some of it is just because we were running so fast in 2018 to get systems enrolled and agencies under management, that we didn’t have time to, as Mike Levenick (@levenimc) recently put it, “trim the fat”. That’s what 2019 is all about. But I’m missing the point of this post: how to quickly open a policy. You can imagine how long it takes to load the list of policies when you have over 1,000 of them.

There are a couple of tools you’ll need. First up you’ll want a tool like Text Expander to create snippets or macros. I’m sure there are some free alternatives out there that will expand a text shortcut into something but Text Expander is what I’ve been using for many years, of course I’m using version 5 which is a perpetual license version and not the current subscription model. (Here’s an article about text expansion apps)

The second tool you’ll need is jss_helper from Shea Craig (@shea_craig). This will help us pull a list of the policies in our system, including the ID of the policy.

Now that you have your tools in place, the first thing you want to do is grab the URL of one of your policies. Just open a policy and copy the URL. Now go into Text Expander (or whatever tool you chose) and create a new snippet from the contents of the clipboard. Edit the URL removing everything after the equals (=) sign in the URL. Give your new snippet a shortcut and voila! You now have an easy way to get 90% of the way to quickly opening policies. Your URL snippet should look similar to this:

https://jss.yourcompany.com/policies.html?id=

Now let’s turn our attention to jss_helper. Once you have it installed and configured to talk to your JPS, you’re going to want to pull a list of the policies in your system. Open up Terminal (if it isn’t already) and run jss_helper with the following options:

jss_helper policies > ~/Desktop/policy_list.txt

Obviously you want to name that file whatever you want, but the cool thing is that you now have a list of every policy in your JPS along with its ID. If you open that file up in Excel or a text editor, you’ll see something like this:

ID: 2034 NAME: Installer Adobe Acrobat DC 19

ID: 1214 NAME: Installer Adobe Acrobat DC Reader

ID: 2030 NAME: Installer Adobe After Effects CC 2019

ID: 2031 NAME: Installer Adobe Animate CC 2019

ID: 2032 NAME: Installer Adobe Audition CC 2019

ID: 2033 NAME: Installer Adobe Bridge CC 2019

ID:  638 NAME: Installer Adobe Codecs

ID:  532 NAME: Installer Adobe Creative Cloud Desktop elevated App

ID:  314 NAME: Installer Adobe Creative Cloud Desktop Non elevated App

Now let’s put it together. Open up your web browser and in the address bar type whatever shortcut you created for the policy URL above. Once the URL expands, before pressing enter, type in the ID number of the policy you want to open and then press enter. The policy should open up without having to wait for the list of policies to load or having to search the web interface for the specific policy.

Hopefully this will help speed up your game and help you become quicker and getting stuff done.

Categories: Jamf Pro, Tech Tags: , ,

Using AWS Lambda To Relay Jamf Pro Webhooks to Slack

January 8, 2019 Leave a comment

I recently got interested in utilizing webhooks in Jamf Pro but had no idea where to start. I went and watched Bryson Tyrrell’s (https://twitter.com/bryson3gps) presentation from JNUC 2017 Webhooks Part Deaux! and then went over to take a peek at Jackalope on the Jamf Marketplace. I read the docs, I tried to figure out how to do this in AWS ElasticBeanstalk, but I just couldn’t get it going. Just too much going on to devote enough time to it. So, I went over to Zapier and signed up for their free account so I could get this going. I got it working, but I quickly got throttled because I decided to enable the “ComputerCheckIn” webhook to make sure it worked. I think we flooded the 100 connection limit within 30 seconds and wound up having thousands of items in Zapier.

Well, that wasn’t going to work, so I changed it to “ComputerAdded” and waited for my month of Zapier to renew so I’d get 100 new “zaps”. That worked, until we went over the 100 limit again and had to wait. There had to be a better way that wasn’t going to cost me a ton of money. So I went Googling and came across an article on how to use AWS Lambda to do what I wanted to do: AWS Lambda For Forwarding Webhook To Slack.

I walked through the steps outlined on the page to setup the function in Lambda and everything worked great until I got to the part where I was making requests out to Slack. Lambda had a problem with the request method. Specifically this line of code:

 var post_req = https.request(post_options, function(res) {

So another round of Googling and I came up with the Node.js docs page on HTTPS and I figured out how to properly make the call:

Once I was able to get past the https connection issues, I was able to utilize the rest of Patrick’s example to get my webhook from Jamf feeding into a Slack channel. We uploaded a custom emoji to our Slack channel and used the Slack documentation on basic message formatting and on attachments to get the notification to look how we wanted.

Ultimately we created two Lambda functions, one for ComputerAdded and another for ComputerInventoryComplete, each feeding into their own channel in our Slack. This was fairly easy to accomplish, the next step is to find a way to feed DataDog, or some other service, the ComputerCheckIn webhook so I can get a count of how many check-ins we have each day.

The code we used is below, but I wanted to point out one or two things. Where I got hung up the most was how to pull things like Computer Name or Serial Number from the JSON we were getting from the Jamf Pro server. Since the JSON contains two arrays, “webhook” and “event”, it took me a little bit to understand how to grab that data. To be honest, my skills here are lacking considerably so it took me longer than it should. Ultimately I figured out that you just have to dot walk to get the data you want. So to get the Computer Name it’s:

body.event.deviceName

“body” is the JSON object that we parse the webhook into. Once I figured that out I was all set to grab whatever data from the event, or webhook, array that I needed. Hopefully my head banging will help others not stumble quite so much.

Here’s the Node.js code we used as the template:

 

 

Categories: Jamf Pro, Tech Tags: , ,

Scripting Remote Desktop Bookmarks

February 29, 2016 Leave a comment

A few years ago I was searching for a way to easily create bookmarks in Microsoft Remote Desktop 8 on the Mac. Prior to version 8 you could drop an .RDP file on a machine and that was really all you needed to do to give your users the ability to connect to servers. Granted, you can still use this method, it’s just a bit sloppier, in my opinion.

So I went searching for a way to script the bookmarks, and that led me to my good friend Ben Toms’ (@macmuleblog) blog. I found his post, “HOW TO: CREATE A MICROSOFT REMOTE DESKTOP 8 CONNECTION” and started experimenting. After some trial and error, I discovered that using PlistBuddy to create the bookmarks just wasn’t being consistent. So I looked into using the defaults command instead. I finally was able to settle on the following script:

You can find that code in my GitHub repo here.

RDC URI Attribute Support

I had posted that script up on JAMF Nation back in June 2014 when someone had asked about deploying connections. Recently user @gmarnin posted to that thread asking if anyone knew how to add an alternate shell key to the script. After no response, he reached out to me on the Twitter (I’m @stevewood_tx in case you care). So, I dusted off my script, fired up my Mac VM, and started experimenting.

The RDC GUI does not allow for a place to add these URI Attributes. I read through that web page and Marnin forwarded me this one as well. Marnin explained that he was able to get it to work when he exported the bookmark as an .RDP file and then used a text editor to add the necessary “alternate shell:s:” information. Armed with this knowledge, I went to the VM and started testing.

First I created a bookmark in a fresh installation of RDC. I had no bookmarks at all. After creating a bookmark I jumped into Terminal and did a read of the plist file and came up with this:

Now that we had a baseline, I exported the bookmark to the desktop of the VM, edited it to add the “alternate shell” bits, and then re-imported it into RDC as a new bookmark. I then tested to make sure it would work as advertised. After some trial and error, I was able to get the exact syntax for the “alternate shell” entry to work. Now I just needed to see what changes were made in the plist file. A quick read showed me the following:

The key is the line that has “remoteProgram” as part of the entry. You have to get the full path on the Windows machine to the application you want to run on connection to the server. Once you know that path, you can adjust your bookmark script however you need.

The script I posted above, and is linked in my GitHub repo, contains the line to add that Remote Program (alternate shell). If you do not need it, just comment it out of the script.

 

Upgrading Adobe Flash Player

December 18, 2015 1 comment

Recently on JAMF Nation there was a discussion about the Adobe Flash Player Distribution site going away. This site is where admins can go to get a copy of Flash that can then be legally distributed to their fleet of machines. The discussion started out to be about the change Adobe recently made to the URL for this site, but quickly turned to a discussion around distribution of Flash via Casper.

While I have signed up for the Adobe distribution site, I currently utilize a PKG file that comes from AutoPKGr (I replaced my Jenkins install with AutoPKGr last year sometime). Utilizing AutoPKGr makes my life easier, because I do not have to do anything except update my policy to replace the actual PKG file. I’m not going to go into setting up AutoPKGr for use with Casper, there have been plenty of discussions on that, but rather I am going to list out my procedures for processing Flash upgrades.

It’s Upgrade Day

I typically find out that there is a Flash upgrade from JAMF Nation. Someone typically posts that there is a Flash update almost immediately upon release. Once I’ve verified that the update has been uploaded to my JSS by AutoPKGr, I will go update my policy, changing out the PKG file.

As you will see, the policy is set to trigger on “Recurring Check-In” because I don’t care if a web browser is open or not. Flash can be installed while browsers are open, the users just have to restart the browsers that are open after the update. We’ll handle letting them know via a CocoaDialog script.

There are a few pre-requisite items we need to have in place for this process to work. First, we need to have a way to grab the Flash version off of the machines in our fleet. Second, we need to have a Smart Group that will capture all of the machines that are out of spec. This will allow us to scope our policy to those machines.

Grab the Version

I utilize an Extension Attribute to grab the version of Flash and store it in the database. While it can be argued that utilizing an EA to grab the version is not efficient, since the EA will run every time a Recon runs, there really isn’t another reliable method for grabbing the version.

So, setup an EA to grab the version of Flash. My EA is named “AdobeFlashVersion” and utilizes the following BASH script:

That’s pretty straight forward. Now that we have the version, we can build our Smart Group.

Screen Shot 2015-12-18 at 5.38.04 PM.png

As you can see, just pick your EA name out of the list of criteria to search for, and enter the version you are searching for using the “is not” operator.

Policy Time

Now that we’ve got our Smart Group collecting machines that are out of date, we can build our policy to install the update. We will name our policy “Update Flash Player” and place it in whichever category makes sense to your deployment of Casper.

I have my update policy set to run at “Recurring Check-in”, which means that machines will update as soon as they contact the JSS. The frequency is set to “Once per computer”, since we only need it to run one time.

General

We’ll click on Packages next so that we can add our Flash package. Click on Configure to get a list of all packages in the JSS:

 

Screen Shot 2015-12-18 at 5.32.24 PM.png

We should now have a list of all packages that the JSS knows about. Locate our latest Flash Player package and click Add to add it to the policy:

Screen_Shot_2015-12-18_at_5_32_29_PM.png

I utilize a script that runs after Flash has been installed to notify end users to restart any open web browsers. My script uses CocoaDialog to make these notifications, but you can use the built in notification process that Casper has. The script I utilize is below:

Now that we’ve added that script to our policy, we will add a line to the Files & Processes tab to set Flash to not auto update.

FilesAndProcesses.png

That line of information in the Execute Command box simply adds a line to a file called mms.cfg to tell Flash Player to not try to auto update. The line is:

The final thing for us to do is to add our Scope. Just click on the Scope tab at the top and add our Update Flash Smart Group:

Screen Shot 2015-12-18 at 6.01.26 PM.png

 

That’s all there is. Now that we have our update policy in place, each time there’s a new version we just have a few simple steps to update our end users:

  1. Get the new Flash package into the JSS
  2. Change our Smart Group to look for the new version number
  3. Change our policy to remove the old version and add the new version
  4. Finally, Flush All on the policy logs so everyone in the Smart Group gets the update.

 

I have been utilizing this method for updating Flash for well over a year now, and I have not had any troubles at all.

I hope this quick article has helped you out.

 

Categories: Tech Tags: , , ,

Meet My New Assistant – Jenkins

October 31, 2013 Leave a comment

Continuing with my posts on automation, or at least the automation of package building, I’d like to introduce you to my new assistant, Jenkins.  Jenkins is a continuous integration server.  Continuous Integration, or CI, is defined by Wikipedia as:

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day.

To put it plainly, or to put it into the perspective of a Mac sysadmin, Jenkins can be used to run shell commands at a given interval, or to run several commands in series.  We can then use CRON like scheduling within Jenkins to run these commands at a given time each day, each week, or whatever interval you give.

Jenkins will require the use of the Java 6 JRE on the machine you run it on.  You can go out to the Jenkins CI web site (http://jenkins-ci.org/) to download the installer for Mac.  Once you have downloaded the software, while logged in as an admin on the machine, run the Jenkins installer PKG.  After the installation has completed, either restart the computer, or open a Terminal window and load the LaunchDaemon:

launchctl load /Library/LaunchDaemon/org.jenkins-ci.plist

If Java is not installed you may be prompted to load Java.  After completing these steps, open a web browser and navigate to the home page for Jenkins:

http://localhost:8080

You should hopefully see the Jenkins dashboard, which looks similar to this:

JenkinsHome

NOTE:  If you receive an error about the home folder, try restarting the computer.

You can also check this web site for more info:  https://wiki.jenkins-ci.org/display/JENKINS/Thanks+for+using+OSX+Installer

If you successfully loaded the Jenkins dashboard, then you are all set to start using the power of a CI server.  I utilize Jenkins to work with my AutoPkg installation (on the same machine) so that I can build packages while I sleep.

Next up we’ll look at integrating Jenkins and AutoPkg.

AutoPkg – Your New Best Friend

October 30, 2013 2 comments

There’s been a lot of talk in the Mac admin community recently about AutoPkg (http://autopkg.github.io/autopkg/).  This tool, currently being developed by Greg Neagle and Tim Sutton, allows for the use of “recipes” to download and package different software found on the Internet.  This ability takes a lot of the work out of locating software, downloading it, and then packaging it, something a Mac admin may do multiple times a week.  AutoPkg automates all of that.  And, if you are a user of Munki, there are even recipes in AutoPkg that will import directly into Munki and update the catalogs.

As a prerequisite for AutoPKG to work, you need to have the command line version of git installed.  If you’ve installed XCode, then you have git.  If not, you can get git by downloading either a GUI GitHub tool like this one here, or download the command line version of git here.

Once you have git installed, go ahead and download the AutoPkg installer file from this location.  Now that it is downloaded, go ahead and run the AutoPkg installer.  This will install the AutoPkg software in the proper  locations on the machine.  Once completed, fire up Terminal and you can verify the software is properly installed by running the following command:

autopkg version

That will give you the current version installed on the system.  Now that AutoPkg is installed, you may want to create a directory in a common location, like the root of the drive or in the /Users/Shared folder, to hold the output from AutoPKG.  By default AutoPkg stores it’s output inside the user’s Library folder at ~/Library/AutoPkg/Cache.  This location can be changed by adjusting the CACHE_DIR in the preferences.  I like to store it at the root of the drive in a folder named Autopkg_Done.

mkdir /Autopkg_Done
chmod 777 /Autopkg_Done

Now that you have the CACHE_DIR created, you’ll need to tell AutoPkg about it.  This is done with the following command:

defaults write com.github.autopkg CACHE_DIR /path/to/cache/dir

So, in our example, the command we’d use is this:

defaults write com.github.autopkg CACHE_DIR /Autopkg_Done
NOTE:  AutoPKG stores its preferences in the user’s Preferences folder (~/Library/Preferences/com.github.autopkg.plist).  Because of this, any new user on the machine that will need to use AutoPKG will need to have the CACHE_DIR set and will need to download the recipe repositories (more on this in a minute).

With AutoPkg installed, and the CACHE_DIR set, all we have left is to tell it about some recipe repositories.  AutoPkg utilizes git repositories that hold recipes for building different packages.  Like using a recipe to bake a cake, AutoPkg uses these recipes to build the different files.

As of this writing, there are four repositories that I am aware of.  They are:

https://github.com/Jaharmi/autopkg_recipes
http://github.com/autopkg/recipes.git
https://github.com/hjuutilainen/autopkg-recipes
http://github.com/keeleysam/recipes
We need to tell AutoPkg about these repositories.  This is accomplished with the following command line:

autopkg repo-add <repoURL>

So for the four repositories above, we would use the following:

autopkg repo-add https://github.com/Jaharmi/autopkg_recipes
autopkg repo-add http://github.com/autopkg/recipes.git
autopkg repo-add https://github.com/hjuutilainen/autopkg-recipes
autopkg repo-add http://github.com/keeleysam/recipes

Now that we have our repositories in AutoPkg, we are free to run one of the recipes.  We can see what recipes we have access to with the following:

autopkg list-recipes

If all went right, you should see a list of the recipes that your AutoPkg installation knows about.  To run one, simply use the following:

autopkg run <recipe>

For example, to run Adobe Flash Player:

autopkg run AdobeFlashPlayer.pkg

That will download the Flash Player and create a PKG file for deployment inside of our CACHE_DIR (/Autopkg_Done in our case).  We can navigate through the folders there to find a pristine Flash installer package that we can now deploy to our machines.
There’s plenty more to know about AutoPkg, including how to import directly into Munki during a build.  Check out the wiki for more information on Munki integration, or if you want help with installation and config, go here.

Next up, we’ll setup Jenkins, a continuous integration server that will eventually allow us to build packages while we sleep

Categories: Tech Tags: , , ,