At this point, you should probably know that if you put items in a manifest’s optional installs, it will appear to users for installation/removal on the Software tab of Managed Software Center.
You probably have also noticed that if you make an item a managed install, Managed Software Center will automatically install it, and if you make an item a managed uninstall, Managed Software Center will automatically remove it.
At some point in the future, you may want to play around with Featured Items (to not show all optional installs but only certain ones).
Something that can be a confusing to new Munki admins is the lack of managed installs appearing to users. Initially, that’s not a problem, because you are just focused on getting the managed installs installed. But then you’ll get a teacher who says “Is Flash installed on my Mac?” And if you have Adobe Flash as a managed install, you as the Munki admin know that Flash is installed on her computer, but she has no way to verify that through Managed Software Center. If she searched for Flash in MSC, nothing would come up. This is because there are a lot of managed installs that you wouldn’t want users to see (various .mobileconfig profiles and payload-free packages that manage settings). Ideally, as with featured items for optional installs, you’d also be able to have featured items for managed installs (to highlight to users “Yes, you have this, and it’s a mandatory installation”), but that hasn’t been a top priority for Munki development, and it’s not really a dealbreaker for Munki admins. It can just be a bit confusing at first.
Here’s something else you may notice, particularly in your early rollout of Munki—because your existing fleet probably already has software on it (maybe outdated software, since Munki hasn’t been updating it) before you set up Munki on those client machines, certain optional installs may show up as “other available updates.”
Here, for example, you can see the user already had older versions of GIMP and Handbrake installed. Instead of MSC just setting them to update, they’re listed as Other available updates. If you click the plus sign next to each, they will then be managed by Munki going forward, as you can see by checking the /Library/Managed Installs/manifests/SelfServeManifest file on the client machine.
Notice that after you click the plus signs, Munki puts them as managed installs in the SelfServeManifest. This isn’t to be confused with the managed installs for the manifest you put in the Munki repo. These are still optional installs for the client machine, but once the client has selected to install the items via MSC, those items become managed by Munki, so they’re locally managed_installs, because the user has selected to install them via MSC, so Munki will make sure they stay installed until the user decides to remove them via MSC.
“Wait,” you might be thinking, “So I have to ask my users to click the plus sign next to every single item they already installed before Munki was on their machines?” Nope. That’s where managed updates come in handy. You don’t have to make everything a managed update, but you should make everything a managed update that you want Munki to keep updated. So it’s highly likely that if you have optional installs that you want users to be able to install but you also want them to always have the latest version, you will make all of those optional installs into managed updates as well.
Incidentally, if you don’t like the default giant banners in Managed Software Center, you can replace those with your own. That has tangentially to do with manifests in that the client customization .zip file will be the name of the manifest (or site_default if you want it to apply to all clients). More details in the Client Customization section of the Munki wiki.