Munki has an option to force install by a certain date (specifically, using the force_install_after_date key), but it doesn’t do a force uninstall after a certain date.

You can make an item a managed uninstall, which means Munki will uninstall it when possible, but if that requires a logout or reboot, you don’t know when that might happen.

So to force an uninstall after a certain date, there’s a messy hack you can employ, which is to create an uninstall nopkg.

So, for example, if you want to force remove item X, you would have, of course, an item X in your repo, but you would then create a nopkg item for uninstall-X, which, when “installed” would uninstall X.

Now, this can be a bit tricky, because Munki has built-in logic for how it does its installs. For example, let’s say item X had a relationship with item Y, where item Y is an update for X. If you use Munki’s built-in installation logic to make item X a managed uninstall, Munki would know to remove item Y as well. But if you create a separate nopkg that just runs some script to remove item X, the nopkg doesn’t also necessarily know item Y is an update for item X.

Likewise, if you have item X as a managed install as well, you could have Munki fighting with itself, since it will try to install item X but also (via your hacky nopkg) install item uninstall-X. (In ordinary circumstances, make an item both a managed install and a managed uninstall would usually have Munki just keep it installed.)

But if you are careful with how you construct things, this can definitely work. I wouldn’t recommend it (better to just let managed uninstalls do its job), but if you absolutely need to remove a certain piece of software by a certain date, this can do it.

Another potential hack is to have item Z force install by that same date, and then make item X a regular managed uninstall, and when users are forced to install item Z, item X will uninstall at the same time.