At the 2017 MacAdmins Conference at Penn State University, Adobe recently announced some upcoming changes to their IT-focused packaging tools. Some of these changes will have a big effect on organizations using AutoPkg to automate the creation of Adobe packages.
Jamf Pro has a couple of triggers, events that cause that computer to check-in with the Jamf Pro server to run policies. Those include: Startup, Login, Logout, Network State Change, Enrollment Complete, Recurring Check-in, and Custom. You can read the description for each of those triggers by creating a new policy (you don’t have to save it) and read the descriptions for each of them in the General policy payload.
Recently, I had a situation where we wanted to run an update that’s pretty big on logout. This has the benefit of ensuring the software isn’t running. There are pros and cons to this trigger which I won’t get into here. However, one thing that I’ve always found unacceptable is the JAMF Helper HUD dialog in the bottom right corner that shows up.
I’ve submitted a feature request on JAMF Nation to improve this functionality: https://www.jamf.com/jamf-nation/feature-requests/5980/login-and-logout-policies-should-have-a-more-descriptive-message
The Jamf Pro administrator will know what the dialog means, but end users will be clueless. It’s not descriptive and quite confusing. You can try to educate your end-users on what this means, but you shouldn’t have to and naturally many of them may not remember.
I recently blogged about my upgrade process with Jamf Pro. The script I had worked well with 10.12.3. One would assume it would work well with the 10.12.4 macOS app installer as well. However it appears that Apple has removed a flag. Specifically, you can no longer specify what volume you want to target for the installation.
The command that you could use previously in 10.12.3 looked like:
"/Applications/Install macOS Sierra.app/Contents/Resources/startosinstall" --applicationpath "/Applications/Install macOS Sierra.app" --volume / --rebootdelay 30 --nointeraction
In 10.12.4, it now looks like:
"/Applications/Install macOS Sierra.app/Contents/Resources/startosinstall" --applicationpath "/Applications/Install macOS Sierra.app" --rebootdelay 30 --nointeraction
Those are just examples of some of the flags you could use. Basically they’ve removed
--volume /. All this to say I had to update my script to account for this. This led to a bunch of other code I saw that I could optimize. I have added some additional exit codes and added additional functions to reduce code re-use. The updated script can be downloaded from my GitHub repo. For instructions on how to use it, please refer to my previous blog post.
Recently there was a tweet from Hannes Juutilainen about a new tool in macOS 10.12.4 called
AssetCacheActivatorUtil. Charles Edge recently wrote a blog post on some new tools that came with the macOS 10.12.4 update. This update introduced AssetCacheActivatorUtil along with a few other related tools: AssetCache, AssetCacheLocatorUtil, AssetCacheTetheratorUtil.
The man page has some basic options on how to use this tool:
AssetCacheActivatorUtil — control the macOS caching server
The caching server built-in to macOS is deactivated by default. In its first three forms, AssetCacheActivatorUtil activates the built-in caching server, deactivates it, or reports its activation status. In its fourth form, AssetCacheActivatorUtil reports whether the built-in caching server is eligible for activation. Installing macOS Server prevents the built-in caching server from activating. In its fifth form, AssetCacheActivatorUtil reports the built-in caching server’s status.
The benefit to having this baked into macOS is that you no longer need to have the macOS Server app installed. You could take any Mac in your organization and have this service running. For example, if you have Mac Minis in conference rooms, you can have them running this service without having to place a Mac in your server room.
The first thing that came to mind was how exactly do we set the cache limit or manage any other preferences. Thanks to a tip from Clayton Burlison I was able to figure out how to set the Cache Limit.
To activate the caching service, simply enter
AssetCacheActivatorUtil activate in the command line. That’s right, no sudo required.
AssetCacheActivatorUtil will write its preferences to
/Library/Preferences/com.apple.AssetCache.plist and places its cache in
/Library/Caches/com.apple.AssetCache. You can also get certain information by running
AssetCacheActivatorUtil status. The one caveat here is that if you want to manage the preferences for the caching service, you will need to deactivate the service. Simply type,
AssetCacheActivatorUtil deactivate. Once you’ve done this, you can now write to the preference list file.
To set the caching limit simply enter a command like:
defaults write /Library/Preferences/com.apple.AssetCache.plist CacheLimit -int 15000000000 where the integer appears to be in bytes (e.g. 15000000000 bytes = 15 gigabytes). I’ve gathered this from some of the values you get when you run
AssetCacheActivatorUtil status: TotalBytesDropped, TotalBytesImported, TotalBytesReturned, TotalBytesStored, TotalBytesStoredFromOrigin, TotalBytesStoredFromPeers (these all appear towards the end if the output from this command).
There may be other keys of interest in this plist (note: there are more than these keys, but these are just the ones that stood out to me):
Key = ReservedVolumeSpace; Type = Int
Key = DataPath; Type = String
Key = LocalSubnetsOnly; Type = Bool
Key = PeerLocalSubnetsOnly; Type = Bool
Key = SavedCacheDetailsOrder; Type = Array of Strings which would seem to allow you to pick the data you want to cache: Mac Software, iOS Software, Apple TV Software, iCloud, Books, iTunes U, Movies, Music, Other
The one other thing I did test was to see the
ReservedVolumeSpace key could be higher than the
CacheLimit key. This would make sense. The ReservedVolumeSpace would be the space on the volume that you want to reserve specifically for caching and the CacheLimit would be how much of that reserved space is allocated to caching. What ends up happening if you try to make the CacheLimit key higher than ReservedVolumeSpace is that the CacheLimit will be set to equal the ReservedVolumeSpace value.
The last thing I want to note is that trying to manage these values with a configuration profile did not work in my testing. You need to write to the plist because that’s where this tool reads from.
I have not tested the the other keys, but feel free to report back in the comments what they do if you’ve tested it.
Lastly, please consider speaking to your networking team if you do decide to turn this service on. When they see so much traffic coming from one Mac, they might start to wonder what’s going on. Communication is important and no one likes surprises.
Apple is still currently testing 10.12.4 Beta 7 as of the time of this post, but they apparently have introduced a new payload preference that can be managed through a configuration profile. You can read more about this preference key publicly through their documentation (no login required). The new preference key is
allowCloudDesktopAndDocuments which accepts a boolean value. If set to
false, disallows macOS cloud desktop and document services. Defaults to
true. Available only in macOS 10.12.4 and later. For enterprises, this is a rather important preference that should have probably been released when 10.12 first released, but better late than never.
There are quite a few methods that people use to make macOS updates available to their end users. My method takes a little inspiration from those posts with a few differences. This time around I wanted to use the macOS installer app from Apple which has a neat little command line tool call startosinstall. There was no particular reason to use this method other than there were no requirements to install any particular packages post-install which you can do with a tool like createOSinstallerPKG. We had a few requirements:
- Computer has sufficient free drive space.
- User is not logged in to avoid the new iCloud Drive Document Sync feature.
- Ensure the user is plugged into a power source.
- Provide dialogs to give the user feedback such as a time estimate and dialogs on what to expect next.
- Make use of the JSS parameter to allow for customization and potential re-use for future operating systems.
JSS script parameters are a great feature that allow you to create scripts that can be flexible in the values that are gathered. I’m not sure how often they are used but suffice to say they can be very useful when you have scenarios where common commands are used repeatedly and just need variables changed. Parameter labels can also be assigned to JSS parameters as shown in Rich Trouton’s blog post. Parameter labels can also be set by going to Settings > Computer Management > Scripts > clicking on the script and selecting the Options tab. This allows you to go from the generic Parameter 4, Parameter 5, etc. and have something more descriptive like “Free Space Required” or “Custom Trigger”.
However, JSS parameters have a few limitations. Below I’ll go over some of those limitations and the associated feature requests that would address them.
It has been reported that some of the new MacBook Pros (Late 2016) have been shipping with System Integrity Protection (SIP) disabled. Apple has addressed this with the 10.12.2 update release. You can read about SIP on Rich Trouton’s blog.
There is one obvious question that comes to mind, do you trust the computers have not been compromised in shipping, especially with SIP disabled? Perhaps SIP doesn’t play as much into this question if your organization works off the assumption that you cannot trust any bits that come on the drive on new computers and they must all be wiped. After all, if someone intercepts a computer during shipping, it would be just as easy for them to disable and re-enable SIP as needed.
One thing to note here is that if you wipe and image new computers, that alone won’t re-enable SIP as that information is stored in memory. If you don’t wipe and image and instead rely on something like DEP or another no-imaging workflow, you still need to report on SIP’s status and somehow take action against computers that have it disabled to re-enable SIP.
Two ways of re-enabling SIP that come to mind: 1) boot into the Recovery Partition and re-enable SIP and 2) reset the NVRAM. The first you cannot really automate much short of asking all techs to reset PRAM on every computer coming in. The second can be done manually or via the command line. Our interest will be in doing this via the command line in order to automate this.
A year ago or so ago I discovered a bunch of computers at my previous job would drop all profiles. We could never find the cause, but what was alarming is that the JSS would report the computer as having profiles installed when in fact none are.
There two simple ways to confirm this:
sudo profiles -H
2. Open up System Preferences and see if the Profiles pref pane shows up
Unfortunately, I was never able to reproduce the issue or find the cause. Therefore I could never get any further in troubleshooting with Jamf. Fast forward a year later, through some other issues I was reporting and troubleshooting, I was able to finally reproduce the issue. The steps are real simple:
sudo rm -rf /var/db/ConfigurationProfilesin Terminal. This command will remove the profiles from the computer.
- Confirm profiles are not installed by checking System Preferences (if you had it opened, quit and reopen it) and running
sudo profiles -Hvia CLI
sudo Jamf recon -saveFormTo ~/Desktop/noProfilesInstalledin Terminal.
- Check inventory record for computer and see Profiles. How many profiles do you see?
sudo Jamf mdmin Terminal
sudo Jamf recon -saveFormTo ~/Desktop/ProfilesInstalledin Terminal.
- Check inventory record for computer and see Profiles. How many profiles do you see?
This is reproducible in the latest version of the JSS and probably goes back quite sometime since configuration profiles were supported in the JSS. For some extra data, the recon command in steps 3 and 6 should reproduce XML of all the inventory information getting collected by the Jamf binary. The jamf binary is ACCURATELY reporting whether profiles are installed. If profiles are installed the info will be enclosed in the
<ns2:configProfiles> DATA HERE </ns2:configProfiles> tags and if profiles are not installed then it will simply list
<ns2:configProfiles/>. In short, the issue is not on the jamf binary.
The implications of this are huge. Your end users could delete that directory and completely bypass configuration profile enforcement. Let’s take IBM as an example. All their users have admin access. Say they enforce filevault 2 key re-direction, some password complexity requirements, and some restrictions via profiles. Their end users could bypass all of that.
What does Jamf have to say:
Currently, the list of profiles that we see in a Computer Record is generated not through ‘Jamf recon’ or through utilizing the ‘profiles’ binary; but through the MDM command ‘ProfileList’. The MDM command would need to come from the JSS, and unfortunately, would inevitably fail considering the machine removed its MDM profile. Considering this, and what you mentioned with the need to know what profiles are currently on the client computer, what would be needed is essentially a feature within the Jamf binary framework that detects whether or not the MDM framework has been broken. And, if it is broken, repair it. In the end, an end user with admin privileges would be able to do just about anything. We have lots of customers that utilize a home brewed type of ‘self repair’ using LaunchDaemons. That too though, can be broken by an admin user.
What can you do in the meantime? Create an extension attribute. Extension attributes allow you to collect data in the JSS that is not otherwise gathered by the jamf binary. This data is collected at inventory or when you run the jamf recon command on a client. There are two that I like to use, but there are even more out there that list out ALL configuration profiles if you want to get even more granular.
#!/bin/bash profiles="$(profiles -C | wc -l)" profile_count="$(echo $profiles - 1 | bc)" if [ "$profile_count" -gt 0 ]; then echo "<result>$profile_count</result>" fi if [ "$profile_count" -le 0 ]; then echo "<result>0</result>" fi
#!/bin/bash #If profiles are on the computer it spits out: #profiles are installed on this system #otherwise: #profiles are not installed on this system profile_status="$(/usr/bin/profiles -H)" echo "<result>$profile_status</result>"
Create a smart group with the extension attribute as the criteria and then scope a policy to those groups. The policy should make use of the Files and Process payload option “Execute command”. Run the command:
to re-enable mdm on the client.
If I can create an extension attribute, what’s the problem? The JSS is supposed to report accurate inventory information for each computer client. It should be accurate up to the last recon/inventory update it did on that client. If we cannot trust the inventory records in the JSS, what good is it? Apple is the one pushing MDM and our reliance on it. Jamf is supposed to be the biggest cheerleader behind that given their quick implementation on almost all mdm/dep/vpp features that Apple introduces. However, how can we trust MDM if the JSS isn’t reporting things accurately?
You might argue: just don’t give your users admin access. Unfortunately, that’s not possible in all environments, and usually there are some exceptions that need to be made. But even so you then start getting into how far down do you lock your computers. You might argue, if the user is removing profiles, they can just remove the jamf binary altogether. Yes, this is true, but that then becomes more of an organizational policy (HR) issue than a technical (IT) issue. The problem here is with reporting and gaining insight. If someone removes the jamf binary, at least the JSS can at least run reports on the last check-in for clients based on the data the JSS has and you can trust the record is accurate. But you cannot do this by looking at the JSS profile record for clients.
I was told to submit a feature request on JAMF Nation and so I did. I encourage you to up vote it if you are a Casper/Jamf Pro customer who uses MDM / Configuration Profiles through the JSS. The data that the jamf binary collects on installed profiles should be what is reported by the JSS. Do not rely only and primarily on the mdm command “ProfileList”. Currently, the JSS does NOT even properly report anything useful or accurate on locally installed profiles either. By allowing the JSS to display what the jamf binary reports based on actual profiles installed, companies can get accurate and insightful data.
The second part of this is that, the jamf binary SHOULD re-enable MDM of course IF AND ONLY MDM isn’t supposed to be disabled from the client.
Here are the feature requests regarding locally installed profiles and scoping to config profiles which I strongly encourage you to upvote as well:
The announcement of the new MacBook Pros which only have USB-C ports will begin a frustrating, but needed transition to new devices that are USB-C capable. There’s a lot that USB-C can do, but it won’t be covered here. Here is one article I did find insightful by Stephen Foskett. I won’t try to guess how long this transition will take, but the prospect of having to only use one cable for connecting and powering devices is really exciting even if there is some initial confusion.
The purpose of this post is to get you to think about what you might need to transition with a spreadsheet linked at the end with links to the cables, adapters, and devices in question. Just note, that I have not tested and may not get to test all the devices I’ve linked in the spreadsheet. Prices may vary as well. The goal was to try and get the best value for functionality. I am also not affiliated with any of the vendors and sellers that I’ve linked to. With that all said, let’s get to the questions you should be thinking about.