PKG vs DMG in the world of High Sierra

I use PKG almost exclusively. We do have a small number of them, but I've never been a fan of using DMG for deployments for a number of reasons. For the few uses that DMGs provide in a Jamf workflow - for FEU and FUT - it can be scripted to provide the same type of functionality. I can count on a few fingers the number of times I've needed FEU or FUT and just as few fingers the number of DMGs we have on our shares because of that.

Thank you @mm2270 that was my thought too. I guess I am creature of habit. When you start something and build workflows in one direction, one has to stop and sometimes rethink the workflow to see if it makes sense. Thanks for chiming in!

I use mostly .pkg for my labs and rarely use .dmg's for anything except for license keys and browser specific settings.

@mconners Creating .pkg installers also gives you the potential to do a manual install of something independently of Jamf Pro.

Note: I'm not implying you would want to install independently of Jamf Pro mind you, but if you have machines located where it's more reliable to Sneakernet a USB drive than do a network transfer it's nice to be able to use the same installer in both cases.

only issue I've had with DMGs and High Sierra is that composer creates apfs formatted DMGs which can't be opened on anything that doesn't understand apfs

This topic intrigues me as we're planning on migrating to High Sierra from Sierra either late spring or early summer. I had not heard that there were issues with dmg's. More details or a link or two would be appreciated.

For what it's worth I mostly use pkg's but have some key dmg's where I'm configuring permissions. I'm not looking forward to redoing them if that's what's needed.

Hello @jhuls as you probably already saw. High Sierra and composer will generate APFS DMG's. I myself have not had any experience with this to be honest, but I have heard of it being an issue. This is partly why I am making the move to PKG's.

What I have been doing slowly and (testing) is moving the DMG's into Composer, version 9.101, because newer versions of Composer won't let you delete items. Once moved into Composer, I have been converting to source. Once converted, I have been able to then save as a PKG. This new file I move back into the JSS and test deployment.

At one point, I have been told installers larger than 1 GB should be cached using the Cache installer option under the packages payload. From there, I generate a new policy to install that cached package. A few more steps, but at least it gets the job done.

I scope the cached installer policy to a smart group where the criteria is cached package is found and the name of the cached packages. Run it once per computer and you should be good to go.

As far as DMGs being created in APFS format on HS systems, yes, that's an issue. But frankly, it could be solved by Jamf if they would update Composer to allow you to choose the disk image format when building one out instead of just going with the OS default format. In fact, see these FR threads, the second of which seems to have sparked this very thread by @mconners:
https://www.jamf.com/jamf-nation/feature-requests/6770/let-me-choose-filesystem-when-creating-a-dmg-in-composer
https://www.jamf.com/jamf-nation/feature-requests/6813/composer-makes-dmgs-in-apfs-and-hfs+-when-run-from-10-13

Perhaps that's easier said than done, but I can't imagine it's too difficult. Not sure why Jamf didn't see this would be an issue for environments that have a large mix of OSes to manage. They should address that, since as of right now, a High Sierra machine will successfully mount an HFS formatted disk image, but anything pre late Sierra will not mount an APFs volume, AFAIK.

But beyond that, there are other reasons why DMG isn't necessarily the best format to use for deployments. Some have already been mentioned. As @sdagley said above, the DMG as Composer builds it, is a proprietary deployment format that only works with Jamf Pro. For as much as I would love to believe we will be using Jamf Pro in an organization forever and all eternity, this simply isn't a realistic expectation. There are reasons why orgs sometimes move onto or into other products. Some technical, and some political. Because of that unpredictability, I don't like the idea of locking myself in to a proprietary format for hundreds of deployment packages, and then have to switch them all over later if something changes. Plus, as mentioned, it's somewhat easier to do local testing and hand out a pkg to a tech for example. You can't really give a DMG from Composer to someone and expect them to know what to do with it.

I went all PKG some time ago, mainly as a result of needing to bundle the vendor DMG inside the deployment for some products that use Apple's DMG signing thing, but also because I found myself increasingly wanting to add a bit of scripting to things after installation.
They just seem to be more reliable as well in my experience. The only real downside I can see is you don't get the indexing options and possibility of uninstallation, but to be honest most of the things you would package using a DMG you can create an uninstall script in about 5 minutes for anyway!

Thank you all for your quick and thoughtful feedback. I am almost done switching over to PKG's from DMG's. While I had a lot, now I have to do a lot of testing before summer is out.

Let me ask @Look, @mm2270, @sdagley, @Felipe.hernandez and others, in a single policy for deployments, how many PKG's do you put in? Is there a limit from a performance perspective or something?

Right now, in a single policy, I am trying to limit to only 10 PKG's and if I need to install additional applications, I plan on having a step 2 to continue the process using a custom trigger to call step 2 up.

Thoughts?

@mconners The only limits that I see are the obvious ones, the size of the .pkg file and the speed of the network. Both contribute more negativity then than the amount of .pkg files per policy.

@mconners It kind of depends on your connection to your client machines and/or the complexity/size of the packages you're installing. If you have a fast connection and simple packages bundle them up. If you have large/complex packages, limit how many you do at once. Office 2016 for example I prefer to do as one Policy per app.

Yeah, same answers from me as above. Depends on how large the pkgs are. Large stuff I tend to keep to one policy, unless the additional pkgs are pretty small and don't contribute much to the overall bandwidth needed. Other than that, I actually don't know what the finite limit is to what you can add for # of pkgs to a policy. Probably kind of high, but again, you probably don't want to add too many at once no matter their size. 10 would be the most I would ever add to a single policy, and I think I'd be hard pressed to locate an active policy right now that uses that many.

@mconners I have one policy with 12 PKGs and 10 DMGs (I haven't bothered going back over legacy packages and repacking). I also has 3 or 4 scripts as well and everything works fine, well at least over ethernet.
I honestly think that aside from time there is no reason why more items should cause an issue, it deals with each PKG or DMG independently one after the other as seperate downloads and install anyway.
I am even layering up two or there of these type of policies (most of the others are smaller at around 5 or 6 items) all called using triggers from one control policy without too many issues.
If you after the fastest possible solution this might not be it, but it's flexible and gets the job done.
As @sdagley said the size of the largest PKG is probably thre determining facting when it comes to performance and reliabiliy a single 20 GB PKG like Adobe CC is far more likely to fail or cause performance issues than 10 or 15 smaller ones. If the network drops 75% through the 20GB it will start again from a new DP and you lose 15 GB worth or traffic, if it fails 75% through a 1GB PKG you only lost 750MB of traffic.