Skip to main content
Question

General app deployment troubleshooting in Jamf School

  • January 4, 2022
  • 4 replies
  • 68 views
MasterNovice
Forum|alt.badge.img+5

Does anybody have reference to, or some general input on troubleshooting steps for failed app deployment? Right now the only thing I really know to check is the activity log for the device. So, the server has sent the request to the client to do a thing. In Jamf, the status usually changes to "Acknowledged" for this line item, so I'm assuming it got a response from the client on the request. But how to I verify that on the client side, and where can I begin to troubleshoot how far in the process a deployment got before it failed?

Did it fail to download (where does a package download to on the client while staging for install)?

Was there a permissions issue (where is the process logged and what permissions/authentication are being used to authorize the task)?

Is there a dependency missing? (where is the process logged)?

Is something just corrupt or failed for an unexpected reason/bug (where is the process logged)? 

I'm trying to improve my understanding of the process in general I guess, and where to find verification on milestones in the process. I've started streaming messages in the Console and trying to filter for processes like mdmclient or keywords related to the specific package name I'm working with, but I'm not sure this is the best method. Often I don't understand the specific messages anyway, and don't know which specific actions I should be looking for in the logs. 

I know the question is a little general and abstract, but how do you approach troubleshooting a failed action or deployment from Jamf on the client side? 

    4 replies

    T
    Forum|alt.badge.img+5
    • TSOAFTVPPC
    • Contributor
    • January 5, 2022

    I could be called a master novice as well!

    When you say app deployment what do you mean?
    Appstore apps?
    Installer packages?
    Are these packages on the distribution point?
    Before deploying apps, did you confirm they are well behaved installers? Some apps require user engagement/intervention.
    Have you tested the installer packages locally first by using terminal to install packages?

      T
      Forum|alt.badge.img+5
      • TSOAFTVPPC
      • Contributor
      • January 5, 2022

      I could be called a master novice as well!

      When you say app deployment what do you mean?
      Appstore apps?
      Installer packages?
      Are these packages on the distribution point?
      Before deploying apps, did you confirm they are well behaved installers? Some apps require user engagement/intervention.
      Have you tested the installer packages locally first by using terminal to install packages?


      Also one of the reasons I like Jamf remote is that you can use it to deploy a package and a failure will give you a pretty verbose html document describing what failed and why.

        MasterNovice
        Forum|alt.badge.img+5
        • MasterNovice
        • Author
        • Contributor
        • January 6, 2022

        I could be called a master novice as well!

        When you say app deployment what do you mean?
        Appstore apps?
        Installer packages?
        Are these packages on the distribution point?
        Before deploying apps, did you confirm they are well behaved installers? Some apps require user engagement/intervention.
        Have you tested the installer packages locally first by using terminal to install packages?


        | When you say app deployment what do you mean?

        Thanks for the reply! Well, all of the above really. We use Jamf cloud, so the distribution point is their onilne repository I guess, when we upload custom packages, or the store if we're deploying a VPP app? Deployments from the app store generally work pretty well and without issue. It's mostly custom apps that are problematic, stuff that has to be repackaged or uploaded because it isn't in the store. Yes, I do try to run an installer first to verify behavior, any pop ups or option that have to be dealt with. This is a really good recommendation and took me a long time to get in the habit of it!

        I think I'm just looking to verify more specifically what happens with the process and where to verify on the client side like "Yes, I got the request to install a package. Yes, I was able to download the package and it should be in this location on the client now. Yes, I tried to install the packaging using this install command and arguments. I got an error that x happened and stopped." I can try to kind of logic-sleuth what makes sense in a failure, but I'm usually just guessing, and then have to test for that guess which can take a lot of time, or is just plain wrong.

        I'd love to know where I could verify more specifically in a log, like, "Tried to run an Intel binary on an M1, Rosetta's not running or hasn't been authorized to run." Or, "I tried to establish a connection for the download and failed, something's blocking connection to Jamf on port x." Or, "Tried to run as a standard user and admin is required" so that I'm not always guessing at what might be the issue when no errors present during the deployment. I know the log wouldn't be that clear and verbose, but I just mean the line items that confirm the process you know?

        MasterNovice
        Forum|alt.badge.img+5
        • MasterNovice
        • Author
        • Contributor
        • January 6, 2022

        Also one of the reasons I like Jamf remote is that you can use it to deploy a package and a failure will give you a pretty verbose html document describing what failed and why.


        This sounds really interesting and in line with the info I'd love to have!

        I feel like I should know what Jamf remote is, but I do not. : ( Like remote control/screensharing? Is this a School feature?

        Terms & ConditionsCookie settingsAccessibility statement