Acrobat 11 Pro

We install the serialized version of Acrobat Pro XI in Self Service without any issue. Are your distribution points SMB, AFP or HTTP(s)? I know some people using SMB have had to wrap the .pkg in a DMG to get things to install properly. We mainly use HTTP for our distribution point and haven't had too many issues installing Adobe or other vendor .pkg files.

In my opinion the only way to get Adobe stuff to install reliably is to wrap it in a flat package and install on the local disk. it makes for some huge packages but I get 90%+ reliability this way.

After some testing, it appears that the policy that installs the adobe package runs just fine when executed from say, a command line like "sudo jamf policy -trigger acropro" or one of the other types of triggers, but when I attempt to install it via Self Service is where it fails and says it succeeds.

Does anyone have any ideas of how I might debug this or what's going on?

I have access to this policy scoped to one Active Directory group we have for users who are permitted to install Acrobat Pro, since it is paid -- that is the only restriction, and if you're not in that group you can't see the item in Self Service. I am wondering if that is getting in the way -- but if that were the case presumably the user would not be able to see it at all to install it?

The policy logs on the JSS do not reflect the success in the self-service instance, but they do in the trigger-downloaded one.

@jbarnes Can you clone your Self Service policy and scope it only to one single test computer and try and install to see what happens?

@mpermann I totally didn't think of that, so I'm glad you did!

That seems to fix it. I am wondering why the AD group limit breaks it. I don't have people log into self service, yet it "knows" who you are since it displays or does not display packages based on this. Hmm.

@jbarnes we don't bind/use AD so I can't speak directly to the use of AD groups. But I wouldn't think it should cause it to not work. I would encourage you to open a support case with JAMF regarding this and if they help you resolve it or give you a reason why this won't work that you post back your findings. You might save someone else a bunch of grief by posting their response.

@mpermann Good idea, I did that.

What the problem ended up being was -- I did not have self service set so that users had to login and yet, it knew who I was and listed my username in the right hand side of the window as well as showed me the packages that I was entitled to see due to the scoping to AD user.

Apparently this is a defect -- I am not supposed to be able to see things scoped to AD unless I have the login mechanism for self-service checked in the JSS despite SS knowing I am me. When it came time to actually execute the SS policy, that's why it was failing.