Archive

Author Archive

Deploying Printers via Script

October 20, 2018 2 comments

Deploying printers on the Mac in an enterprise environment, or heck, just in a small office environment, can be done in multiple ways. If you don’t have a management tool, or ARD, you’re going to be running around doing it by hand. If you have a management tool, like Munki or Jamf, then you can deploy printers in a more automated fashion. My preferred method is to use a Bash script to deploy printers because it provides me a little more flexibility

Identify The Driver

The first thing to do is to identify the printer and the driver that is required. For most printers this is pretty simple, just navigate to the IP address of the printer to verify the make and model, then head over to the vendor’s website to download the latest driver. Once you have the driver, install it on your machine and then go find the driver file on your system. On the Mac, most printer drivers are stored in:

/Library/Printers/PPDs/Contents/Resources

If your printer has a “RIP”, or “Raster Image Processor“, identifying those drivers can be a little trickier. Head over to this post on how to identify the driver, and download it, on an EFI Fiery RIP. Drivers for an EFI Fiery or other RIP are usually stored in:

/Library/Printers/PPDs/Contents/Resources/<localization folder>

For us here in North America, that folder path would be:

/Library/Printers/PPDs/Contents/Resources/en.lproj

Once you have identified the driver, copy the full path of the driver file (Option-Command-C, or hold down Command then Edit->Copy as Pathname, or right click while holding Command) to your clipboard.

Build The Command

The next thing we need to do is figure out the command to run to add the printer. Fire up Terminal and let’s figure out the commands to use. We will utilize the lpadmin command to get the printer on the system. For this post this is what our command will look like:

sudo lpadmin -p <name> -E -o printer-is-shared=false -v ipp://1.1.1.1 -D "<name>" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz"

That looks a little daunting, so let’s break it down a little bit.

-p <name>  This flag sets the name of the printer as seen by the cups process. Use a name with no spaces, or substitute underscores for the space.

-E  This flag enables the printer to accept jobs

-o printer-is-shared=false  The -o flag allows us to pass options to the printer. In this case we are making sure the printer is not shared on the network.

-v ipp://1.1.1.1  The -v flag sets the URI of the printer.

-D <name>  Where -p set the name the cups process saw, the -D flag sets what I call the “friendly” name, the name that is visible in the GUI.

-P <driver path>  Pretty self explanatory, the -P flag sets the path to the driver.

Now that we have everything, run the command in Terminal to add the printer. You can verify the printer added by using the lpstat -a command. With the printer added, open up a program and send a test print to the printer. It is important for us to do this step so that we know our handy work is working properly.

Put It In A Script

Let’s get to the script to add the printer. Open your favorite code editor (TextMate or Sublime Text for me) and start a new script. I utilize Bash, but you could just as easily do this in Python if you prefer. First we want to make sure the proper driver is on the system, and if it isn’t we want to install it.

if [[ ! -f "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz" ]]; then
/usr/local/bin/jamf policy -trigger xeroxGenericDriver
fi
view raw gistfile1.txt hosted with ❤ by GitHub

If the driver file is not on the system, we call the jamf binary to trigger our install policy. Adjust this to fit your management toolset.

Now with the driver check complete, we use a case statement to choose the printer (or printers) to install. We pass the choice to the script using Script Parameters in our Jamf Pro server policy. Here’s an example showing how we can install one printer, or multiple printers in an office.

lpa='/usr/sbin/lpadmin'
case $printer in
Printer1)
${lpa} -p Printer1 -E -o printer-is-shared=false -v ipp://10.1.1.1/ipp/print \
-D "Printer1" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz"
;;
Printer2)
${lpa} -p Printer2 -E -o printer-is-shared=false -v ipp://10.1.1.2/ipp/print \
-D "Printer2" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz"
;;
OfficePrinters)
${lpa} -p Printer1 -E -o printer-is-shared=false -v ipp://10.1.1.1/ipp/print \
-D "Printer1" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz"
${lpa} -p Printer2 -E -o printer-is-shared=false -v ipp://10.1.1.2/ipp/print \
-D "Printer2" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz"
;;
esac
view raw gistfile1.txt hosted with ❤ by GitHub

You can hopefully see the flexibility this provides us for using one script to install multiple printers. Sure, we still have multiple policies in the JPS, but rather than have multiple printers or multiple scripts as well, we can do this with just the one. And, when a printer needs to change, we just edit the script.

Bonus Round

What about adding printer options, like paper trays or output trays or setting a printer to B&W instead of color? We can use lpoptions to figure out what those options are and to set them. Since that can be a daunting task, head over to this post about using lpoptions to identify the settings.

Hopefully this post has helped you evaluate the use of a script to add printers and has given you a new tool for your toolbox.

Categories: Jamf Pro, Tech Tags: , , ,

Custom Theme Fonts Office 2016 Mac

March 10, 2018 Leave a comment

I was given the task of deploying a custom theme for Office 2016 the other day. Not having done this before, I did what I always do: I searched Google for the answer. I was able to figure out where to place the theme file, so I went about my merry way packaging up the theme (along with a script to move it into place) and the fonts that were part of the them, and then I deployed it.

Today I started getting reports that the fonts were not working in the theme. It turns out that when you use custom fonts in a theme, you have to deploy a special XML file that describes those fonts. I headed back over to Google only to find out that Office 2016 on the Mac does not support the creation of themes with fonts in them. Well, it doesn’t give you an easy way to customize the fonts

Fortunately, with a little searching, I found a web site that explained how to hack together a Theme Font file: XML Hacking Font Themes. So I started off and created a new XML file to get the fonts into the theme.

The easiest thing to do, as is explained in that article, is to grab an XML file out of the app bundle:

Just grab one of those XML files and copy it to your desktop. Once you’ve done that, edit the file, replacing the font inside the <a:latin> bracket with the name of the font you need. Do this for the Major and Minor font sections, then save the file. Name the new file the name of the font you are using to make it simple to find. My completed XML file looks like this:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<a:fontScheme name="Arial" xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main"&gt;
<a:majorFont>
<a:latin typeface="Montserrat"/>
<a:ea typeface="" />
<a:cs typeface="" />
</a:majorFont>
<a:minorFont>
<a:latin typeface="Montserrat"/>
<a:ea typeface="" />
<a:cs typeface="" />
</a:minorFont>
</a:fontScheme>
view raw gistfile1.txt hosted with ❤ by GitHub

Now that you have your XML file and your theme, you need to place them in the correct folder. Office 2016 keeps themes inside the user’s home folder in the following path:

/Users/<user>/Library/Group Containers/UBF8T346G9.Office/User Content/

We’re going to throw the theme into the Themes folder in that path, and the font XML file will go into the Theme Fonts folder in that path:

Voila! You now have a working theme in Office 2016 that can be used in PowerPoint, Word, or Excel.

Categories: Uncategorized

Pre-Loading AWS S3 Buckets With Jamf Pro

November 4, 2017 Leave a comment

It’s been far too long and way too much has been going on. I took a new position back in February with our corporate office with the lofty goal of migrating 15,000 endpoints into a centralized Jamf Pro instance. We worked with Jamf and with our internal resources to determine where to place the infrastructure and finally settled on AWS. I’ll go into more detail in other posts because for now, I wanted to talk about sideloading packages in S3.

Most of us have dev or test environments. Ours is in AWS alongside our production environment. With the release of Jamf Pro 10 this past week, it meant it was time to upgrade our dev instances to 10. Not only do we host the servers in AWS, but we also host the distribution point for our dev instance on S3. As you may be aware, each time you create a new cloud distribution point with Jamf Pro a new S3 bucket is spun up. That’s fine, but what if you have a bunch of test packages already in a dev S3 bucket that you want to use? That’s where I found myself this evening, and I figured out how to move those into the new S3 bucket that Jamf Pro created.

After spinning up your new Jamf Pro servers and creating your S3 bucket in Jamf Pro, head over to the AWS Console to manage your S3 buckets. Locate your original bucket and select all of the files in the bucket.

Next go under the More button and choose Copy.

Now go find the new bucket that was created by Jamf Pro and go under the More button in the bucket and choose Paste.

After getting the files over, we now have to tell Jamf Pro that the packages are there. Using the AWS CLI from your computer, grab a listing of your bucket:

aws s3 ls s3://<yourbucketaddress> >> ~/mypackages.txt
view raw AWS CLI LS hosted with ❤ by GitHub

Now that you’ve got a list of all packages in that S3 bucket, you’ll want to get rid of all of the extra data so that you only have the package filename. I used Excel to delete columns and combine columns if there were spaces (use the Open menu in Excel and choose “Delimited” and use Spaces as your delimiter). Once you have a clean list, save that out of Excel and then open it in your favorite text editor. TextMate is my go to for this. You’ll want to save the text out as a CSV with LF only.

We now have a clean list that we can send through a handy API script to stub out the packages in Jamf Pro. We will use the following script to import this data into the Jamf Pro server. Be sure to edit the JSS address in the script before running.

#!/bin/sh
# Name: addPackages.sh
# Date: 27 Mar 2018
# Author: Steve Wood (steve.wood@omnicomgroup.com)
# Purpose: used to stub out packages in the Jamf Pro database
# The CSV file needs to be saved as a UNIX file with LF, not CR
# Version: 1.1
# Update: 27 Mar 2018 - fixing an error in the counter
# A good portion of this script is re-purposed from the script posted in the following JAMF Nation article:
#
# https://jamfnation.jamfsoftware.com/discussion.html?id=13118#respond
#
args=("$@")
#jssAPIUsername="${args[0]}"
#jssAPIPassword="${args[1]}"
jssAPIUsername="apiuser"
jssAPIPassword="apipass"
jssAddress="https://yourserveraddress.com"
file="${args[0]}"
#Verify we can read the file
data=`cat $file`
if [[ "$data" == "" ]]; then
echo "Unable to read the file path specified"
echo "Ensure there are no spaces and that the path is correct"
exit 1
fi
totalqty=`awk -F, 'END {printf "%s\n", NR}' $file`
#Set a counter for the loop
counter="0"
duplicates=[]
echo $data
#Loop through the CSV and submit data to the API
while [ $counter -lt $totalqty ]
do
counter=$[$counter+1]
line=`echo "$data" | head -n $counter | tail -n 1`
package=`echo "$line" | awk -F , '{print $1}'`
apiData="<package><id>0</id><filename>${package}</filename><name>${package}</name></package>"
output=`curl -sS -k -i -u ${jssAPIUsername}:${jssAPIPassword} -X POST -H "Content-Type: text/xml" -d "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>$apiData" ${jssAddress}/JSSResource/packages`
echo $output
error=""
error=`echo $output | grep "Conflict"`
if [[ $error != "" ]]; then
duplicates+=($serialnumber)
fi
done
echo "The following packages could not be created:"
printf -- '%s\n' "${duplicates[@]}"
exit 0
view raw addPackages.sh hosted with ❤ by GitHub

Let’s open up terminal and run our script, feeding it our cleaned up text file.

/path/to/script/addPackages.sh <jssuser> <jsspass> /path/to/textfile.csv

That’s it. As that script runs it will add the packages to the Jamf Pro server so you don’t have to. This will help speed up the process of creating new dev instances each time.

In some of my next posts I’ll discuss how we are using the Server app on machines as distribution points, and utilizing simple scripts with LaunchDaemons to keep them in sync.

Categories: Casper, Jamf Pro, Tech

Collecting Data Using Plist Files

July 16, 2016 Leave a comment

At our recent Dallas area Casper User Group meeting, we got into a discussion around collecting data during a Casper recon. Specifically we were discussing the use of Extension Attributes to collect information about virtual machines.

Extension Attributes are a way to capture information from your systems. You can use scripts to pull information or drop downs or text boxes to store static information in the database. In the instance of collecting info about virtual machines, a script would be run on the systems during the recon to gather the information. Running a script on the system each time a recon happens can be processor heavy, depending on the data that is being gathered. For example, gathering home folder size by running “du” each time a recon happens can be taxing.

Rather than run the script each recon, you can use a policy to run the script once a week, once a month, or just one time, to gather the information you need and place it in a plist file somewhere. During the standard recon period, you can then use an Extension Attribute to read the information in that plist file. This is much less taxing on the systems than running the script during a recon.

Stash The Data

For our example, rather than run through grabbing info about virtual machines, let’s work on grabbing the home folder size for the logged on user. We will store the info in a plist file that we will stash in /Library/IT_Data.

First we need to find the logged in user name. There are plenty of ways to do this, but we’ll use the “Apple approved” method, using a Python one liner. Okay, it’s not really a one liner, it’s just built like one.

loggedInUser=`python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "\n");'`
view rawcontents.sh
view raw gistfile1.txt hosted with ❤ by GitHub

Now that we have our logged in user, we just need to find the user’s home folder and use du to grab the data. We’ll use dscl to grab the home folder location and then du to get the home folder size.

homeDir=`dscl . read /Users/$loggedInUser NFSHomeDirectory | awk '{ print $2 }'`
homeSize=`du -hs ${homeDir}`
view raw gistfile1.txt hosted with ❤ by GitHub

The next thing we need to do is to store this information into our plist file. Using the defaults command, we can write as much data as we want into the plist file, We can use different keys to store whatever data you want, and then recall it during recon by asking for those specific keys.

defaults write /Library/IT_Data/com.mycompany.homesize.plist HomeFolderSize -string "${homeSize}"
view raw gistfile1.txt hosted with ❤ by GitHub

Retrieve The Data

Now that we have the data stashed away, we just need to grab it during the recon process. To do this, we’ll use the defaults command again, to grab the data. We’ll use some variables for the folder path and the plist name, that way we can re-use this code fairly easily. We also want to make sure the file actually exists before trying to read data from it, hence the If statement.

if [[ -e ${dataFile} ]]; then
homeSize=`defaults read ${dataFile} HomeFolderSize`
fi
view raw gistfile1.txt hosted with ❤ by GitHub

Once we’ve read the data, all that’s left is to echo it out into the EA.

if [[ ${homeSize} ]]
echo "<result>${homeSize}</result>"
else
echo "<result>No Results Found</result>"
fi
view raw gistfile1.txt hosted with ❤ by GitHub

That’s All Folks

That’s pretty much all there is. Now that we know how save data to a plist and then read it back, this method could be used for any data we only need to gather once, or gather at infrequent times.

The full script to write the data and to then read the data are below.

#!/bin/bash
loggedInUser=`python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "\n");'`
homeDir=`dscl . read /Users/$loggedInUser NFSHomeDirectory | awk '{ print $2 }'`
homeSize=`du -hs ${homeDir}`
# check for our storage folder, and create if missing
if [[ ! -d "/Library/IT_Data" ]]; then
mkdir "/Library/IT_Data"
fi
defaults write /Library/IT_Data/com.mycompany.homesize.plist HomeFolderSize -string "${homeSize}"
#!/bin/bash
dataFolder="/Library/IT_Data"
dataFile="${dataFolder}/com.mycompany.homesize.plist"
if [[ -e ${dataFile} ]]; then
homeSize=`defaults read ${dataFile} HomeFolderSize`
fi
if [[ ${homeSize} ]]; then
echo "<result>${homeSize}</result>"
else
echo "<result>No Results Found</result>"
fi
Categories: Casper, Tech Tags: , , , ,

To Image or To First Boot

July 14, 2016 Leave a comment

When I first started out with the Casper Suite back in 2008, it was commonplace to create imaging configurations with their Casper Imaging tool. Drop an OS image into Casper, add in some applications in the order you want them installed, maybe a preference or two, and voila, you now have an imaging configuration for use in Casper Imaging. The next steps after that were to boot the machine you want imaged from an external source (NetBoot, USB drive, DVD, etc), run Casper Imaging, choose the configuration you want to run, and after some amount of time you’d have a machine ready to deploy.

Fast forward a few years, and more and more admins are no longer using an imaging methodology like this. Instead we’ve switched to leaving the factory operating system in place and simply adding the necessary applications and settings onto the systems. You can still utilize an imaging configuration deployed with Casper Imaging for this method, and that’s exactly how I first started with this method, but then I switched methods again, and started deploying apps and preferences with a post image, or First Boot, script.

This method, I felt, allowed me more opportunities to update the imaging process without having to touch the configuration. All I had to do was create a simple Bash script (or Python or whatever language you prefer) that would get called after Casper was done. After Casper had done it’s thing and restarted, my script would run and apply any config type items (set NTP server, time zone, etc) and then use the jamf binary to install software by calling policies.

Let’s take a look at the actual script and the LaunchDaemon I use to call it. The script in its entirety can be found on my GitHub repo here.

Script City

So the first bit of the script is just for setting up some variables and to setup logging. The script will output everything into this log file so that you can go back and troubleshoot later. If you are passing any sensitive data in the script, you may want to ship the log to a secure server and then delete it.

## Set global variables
LOGPATH='/path/to/your/logs'
JSSURL='https://<yourjssurl>&#39;
JSSCONTACTTIMEOUT=120 # amount of time to wait before timing out waiting for connection
LOGFILE=$LOGPATH/deployment-$(date +%Y%m%d-%H%M).logging #re-name to whatever name you want
VERSION=10.11.5
## Setup logging
if [[ ! -d $LOGPATH ]]; then
mkdir $LOGPATH
fi
set -xv; exec 1> $LOGFILE 2>&1
view raw gistfile1.txt hosted with ❤ by GitHub

After we’ve taken care of some of that housekeeping, we lock the screen so the end user or tech knows that we are working on the system. You can use the default lock icon that Apple uses, or you can upload your own icon and declare that in the swuIcon variable. This bit of code is not my own, but was borrowed from Mike Morales out of this JAMFNation post. Thanks Mike!

## Block the user from being able to see our trickery
## Define the name and path to the LaunchAgent plist
PLIST="/Library/LaunchAgents/com.LockLoginScreen.plist"
## set the icon
swuIcon="<set to your ICON for use on lock screen if you want>"
## Define the text for the xml plist file
LAgentCore="<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<!DOCTYPE plist PUBLIC \"-//Apple Computer//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">
<plist version=\"1.0\">
<dict>
<key>Label</key>
<string>com.LockLoginScreen</string>
<key>RunAtLoad</key>
<true/>
<key>LimitLoadToSessionType</key>
<string>LoginWindow</string>
<key>ProgramArguments</key>
<array>
<string>/System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/MacOS/LockScreen</string>
<string>-session</string>
<string>256</string>
</array>
</dict>
</plist>"
## Create the LaunchAgent file
echo "Creating the LockLoginScreen LaunchAgent..."
echo "$LAgentCore" > "$PLIST"
## Set the owner, group and permissions on the LaunchAgent plist
echo "Setting proper ownership and permissions on the LaunchAgent..."
chown root:wheel "$PLIST"
chmod 644 "$PLIST"
## Use SIPS to copy and convert the SWU icon to use as the LockScreen icon
## First, back up the original Lock.jpg image
echo "Backing up Lock.jpg image..."
mv /System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/Resources/Lock.jpg \
/System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/Resources/Lock.jpg.bak
## Now, copy and convert the SWU icns file into a new Lock.jpg file
## Note: We are converting it to a png to preserve transparency, but saving it with the .jpg extension so LockScreen.app will recognize it.
## Also resize the image to 400 x 400 pixels so its not so honkin' huge!
##echo "Creating SoftwareUpdate icon as png and converting to Lock.jpg..."
##sips -s format png "$swuIcon" --out /System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/Resources/Lock.jpg \
##--resampleWidth 400 --resampleHeight 400
cp $swuIcon /System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/Resources/Lock.jpg
## Now, kill/restart the loginwindow process to load the LaunchAgent
echo "Ready to lock screen. Restarting loginwindow process..."
kill -9 $(ps axc | awk '/loginwindow/{print $1}')
view raw gistfile1.txt hosted with ❤ by GitHub

Next we put a dummy receipt down in the JAMF Receipts folder (/Library/Application Support/JAMF/Receipts). This is so we can scope via Smart Groups to machines imaged on a certain day, if we need or want. The modelName variable uses system_profiler to grab the machine model.

TODAY=`date +"%Y-%m-%d"`
if [[ ! -d "/Library/Application Support/JAMF/Receipts" ]]; then
mkdir /Library/Application\ Support/JAMF/Receipts
fi
touch /Library/Application\ Support/JAMF/Receipts/$modelName_Imaged_$TODAY.pkg
view raw gistfile1.txt hosted with ❤ by GitHub

After this, we get into setting system preferences like time servers and such. Rather than post all of the code, I’m going to point out a few key blocks. Like this one for enabling Location Services:

### Enable Location Services to set time based on location
/bin/launchctl unload /System/Library/LaunchDaemons/com.apple.locationd.plist
uuid=`ioreg -rd1 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}'`
/usr/bin/defaults write /var/db/locationd/Library/Preferences/ByHost/com.apple.locationd.$uuid \
LocationServicesEnabled -int 1
/usr/sbin/chown -R _locationd:_locationd /var/db/locationd
/bin/launchctl load /System/Library/LaunchDaemons/com.apple.locationd.plist
# set time zone automatically using current location
/usr/bin/defaults write /Library/Preferences/com.apple.timezone.auto Active -bool true
####
view raw gistfile1.txt hosted with ❤ by GitHub

UPDATE: With Apple’s continuing security stance and the introduction of SIP, it is no longer possible to set the Location Services settings via script.

Or how about how to set the system preferences authorization to allow users access to the Network pref panel, etc:

##########################################
# /etc/authorization changes
##########################################
security authorizationdb write system.preferences allow
security authorizationdb write system.preferences.datetime allow
security authorizationdb write system.preferences.printing allow
security authorizationdb write system.preferences.energysaver allow
security authorizationdb write system.preferences.network allow
security authorizationdb write system.services.systemconfiguration.network allow
view raw gistfile1.txt hosted with ❤ by GitHub

And finally, the script checks for the location of the jamf binary file (to combat post-10.11 woes) and uses the binary to call policies. Thanks to Rich Trouton (derflounder.wordpress.com)for the code that checks for the binary location. Just copy and paste (changing policy ID and description) the policy install piece to add as many policies as you need.

# check for jamf binary
/bin/echo "Checking for JAMF binary"
/bin/date
if [[ "$jamf_binary" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ ! -e "/usr/local/bin/jamf" ]]; then
jamf_binary="/usr/sbin/jamf"
elif [[ "$jamf_binary" == "" ]] && [[ ! -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]]; then
jamf_binary="/usr/local/bin/jamf"
elif [[ "$jamf_binary" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]]; then
jamf_binary="/usr/local/bin/jamf"
fi
## JSS Policies for installing software
## Duplicate each block for the number of policies you need to run at post imaging time
/bin/echo "Installing <change to name of software>"
/bin/date
${jamf_binary} policy -id 1 # MAKE SURE TO SET TO THE CORRECT POLICY ID #
view raw gistfile1.txt hosted with ❤ by GitHub

After installing everything, run software update to install updates, remove the LaunchDaemon that controls the lock screen, and then restart the computer.

LaunchDaemon And Delivery

Now that we have our script built, we need to get it onto the system and have the system call the script. Let’s start with the LaunchDaemon. It’s a simple process to create a the file, just open up your favorite text editor (I like TextMate for writing Bash and Sublime Text for writing Python), drop in your XML and save out as a .plist file.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.yourcompany.postimage</string>
<key>ProgramArguments</key>
<array>
<string>/path/to/your/scripts/postimage_10.11.5.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
view raw gistfile1.txt hosted with ❤ by GitHub

With our script written and our LaunchDaemon ready, we just need to bundle it all up and get it into Casper. I use Packages for this part, but you can use your favorite packaging application.

I utilize a folder that I create inside of /private/var to hide all of my admin stuff, like scripts and binaries. So for this script, I would place it in this folder path I create, place the LaunchDaemon inside of /Library/LaunchDaemons, and then package it up.

Once packaged, drop your package into Casper Admin, set the priority to something low, like 5, and make sure to select “Install on boot drive after imaging”

With all of that work done, just add that to a configuration for Casper Imaging and image away. Casper Imaging will reboot the computer, at which time Casper’s first boot script will run and install any packages that were set to “Install on boot drive after imaging” and then restart the computer.

With our package installed during that process, on reboot of the computer our LaunchDaemon will take over and call our script. From there it’s just a matter of watching the paint dry until our computer is ready for us.

Final Thoughts

I’ve glossed over some things to try and shorten an overly long post. There are plenty of ways to image computers, and while this process works for me right now, it may not be your cup of tea. I’m currently looking at whether I should get rid of the system preference pieces and move that to Configuration Profiles, or if there’s some other trick to try. Either way, never stop tinkering with what you do, it’s what makes the job enjoyable and is the quickest way to learn something new.

If you’d like more information, or have a question, hit me up on the inter webs.

Categories: Uncategorized

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:

#!/bin/sh
# date: 18 Jun 2014
# Name: RDC-Connection.sh
# Author: Steve Wood (swood@integer.com)
# updated: 29 Feb 2016 - included line to add remote program to start on connection for @gmarnin
# grab the logged in user's name
loggedInUser=`/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }'`
# global
RDCPLIST=/Users/$loggedInUser/Library/Containers/com.microsoft.rdc.mac/Data/Library/Preferences/com.microsoft.rdc.mac.plist
myUUID=`uuidgen`
LOGPATH='/private/var/inte/logs'
# set variables
connectionName="NAME YOUR CONNECTION"
hostAddress="SERVERIPADDRESS"
# if you need to put an AD domain name, put it in the userName variable, otherwise leave blank
userName='DOMAINNAME\'
userName+=$loggedInUser
resolution="1280 1024"
colorDepth="32"
fullScreen="FALSE"
scaleWindow="FALSE"
useAllMonitors="TRUE"
set -xv; exec 1> $LOGPATH/rdcPlist.txt 2>&1
defaults write $RDCPLIST bookmarkorder.ids -array-add "'{$myUUID}'"
defaults write $RDCPLIST bookmarks.bookmark.{$myUUID}.label -string "$connectionName"
defaults write $RDCPLIST bookmarks.bookmark.{$myUUID}.hostname -string $hostAddress
defaults write $RDCPLIST bookmarks.bookmark.{$myUUID}.username -string $userName
defaults write $RDCPLIST bookmarks.bookmark.{$myUUID}.resolution -string "@Size($resolution)"
defaults write $RDCPLIST bookmarks.bookmark.{$myUUID}.depth -integer $colorDepth
defaults write $RDCPLIST bookmarks.bookmark.{$myUUID}.fullscreen -bool $fullScreen
defaults write $RDCPLIST bookmarks.bookmark.{$myUUID}.scaling -bool $scaleWindow
defaults write $RDCPLIST bookmarks.bookmark.{$myUUID}.useallmonitors -bool $useAllMonitors
#comment out the following if you do not need to execute a program on start of connection
# You can adjust the string to be any app that is installed.
defaults write $RDCPLIST bookmarks.bookmark.{$myUUID}.remoteProgram -string "C:\\\\Program Files\\\\\\\\Windows NT\\\\Accessories\\\\wordpad.exe"
chown -R "$loggedInUser:staff" /Users/$loggedInUser/Library/Containers/com.microsoft.rdc.mac
view raw gistfile1.txt hosted with ❤ by GitHub

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:

YosemiteVM:Preferences integer$ defaults read /Users/integer/Library/Containers/com.microsoft.rdc.mac/Data/Library/Preferences/com.microsoft.rdc.mac.plist
{
QmoteUUIDKey = "ff870b10-7e8e-47c2-98bd-f14f3f0cd1b0";
"bld_number" = 26665;
"bookmarklist.expansionStates" = {
GENEREAL = 1;
};
"bookmarkorder.ids" = (
"{2a3925d6-659e-456e-ab03-86919b30b54b}"
);
"bookmarks.bookmark.{2a3925d6-659e-456e-ab03-86919b30b54b}.fullscreenMode" = "@Variant(\177\017FullscreenMode\001)";
"bookmarks.bookmark.{2a3925d6-659e-456e-ab03-86919b30b54b}.hostname" = "termserv.company.com";
"bookmarks.bookmark.{2a3925d6-659e-456e-ab03-86919b30b54b}.label" = Test;
"bookmarks.bookmark.{2a3925d6-659e-456e-ab03-86919b30b54b}.username" = "";
"connectWindow.geometry" = <01d9d0cb 00010000 000001b4 000000a0 000003b9 0000033f 000001b4 000000fc 000003b9 0000033f 00000000 0000>;
"connectWindow.windowState" = <000000ff 00000000 fd000000 00000002 06000002 44000000 04000000 04000000 08000000 08fc0000 00010000 00020000 00010000 000e0074 006f006f 006c0042 00610072 01000000 00ffffff ff000000 00000000 00>;
lastdevinfoupd = 1456781093;
lastdevresourceupd = 1456781153;
"preferences.ignoredhosts" = (
"10.93.209.210:3389"
);
"preferences.resolutions" = (
"@Size(640 480)",
"@Size(800 600)",
"@Size(1024 768)",
"@Size(1280 720)",
"@Size(1280 1024)",
"@Size(1600 900)",
"@Size(1920 1080)",
"@Size(1920 1200)"
);
"show_whats_new_dialog" = 0;
"stored_version_number" = "8.0.26665";
tlmtryOn = 1;
}
view raw gistfile1.txt hosted with ❤ by GitHub

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:

YosemiteVM:Preferences integer$ defaults read /Users/integer/Library/Containers/com.microsoft.rdc.mac/Data/Library/Preferences/com.microsoft.rdc.mac.plist
{
QmoteUUIDKey = "ff870b10-7e8e-47c2-98bd-f14f3f0cd1b0";
"bld_number" = 26665;
"bookmarklist.expansionStates" = {
GENEREAL = 1;
};
"bookmarkorder.ids" = (
"{2a3925d6-659e-456e-ab03-86919b30b54b}"
);
"bookmarks.bookmark.{2a3925d6-659e-456e-ab03-86919b30b54b}.fullscreenMode" = "@Variant(\177\017FullscreenMode\001)";
"bookmarks.bookmark.{2a3925d6-659e-456e-ab03-86919b30b54b}.hostname" = "termserv.company.com";
"bookmarks.bookmark.{2a3925d6-659e-456e-ab03-86919b30b54b}.label" = Test;
"bookmarks.bookmark.{2a3925d6-659e-456e-ab03-86919b30b54b}.username" = "";
"bookmarks.bookmark.{2a3925d6-659e-456e-ab03-86919b30b54b}.remoteProgram" = "C:\\\\Program Files\\\\\\\\Windows NT\\\\Accessories\\\\wordpad.exe";
"connectWindow.geometry" = <01d9d0cb 00010000 000001b4 000000a0 000003b9 0000033f 000001b4 000000fc 000003b9 0000033f 00000000 0000>;
"connectWindow.windowState" = <000000ff 00000000 fd000000 00000002 06000002 44000000 04000000 04000000 08000000 08fc0000 00010000 00020000 00010000 000e0074 006f006f 006c0042 00610072 01000000 00ffffff ff000000 00000000 00>;
lastdevinfoupd = 1456781093;
lastdevresourceupd = 1456781153;
"preferences.ignoredhosts" = (
"10.93.209.210:3389"
);
"preferences.resolutions" = (
"@Size(640 480)",
"@Size(800 600)",
"@Size(1024 768)",
"@Size(1280 720)",
"@Size(1280 1024)",
"@Size(1600 900)",
"@Size(1920 1080)",
"@Size(1920 1200)"
);
"show_whats_new_dialog" = 0;
"stored_version_number" = "8.0.26665";
tlmtryOn = 1;
}
view raw gistfile1.txt hosted with ❤ by GitHub

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.

 

Custom CrashPlan Install With Casper

February 12, 2016 Leave a comment

I’m a fanboy. There, I said it and I’m proud of it. I’m a fanboy of JAMF Software’s Casper Suite. I’m also a fanboy of Code42 and their CrashPlan software. Put them together and it’s like when the two teens discovered peanut butter and chocolate as an amazing combination.

I am all about trying to minimize the amount of time my users need to be interrupted due to IT needs. That’s a large part of the reason we use Casper, so that my users do not have to be inconvenienced. Let’s face it, the more time I take performing IT tasks on their computer that cause them to not be able to work, the less money they are making for our agency. It’s one of my primary tenets of customer support: make every reasonable effort to not disturb the end user, period. So when I discovered several of my end user machines were not backing up via CrashPlan, I needed to find a way to deploy CrashPlan with as little interruption as possible. In steps Casper and CrashPlan together.

Our original setup of CrashPlan that has been running for several years, was setup using local logins. At the time when we first deployed, we were not on a single LDAP implementation, so I didn’t want to deploy an LDAP integrated CrashPlan. Fast forward to now, and we have a single LDAP (AD) and I want to take advantage of that implementation to provide “same password” logins for my users.

Fortunately JAMF has a technical paper outlining how to do this, titled Administering CrashPlan PROe with The Casper Suite. This paper was written back when CrashPlan PROe was still a thing. With the release of version 5 of CrashPlan, it has now become simply Code42 CrashPlan. This document still works for the newer version of the software.

Get The Template

The first step is to get ahold of CrashPlan custom template for the installer. Following the paper, you can download the custom template by navigating to this URL:

http://YourServerAddress:4280/download/CrashPlanPROe_Custom.zip

NOTE: If you are deploying version 5 or higher of CrashPlan, you can use this URL to download a newer version of the kit:

http://YourServerAddress:4280/download/Code42CrashPlan_Custom.zip

While there are two different URLs, you can use either one to customize your install.

Edit Away

After downloading and expanding the zip file, you will need to edit the userInfo.sh file to set some settings. First of which is to hide the application from your users during installation. Simply set the following line:

startDesktop=false
view raw gistfile1.txt hosted with ❤ by GitHub

The next thing you will want to edit are the user variables. CrashPlan uses these variables to grab the user’s short name and their home folder location. An assumption is made when it comes to the user’s home folder, and that is the assumption that the home folder lives in /Users. If your home folders do not live there, or you want to script the generation using dscl, you can. I’m lazy and so I simply went with the /Users setting.

Also, the method to grab the user short name is based on the user that is logged in currently. Now, we didn’t discuss before how you were deploying this via Casper (login, logout, Self Service, etc), but suffice it to say, it is preferable to deploy this when a user is logged in to the computer. There have been many discussions on JAMF Nation about CrashPlan and how to grab the user, I used the information found in this post to grab the info I needed:

user=`/usr/bin/defaults read /Library/Preferences/com.apple.loginwindow lastUserName`
CP_USER_HOME="/Users/$user"
userGroup=`id -gn "$user"`
CP_USER_NAME="$user"
view raw gistfile1.txt hosted with ❤ by GitHub

Now that you have the edits done, keep going through the technical paper, running the custom.sh script next to build the Custom folder we will need in a minute, and to download the installers. The custom.sh script will download the installers for Windows, Mac, and Linux, and slipstream the Custom folder into the installer package for us. In our case, since we are only concerned with the Mac installer, it places a hidden .Custom folder at the root of the DMG. We want that folder. So follow along in the tech paper to mount the Mac installer DMG and copy the .Custom folder out somewhere.

Package It All Up

We are going to need to deploy these custom settings alongside the CrashPlan installer. The tech paper has you using Composer (no surprise since it is their product), but I personally like to use Packages for my packaging fun. I’m not going to get into a discussion about what the best packaging method is, because that’s like debating which Star Trek movie was the best.

Using your method of packaging, create a package that drops that Custom folder (notice we are dropping the period so it is not hidden) into the following location:

/Library/Application Support/CrashPlan

Now that we’ve got our custom settings, we can move over to the JSS to work on our deployment. I’m going to skip discussing how to do this via Self Service, and instead stick with either a Login trigger or Recurring Check-In trigger. But first things first, go ahead and upload that custom settings package you just created into the JSS. Once it’s uploaded set the priority to something low, like 8:

 

Screen Shot 2016-02-12 at 12.05.44 PM

Create Your Policies

The tech paper discusses uploading the CrashPlan installer along with the custom properties, but I like the method that is discussed in this JAMF Nation post. It’s towards the bottom, and basically it uses curl to download the installer from the CrashPlan server. This method insures you have the latest version for your server. Of course, if you are trying to deploy to end users around the globe that may not have curl access to your CrashPlan server, uploading the installer to Casper may be your only option. For me, however, it was not.

First step is to create a new script in the JSS (or upload a script if your scripts are not stored in the database). The script itself is nothing special, it checks for the presence of the CrashPlan launch daemon, and if it is there unloads it and removes CrashPlan. Then the script continues on to install the custom properties (via a second policy) and finally installs CrashPlan:

Screen Shot 2016-02-12 at 12.14.24 PM.png

Screen_Shot_2016-02-12_at_12_28_13_PM.png

#!/bin/sh
# unload CrashPlan LaunchDaem if it exists
if [[ -e /Library/LaunchDaemons/com.crashplan.engine.plist ]]; then
launchctl unload /Library/LaunchDaemons/com.crashplan.engine.plist
/Library/Application\ Support/CrashPlan/Uninstall.app/Contents/Resources/uninstall.sh
rm -rf /Library/Application\ Support/CrashPlan
fi
# install the custom properties folder
jamf policy -event CrashInstall
# now install CrashPlan
curl http://yourserveraddress:4280/download/Code42CrashPlan_Mac.dmg > /var/tmp/CP.dmg
hdiutil attach /var/tmp/CP.dmg
installer -pkg /Volumes/Code42CrashPlan/Install\ Code42\ CrashPlan.pkg -target /
hdiutil detach /Volumes/Code42CrashPlan
rm -rf /var/tmp/CP.dmg
view raw gistfile1.txt hosted with ❤ by GitHub

As you can see, I’m using a second policy to install the custom properties. You could do everything with one policy and two scripts, or one policy and curl the custom properties from another location. The key point is that if you are removing an existing installation (like I was), you cannot install the custom properties until you are done removing the existing. Make sense?

Now that we have all of our pieces and parts up there, you will create your two policies, one to install the custom properties and the other to run the script.

To Trigger Or Not To Trigger

With your policies created, you now need to determine how you want to trigger these policies. Obviously you will need to trigger one from within the script, but what about the main policy that kicks it all off? Well, I would probably do this via a recurring check-in trigger. It keeps the user from having to wait for the policy to complete before their login completes.

Of course, you could use the login trigger and throw up a nice notification using jamfHelper, Notification Center, or CocoaDialog. That sounds like a nice post for another day.

I Didn’t Do It

I cannot take the credit for this process. It was people like Bob Gendler and Kevin Cecil on JAMF Nation, along with the folks at JAMF and Code42, that did the heavy lifting. I just put it all into one location for me to remember later.

Upgrading CrashPlan Pro to 5.1.2 on Ubuntu

February 11, 2016 Leave a comment

Since I tend to forget things the day after I do them, I’ve decided I’m going to write this one down. While I can manage my way around a LINUX install, especially Ubuntu flavors of Linux, I’m no system administrator or whiz kid by any stretch of the imagination. I tend to plunk around and can find some articles online (usually on Ask Ubuntu forums) to get done what I need. Rather than forget where I found this info, this time I decided I’m going to write it up.

The 5.1.2 upgrade to CrashPlan Pro requires Oracle Java 8 as indicated in this article. Since I run all of my Ubuntu boxes headless (they’re all VMs) I do everything the way any good UNIX head does: via the terminal. Of course, as I stated above, I’m no super user in LINUX so I take the easy way out and use package managers to do the installation, apt-get in particular since I am on Ubuntu. Unfortunately, apt does not have Oracle Java 8 as an available package. So in order for me to be able to use apt-get, I needed to first find a repository that had it.

A quick Google search led me to this article. After following the steps in the article, I had Java 8 installed and ready for the upgrade to version 5.1.2 of CrashPlan.

The next step was to make sure I had a fresh database dump from CrashPlan. Into the GUI for the CPP server to generate a dump. It’s a good idea to copy that dump file off to another server/system.

Now that we’ve backed up and we have Java installed, go ahead and download the update files. You can find the files, along with the official CrashPlan documentation here.

Finally, once you have the server upgraded, you’ll want to upgrade your client devices. You can find the official documentation here.

Categories: Tech Tags: ,

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:

#!/bin/bash
FlashVersion=$(defaults read /Library/Internet\ Plug-Ins/Flash\ Player.plugin/Contents/Info.plist CFBundleShortVersionString)
echo "<result>$FlashVersion</result>"
exit 0
view raw gistfile1.txt hosted with ❤ by GitHub

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:

#!/bin/sh
CD="/path/to/cocoaDialog.app/Contents/MacOS/cocoaDialog"
# pass the title, text, and Icon via $4, $5, $6, and timeout via $7
cdTitle=$4
cdText=$5
# what icon to use
# if no icon is given, set a default
if [[ -z "$6" ]]; then
cdIcon="/private/var/inte/icons/globeDownload.icns"
else
cdIcon=$6
fi
if [[ -z "$7" ]]; then
cdTimeout="--no-timeout"
else
cdTimeout="--timeout $7"
fi
bubble=`$CD bubble --title "$cdTitle" $cdTimeout --text "$cdText" --icon-file $cdIcon`
exit 0
view raw gistfile1.txt hosted with ❤ by GitHub

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:

touch /Library/Application\ Support/Macromedia/mms.cfg | echo "AutoUpdateDisable=1" > /Library/Application\ Support/Macromedia/mms.cfg
view raw gistfile1.txt hosted with ❤ by GitHub

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: , , ,

DFW Casper User Group Meeting April 1, 2015

April 1, 2015 Leave a comment

Here are the links to resources that were mentioned tonight at the meeting:

Rich Trouton’s blog:  http://derflounder.wordpress.com

Ben Tom’s blog:  http://macmule.com

Shea Craig’s blog:  http://labs.da.org/wordpress/sheagcraig/

Univ Utah rc.netboot fix:  http://goo.gl/xrBxa

JAMF Support GitHub:  https://github.com/JAMFSupport/

Bryson Tyrell:  https://bryson3gps.wordpress.com/

Mike Morales GitHub:  https://github.com/mm2270

JAMF Nation JNUC 2014 Playlist: https://www.youtube.com/playlist?list=PLlxHm_Px-Ie2e4a8tSFpc7JKdxYPxAS0M

My GitHub Repo:  https://github.com/stevewood-tx

IRC – there is a #jamfnation channel on the Freenode IRC server. A lot of great minds hang out on that channel during the day. While it is not a JAMF sponsored place, even a few JAMFers hang out in there occasionally. It’s a great way to get help in real time.  If you’ve never used IRC before, or it’s been a while, IRC Cloud is a great IRC app:

www.irccloud.com

Some Tools:

AutoDMG – tool for creating never before booted OS X DMG files for use in Casper or AutoCasperNBI

AutoCasperNBI – tool for creating NetBoot images

CreateUserPKG – tool for creating a package that will “install” a user on a system

AutoPKG – tool for downloading applications and updates. Utilizes recipes from the community. Can be coupled with Jenkins for automation. See my series of posts about it, starting with this one.

AutoPKGr – AutoPKG with a GUI front end, and integeration into the JSS. This tool eliminates the need to implement Jenkins

vfuse – tool for creating VMware Fusion VMs from DMG files

The presentation from tonight, minus the movies, can be downloaded from here:  https://github.com/stevewood-tx/CasperUserGroup

Music tonight was courtesy of the JNUC 2014 playlist on Spotify, put together by Mike Paul:  https://open.spotify.com/user/springfedmusic/playlist/3u1Hja1DYQHVOzvlGcWbK1

Categories: Uncategorized