Migration from Munki to Casper

@georgecm12 Here are my thoughts... I hope they help.

1) Yes, but if you drag a .app to composer it will make it into a pkg or dmg for you to deploy, very easy.
2) Can be done by policy and a smart group. Policy can be set to install items based on them not existing. So the next time the computer does inventory it would re-install.
3) I have found vendor pkgs with built in scripts work well in casper as is.
4) Yes I think you would need to do this, but it is pretty easy to run a post flight script to process the xml file.
5) Smart Groups and policies will provide this functionality, it just needs to be thought out with priorities and contingencies.
6) Policies and Smart groups again. Casper just announced at the Ice-Out event they will be releasing a new patch management framework for Casper that will do all what you want. So be on the look out for that in the new versions.

AutoPkg & AutPkgr is a great way to keep up to date on patches and get them packaged for you, for quick addition to your Casper system. Watch the Ice Out presentation about the upcoming patch management.

http://www.jamfsoftware.com/resources/jamf-nation-ice-out-2015/

I am currently in the process of doing a Munki to Casper roll out....so to your points:

1) "Drag and drop" installations, i.e. a .dmg that contains an .app, that you just drag into your Applications folder to install. Currently, with Munki, I can import these as-is, with no modifications necessary. From what I've seen and been told, these would all have to be packaged as a .pkg. I have been able to do this either using this or setting up a test Mac, installing the DMG and then using Casper Composer to create the .pkg

2) "Self-healing." By this, I mean that if a user who may have admin privileges decides they want to remove a particular application (printer, etc.), Munki will automatically detect "this item that this computer should have is gone" and put it back right then and there. It sounds like to implement a similar feature in Casper, I would have to create smart groups for every application, and even then it would take an inventory report and a recurring check-in before the product is restored. User decided to delete needed app, now they have to wait until it's re-installed...not the ideal response, but we can only cater to the users so much. A smart group that maintains a group of machines that need to have specific apps installed works, yes...there is a bit of delay if the app is removed, but if you have check-in set to every 5 minutes which would then alert the JSS that the app is no longer installed and then kick of the install shouldn't be too much of a delay

3) Using a vendor-provided PKG with an administrator-written pre-install/post-install script. This is built-in to Munki; it sounds like to effectively do this with Casper, I'd have to re-package. Casper Composer will catch the process and create the new .pgk, also what is the pre-install and post install script? If they are stand alone scripts they can be uploaded into Casper and added to the policy to run before and after the pkg installs...

4) Using a vendor-provided PKG with a InstallerChoicesXML. Again, built in to Munki; I'd have to package the vendor PKG into another PKG, along with a post-install script that installs the vendor PKG along with the InstallerChoicesXML file. Again, Casper Composer is your friend :) or, as you mentioned upload each part into Casper and create a policy including all parts

5) "Dependencies." For example, SPSS requires Java to be installed first; Office 14.4.7 Update requires Office 14.1.0, which is an update for Office 14.0.0. I'm not seeing anything like that built-in to Casper. I haven't run into this myself, so can't really comment....but in my scenario, we image machines using the JAMF NetSUS which we use to then create configurations that will install anything we want on the base image, such as latest and greatest of any dependencies such as Java

6) 3rd Party Patch Management. This is basically where the client looks at the software installed, does a version comparison, checks with the server, and sees that there is an installer for a newer version, and installs it. In other words, the entire main function of Munki. I know this is a planned feature for some future version of Casper. Again, some of this can be replicated with smart groups, but it seems I'd have to create smart groups for every application I deploy, which is kind of ugly. AutoPKG, I am in the process of testing this out as well using this

Munki to Casper is not a copy and paste transition, depending how you have Munki configured you will need to re-write scripts, re-create packages and so on. I am coming from a Munki environment that was highly dependent on Ruby scripts...you are essentially recreating the environment and management processes when moving to Casper, but once that is all done the continued management will by much easier and fluid than it is with Munki.

Just my 2 cents. :)

@Carlos wrote:

once that is all done the continued management will by much easier and fluid than it is with Munki.

Worth the price of admission. ;)

I don't have anything to add regarding the transition from Munki, but If you're using installPKGfromDMG.sh referenced above by @Carlos you might run into issues where a .dmg mounts to a volume containing a space. We came across this with an Oracle installer (I think).

The solution was to modify the mountVolume line to use tab as field separator, then it parses the full mount path, - including spaces. Hope this helps.

mountVolume=`echo "$mountResult" | grep Volumes | awk -F '	' '{print $3}'`

Thanks for the responses thus far. I'm considering them all, and will continue to as I move forward.

I'll admit that #1 (drag and drop installs) is an annoyance, not a show-stopper. As pointed out, Composer will turn them into PKGs, as would a variety of tools (The Luggage, Autopkg, etc.) Each time I have to do this does add up. (@Carlos, the script you reference is for a DMG that contains a PKG. I'm referring to a DMG that contains an .app that you would just drag into the Applications folder. Thanks, though, for the pointer to the script.)

So far, from what I'm hearing, there doesn't seem to be an automatic way to implement #2. With Munki, I tell a machine that it should have products X, Y, and Z. If they aren't on there, they're put on there; if they're removed, they get put back. It's all automatic. It sounds like the closest I could come with this is to create individual smart groups for each item I want reinstalled, which to me seems very clunky by comparison. Granted, it doesn't come up much, but it is nice to have.

For #3, it sounds like this might not be an issue. I'll look further into it. Thanks.

Item #4 is, again, something that doesn't sound like it's available directly. Looking at my list of software, there's really only one major package that I use InstallerChoicesXML with. I'm going to work around this one and put this in as a feature request. As long as Casper is already natively working with packages, it doesn't seem like it should be that hard to add a GUI to allow the administrator to use InstallerChoicesXML.

Item #5 is the one that really hurts me having to go to significant work to reproduce what is built into Munki. I heavily use dependencies in my current workflow. The idea of having to create tons of smart groups to try and replicate this functionality seems, right now, to be almost an insurmountable task.

As noted, I understand #6 is coming, and yeah, I appreciate that they "teased" it at Ice Out, but the uncertainty of when it is coming (and what state it will be in it's initial implementation) makes me nervous.

I am going to take a little bit, then dive back in and see if what I'm getting from Casper is worth giving up what I miss from Munki. Right now, it doesn't feel like it will be, but we'll see.

@georgecm12 the beauty of Casper is that it is not the only solution, nor is it a tool that locks you out of other tools. So if Casper cannot meet the needs, use it in combination with Munki, unless you have a directive at your organization that says you cannot do this. Your migration does not have to be an all or nothing proposition.

As far as #5 goes, you could build your app deployment policies with the dependencies already in the policy. Of course with apps like Office you wouldn't want to deploy 14.1 all over again every time you deploy a new 14.x patch. However things like Java could be re-installed if necessary. Otherwise, you could solve it with Smart Groups and scoping of policies. You could also use a script, or series of scripts, that checks for the proper version dependencies and calls a policy to install the proper dependencies before installing what you want. A case statement, for example, would work great. Perhaps something along these lines:

if $officeVersion < 14.1 then;
   jamf policy -trigger officeSP1patch
else
   jamf poicy -trigger patchOffice
fi

That is, of course, just pseudo code, but you get the idea.

I am not running 9.72, so I cannot speak to the problems you are having with AutoPKGr, but I can tell you that it is a great tool and works flawlessly for me.

Anyway, just my 2 cents.

Why are you interested in migrating away from Munki? What features does it lack?

I'm with @adamcodega If you already have a mature install of munki, perhaps you are better off at looking at what you are missing that Casper provides... I would suggest its not much. Perhaps invest some time/resources in adding features or taking advantages of features that already exist with Munki.

The thing with Casper is that its an easy entrance to mac management. However the more complex or large scale your environment is, the more complex the solution you need to create. I've found that Munki gives me more flexibility in this regard.
However you could do it all in Casper as well. But if you end up creating super complex scripts and policies what benefit is there really? Might as well do the same thing with pkginfo's in Munki

once that is all done the continued management will by much easier and fluid than it is with Munki.

I disagree

munkiimport /path/to/firefox.app

Client gets new firefox version on next munki run. (if they have firefox as an application listed in their manifest)

Casper doesn't even come anywhere near to this.

Don't get me wrong, Casper is great. BUT it has some big workflow issues (Software Deployment/Patch Management) and its not in anyones interests to sweep them under the rug.

I disagree with so much on this list. Munki is far easier than Casper on all the items listed by Georgecm12

1) Drag and drop on Munki is literally that. Except for pkgs, Casper needs to repackage it everything through composer.
2) This cannot be done with policies, unless you write and insane policy to check for multiple points or have the policy call a script. All of which is not in the policy but a different area. Casper likes to spread out.
3) Casper can do this but requires a script to be written in another area and then put into the policy. Not all together and clean.
4) I don't think Casper does this at all. You have to run it through composer again and capture the install. Not ideal because you loose the devs scripts.
5) If you love extra work and complicated policies and management and delayed disjointed updates, yes, totally possible. 6) Again, love work? Totally! The new patch management doesn't work well yet and doesn't do this. Maybe someday. In the meantime, lots of policies and lots and lots of management. If your going Casper, maybe keep some Munki.

Or better yet, stay with Munki.

As mentioned, use both if you can. Let Munki handle Autopkg and 3rd party patching, plus some of those stubborn installs

We're now 18 months later. I wonder what the OP's standpoint is at this moment. And also if any of the arguments are maybe solved or enhanced by JAMF.

@mattiasvdm not sure if you are aware, but this has become jamJAR