Hello, and welcome to post three in this blog post series of deploying iMac's in a Lab environment. If you haven't already, I'd urge you to seriously consider going back over the first two posts, which lays the groundwork for getting here. Without it, things may not go to plan. Go on, off you trot.
Back?
Today, We're going to concentrate on preparing our environment for deploying the applications we need. There are a few ways we could do this. But, as this is all about full automation, we're going big, and with style!
DEPNotify has been part of my Staff on-boarding workflow for quite a while. It's a pretty "simple" method, and mostly used as feedback for the user to see what's happening. Although, you can do some incredibly cool stuff with it. So, where the hell do I start?
DEPNotify Package
Let's begin by getting the DEPNotify application, and making the package available on our Distribution Points. Grab the latest version from the GitLab repo and add it to your relevant DP's:
DEPNotify Script
Next, we're going to add the script required to bring all of this together in the background. Or, as Chad from Rocketman Tech infers - making the magic happen.
Chad Lawson
Previously, I've always used the DEPNotify-Starter resources from Jamf's GitHub repo. But this time, I'm going to make use of the script by Rocketman:
Rocketman-TechJust like before, we'll add the script to Jamf, and configure the options to make it easier in the future. In 6 months, are you going to remember what's supposed to go in "Parameter 5"? If so, kudos, I'm lucky if I can remember week to week.
In its current state, the script isn't really very helpful for us. We need to tell it what we want it to do. In this case, we want to install specific pieces of software. To do that, we're going to need policies for it to call on. I've got one or two that are needed …
But, let's go through a few. In keeping with the example workflow within the DEPNotify script, we'll start with some Machine Configuration.
To keep the test times short, I'm going to use two of my smaller scripts. The first is to set the device name to our standards, and the second to configure the time zone and NTP settings on the device. In the DEPNotify script, that would look like this:
## EXAMPLE WORKFLOW
##
# ## Machine Configuration
DEPNotify "Command: MainText: Configuring System Settings"
DEPNotify "Status: Setting Computer Name"
jamfCommand labzt-onboarding-setdevicename
DEPNotify "Status: Setting Computer Time Zone to UK"
jamfCommand labzt-onboarding-settimezonentpBut what about something a bit more substantial. Well, as we begin to build out what we need to deploy, we keep adding to the script:
## EXAMPLE WORKFLOW
##
# ## Machine Configuration
DEPNotify "Command: MainText: Configuring System Settings"
DEPNotify "Status: Setting Computer Name"
jamfCommand labzt-onboarding-setdevicename
DEPNotify "Status: Setting Computer Time Zone to UK"
jamfCommand labzt-onboarding-settimezonentp
#
# ## Browsers
DEPNotify "Status: Installing Microsoft Edge"
DEPNotify "Command: MainText: Starting software deployment.\n\nThis process can take up to 3-4 hours to complete."
jamfCommand labzt-onboarding-edge
sleep 3
#
# ## Office Applications
DEPNotify "Status: Installing Microsoft Office 365"
jamfCommand labzt-onboarding-office365
sleep 3
#We just keep building it up until we've got everything we require. While we're testing, let's keep it to these few simple jobs. We don't want to be waiting for hours on each test.
Now we have the script performing a few actions, we need to actually make use of it. Policy time!
Onboarding Policy
Let's create the policy to actually make use of this script. Again, this section is going to be image heavy, as it's much easier to convey all the things we're doing.
First, we'll configure the General tab. We're starting the policy name with number "10". Policies run in an alphanumerical order.
Policy Naming Tangent
You can read a discussion on this on the Jamf Nation Community forum:
It's also covered here:
Chad Lawson
Back to the Policy
Anyway, back to it.
We want this policy to run at login (see where we're going with this and the auto login?). We're also going to have this run at a recurring check-in, just in case it fails to run immediately. There's also a custom event trigger. You never know. One of the joys of deploying Apple devices is the unpredictability!
We only want this to run once per computer, especially with recurring check-in selected. Don't want to be attempting to install all the software every check-in!
So, what is it that we want this policy to actually do? First, we'll need to have it install the DEPNotify package for us.
Then, we want it to run the script to actually do something with DEPNotify. We need to set the priority to After. This will make sure the script only runs once the package installs. If we try to run it Before, it's not going to do anything as DEPNotify won't be there.
We're also going to pass the -fullScreen option, as we don't want users walking up to the devices and using them while we're trying to deploy software. We'll also set the title.
Finally, we want to scope this to the Smart Group we created in the previous post (Devices - Auto Logon Enabled) that contains devices that have auto logon enabled. This ensures that we're only targeting devices that are automatically logging on. We do not want this deploying to loads of machines when a user logs in by mistake.
Summary
While I could probably add more to this post, I think this would be a suitable break point. The next part would make this feel too long.
What did we do in this post?
- We've downloaded DEPNotify and added it to our Distribution Points
- Added the script that will deploy our software
- Made changes to the script to actually do something
- Created a new policy that will install DEPNotify, and run the DEPNotify script to install the software. This will happen at logon, or, at the next convenient check-in, if it's unable to run immediately.
If you were to run a machine through this process right now as it is, it would still give great results. You could assign it to your Lab - DEP MDM server in ASM, plug it in, and have it at the desktop with Office and Edge installed without having to put your hands on it.
In Part 4, we're going to go through the rest of our policies, and really build it out to do everything we need it to do. Along with some additional tips on really making the most of Smart Groups and another feature within Jamf Pro ;)!
Part 5, we'll complete the last few additions to finish it all off, making the device user ready.
And finally, Part 6, we'll go through a bit of a summary of everything we've done and look at how the whole process hangs together from a high level overview. If I receive any feedback, I'll also probably go through that here.
The post Photo for this post series was by Quaritsch Photography on Unsplash