Thanks to a funding bid from the Mayor of London we were recently able to upgrade our key Mac teaching rooms with the latest hardware for our Media students. With it brought a foray into the brave new world of Jamf Pro for management and DEP \ MDM deployment rather than the trusty DeployStudio imaging method the college has used for many years.
This post outlines some of the new things my colleague Tristan Revell and I have learnt along the way.
Most of the setup process during our Jamf Jumpstart session went smoothly but watch out when configuring your Active Directory bind settings. The service account we used initially wouldn’t connect for love nor money and in desperation I tried making a new account, avoiding any extra characters (-, _ etc) in the username and no special characters in the password… voila it worked first time. Whether that’s a bug or standard behaviour I’m unsure as it didn’t seem to be documented anywhere as a specific requirement.
DEP deployment process
Order from a well-known reseller to ensure they add your purchases into DEP correctly. Sometimes it can take a few days (or longer) to get sorted out so plan this in early if you’re on a deadline!
Once assigned add the Macs to a PreStage Enrollment group in Jamf. Remember to select all the Macs you want to activate with DEP and then hit Save when ready to deploy.
Firewall rules
In order for DEP & MDM Enrollment to work correctly you need to ensure the Macs can contact Apple’s servers for various applications, such as
- Apple Push Notifications
- Apple Maps (to set time and date correctly during out-of-box setup)
We allow these apps out to Apple’s IP range 17.0.0.0/8 as per their documentationΒ https://support.apple.com/en-us/HT203609
Internet recovery and OS upgrade
We needed to upgrade the Macs straight out the box as they shipped with High Sierra but we wanted to start from the latest OS Mojave. Rather than install the older version and upgrade we decided to wipe and use Internet Recovery to start from a fresh copy of Mojave:
https://support.apple.com/en-gb/HT204904
The downside of Internet recovery is that it not only uses Apple’s published URLs such as osrecovery.apple.com as found at https://support.apple.com/en-gb/HT202481 but also a bunch of Akamai IPs as well π¦
At present we’re monitoring the firewall for traffic blocks when we do Internet Recovery and so far the IP-based whitelist entries we added have worked for a couple of weeks without change. However I don’t expect that to stay the case long-term and no doubt will be repeating the process at some point.
Naming machines
For reasons only known to the Jamf developers there’s no built-in functionality to name a machine when it runs through the DEP Enrollment process. The automatically-generated name created by DEP is useless to us as we rely on room-based naming for classroom management.
Fortunately there’s a workaround using a CSV file (or Google Docs if you prefer) that can do a lookup based on serial number and name the Mac to something of our choosing. We host the file internally and provide access to technicians via a network share so they can update the list as required.
https://www.macblog.org/post/automatically-renaming-computers-from-a-google-sheet-with-jamf-pro/
Just make sure you run this early on in the deployment process so the correct name gets used when binding to Active Directory (more on that later)
Splashbuddy
By default the DEP Enrollment process (and subsequent Policies) run silently in the background, not giving the best first-run impression to the user, especially if something like Adobe CC is installed as part of the process! Again the community has stepped in and written the excellent SplashBuddy tool (also check out DEPNotify if your requirements aren’t as complex)
Sachin Parmar’s blog is a fantastic guide to getting the whole process up and running
https://sachinparmarblog.com/automated-managed-mac-estate-dep-splashbuddy-part-1/
In practice the only thing we’ve found different to his steps is the order we created the components; due to naming and selecting order of deployment we found it easier to do it like this
- create DEP Policies in Jamf
- create Packages in Jamf Composer
- edit theΒ io.fti.SplashBuddy.plist file to reference the Packages named above
Apart from that the process works like a charm and looks spot on too!
I’ve took a few liberties with the screenshot below showing SplashBuddy doing its thing as I could never get a photo of a Mac looking as good as Thomas QuaritschΒ has with the ones he’s kindly uploaded for free on UnsplashΒ π
Thomas Quaritsch
We wanted to skip as many of the Setup Assistant screens as possible so ticked all the options within Computers > PreStage Enrollments but the “add user” screen still appeared. After some help via the MacAdmins Slack channel it turns out the option to skip user creation is split out into the Account Settings tab…
Dock management
One area Jamf definitely need to improve upon is management of the Dock. The built-in functionality only provides configuration of the default Apple apps, which definitely aren’t the ones we’re concerned about presenting to the user (think Adobe CC, Microsoft Office etc. instead)
We found two third-party tools that work better than the Jamf functionality, try both and see which one works for you:
Dock Master
Dock Master has an online version and a more recent local utility to help build a custom Dock layout:
http://techion.com.au/blog/2015/4/28/dock-master
https://github.com/Error-freeIT/Dock-Master
Profile Creator
In the end Tristan found another utility that he found more flexible when creating the Dock profile. It’s called Profile Creator and does exactly what it says on the tin; not just for the Dock but for numerous other settings too, such as Firefox, Chrome and many more. It’s still in beta but working well for us:
https://github.com/erikberglund/ProfileCreator
Mounting DFS shares
We’ve used Windows DFS shares under a new dedicated Namespace to store the home and shared drives for the new Macs and wanted them to auto-mount on login. Although Jamf includes built-in functionality to do something along those lines “Use UNC path from AD to get network home folder” there’s a couple of reasons we didn’t want to do this:
- we’ve been burnt by issues relating to network homes in the past and found local homes provide a more reliable experience
- we don’t currently populate the Home folder attribute in Active Directory (Folder Redirection works much better) and didn’t want to change that configuration in case of any unforeseen consequences by doing so
So instead we looked for what I thought would be a simple script to mount a share on login. That turned out to be quite a voyage of discovery!
Putting things in context
The first thing we learnt was that Jamf scripts that run at login run as root, so any scripts need to use a Jamf-defined parameter called $3 to obtain the currently logged-in user. We also found another setting that determines whether scripts run before the Finder loads or whether they can run asynchronously in the background. The latter setting helped with getting speedy login and the environment set as we wanted it.
Searching for the one
The first script we tried was created by Jamf themselves
https://www.jamf.com/jamf-nation/third-party-products/files/476/mountnetworkshare-sh-mount-a-network-share
However it seemed to struggle with reading the DFS namespace as well as mounting a dynamic path relating to the currently logged in user; for example we wanted to mount a path something like \\domain.fqdn\Mac\Home\$3 but the script either took the path very literally if entered as a Parameter or not at all if hardcoded in.
Other scripts we tried worked fine from Self Service (provided the user logs in first in order to get $3 populated by Jamf) but not at the Login Trigger. It was beginning to get a bit disheartening then we found the miracle cure!
Reading through various comments in the Jamf Nation forums turned up this gem from Samuel Look (scroll to second post from the bottom)
https://www.jamf.com/jamf-nation/discussions/29066/script-to-auto-mount-network-share-using-kerberos-authentication-on-login-macos-10-13-5
Key things it does differently to the Jamf script include
- using AppleScript rather than Bash to do the actual mount
- waiting forΒ CoreServicesUIAgent to start i.e. desktop ready before attempting to proceed
- accepts a path that can be concatenated into a variable so we can do our dynamic DFS path for the user folder
We have up to four instances of this script running, depending on the combination of user groups and shared drives we wish to mount and it’s working nicely in our environment. Within Jamf we have two copies uploaded into the Scripts repository. One is the unaltered version, which uses the first user-defined Parameter (aka $4) to define the path to mount. The other script is our adjusted version, which includes a couple of extra lines to calculate the path to the user’s DFS folder path.
The snippet is below, the hashed section should give you an idea where it sits within the script:
##### START #####
Current_User=$3
# Share_Path=$4
Share_Path="smb://domain.fqdn/Mac/Home/$3"
Replace Share_Path with your share path, placing the $3 wherever your username-specific section lies.
Configure defaults
The standard behaviour in macOS 10.12 and above is to warn the user before connecting to unknown network shares with a dialog box saying “enter your name and password for the server”.
This warning (and requirement to manually click the Connect button) prevents mapped drives from loading up silently. To fix it we configured the AllowUnknownServers option using defaults write as outlined in the Apple KB below:
https://support.apple.com/en-us/HT207112
Kerberos SSO
Another item to tick off the list was getting SSO to work correctly across all browsers. Safari worked out the box, however Firefox and Chrome need a few tweaks:
Firefox
You need to configure the following items using Profile Creator (or your tool of choice)
- network.negotiate-auth.trusted-uris
- network.automatic-ntlm-auth.trusted-uris
The syntax for the above is just the domain, with multiple entries separated by commas e.g.
yourinternaldomain.fqdn,anotherdomain.fqdn
You may also need to set this to true depending on how your server names are configured on the sites you want to SSO with
- network.negotiate-auth.allow-non-fqdn
Chrome
It’s a similar process for Chrome but slightly different settings
- AuthNegotiateDelegateWhitelist
- AuthServerWhitelist
Syntax for these is *domain.fqdn, same again with commas to separate multiple entries
*yourinternaldomain.fqdn,*anotherdomain.fqdn
Oddly our Centrify \ Office 365 SSO isn’t fully working at present in Chrome and presents an authentication screen whereas Firefox and Safari SSO correctly; however other Kerberos SSO sites work fine. Need to investigate further to see if it’s just a missing domain that needs adding for Chrome or if there’s a technical limitation somewhere.
I have seen a support page from another hosted SSO provider saying their service doesn’t work on Chrome for Mac, which does make me wonder if there’s a bug that needs fixing for this to work smoothly. Will test further when time permits.
Printing with PaperCut
Previously we used a bash script to map printers based on the name of the machine but wanted to try and stick to the native Jamf functionality going forward for ease of management. Initially that seemed simple enough; add the printer manually on a Mac in the office then use Jamf Admin to upload the printer to the server and create a Policy to map it.
However this didn’t seem to work and kept popping up authentication dialogs. Not good.
A swift bit of research brought up the fact that although you can set Kerberos Negotiate auth on the printer it doesn’t get carried over in the upload to Jamf. Therefore each printer needs the authentication configured e.g.
sudo lpadmin -p <printername> -o auth-info-required=negotiate
Fortunately there’s a handy script that can be used to set this for all printers mapped on a machine:
https://www.jamf.com/jamf-nation/discussions/4075/lion-kerberos-printing
Although no-one on the forums seems to have implemented it this way it seems to work fine running the Script as an “After” action within the print policy. Effectively meaning the printers map, then get the correct authentication settings configured immediately afterwards. Checking PaperCut on a couple of test jobs shows the user authenticated correctly and jobs are running fine.
Initially we had some issues with older HP printers e.g. Color LaserJet 4600n and it seemed they may be too old to be supported in Mojave. That seems to have settled down a bit now after updating firmware to the latest (2014!) version so we’ll see how they fare and replace if need be.
Know your Limitations
Fortunately I’m not talking about the start of a self-help speech (!) Many of our environment customisations need to be applied to particular groups; most commonly staff and students. Initially we wondered how to achieve this when Scoping Policies as it seemed to require populating JSS Groups rather than using the ones in LDAP that we use for everything else.
The trick (learnt after reading the Jamf Nation forums) is to Scope using All Computers \ All Users as required then use the Limitations tab to restrict the policy to the LDAP group(s) you desire. That method works a treat π
The finished product
With some assistance from our Marketing team we have a nice fresh background to go with the new hardware and software. The subtle grill effect is a nod to the days of the Mac G5 tower and the notice board area on the left contains useful information to remind students about backing up their work and general housekeeping.
We also rebrand Jamf Self Service to match the same “My Apps” terminology we use on our Windows 10 machines with ZENworks. Same concept, different platforms but keeps the user experience consistent.
Help and Advice
After reading Sachin’s blog post I joined up on the Mac Admins Slack channel, an excellent source of community advice with lots of members online at any time and all willing to help out. Was also good to get some experience with using Slack as a collaboration platform
Jamf Nation has lots of reference material in their forums and add-ons
https://www.jamf.com/jamf-nation/
Lastly a shout-out for our Jamf Success Managers who have been proactive at tracking us down on LinkedIn and offering assistance to make sure we get up and running, a nice touch and good customer service.
Much unboxing later (thanks go out to our work experience students for their work here) we now have all our shiny new Mac suites up and running in time for students returning from half-term π