Acrobat 11 Pro

jbarnes
New Contributor

I created a pkg file with the "Administrating Adobe Acrobat XI Pro With The Casper Suite" pdf documentation which combined the serialization with the installer, but when someone clicks on it in self service -- self service claims to have succeeded, yet fails to install anything.

If I take the same package and do:

sudo installer -pkg "/path/to/package" -target /

It does install. However, if I don't specify a target, it fails. I am wondering if it is this particular characteristic that is causing the problem. Does anyone have any ideas as to why this may be happening or info how they did it? To date I've only used dmg files for all our applications, not things generated by a vendor utility. The aforementioned instructions seem to be for people who are doing monolithic images, but we do light imaging (and so 'install to boot volume' does seem relevant -- unless I am mistaken?)

8 REPLIES 8

mpermann
Valued Contributor II

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.

nessts
Valued Contributor II

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.

jbarnes
New Contributor

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.

mpermann
Valued Contributor II

@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?

jbarnes
New Contributor

@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.

mpermann
Valued Contributor II

@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.

jbarnes
New Contributor

@mpermann Good idea, I did that.

jbarnes
New Contributor

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.