Feature request - Detect/report errors for shell commands

[camguise]

It would be great if JSM could identify when a script that has been run via the "shell" enrollment actions. In the most simple form this could just be putting a red X rather than the green tick on any items which exit with a non-zero exit code.

For devices that are being provisioned by end users they would hopefully see the red X and reach out to support to check the full logs. Those being provisioned by IT staff could investigate the logs themselves and it may be a simple case of going into recovery and removing /Volumes/Macintosh\ HD/private/var/db/.JamfSetupEnrollmentDone to let JSM run again or just wiping and re-provisioning the device.

If it helps for testing a simple enrolment item that produces an error could be achieved with the XML below:

<key>enrollmentActions</key>
<array>
  <dict>
	<key>shell</key>
	<string>/bin/bash</string>
	<key>arguments</key>
	<array>
	  <string>-c</string>
	  <string>exit 1</string>
	</array>
	<key>label</key>
	<string>Testing Error</string>
	<key>requiresRoot</key>
	<false/>
  </dict>
</array>

[jordanburnette]

I am also working on a general list of validation methods for this utility and here are a few thoughts that makes sense in my head. In the enrollmentActions key, JSM could support a key called validation that would function the same as the the upper level key so we can keep the whole process contained to a single action (for what the user sees) while running through JSM.

ie.

<key>enrollmentActions</key>
    <array>
      <dict>
        <key>label</key>
        <string>Rosetta</string>
        <key>icon</key>
        <string>/path/to/icon.png</string>
        <key>policy</key>
        <string>rosetta</string>
        <key>validation</key>
          <array>
            <dict>
              <key>shell</key>
	      <string>/usr/local/orgName/script.sh</string>
	      <key>arguments</key>
	        <array>
	          <string>-c</string>
	          <string>exit 1</string>
	        </array>
            </dict>
          </array>
      </dict>
    </array>

Ideally if a validation step fails, we can have a flag to require the policy/command run up to X number of times and if it doesn't complete (or times out after X period per run), write the Label name(s) to a plist somewhere that could then be read by any post-JSM workflows. Since there is a built in recon at the end of the process, this could be leveraged as an EA based on the 'Label' value of the failed item(s).

The way I would consider approaching one of those post-JSM workflows would be to create and load a LD to run once the user gets to the desktop that will kick off SwiftDialog and let the user know things didn't complete successfully. It would read from the previously created plist and use that info to retry installing the failed items while provide additional support resources. This way, the user isn't left with a broken deployment, but the user can still get the resources for help if things don't go perfectly. At the completion, when we know everything is golden, unload and delete the previously created LD.

[scriptingosx]

#16