Deploying Application DMG

@auser Applications you receive from a vendor in a .dmg can't directly be deployed via Jamf Pro. You'll want to look at using Composer to create a .pkg installer to deploy the application and license file (technically you could use a script to download the .dmg and then copy the app to /Applications but using Composer will be easier)

Thanks. I have worked a little bit with packages in composer. Would you suggest packaging the app installer in the locations on my machine and then build the package from there? 

@auser Is there an installer for the app on the .dmg you mentioned in your original post? And if so, is it a standard .pkg installer, or an executable application that runs the installation? If the former you may just be able to deploy that .pkg and create a separate .pkg with Composer to deploy the configuration file.

quickpkg 

@efil4xiN Thanks for the quickpkg link, that's a neat little tool.

If the app is just a drag-to-Applications-to-intall type of app, you mat want to use Composer or quickpkg to package the app, and then build a separate package to install the license fie.  This gives you the modularity to update the app without needing to re-build the license package as well.  If the license file needs to go into the user's home (e.g. ~/Library/Application Support/), then you will need to use Composer to create a .DMG and use the FEU option.

Thanks, the latter is what I did. I created a dmg by simply dragging it from Applications and then dragging the application support folder which included the lic file. The path in composer was my own user folder but after packaging it as a DMG, I used the FEU option when deploying it via policy. Seems to have worked. 

Generally you'll want to install applications in /Applications so they're available to all users. By placing the app in ~/Applications and using FEU you're putting a copy into every user's ~/Applications folder. That may not be a big deal if you're running one user per Mac, but it's not really considered to be best practice.

Thanks. Yes, it is one user per device but how would you recommend amending this workflow? 

Hey @sdagley . The path i get when dragging the app from the applications folder is Macintosh HD>Applications. I do see a Users>Applictions directory as well, but this app is not in there along with other apps installed. Does that look right? 

As for the license file, that is in Macintosh HD>users>myname>Library>Application Support. 

@auser Those are the paths you want, so sounds like the package you created is correct, I just misread your comment about the user folder as being for the app. 

Thanks, so I have it packaged and when I deploy it, I can see in Jamf an error that says unable to mount the package. In the jamf.log I get “you can’t save the file “tmp” because the volume is read only”. I did set all the folders in the package as root, wheel. Are other special permissions I need to give this? 

Please post the full path for the error in the Jamf log

Right after I posted, I came across a really old thread that talked about removing spaces in the .dmg file package. The name of my package did not have a space, but the source file when I uploaded it did. I went in and adjusted it to remove the space and it deployed fine. Not sure if it was coincidence or this in fact is an issue. 

@auser Good to hear your .dmg deployment is now working. On the space issue, it's not uncommon for scripts to be written without accommodation for spaces in a path if the author didn't specifically have to deal with them, and that can bite users who are attempting to repurpose/reuse the script with a different path. https://www.shellcheck.net/ is a useful tool to check bash and sh scripts for that issue, as well as detecting other potential problems.

Thanks for the all the help and resources. One behavior I notice is that when deployed, the app drops in the application folder but the application support folder does not show up until after the app is opened for the first time. Once that is done, the lic file is there as in the dmg I packaged but it requires an activation. Is there a way to have the application support folder to exist and be created with the deployment? The lic file will be the same, so that way the need to activate it bypassed when users open it for the first time. 

@auser Are you seeing the folder for the app being being created in ~/Library/Application Support/ (that ~ means the home directory for the logged in user) or in the global  /Library/Application Support/ directory? When you use the .dmg option to build an installer the files are simply copied to the same path as on your source Mac, so if you look in the /Users directory on a Mac you've run the .dmg install policy on you should see a directory matching the user for your source machine. The FEU (Fill Existing User) and FUT (Fill User Template) should trigger Jamf to replicate the app's Application Support folder into any existing or new user accounts, but it sounds like that's not happening. What you could try is putting the app's application support files into the global  /Library/Application Support/ which should eliminate the need to use FEU and FUT. Another benefit of doing that is it'd allow you to use a .pkg installer which I strongly recommend over .dmg installers, although they do require writing postinstall scripts if you want to move files into the user directories since the FEU/FUT options are only available for Composer created .dmgs

Yes, they are being created in users/xxx/application support/application/lic file. In my package I have this folder structure with only the lic file in it. The directions from the vendor state to put it there. What I notice is that the lic file gets in that folder, but only after the app is opened for the first time. So it’s like the lic file queues up until the app is launched, then it gets added.