Posted on 06-15-2016 09:03 AM
I have a policy that installs software via recurring check-in. When a user is logged in and recurring check-in happens, the software installs fine, dock item added and application is accessible.
If no user is logged in at the time recurring check-in occurs the JSS shows the policy ran and everything installed. Afterwards I login and the applications dock item is a ? and the application is not in the Application folder.
Note on the policy; the policy is a pkg that places files in a /private location and runs a post install script to unzip and install.
Has anyone encountered something similar.
on another note the policy works fine via Self Service.
Solved! Go to Solution.
Posted on 06-15-2016 01:47 PM
The post install script is the most likely culprit. I typically see errors similar to this when a package is trying to run a script that assumes someone is logged in and that it can take advantage of their user context or WindowServer session. The bad news is that finding the exact cause requires some luck and a substantial knowledge of the macOS script behaviors.
If you didn't make the pkg , inspect it with a utility such as Pacifist or Suspicious Package. Composer could be used to decompile the package, but analysis isn't its forte, and it is likely to omit relevant information and/or components.
Look for AppleScript code, calls to commands like open, or executables located outside the payload of the installer. Read over any script comments for references to command line or headless installs. If installing to 10.11 or later, also look for attempts to write to SIP protected directories or to change SIP protected settings.
Open the installer in a GUI on a test machine. Choose Window | Show Logs and then "Show All Logs" before proceeding. Review the logs and look for any windows opening outside Installer.app as the install proceeds.
Posted on 06-15-2016 01:47 PM
The post install script is the most likely culprit. I typically see errors similar to this when a package is trying to run a script that assumes someone is logged in and that it can take advantage of their user context or WindowServer session. The bad news is that finding the exact cause requires some luck and a substantial knowledge of the macOS script behaviors.
If you didn't make the pkg , inspect it with a utility such as Pacifist or Suspicious Package. Composer could be used to decompile the package, but analysis isn't its forte, and it is likely to omit relevant information and/or components.
Look for AppleScript code, calls to commands like open, or executables located outside the payload of the installer. Read over any script comments for references to command line or headless installs. If installing to 10.11 or later, also look for attempts to write to SIP protected directories or to change SIP protected settings.
Open the installer in a GUI on a test machine. Choose Window | Show Logs and then "Show All Logs" before proceeding. Review the logs and look for any windows opening outside Installer.app as the install proceeds.
Posted on 06-16-2016 06:47 AM
@joshuasee I made the pkg with composer. I just dragged a zip file from /private/tmp and used a post install script to install. So its a really simple pkg.
it's just trying to find out why it does not install when a person is not logged in. The policy says that it did install by it actually doesn't.
I set it to install on LOGOUT and that worked fine, Self Service works fine, recurring check-in works fine IF a person is logged in at the time the recurring check-in occurs.
it would be good to figure out why this happens. I have it in Self Service (which is the 100% intention of getting this software installed for users that want it), but for Lab computers I temporarily set the policy to LOGOUT which worked, then set it back to SS.
Is /private/tmp accessible when a computer is sitting at a NOT logged in state ?