London Apple Admins, Mac Admin

University of Utah MacAdmins Meeting, and Adobe’s new SDL licensing

This coming Wednesday I have the pleasure of delivering a remote session for the University of Utah MacAdmins Meeting about Adobe’s new CC 2019 and SDL licensing.

Moving out of the Pool – Adobe’s new Shared Device Licensing – Darren Wallace, dataJAR

At the end of January 2019, Adobe finally released details of their replacement for Device Pool and Serial Number licensing for Adobe CC 2019. In this presentation we will cover the changes, migration concerns and anything else that can reduce wasting time and pain (i.e. Faff) from moving from serial number to shared device based licensing like in a student lab environment.

The meet up is scheduled for Wednesday 20th February at 11AM Mountain Time (6PM GMT). More details can be found here, and the live stream here.

I’ll add the slides and links to a follow up post on the day. Thanks again to the folks at the University of Utah for the offer!

Standard
Mac Admin

Migrating Microsoft Office Suite to MAS deployment

Updated 2019.02.01

Hi All, welcome to a new blog series I’m tempted to call “Ben challenged me to…” 😉

In this post, I will outline and provide details of a possible workflow to migrate from your package installed Microsoft Office for Mac Suite Applications, to Mac App Store distribution.

Introduction

Earlier this month, Microsoft fulfilled a promise made at WWDC 2018 and released the Office Suite on the Mac App Store (MAS)! Ben (aka Mac Mule) covered the release information on his blog here.

Up until now, most Mac Admins have been deploying these Apps from the macadmins.software webpage, either directly or via AutoPKG recipes. In order to switch from these deployed installers to MAS distribution you’ll need to perform a few more steps than just trashing the old Apps and deploying the new ones!

Luckily, the team at Microsoft did an amazing job of documenting the high level steps in order to migrate those users, which can be found here.

Please Note: There are a few assumptions made with this post:

  1. Your users are licensing these Applications by logging into their Office 365 account on launch. The MAS Applications do not (currently?) support volume licensing
  2. You have bought enough Volume Purchase Program (VPP) licenses of each of the Microsoft Office Suite Macs to cover your deployment
  3. You’re familiar with running scripts and deploying MAS Apps via your management platform of choice

Overview

Let’s get stuck in!

So the core piece to take away from that KB article is the following action list:

https://docs.microsoft.com/en-us/deployoffice/mac/deploy-mac-app-store#can-i-convert-an-existing-cdn-based-office-installation-to-mac-app-store

I’m going to break this list down into sections and tackle them one at a time.

Step 1 – Close all Office apps

So, if we’re gonna be removing and redeploying these Apps, we need them not to be open, right?

You’ve a couple of options here, but the simplest is to make sure the user logs out! That way you can run any removals at the Login Window and the Apps should be closed.

Another option could be that you close the Apps for the user but there’s risk of possible data loss depending on how you do this.

Step 2 – Remove the Office apps from the /Applications folder

This one should be easy, right? Simply run a rm -R on the Application bundle.

But, in order to make sure we don’t trash possibly already installed MAS apps, we should also have a check in place. MAS Apps should contain a “_MASReceipt” directory inside the Application bundle (e.g. /Applications/Microsoft Word.app/Contents/_MASReceipt).

So for this step, and each Application, we should check for the presence of the _MASReceipt directory. If not found, we should be good to trash this.

At this time, the Applications I’ve been considering are:

  • Microsoft Excel
  • Microsoft OneNote
  • Microsoft Outlook
  • Microsoft PowerPoint
  • Microsoft Word

Step 3 – Remove the Office entries from the keychain

Good news and bad news for this step.

Good News: The team at Microsoft already have a script that can clean out the user’s Microsoft-related Keychains. This can be found here.

Bad News: This script works on the user’s keychain and so must be run:

  • When the user is logged in (and the keychain unlocked), and
  • As the logged in user (not as root, so not as a normal Jamf Policy)

The reason for this is that the original Microsoft Office for Mac Apps will add keychain entries linked to their identifier/s. When we remove and redeploy these Apps as MAS, they’ll try to access the same keychain entries but with different identifier/s, promoting the below popups to the end user

These can be a few prompts per App and isn’t a great experience for the end user! By running the NukeOffKeychain script you’ll remove these items from the user’s keychain and the new MAS Apps will create them fresh.

Interesting Note: Paul Bowden posted the below in the #microsoft-office Mac Admins Slack Channel:

https://macadmins.slack.com/archives/C07UZ1X7B/p1548463288997200

So keep an eye out for a possible update to NukeOffKeychain that’s a little less aggressive!

Step 4 – Remove the Office package registrations (pkgutil --forget)

This one is to nicely clean up the receipts left behind by the original installer packages. I mean, if we’re removing what the packages installed, we should really remove the receipts for the packages too.

This can be done via the above command (pkgutil --forget). There are various tools that can be used to figure out the receipts from a package, but as we deployed this via Munki, I pulled the information from there.

The package receipts I’ve considered for this are:

  • com.microsoft.package.Microsoft_Word.app
  • com.microsoft.pkg.licensing
  • com.microsoft.package.Microsoft_Excel.app
  • com.microsoft.package.Microsoft_OneNote.app
  • com.microsoft.package.Microsoft_Outlook.app
  • com.microsoft.package.Microsoft_PowerPoint.app

Step 5 – Trigger the MDM server to install the Office apps (such as jamf recon)

This one is a bit easier, once you’ve removed those Apps you can trigger an update in your management system of choice to initiate the installation of the MAS Apps.

For Jamf, you could scope the Apps ahead of time and trigger an Inventory Update (or a recon) to:

  • Update the device record that these Apps are no longer present
  • Trigger an MDM Inventory Update that should start pushing the MAS versions down

Bringing it all together

So, how do we bring this all together?

As part of this work, I wrote a script that can complete steps 2, 4 and 5 above. This can be found here. The list of Microsoft Apps (minus the word “Microsoft”) are loaded in at Line 25, and the full names of the package receipts at Line 28.

My suggested process would be:

  1. Scope the VPP MAS Apps to be deployed to our devices.
  2. Use the script above, triggered at logout / over the login window.
    1. This will remove the non-MAS Microsoft Apps, remove the package receipts and trigger a Jamf Recon
  3. Drop a login script, set to run once per user per device (either via Jamf, outset or a self destructing Launch Agent), that will run the NukeOffKeychain script as the user
  4. In the meantime, the MAS Apps should be pulling down onto the Mac
  5. Grab a tea / coffee / beverage of choice.

Summary and Thanks

There we go. Hopefully this will help you get some ideas on how you can migrate your users to the Microsoft MAS Apps. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

I’d also like the thank the team at Microsoft for their efforts to make these processes easier, and suppling helpful (and prompt) documentation!

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Epilogue

After being thrown this little project, wild Microsoft related puns started appearing….

Thread…


Update 2019.02.01:Adam Codega wrote a great piece on the Why (e.g. why might you switch to MAS App deployment for the Microsoft Office Suite – https://adamcodega.com/2019-02-01-not-how-but-why-microsoft-office-365-for-mac

Standard
Mac Admin

Apple IDs, MDM Servers and You!

Updated: 2018-11-08

Hi All,

As a part of my Jamf Integrator role, I find myself recommending a number of general practices when using Apple IDs and MDM solutions. I felt it was time to document these, with the result being this post.

As with most things I write here, these are my opinions and personal best practices based on my own experiences and encounters and are by no means without fault. If you see anything you don’t think is right, please reach out to me via the comments, Twitter or Slack (or indeed in person!).

Apple ID usage in an MDM Server

There are four main areas Apple IDs can used in relation to an MDM Server:

Apple Push Notification service (APNs) certificate

Probably the most common, this is the Apple ID you would use to create and renew your APNs certificate yearly.

Volume Purchase Program (VPP)

Probably the second most common, this is the Apple ID you would use with the previous VPP store (https://vpp.itunes.apple.com) to bulk buy App and Book licenses from Apple. In most cases, this has been migrated / replaced with the Apple School Manager (https://school.apple.com) or Apple Business Manager (https://business.apple.com) programs.

Device Enrolment Program (DEP)

Probably the third most common, this is the Apple ID you would use with the previous deployment portal (https://deploy.apple.com) to manage your Apple hardware auto-enrolments under the DEP program. In most cases, this has been migrated / replaced with the Apple School Manager (https://school.apple.com) or Apple Business Manager (https://business.apple.com) programs.

Managed Apple IDs (MAIDs)

The newest, and most niche Apple ID, MAIDs are used for education, allowing students who would otherwise be too young, to use Apple services and features such as Shared iPad. MAIDs are outside the scope of this post, but I hope to do a post in the future just on these!

Best Practices

And now the meat of this post, best practices and recommendations created from my own experience as well as other Mac Admins I’ve worked and / or spoken with.

APNS_Logo  APNs Apple ID

APNs certificate expiry

This Apple ID is used with your MDM server and the Apple Push Certificates Portal (https://identity.apple.com/pushcert/) to generate an APNs (or ‘push’) certificate. This in turn, is linked to your MDM enrolled devices (iOS and macOS) in order to carry out MDM tasks. These include:

  1. Deployment of profiles
  2. Deployment of VPP Apps and Books
  3. Running of MDM commands
  4. DEP enrolment (kinda)

This certificate is free to obtain and expires yearly. As there is no charge or disruption to service you can renew this certificate at any time before it expires. It must be renewed with the same Apple ID that was used to create it.

Failure to renew the certificate before it expires, or failure to use the same Apple ID, will require you to generate a new APNs certificate. As a result of this, you will need to re-enrol the MDM aspect of all devices. For Supervised iOS and macOS devices with non-removable MDM Profiles, this will necessitate a full wipe and re-enrollment!

Once you create your APNs Certificate, set a reminder in a task tracking solution and / or calendar. Double points if you do this in a team calendar so multiple people will see it. I tend to suggest stick an alert 30 days before, then a week before, then daily. Once you’ve renewed the certificate and have a new expiry date, just adjust the reminders / events.

Service Apple ID Account

In order to help with the above, create a dedicated Apple ID just for the purpose of creating and renewing the APNs certificate.

Do not use a personal Apple ID! If you, or the owner of the Apple ID leaves the company, you’ll need to create a new Apple ID, a new APNs certificate and to re-enrol the MDM aspect of all devices For Supervised iOS and macOS devices with non-removable MDM Profiles, this will necessitate a full wipe and re-enrollment!

You can create a brand new Apple ID, without any payment details by using the Apple ID web page at https://appleid.apple.com and clicking the ‘Create your Apple ID‘ option in the upper right corner. Use this new account in the Apple Push Certificates Portal when creating the APNs Certificate.

Bonus Tip: If you have multiple MDM venders (perhaps you have a test/dev and production instance, or you have separate MDM instances for iOS or macOS), you can use the same AppleID to create and renew multiple APNs certificate. Just make sure to use the ‘Notes’ box to note which is for which server!

But before that…

Use an Email Alias or Group

Don’t use your personal or individual email account for the Service Apple ID account. Create an email alias or group and use this. I’d typically suggestion something along the lines of apns@domain.com.

That way, if you (or the person who creates the APNs account and certificate) leaves, the institute or company isn’t stuck with an Apple ID they don’t have access to, and no way to renew their APNs certificate. They’ll also be stuck with anger and frustration and potentially pitchforks.

Also, Apple will email this address when the certificate reaches 30-days, 7-days and 1-day to expiry, so it’s worth setting up email forwarding rules, especially if you can link them into a ticketing system!

Multi-Multi-Factor

One key point (as highlighted by Graham Pugh in the comments) is you can add multiple mobile / cell numbers to the same Apple ID for 2 factor authentication. This would allow multiple administrators to log into a service Apple ID without resorting to not using 2 factor authentication.

A second number can be added via the same https://appleid.apple.com page.

vpp-128x128.png VPP Apple ID

VPP token expiry

This Apple ID is used with your MDM server and the VPP / Apple School Manager / Apple Business Manager portal to generate a VPP token. This in turn, is linked to your MDM solution in order to deliver VPP content such as Apps and Books. This token is free to obtain and expires yearly. As there is no charge or disruption to service you can renew this token at any time. If you’re using the previous VPP Portal, it must be renewed with the same Apple ID that was used to create it. If you’re using Apple School Manager / Apple Business Manager, then any account with access to the portal (and has the role ‘Content Manager’ or ‘admin’) can renew this.

Failure to renew the token before it expires, or failure to use the same Apple ID (VPP Portal only), will prevent you from updating or deploying any VPP content. 

You can renew this token after its expired without having to re-enrol devices!

Once you create your VPP token, set a reminder in a task tracking solution and / or calendar. Double points if you do this in a team calendar so multiple people will see it. I tend to suggest stick an alert 30 days before, then a week before, then daily. Once you’ve renewed the token and have a new expiry date, just adjust the reminders / events.

Service Apple ID Account

If you’re not using Apple School Manager or Apple Business Manager, you can only have one VPP Apple ID. As with APNs Apple IDs, make sure to use a service account, and not one tied to a specific person. If you don’t get the chance to create one as part of the setup (and you should), then feel free to create another one as detailed above under “Service Apple ID Account“.

If you are using Apple School Manager / Apple Business Manager, it is recommended to not use your own personal Apple IDs and instead to create a new one just for the purpose of accessing these portals. If need be, create a new email alias for yourself of something like asm.[name]@domain.com or abm.[name]@domain.com and use this to create a new Apple ID.

Use an Email Alias or Group

Don’t use your personal or individual email account for the Service Apple ID account (previous VPP Portal) or your access Apple ID (Apple School Manager or Apple Business Manager portal). Create an email alias or group and use this. I’d typically suggestion something along the lines of vpp@domain.com, asm.[name]@domain.com or abm.[name]@domain.com.

That way, if you (or the person who creates the VPP account) leaves, the institute or company isn’t stuck with an Apple ID they don’t have access to, and no way to renew their VPP token or make new purchases. Again, here be possible pitchforks.

Multi-Multi-Factor

One key point (as highlighted by Graham Pugh in the comments) is you can add multiple mobile / cell numbers to the same Apple ID for 2 factor authentication. This would allow multiple administrators to log into a service Apple ID without resorting to not using 2 factor authentication.

A second number can be added via the same https://appleid.apple.com page.

DEP DEP Apple ID

DEP token expiry

This Apple ID is used with your MDM server and the Deploy / Apple School Manager / Apple Business Manager portal to generate a DEP token. This in turn, is linked to your MDM solution in order to managed DEP enrolment of devices. This token is free to obtain and expires yearly. As there is no charge or disruption to service you can renew this token at any time. It can be renewed with any account with access to the portal (specific minimum account permissions TBC!) can renew this.

Failure to renew the token before it expires, will prevent you from modifying DEP information or adding new devices.

You can renew this token after its expired without having to re-enrol devices!

Once you create your DEP token, set a reminder in a task tracking solution and / or calendar. Double points if you do this in a team calendar so multiple people will see it. I tend to suggest stick an alert 30 days before, then a week before, then daily. Once you’ve renewed the token and have a new expiry date, just adjust the reminders / events.

Apple ID Account

As with all these Apple ID accounts, it is recommended to not use your own personal Apple IDs and instead to create a new one just for the purpose of accessing the Deploy / Apple School Manager / Apple Business Manager portals. If need be, create a new email alias for yourself of something like dep.[name]@domain.com and use this to create a new Apple ID.

New Terms and Conditions

At least once a year Apple release new Terms and Conditions for their Deployment service. This is typically around Autumn when new OS version are released, and occasionally in Spring with any secondary major OS release. You’ll get notified of this via email to the address configured for each Deploy / Apple School Manager / Apple Business Manager portal account.

You’ll need to log into the correct portal, review the changed T’s and C’s and agree them (if acceptable to you). If you fail to do so, you’ll be in the same position as if you let the DEP token expire, namely:

You will not be able to modify DEP information or add new devices.

Multi-Multi-Factor

One key point (as highlighted by Graham Pugh in the comments) is you can add multiple mobile / cell numbers to the same Apple ID for 2 factor authentication. This would allow multiple administrators to log into a service Apple ID without resorting to not using 2 factor authentication.

A second number can be added via the same https://appleid.apple.com page.

Summary

There we go. A long blog full of recommendation when using various Apple IDs with MDM solutions. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Update 2018-11-08

Graham Pugh left an interesting comment in this post regarding the ability to switch to another APNs certificate without having to re-enrol all devices! In his words:

It requires opening up a request ticket and supplying all the cert IDs, and it took a couple of days – so don’t leave it til they’re about to expire!

He also mentioned the ability to add 2FA to an Apple Id, but using multiple phone numbers to allow for multiple administrators to log into the same account. I’ve added this into the post above.

Standard
Mac Admin

Example LDAP mappings for Active Directory in Jamf Pro (redux)

Updated: 2018.11.14

Hi All!

I’ve started using my old LDAP mappings example blog a little more and found it is outdated in a few places. Perfect excuse to update it!

This blog post details example values I’d use when configuring the LDAP section in a Jamf Pro Server for Active Directory.

Please Note: As these are examples, your mileage may vary and you may need to change some values for your specific setup and usage.

What’s the LDAP connection used for?

The Jamf Pro LDAP connection has two use cases:

  1. Allowing the use of LDAP accounts for administration login to the Jamf Pro interface and Apps, as well as end-user login for User Initiated Enrolments
  2. Allowing the use of LDAP accounts and groups for scoping policies, profiles and VPP Apps for deployment

It’s not used for binding devices to your LDAP solution. This can be found under “Settings” > “Computer Management” > “Directory Bindings”, and are deployed through the use of policies.

Where and how should I configure the LDAP connection?

The LDAP connection is configured under “Settings” > “System Settings” > “LDAP Servers”. Occasionally, when trying to configure an AD LDAP connection in a Jamf Pro instance, I find that either the mappings aren’t correct for the environment, or the setup wizard doesn’t quite work. In this case I’ll use the manual method to configure this option, as documented by Jamf here.

Once we have the initial LDAP connection setup, go to the “Mappings” tab and we’ll start there.

User Mappings

Name Type Example / Typical Value Notes
Object Class Limitation Dropdown menu All ObjectClass values
Object Class(es) Text Box organizationalPerson, user
Search Base Text Box DC=ad,DC=dazwallace,DC=co,DC=uk Check*
Search Scope Dropdown menu All Subtrees
Attribute Mappings:
User ID		 Text Box uSNCreated Check*
Attribute Mappings:
Username		 Text Box sAMAccountName Check*
Attribute Mappings:
Real Name		 Text Box displayName Check*
Attribute Mappings:
Email Address		 Text Box mail Check*
Attribute Mappings:
Append to Email Results		 Text Box Typically left blank
Attribute Mappings:
Department		 Text Box department Check*
Attribute Mappings:
Building		 Text Box streetAddress Check*
Attribute Mappings:
Room		 Text Box physicalDeliveryOfficeName Check*
Attribute Mappings:
Phone		 Text Box telephoneNumber Check*
Attribute Mappings:
Position		 Text Box title Check*
Attribute Mappings:
User UUID		 Text Box objectGUID

 User Group Mappings

Name Type Example / Typical Value Notes
Object Class Limitation Dropdown menu All ObjectClass values
Object Class(es) Text Box group, top
Search Base Text Box DC=ad,DC=dazwallace,DC=co,DC=uk Check*
Search Scope Dropdown menu All Subtrees
Attribute Mappings:
Group ID		 Text Box uSNCreated Check* **
Attribute Mappings:
Group Name		 Text Box name Check*
Attribute Mappings:
Group UUID		 Text Box objectGUID Check*

User Group Membership Mappings

Name Type Example / Typical Value Notes
Membership Location Dropdown menu User Object
Group Membership Mapping Text Box memberOf
Append to Username When Searching Text Box Typically left blank
Use distinguished name of
user groups when searching		 Tick Box Ticked
Use recursive group searches Tick Box Ticked

Why do some notes fields show “Check*”?

This guide is full of example values, of which some may not be correct for your setup. If you’re not seeing values returned that you expect when you run the “Test” options, you’ll need to dig into your AD setup to find out why.

There are two simple methods you can use for this:

  1. You can use the built-in Directory Utility Application on a bound Mac. Ben Toms (Mac Mule!) has an old but still valid guide for this here.
  2. You can use a free app called Apache Directory Studio to probe your AD (with valid domain credentials!). Jamf have an older guide on this here.

Once you’ve got your Mappings setup, use the “Test” option to ensure the results you are seeing match your expectations.

Summary

There we go. An older blogging on example or typical LDAP AD mappings in Jamf Pro, brought up to scratch. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

UPDATE 2018.11.14

** – If you’re having your Jamf Pro Server talk to two different Domain Controllers in the same LDAP integration, check out Neil’s comment below

Standard
Mac Admin

Performing an Erase and Install of Mojave with jamJAR

Hi All.

So I’ve been a little quiet on the blogging recently. Between starting a new job and jumping two feet in, it’s been a bit of a hectic few months!

I was recently asked by my new boss (Ben, aka Mac Mule) to look into building a workflow with jamJAR to erase and install a copy of Mojave with minimal interactions. This would allow someone to deploy a ‘clean reinstall’ policy without having to use NetBoot, or the Recovery Partition.

Without further ado, let’s get to it.

Time Sensitive Information

For possible historic reason, please find the versioning of various aspects below.

  • Date: October 2018
  • Jamf: 10.7.1
  • Munki: 3.1.1.3443
  • macOS: 10.14.0

The Requirements

So the requirement was to utilise the newer feature of the ‘Install macOS Application’ (added in the ‘Install macOS High Sierra Application’ version 10.13.4) to perform an erase  and install from the command line, via the --eraseinstall option.

As discussed in a few videos and conferences, we at dataJAR utilise a mixture of Jamf Pro and Munki for software deployments / patching, called jamJAR, therefore the aim would be to use this to achieve our goal.

In case you haven’t heard of it, jamJAR leverages Jamf to write out the contents of local-only manifests for Munki which then performs most software installations and patching. This leans on the strengths of both products to provide the best solution.

Technical Requirements

To utilise this new option, there are two main requirements from a technical perspective:

1) The volume we will be targeting must be running APFS.

  • For devices running High Sierra, if they are using an SSD / Flash storage, they’ll have been converted to APFS automatically, by default.
  • For devices running Mojave, they’ll have all been converted to APFS automatically, by default.

2) You will need to use an “Install macOS High Sierra” Application that installs High Sierra 10.13.4 or newer, or Mojave.

  • For this, I have only tested the Mojave 10.14.0 process, but I don’t see why this wouldn’t work for 10.13.4+, just test in your own environment!

3) Ideal (but not required!) you’d have the device in DEP, assigned to your management solution of choice, therefore giving you an almost ‘Imaging’ workflow.

Scoping

Now as we use jamJAR, we’ll be using Jamf Pro for scoping. In our work here we purely scoped the relevant jamJAR  policy (in this case, “Add to installs” “ERASEAndInstallmacOSMojave”) to devices with an OS  “like” “10.14.”

You should set this up as required for your own environment. Perhaps you add devices to the policy manually? Perhaps you put the policy in Self Service and behind a login barrier?

For our usage, we also set the policy up as Self Service only (no triggers). This meant we could control the testing and deployment.

Forced Logout

Lastly, as we have the Munki install configured as requiring a logout, it won’t trigger automatically until someone logs out. To get around this, we added a ‘logout’ action into the same Jamf policy that will force a logout once the Munki install is cached and good to go.

How’s it look?

A little something like this, complete with some dataJAR Munki rebrand work (More info):

Please Note: This has been sped up over the slower screens. Total time from clicking ‘Go’ to rebooted back to the setup assistant is around 40 minutes. This included download time!

So what do I need to do?

So in order to get this working as intended, I had to add two keys to the pkgsinfo ?file (ERASEAndInstallmacOSMojave.plist): additional_startosinstall_options and installcheck_script:

additional_startosinstall_options

Of the two keys to add, this is the newest and the one with (arguably) the least amount of testing and documentation of all possible options. This is mostly due to how new the commands are, and how often they change / are added to.

This key is detailed in the Munki wiki here, but essentially we simply add the erase flag as show here. This is what instructs the startosinstall command to erase the disk first instead of performing an ‘in-place’ install.

installcheck_script

This key is used to change the default behaviour of Munki, detailed here. In summary, Munki will not try and install a macOS installer Application workflow if the current device is already running the same major OS version, e.g. If I add a 10.13.6 Install macOS appliance to a manifest, it won’t install on any devices running macOS 10.13.0-10.13.6. This is helpful as it’ll stop devices going through a 1 hour workflow just to update their OS, when a combo update would be better for the job.

Unfortunately, this breaks our usage above, so to get around this, I simply added a installcheck_script that runs an exit 0 which asks Munki to proceed with the install. This is shown here.

Complete pkgsinfo file

To help you get a better understanding of how the pkgsinfo file looks for the above, you can find a copy here.

Please Note: This won’t be a drop in replacement for your own one, but is more to give you an idea.

Considerations if you’re not using jamJAR

So you’re looking to role this out yourself but aren’t using jamJAR? It’s easily possible, with some considerations.

I’m using Munki…

I’m using Jamf Pro…

The folks at Jamf have a White-paper already written up for you, go check it out here.

Other associated links

Summary

Phew that was a long one! I’ve detailed how we utilise jamJAR to perform an Erase and Install of macOS Mojave, as well as some considerations if you’re not using jamJAR, but are using Munki or Jamf Pro. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Standard
London Apple Admins, Mac Admin

London Apple Admins Meetup @ Go Cardless – Talk Slides

Tonight was the London Apple Admins meetup @ Go Cardless (Thanks massively for hosting us)!.

As part of the evening I delivered a talk on Signing and De-signing Configuration Profiles.

I’ve added a copy of my slide deck below, as well as some follow-up additional reading:

 

Signing and de-signing profiles, and you.pdf

Follow-up Links:

Thanks to all those that could attend, and if you couldn’t make it, feel free to check out the video (once it’s up!)

 

Standard
Personal

Walk – Thames Path south bank – Section 2 of 4 (Plus Battersea Park)

So today’s walk was the south bank section 2, from Albert Bridge to Tower Bridge. As the walk starts from the far side of Battersea park (the opposite side of the park from the station) I got some nice park time too. The total length is listed as 6 miles (10 km).

On the way I found;

  • Battersea Park
  • Albert Bridge
  • The London Peace Pagoda
  • Battersea Power Station
  • MI6
  • Houses of Parliament (and Big Ben / Elizabeth Tower)
  • TV Presenters for Trumps visit 😑
  • London Eye
  • Namco Fun-scape (never seen that one before)
  • London South Bank (and some amusing graffiti)
  • St Paul’s Cathedral
  • Tate Modern Art Gallery
  • Shakespeare’s Globe Theatre
  • Tower Bridge

Again, this one wasn’t as long, but also wasn’t as interesting as the first walk, but better than yesterday’s one.

Pictures below

 

Standard