Problem

Munki has the ability to force updates to install by a certain date, using the force_install_after_date flag, but what do you do when you have an older version you want enforced, but you also want to import a newer version into the Munki repo? If you have Slack 4.29 you want force-installed in two weeks, and then you import version 4.30 a week later (with the same catalogs), Munki will see that 4.30 is the highest version available, and then it will completely ignore the force_install_after_date flag in the Slack 4.29 version.

Possible workarounds

So what can you do here?

Don’t import that new version

Well, one thing you can do is just not import 4.30 and leave 4.29 as the highest version available in the repo, but maybe that’s not what you want to do. Maybe you don’t want users updating to 4.29 if 4.30 is available.

Enforce the same deadline for all apps

Another option is to just have all items with a force_install_after_date of a single day once a month. So let’s say you want Slack, Chrome, and Zoom all updated, you could just set them all to have a force_install_after_date of the last Thursday of the month, and even if the latest Chrome version comes out the last Wednesday or of the month and the latest Zoom comes out two weeks earlier, they both get enforced on that same Thursday (with Zoom just having a two-week lead-up, and Chrome having only a day).

Use an older installs array in a newer item

There’s still another approach you can take, with its own limitations (which I’ll go into later). You can import the new version but keep the old installs array.

Here’s an example…

Let’s say I have a force_install_after_date for Chrome 108.0.5359.98 of 17 March, and I have Google Chrome 96.0.4664.110 installed, Munki will then tell me I have to install Chrome 108.0.5359.98 by 17 March.

But if I keep that force_install_after_date for Chrome 108.0.5359.98, and then I import Chrome 111.0.5563.64 into the repo, and my client Mac still has Chrome 96.0.4664.110 installed, all of a sudden, 108.0.5359.98’s force_install_after_date isn’t enforced:

Here’s a small hack you can do, though: change the installs array for 111.0.5563.64 to be the installs array for 108.0.5359.98:

 <key>installs</key>
 <array>
  <dict>
   <key>CFBundleIdentifier</key>
   <string>com.google.Chrome</string>
   <key>CFBundleName</key>
   <string>Chrome</string>
   <key>CFBundleShortVersionString</key>
   <string>108.0.5359.98</string>
   <key>CFBundleVersion</key>
   <string>5359.98</string>
   <key>minosversion</key>
   <string>10.13</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>

Then add in the force_install_after_date from Chrome 108.0.5359.98 as well:


 <key>force_install_after_date</key>
 <date>2023-03-17T11:00:00Z</date>


Now, Macs with 96.0.4664.110 installed will get a force_install_after_date of 17 March again.

But Macs with 108.0.5359.98 won’t.

And if you update the Macs with 96.0.4664.110, they will update to 111.0.5563.64 instead of to 108.0.5359.98

Limitations of this approach

The obvious limitation, of course, is that—as you can see in the example above—the Macs on the newest old version (e.g., 108.0.5359.98) won’t get updated to the new version (111.0.5563.64).

The other limitation is that you can stack this only once. If you import a Chrome 112, for example, that will then override Chrome 111 (assuming they all have the same catalogs).

Acknowledgements

Thanks to folks on the MacAdmins Slack, especially Allister Banks, for bringing up this issue and a couple of potential approaches.