www.aarondavidpolley.com
Open in
urlscan Pro
103.20.202.161
Public Scan
Submitted URL: https://aarondavidpolley.com/
Effective URL: https://www.aarondavidpolley.com/
Submission: On December 09 via api from US — Scanned from AU
Effective URL: https://www.aarondavidpolley.com/
Submission: On December 09 via api from US — Scanned from AU
Form analysis 2 forms found in the DOM
GET https://www.aarondavidpolley.com/
<form role="search" aria-label="Search for:" method="get" class="search-form" action="https://www.aarondavidpolley.com/">
<label for="search-form-1">
<span class="screen-reader-text"> Search for: </span>
<input type="search" id="search-form-1" class="search-field" placeholder="Search …" value="" name="s">
</label>
<input type="submit" class="search-submit" value="Search">
</form>GET https://www.aarondavidpolley.com
<form action="https://www.aarondavidpolley.com" method="get"><label class="screen-reader-text" for="cat">Categories</label><select name="cat" id="cat" class="postform">
<option value="-1">Select Category</option>
<option class="level-0" value="44">Artists (4)</option>
<option class="level-0" value="15">Audio Info (4)</option>
<option class="level-0" value="1">General News (39)</option>
<option class="level-0" value="17">Inspirational (2)</option>
<option class="level-0" value="16">MacAdmin (17)</option>
<option class="level-0" value="45">Music (5)</option>
</select>
</form>Text Content
Skip to the content
Search
AARON DAVID POLLEY
Musician & MacAdmin
Menu
* About
* MacAdmin
* Music
* Contact
Search
Search for:
Close search
Close Menu
* About
* MacAdmin
* Music
* Contact
Categories
General News
JNUC 2022 SESSIONS RECAP | COMPNOW INFOCHINO
* Post author By Aaron
* Post date October 28, 2022
CompNow’s QLD Engineering Manager, Aaron Polley takes you through his favourite
sessions from JNUC 2022 and what the key take aways were overall. He covers
everything from Anatomy of Mac Attack to Microsoft Integrations to dealing with
IT challenges during war. Learn more about our Apple and Jamf offering:
https://www.compnow.com.au/blog/jnuc22/ #JNUC2022 #Jamf #MacManagement
--------------------------------------------------------------------------------
Categories
MacAdmin
MDM MANAGED ADMINISTRATOR ACCOUNT
* Post author By Aaron
* Post date July 30, 2020
The tale of the macOS MDM Managed Local Administrator Account vs Jamf Management
Account
Over the years as Jamf Pro and macOS have evolved, from pre-MDM framework,
including the Casper Suite days, to the more recent evolutions of FileVault and
SecureToken, Apple is investing more and more into “non-agent” frameworks to
build on the Success of an MDM first approach in iOS.
Jamf Pro has been a fantastic tool for running policy and agent/binary based to
fill in the gaps for where MDM framework initially didn’t existing, and then
subsequent in its short comings.
The next low hanging fruit in both Apple and Jamf Pro’s evolution, around local
macOS account management, is the macOS local administrator account.
Apple have recently clearly defined the future role of the “managed
administrator account” that the MDM framework can remotely manage:
https://support.apple.com/en-au/guide/mdm/mdmca092ad96/web
Jamf Pro currently has a partial implementation of the “managed administrator
account” as part of macOS PreStage Enrollment, however there currently is no
ongoing “stateful” management of the account.
Jamf Pro does currently have a process of managing the password of Jamf Pro
Management Account found in User-Initiated Enrolment using the Jamf Pro binary
via policies.
A recent release of Jamf Pro better separated the MDM created PreStage enrolment
account and the Jamf Management Account, however, the Jamf Management Account
framework is largely one of Technical Debt in the Jamf Pro Framework.
2 Possible pathways forward:
1. Migrate the Jamf Pro Management account out of policy/binary based
management and assume the role of Apple’s “managed administrator account”.
Some of the related Jamf Admin functions will need to be deprecated and some
replaced by modern MDM features such as MDM enabled Apple Remote Desktop
management
2. Build out the MDM commands/framework for ongoing management of Apple’s MDM
“managed administrator account” and mark the Jamf Management Account as
deprecated. This would also involve replacing the Jamf Management account
under UIE with the MDM “managed administrator account” for consistency
across “Device Enrolment” and “Automated Device Enrolment” intended for
corporately owned devices. User enrolment channel being developed by Apple
will not have any management account in scope.
Which ever pathway is chosen, the messaging to Jamf Pro administrators in the
community will be to move the primary corporate admin account account on
corporately owned shared and one to one macOS devices to the MDM MDM “managed
administrator account” and have a place on the Jamf Inventory Record to manage
the password of the account as part of MDM commands and/or inventory data.
Similar to the concept of FileVault PRK and IRKs, I envision Jamf Administrators
having the ability choose a common password across all devices, configured in
one place, opted in as a default option on all macOS devices, with alternate
options for individually specified and individually auto generated (ie LAPS
concept) passwords on each computer inventory record. Auto generated, unique per
machine, as found as an option with the Jamf Management account currently,
should be a global option for the MDM “managed administrator account”.
The direction from Apple is clear and the technical debt of the Jamf Management
account is confusing for many Jamf Administrators.
Here is a Feature Request I created before I turned it into a blog post (upvote
away!):
https://www.jamf.com/jamf-nation/feature-requests/9590/macos-mdm-managed-local-administrator-account-vs-jamf-management-account
Here is a MacAdmins Community related discussion on the topic as well (non-Jamf
specific):
https://twitter.com/wikiwalk/status/1275622118324162561
* Tags administrator, JAMF, Mac, MacAdmin, macOS, MDM
--------------------------------------------------------------------------------
Categories
MacAdmin
VPP REDEMPTION CODES & APPLE SCHOOL MANAGER
* Post author By Aaron
* Post date June 2, 2020
Another interesting discussion today on the MacAdmin’s slack revealed a workflow
gap created for some schools when Apple deprecated Volume Purchasing (VPP)
Redemption Codes.
Essentially, a really horrible process could be used to buy a bunch of licenses
for an app, in the form of codes, and give them to end users to redeem.
It was superseded some time ago by Managed Distribution, championed by MDMs, to
initially assign licenses to devices, “activated” against their Apple ID. This
was later improved again by assigning directing to a device (no Apple ID
required).
This evolution saw the decline of ye old redemption codes to the point that
Apple chose to sunset it (for EDU only??) and focus on managed distribution.
This has left a gap in workflow for some schools.
Some schools were using codes as a lightweight touch to tackle the ever popular
adoption of bring your own device (BYOD), gifting apps to students to use on
their personal devices (assume wrapping up in school fees). No need to enrol a
BYO device into MDM.
With that option now gone, solidified by Apple forcing migration for the legacy
volume purchasing portal to Apple School Manager in December 2019, schools are
trying to figure out how to replace this workflow. Mass purchase of iTunes cards
is being floated.
One option, which does involve MDM, is the new user enrolment MDM channel. I
won’t go into detail here, but effectively iOS 13 and macOS 10.15 devices can
enrol into your MDM using a managed Apple ID (from ASM) and get a quarantined
slice of your device storage to install organisation content (if your MDM
supports it). The MDM can’t even see your device serial number… making its new
set of limitations a much more comfortable pill to swallow than “letting you
install an app gives you access to erase my entire personal device” level of
control.
The other option (which will be the most attractive to the redemption code
loving crowd) is Apple Configurator 2.
This article points out a nice solution for “If you want to use managed
distribution, but don’t have an MDM solution”:
https://support.apple.com/en-au/HT202995
Given you only need initial access to the device and then can revoke later as
needed, this might be a nice solution.
To Add:
https://support.apple.com/en-gb/guide/apple-configurator-2/cadbf9c811/mac
To Revoke:
https://support.apple.com/en-gb/guide/apple-configurator-2/cadeaa4649f2/mac
Let’s see if this approach gets any traction with the BYOD wrangling EDU
community.
* Tags Apple, iOS, MacAdmin, macOS, MDM
--------------------------------------------------------------------------------
Categories
MacAdmin
ADDTRUST ROOT CA EXPIRY AND MACOS
* Post author By Aaron
* Post date June 2, 2020
Update 2020-06-11: prior to May 30th I observed another symptom of this cert
expiry that I didn’t comment on originally in this post. A client I recently
worked with, who uses Aruba Clearpass to manage BYOD device onboarding to their
managed WiFi SSID, were seeing this message across their user base.
The conclusion was the user context profiles installed manually by the user via
the user driven onboarding process (which included the AddTrust root CA) were
causing macOS to warn them around 30 days out and periodically after. Device
level profiles including the same CA installed via Jamf Pro using SCEP did not
alert the user. The CA was actually not in the current/relevant trust cain, but
because it was managed via the profile, it alerted the user.
Update 2020-06-10: MacMule wrote an interesting post on the effects of this
expiry on popular MacAdmins tool AutoPkg:
https://macmule.com/2020/06/02/autopkg-curl-exit-status-60/
There have also been reports of on premise Jamf Pro environments having fallout
by way of failed binary installs. When enrolling via either Automated Device
Enrolment (DEP) or User-Initiated Enrolment the InstallApplication phase would
likely deliver the initial package/commands to download the binary but the
subsequent curl of binary components and binary enrolment will fail. This is
most obviously identified by the MDM Profile and PPPC profile being installed
but no other profiles and nothing under /usr/local/jamf (missing). The binary (&
Self Service) were not present, causing the machine to fail enrolment and be
present in the Jamf Pro web admin but marked as “unmanaged”.
Update 2020-06-03: there is a great write up with more technical detail at
https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
--------------------------------------------------------------------------------
This wonderful piece of info took off in Twitter and MacAdmins Slack today:
https://twitter.com/sleevi_/status/1266647545675210753?s=20
TLDR; The AddTrust root CA expired May 30 2020 and now OpenSSL libraries used in
tools like `curl` are struggling to recognise intermediate certs that are
cross-signed to get around expiring root issues
Your Mac will trust the cert in Safari, but curl (used to download things in
scripts) may not for example.
Why this is a problem for macOS:
https://mobile.twitter.com/sleevi_/status/1266781570108723208
It appears that macOS transition to LibreSSL as early as macOS 10.13 for some
components but the bits left effect this bug today. `nscurl` is Apple’s variant
and the basis of other tools in macOS does not seem to be affected.
Bottom line: check your scripts…. it appears I may have some work to do.
* Tags curl, MacAdmin, macOS, openssl
--------------------------------------------------------------------------------
Categories
MacAdmin
MANAGING APPLE SOFTWARE UPDATES IN MACOS
* Post author By Aaron
* Post date May 30, 2020
For those managing Apple Software Updates with Munki, Jamf Policies or other
scripted/binary/agent methods powered by the `SoftwareUpdate` binary, take note
of this post from the team behind Munki:
https://github.com/munki/munki/wiki/manual-apple-updates-in-munki-5
TLDR: we should be using MDM commands on DEP enrolled machines and/or managing
Apple software updates exclusively with configuration profiles, directing all
updates through the native macOS process in System Preferences.
Here is a Jamf Perspective, but missing the above detail on software update
binary issues:
https://docs.jamf.com/best-practice-workflows/jamf-pro/managing-macos-updates/Introduction.html
The reality is that any management system/script/etc that has historically used
the softwareupdate binary is not a viable way of running updates moving forward
(unless Apple change their trajectory, which I highly doubt).
If your org does not currently manage how System Preferences handles Apple
Updates, start. If you are not currently using Automated Device Enrollment (DEP)
or an MDM that can push Software Update commands over MDM framework, change.
Start managing your macOS System updates like iOS
--------------------------------------------------------------------------------
Update 2020-06-28: here is a more specific explanation of why the command line
installer tools have become unreliable and a possible workflow for Jamf Pro (or
similar tools) when you want to manage updates at specific intervals:
https://babodee.wordpress.com/2019/07/23/handling-macos-software-updates-with-jamf-pro/
--------------------------------------------------------------------------------
Categories
MacAdmin
MACOS SETUP ASSISTANT PREFERENCES (SKIP SCREENS)
* Post author By Aaron
* Post date April 7, 2020
As I have recently discussed with some of my colleagues, there have been some
inconsistencies over the years managing the Setup Assistant experience on macOS
when new users login. Lets talk about 2 ways many know to manage this:
* DEP Enrolment Profile, choosing items to Skip (such as a Jamf Pro PreStage
Enrolment Profile)
* Manual Profiles Created by the MacAdmins community, like these:
* https://github.com/rtrouton/profiles/tree/master/SkipDarkorLightAppearance
* https://github.com/rtrouton/profiles/tree/master/SkipDataAndPrivacy
* https://github.com/rtrouton/profiles/tree/master/SkipScreenTimeSetup
* https://github.com/rtrouton/profiles/tree/master/SkipSiriSetup
* https://github.com/rtrouton/profiles/tree/master/SkipTouchIDSetup
* https://github.com/rtrouton/profiles/tree/master/SkipiCloudSetup
Here are the 3 issues I have encountered:
* All items being skipped for a new user login on a pre-configured computer,
but the setting up your Mac screen still being displayed
* All except a couple items being skipped for a new user login on a
pre-configured computer, even though we “ticked all the skip options in the
DEP Enrolment Profile”
* Deploying the community sourced custom profiles above but only some of them
work/don’t skip everything
Given I have been victim of all these scenarios I thought it was time to take a
closer look.
First, to Apple’s documentation:
https://developer.apple.com/documentation/devicemanagement/setupassistant
Stand out observations:
* There are 8 preferences keys for skipping items
* The profiles above only refer to 6/8, with one key per profile
* Documentation and the community profiles both refer to the PayloadType
needing to be com.apple.SetupAssistant.managed
* Custom Settings Profiles from Jamf use com.apple.ManagedClient.preferences
for the PayloadType when managing app preferences like those of Microsoft
Office
So from this hit list of info, we see that our community profiles may be letting
us down, possibly adding to one of our other issues we see as well.
Digging a bit further, I uploaded SkipiCloudSetup.mobileconfig to my test Jamf
Pro and then re-downloaded and unsigned a copy of it to see if what I uploaded
matched which I got back, it did’t. The important bits:
* PayloadType was still com.apple.SetupAssistant.managed
* SkipCloudSetup preference key was still there, but instead of being TRUE, it
was FALSE
* SkipSiriSetup preference key magically joined it in the profile and was also
FALSE
Looks like best practice for making sure Jamf doesn’t mess with your custom
config profile by Signing/Encrypting it before upload still applies:
https://www.jamf.com/jamf-nation/articles/648/deploying-custom-configuration-profiles-using-jamf-pro
This will undoubtedly be causing a bunch of issues and confusing things to no
end, summary on custom profiles:
* Custom profiles we often refer to don’t include all the keys
* When they are uploaded to Jamf as is, unencrypted, they may not end up on the
computer the way they started and therefore not work
So where does this leave us for the other 2 issues? A few simple thoughts:
* macOS changes as point releases come, so the behaviour of the Skip preference
keys change, and new keys have been added over the last few major releases
* If the MDM deploys DEP Enrolment Profiles with the Skip items included for
High Sierra, and then machine over its life is upgraded to Catalina, that
profile is never re-installed to include the latest Skip items, even if the
MDM has added them into the product. ts a one off set of settings that
doesn’t change until the device is wiped or intentionally un-enrolled and
re-enrolled
* In the same thought, the checkboxes we see in a Jamf PreStage do not mirror
the preference keys in Apple’s documentation so likely these have changed and
evolved over time and the behaviour of what is linked to what has changed.
Jamf may be deployed deprecated Skip keys for some items, for example,
satisfying all of the requirements but not quite 100% causing the “setting up
your mac” screen to display as it tidies up the loose ends, especially if the
user hasn’t logged in since an OS update
With all of this considered, it looks like deploying a set of managed setup
assistant preferences to all machines ON TOP of the DEP Profile is desired to
you want to be 100% sure the machine experience is what you intend.
HERE IS WHERE WE GO OFF DOCUMENTATION…
As I said before, the PayloadType for these preferences, according to Apple,
needs to be different to normal preference management we perform for other apps.
Testing on macOS Catalina 10.15.4 and 10.15.5b, here is what I have found:
Create a plist with all of the preference keys, upload it into a NEW Jamf Pro
file into the Custom App Settings payload, and it works!
defaults write ~/Downloads/com.apple.SetupAssistant.managed.plist SkipAppearance
-bool truedefaults write ~/Downloads/com.apple.SetupAssistant.managed.plist
SkipCloudSetup -bool true
defaults write ~/Downloads/com.apple.SetupAssistant.managed.plist
SkipiCloudStorageSetup -bool true
defaults write ~/Downloads/com.apple.SetupAssistant.managed.plist
SkipPrivacySetup -bool true
defaults write ~/Downloads/com.apple.SetupAssistant.managed.plist SkipSiriSetup
-bool true
defaults write ~/Downloads/com.apple.SetupAssistant.managed.plist SkipTrueTone
-bool true
defaults write ~/Downloads/com.apple.SetupAssistant.managed.plist SkipScreenTime
-bool true
defaults write ~/Downloads/com.apple.SetupAssistant.managed.plist
SkipTouchIDSetup -bool true
plutil -convert xml1 ~/Downloads/com.apple.SetupAssistant.managed.plist
As long as the Preference Domain is set as com.apple.SetupAssistant.managed and
the uploaded property list file displays as such, were good
{SkipScreenTime=true, SkipTouchIDSetup=true, SkipAppearance=true,
SkipPrivacySetup=true, SkipCloudSetup=true, SkipSiriSetup=true,
SkipTrueTone=true, SkipiCloudStorageSetup=true}
What happens in the background, is we get a profile with a PayloadType of
com.apple.ManagedClient.preferences with sub items of:
* Key: com.apple.SetupAssistant.managed
* Dictionary -> Key: Forced
* Dictionary -> Key: mcx_preference_settings
* All sub preference keys we expect below that
As we are now delivering this as a FORCED MCX Preference for the Machine and
therefore ALL existing AND new users, rather than a “set once” config per
machine that MIGHT deliver to all users, this should give a more consistent
experience in theory.
Its contrary to Apple’s explicit documentation, but in line with their overall
ManagedPreferences
framework: https://developer.apple.com/documentation/devicemanagement/managedpreferences
As I said, I have tested this flow and it works as expected with new users
created after the profile was installed from a UIE/UAMDM Jamf configuration on
10.15.4/5 as well as a DEP configuration on 10.15.4/5.
Testing today on 10.15.5, having ONLY the DEP Profile with everything skipped
resulted in the Setting Up Your Mac screen for a new user login. Applying my
profile created with the attached plist from my example commands above,
dismissed the Setup screen entirely on first login.
CONCLUSION
Use your DEP profile to set your desired 1st user experience for Setup Screens
and use the Custom Profile (type com.apple.ManagedClient.preferences via Plist
upload in the case of Jamf) to manage it from a ManagedPreferences
engine/framework for all subsequent users that login to the Mac, keeping in mind
the timing of delivery MAY override the 1st user experience settings in the DEP
Profile (more testing to be seen on that).
Hope this is as helpful for other as it was for me.
Jamf Pro
Plist: https://gist.github.com/aarondavidpolley/9e41928c64203c6cd65ba0a02a37b77b
//Aaron
--------------------------------------------------------------------------------
Categories
General News Inspirational MacAdmin
THE POTENTIAL GOOD OF COVID-19
* Post author By Aaron
* Post date March 20, 2020
If the age of Coronavirus lasts for an extended period of time it will force a
lot of workplaces that “use computers for primary tasks” to turn all of their
processes into remote achievable ones.
In other words, those with difficulty attending a workplace (due to a physical
disability, weak immune system, geographic barrier, etc) will have access to
more jobs and new jobs than was the case before #COVID19. It’s only a theory at
this point but it’s very possible.
If a company in Sydney (read large city) removes the need for its employees to
be in its Sydney office in order to do their daily tasks, someone in Byron Bay
(read regional town) can be a full time employee working from home. It’s a very
interesting concept.
About 85% of my work since I moved to a regional area late last year is for
clients interstate that I physically don’t visit. Coronavirus has reinforced my
ability to work 24/7 from home rather than the office 1hr away and it be more
accepted (when I actually could have done it already).
Now that it’s expected (as we’ve all been told to work from home at my
employer), it’s even better as all my internal meetings have moved online and my
colleagues are more engaged to work 100% remotely, not just me. It’s awesome.
I think the outcome of this unintentional social experiment is actually going to
be very positive. People will realise all of the tasks that can actually be done
and are more efficient without physical access/contact with other
people, places, & spaces.
People will also come to better value and prioritise the things that are best
done with physical access/face to face. They will get better at doing remote
tasks well.
We will be more intentional and effective both in person and remote.
This is my hope for 2020 and COVID-19.
Stay safe
--------------------------------------------------------------------------------
Categories
MacAdmin
VMWARE AIRWATCH MUNKI IMPLEMENTATION TEARDOWN
* Post author By Aaron
* Post date April 25, 2018
Hi All,
As some of you may know, I am a big fan of ye old macOS management tool Munki.
Though NOT an MDM, it is a powerful tool for managing macOS device apps and
preferences and loved by the MacAdmins community. Please read through on the
links above if you want to know more on those…
Anyway, for those who know what all of this wonderful stuff is and are curious
on how AirWatch is using the beloved tool, read below:
AIRWATCH MUNKI IMPLEMENTATION
Core Folder:
> /Library/Application Support/AirWatch/Data/Munki/
Binary:
> /Library/Application Support/AirWatch/Data/Munki/bin/managedsoftwareupdate
Some standard install paths exist but not used; probably created by the binary
on its first run.
> /Library/Managed\ Installs/Cache
> /Library/Managed\ Installs/catalogs
> /Library/Managed\ Installs/manifests
Contents of core folder /Library/Application Support/AirWatch/Data/Munki/:
* Managed Installs
* MunkiCache
* Munki_Repo
* bin
Main preference file:
> defaults read /Library/Preferences/AirWatchManagedInstalls.plist
> {
> AppleSoftwareUpdatesOnly = 0;
> ClientIdentifier = "device_manifest.plist";
> FollowHTTPRedirects = none;
> InstallAppleSoftwareUpdates = 0;
> LastCheckDate = "2018-04-25 08:28:59 +0000";
> LastCheckResult = 0;
> LogFile = "/Library/Application Support/AirWatch/Data/Munki/Managed Installs/Logs/ManagedSoftwareUpdate.log";
> LogToSyslog = 0;
> LoggingLevel = 1;
> ManagedInstallDir = "/Library/Application Support/AirWatch/Data/Munki/Managed Installs";
> OldestUpdateDays = 0;
> PendingUpdateCount = 0;
> SoftwareRepoURL = "file:///Library/Application%20Support/AirWatch/Data/Munki/Munki_Repo/";
> UseClientCertificate = 0;
> }
Compared to normal preference file location:
> /Library/Preferences/ManagedInstalls.plist
Curiously, this is not a standard function to change which preference plist file
it reads.
The “Munki_Repo” in the plist file above is a local folder which the
binary reads as the Munki Repository (different to a tranditonal install where
that would be pointing to a remote server)
The following traditional Munki Repo folders exist:
* catalogs
* icons
* manifests
Traditional folders not present:
* pkgs
* pkgsinfo
A non traditional folder exists in the repo:
* MunkiData
MunkiData contains a munki_data.plist which appears to be their way of knowing
whats installed by them (AirWatch) and therefore knowing what to remove or not
when a device un-enrolls from management. File contents:
> <?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">
> <plist version="1.0">
> <array>
> <dict>
> <key>ComputedBundleID</key>
> <string>com.vmw.macos.Chrome</string>
> <key>ComputedBundleVersion</key>
> <string>66.0.3359</string>
> <key>ManagedTime</key>
> <date>2018-04-25T09:08:16Z</date>
> <key>RemoveOnUnenroll</key>
> <true/>
> <key>munki_version</key>
> <string>3.0.0.3335</string>
> <key>name</key>
> <string>Chrome</string>
> </dict>
> </array>
> </plist>
Here are the contents of my example manifest plist in the Munki_Repo/manifests
folder:
> <?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">
> <plist version="1.0">
> <dict>
> <key>catalogs</key>
> <array>
> <string>device_catalog.plist</string>
> </array>
> <key>managed_installs</key>
> <array>
> <string>Chrome</string>
> </array>
> </dict>
> </plist>
And the example catalog file, which includes all pkginfo :
> <?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">
> <plist version="1.0">
> <array>
> <dict>
> <key>PackageCompleteURL</key>
> <string>https://localhost:7443/Application/GoogleChrome-66.0.3359.117.dmg?url=https://cdnau02.awmdm.com/cn500.airwatchportals.com/18659/Apps/1329a943-833f-4ebf-b36e-0baeb9e58d83.dmg?token=st=1524646902~exp=1524733602~acl=/*~hmac=7fb9d93e5cae26b64a3ae09553f1314fc5971a3277445b57575e366a1844149e&size=68680725&bundleid=com.vmw.macos.Chrome</string>
> <key>RestartAction</key>
> <string>None</string>
> <key>autoremove</key>
> <false/>
> <key>catalogs</key>
> <array>
> <string>device_catalog.plist</string>
> </array>
> <key>category</key>
> <string>Software</string>
> <key>description</key>
> <string></string>
> <key>developer</key>
> <string></string>
> <key>display_name</key>
> <string>GoogleChrome-66.0.3359.117</string>
> <key>installer_item_hash</key>
> <string>8d050591d8bd465dcae2d60a8e699bce037d0ce51f5da4349eed78b626e9ce47</string>
> <key>installer_item_location</key>
> <string>GoogleChrome-66.0.3359.117.dmg</string>
> <key>installer_item_size</key>
> <string>67071</string>
> <key>installer_type</key>
> <string>copy_from_dmg</string>
> <key>installs</key>
> <array>
> <dict>
> <key>CFBundleIdentifier</key>
> <string>com.google.Chrome</string>
> <key>CFBundleName</key>
> <string>Chrome</string>
> <key>CFBundleShortVersionString</key>
> <string>66.0.3359.117</string>
> <key>CFBundleVersion</key>
> <string>3359.117</string>
> <key>minosversion</key>
> <string>10.9.0</string>
> <key>path</key>
> <string>/Applications/Google Chrome.app</string>
> <key>type</key>
> <string>application</string>
> <key>version_comparison_key</key>
> <string>CFBundleShortVersionString</string>
> </dict>
> </array>
> <key>items_to_copy</key>
> <array>
> <dict>
> <key>destination_path</key>
> <string>/Applications</string>
> <key>source_item</key>
> <string>Google Chrome.app</string>
> </dict>
> </array>
> <key>minimum_os_version</key>
> <string>10.9.0</string>
> <key>name</key>
> <string>Chrome</string>
> <key>postinstall_script</key>
> <string>#!/bin/bash
>
> open /Applications/Google\ Chrome.app
>
> exit 0</string>
> <key>unattended_install</key>
> <false/>
> <key>unattended_uninstall</key>
> <false/>
> <key>uninstall_method</key>
> <string>remove_copied_items</string>
> <key>uninstallable</key>
> <true/>
> <key>version</key>
> <string>66.0.3359.117</string>
> </dict>
> </array>
> </plist>
The thing that stands out the most above is the PackageCompleteURL key used.
Basically, the normal behaviour for items is to look in the Munki_Repo/pkgs
folder for the asset but since the repo is local, they redirect to their storage
for the actual package download. They do it via some local proxying method which
is quite interesting…
In my example above I made the item on demand (rather than auto installed) and
set a post install script to launch Chrome after it was installed (so I would
know when it happened).
In a native munki world, you would be using the Managed Software Center GUI app
to choose items that are “option installs” to install them on demand. In the
AirWatch world, the back end system is making everything a managed install when
it hits Munki, just holding it back until the user initiates it on an AirWatch
portal as we’ll see shortly.
Its also worth noting that logs and other items are located in the “Managed
Installs” folder as normal, except in the “/Library/Application
Support/AirWatch/Data/Munki/Managed Installs/“ location rather than
“/Library/Managed Installs/“
WALKING THROUGH INSTALL PROCESS
I used the “MyOrg Apps” Web shortcut the AirWatch Agent placed in my dock after
it was installed and I was taken to a portal where I could browse or search for
Apps that were assigned to me. On the front page was Chrome, so pressed to
install and confirmed.
The AirWatch agent then started to do its work (shown. by the menu bar icon
blinking) and after a minute or so Chrome launched as per my post install
script.
My web based self service app portal now shows Chrome as “installed”
COMMENTS ON PREPARATION/UPLOAD PROCESS
The other interesting thing to note in my example is when I uploaded a DMG of
the Google Chrome app into the AirWatch portal and assigned it, it asked me as
part of the upload to download and install their “VMWare AirWatch Admin
Assistant” on to my admin Mac to generate metadata.
The app basically asked for the DMG and less than a minute later spat out a
folder in ~/Documents/VMware AirWatch Admin Assistant/ with an icon, DMG with
modified name, and a plist containing the metadata the admin portal was after.
I would say in future it would be wise to run the assistant first and use the
DMG it creates as I assume it makes sure the app in question is in the root
level of the DMG as Munki prefers (different to the full path to place method
Jamf uses for DMGs for example)
FINAL THOUGHTS
Overall, this is a simple but effective implementation of Munki leveraging the
binary’s smarts but adding some integration with AirWatch systems to leverage
the entire toolkit. It will be interesting to see how this aids AirWatch’s
adoption for macOS management in the enterprise over the coming months/years.
* Tags AirWatch, macOS, Munki, VMware
--------------------------------------------------------------------------------
Categories
MacAdmin
JAMFWATCH
* Post author By Aaron
* Post date April 13, 2018
Hi All.
After being at a recent Jamf course I was inspired to create a new project
called JamfWATCH. As per GitHub:
> Jamf Pro WATCH Dog: Monitor and self heal Jamf Pro enrolment if framework is
> removed from a client computer
Basically, at both reactive and recurring intervals this tool checks if it can
communicate with the Jamf Pro Server its supposed to be managed by and if senses
an issue tried to repair itself. Great for scenarios where end users may have
admin rights and decide to do silly things like remove management from their
computer.
Check it out, test, and provide feedback!
https://github.com/aarondavidpolley/JamfWATCH
* Tags JAMF, macOS
--------------------------------------------------------------------------------
Categories
MacAdmin
SCRIPTS TO THE RESCUE
* Post author By Aaron
* Post date January 7, 2018
Hi All,
I finally got around to organising a bunch of the scripts I have used over the
last few years and put them into a more generic pool to be accessed and re-used.
Have a look at my new GitHub repo:
https://github.com/aarondavidpolley/ScriptRepo
Check them out and use whatever will help
* Tags macOS, Scripts
--------------------------------------------------------------------------------
POSTS NAVIGATION
← Newer Posts1 2 … 7 Older Posts →
* About
* MacAdmin
* Music
* Contact
RECENT POSTS
* JNUC 2022 Sessions Recap | CompNow Infochino
* MDM Managed Administrator Account
* VPP Redemption Codes & Apple School Manager
* AddTrust Root CA Expiry and macOS
* Managing Apple Software Updates in macOS
ARCHIVES
Archives Select Month October 2022 (1) July 2020 (1) June 2020 (2) May 2020
(1) April 2020 (1) March 2020 (1) April 2018 (2) January 2018 (1) November
2017 (1) October 2017 (2) July 2017 (1) October 2016 (3) March 2016 (3)
April 2014 (1) May 2013 (1) April 2013 (2) March 2013 (11) April 2012 (1)
April 2011 (2) January 2011 (1) October 2009 (1) June 2009 (1) April 2009
(1) December 2008 (1) October 2008 (1) January 2008 (1) December 2007 (2)
October 2007 (1) April 2007 (1) February 2007 (1) January 2007 (4) December
2006 (1) November 2006 (4) October 2006 (6)
CATEGORIES
Categories Select Category Artists (4) Audio Info (4) General News (39)
Inspirational (2) MacAdmin (17) Music (5)
© 2024 Aaron David Polley
Powered by WordPress
To the top ↑ Up ↑