Prevent Package from installing during imaging

[McAwesome]

We have a package that works perfectly when installed via policy/Remote, but doesn't work correctly during imaging. That's fine by me. We can just push it when needed. I'm certain either myself or one of the other techs on my team will forget that at some point and try to add it when we reimage some machine. I'm looking for a way to prevent it from being either added to configurations or installed during the imaging process. The Limitations field seemed like a good way to narrow it down, but I have no idea how I would specify the Casper Imaging app and not a particular OS version. Does anyone have any suggestions?

[davidacland]

It sounds like its just having difficulty installing on a non-booted volume. To get around that you can select "Install on boot drive after imaging" in the package options which will make it a postponed install.

[bentoms]

@McAwesome I second what @davidacland has said.

In fact I tick that box for all PKG's as habit now.

[McAwesome]

@davidacland @bentoms, that's not it. By default, we mark all .pkg installers to install on boot after imaging. This particular annoying installer requires access to a particular remote folder while it installs. Normally I'd just make a second package that would place the files locally(somewhere like /Library/Application Support/TEMP), but this installer really doesn't like that setup for some reason. I've placed the files in the JSS and aimed the installer at those files. This works any time it would mount that share(like during a policy push). The problem is that Casper Imaging doesn't remount the JSS quite right(if at all) during the "Install on boot drive after imaging" phase, so the installer doesn't have access to the needed files. In order to get around this, I'd have to find a way to mount a share again during that phase of the imaging process. Rather than pull my hair out on that puzzle, it's just easier to make a policy triggered to enrollment/self service/whenever.

I'm still looking at why it doesn't like locally stored versions of the files. If I can figure that out, I'll swap over to that approach. In the mean time, this approach works in most situations other than imaging. It'd just be great to have a better way to limit it than just putting "DO NOT USE DURING IMAGING" in the notes for the pkg though.

[davidacland]

Ah ok. Sounds like one of those odd installers that makes up its own rules.

Yep I'd go for a big note on the pkg. You could also add the note (or a cut down version) in the package name. In case someone doesn't look at the notes.

[bentoms]

@McAwesome I guess the "adobeInstall" account under which the PKG is installing post imaging isn't mounting the share.

Might be worth naming & shaming the PKG perhaps others have workarounds?

[calumhunter]

+1 name and shame.

If it were me, I'd be repackaging it and fixing the preflight/postflight scripts. Or is it not even an apple pkg file?

[McAwesome]

It's Smart Notebook. They have an official pkg builder that I've been using(to make sure it's easy to reproduce if I'm not around). This works great for installing and activating Notebook, but for some reason it cannot put the Gallery files in the same package. So they have you point the installer to a place where the files are located. The only two options are "Same folder" and "Network location", and attempts to just use "Network location" as a local file path haven't been successful. If the installer can't access the Gallery files, it continues on and just skips that part of the process. So it installs half of the program if it can't mount that share. Not end of the world, but less than ideal.

I'm going to attempt a few more things tomorrow to see if I can get it to accept locally stored files instead of network stored files.

[calumhunter]

ah ok, I haven't used smart notebook for a very long time, but I vaguely remember a similar issue. I got it to work in the end, not sure how, I think I created a separate package for the gallery files, but there was something messed up about how the gallery files were indexed or named that caused issues. Hmmm sorry can't be more helpful

[davidacland]

Ugh, Smart Notebook. I've had run ins with it the past, for different crashing issues. Strangely I haven't seen it recently either, not sure if they're less popular these days?

I'll be interested to hear what your final solution is for it though.

[bentoms]

@McAwesome Does this JAMF Article not help?

[daz_wallace]

I'm pretty sure (although this is from memory!) that the packaging tool for SMART (as mentioned in @bentoms's post) will download and package the Gallery items as part of the installation.

It's been a while since I've done it but I'm pretty sure that it is the case.

[daz_wallace]

These are the options I see with the latest packaging tool:

When I last packaged SMART, I believe I selected "I need to download it", clicked the "Download and unpack..", followed by selecting the "In the same folder as the installer itself" options.

From memory, this deployed the whole lot from the installer package.

Hope that helps somewhat!

Darren

[McAwesome]

@bentoms That article glosses over the issue I'm having. It never actually goes into details on how to set up things. It just says "Customize the installer".

@daz_dar When you select "In the same folder as the installer itself", the installer expects to find the gallery files in the exact folder you run the installer from. If you push it with Casper, I believe that folder is /Library/Application Support/JAMF/Waiting Room. If the files are not in that folder like the installer expects, it will continue on with no visible difference and install Notebook successfully. You'll only find out it didn't install the Gallery files when you try to do something gallery related. You can check this quickly by opening the Gallery Setup app and seeing what options you have available.

[daz_wallace]

Ah so my memory wasn't right! : )

I guess the other options would be to:
1) Package and deploy those files yourself.
2) Contact SMART and find out if they have a better way to deploy the Gallery content
3) Use a naming convention / internal documentation to ensure that no other admins try and use this with an imaging configuration.

Good luck!

Darren

[McAwesome · Accepted solution]

I found my work around for a local solution. I had been setting the path correctly, but since I didn't have those temp files on my local machine at the time of building the pkg Smart decided I would never have anything there. It didn't matter that the machines it would actually be run on would have the files in the right place. It just disables the Gallery install if the path doesn't work. Adding the "/Library/Application Support/Smart Local Files/<gallery stuff>" before creating the pkg pointing at it makes the built pkg work.

I created the installer, Gallery Files cache(Composer, "Monitor File System Changes", add "/Library/Application Support/Smart Local Files"), and a script to clean up afterwards. I can confirm that this approach works during imaging. So I guess my main problem is resolved without the need to limit packages from working through Casper Imaging.

This would have been easily averted had it just popped up saying that was the case or that it was disabling the Gallery because of the unreachable files. That would have been too easy though.

[bentoms]

@McAwesome glad you got it figured out. What a PITA product.