Uploaded DMG file, but Self Service does not download or install it.

Bernard_Huang
Contributor III

Hi,

This must be a noob question, but I've worked on this for a few hours now but still can't figure it out.

I have uploaded a DMG file via Casper Admin. Then via JSS I have created a policy, and included the DMG file in the package.

I then find the policy within Self Service. When I try to install it, I can see the status of "Gathering Information", then it does nothing. Usually I see the status change from Gathering Information > Downloading > Installing > Clean Up. Self Service doesn't even get to the download step, which means it can't do anything.

So, is there something different my DMG package? Are there different types of DMG packages I should be aware of? Should I Open the DMG, then get the *.app out, and then repackage it myself? I have done a few other software DMG uploads, and they all work fine.

The DMG package is for XAMPP, if that matters. It was downloaded from https://www.apachefriends.org/download.html

1 ACCEPTED SOLUTION

Bernard_Huang
Contributor III

Worked it out! - but I don't know why.

Previously I had the scope as users - and I had my own name in it.
Therefore any Macbook logged on as me, would see the software (XAMPP) within Self Service.
With this setup, I can see the software, but when I click on install, all it did was "gather information"

I now added my Macbook's serial number to the policy's scope. So (again), my computer is registered to be be able to see the software.
This time, when I click install, it starts downloading (Woo Hoo!)

Now that the issue is resolved, anyone can explain why add a user doesn't work, but adding a computer to scope does?

View solution in original post

15 REPLIES 15

pat_best
Contributor III

have you looked at the self service policy log?

davidacland
Honored Contributor II
Honored Contributor II

The installer in that DMG is a .app file so Casper won't know what to do with it.

If it is failing to download the DMG, I would check that the package is on the distribution point the policy is using and check the policy logs to see why it is failing.

If it is getting that far but not installing, it will be the .app issue. You'll need to re-package it first.

Bernard_Huang
Contributor III

@pat.best ,
I looked into the logs, there are none :( I'm guessing it really did nothing, as it doesn't even get to download.

@davidacland ,
I have checked the distribution point, it says "Every Computer's default distribution point".
I would think that's ok.

I am comparing this XAMPP policy with other that are valid and working. all settings seems to be correct.

Bernard_Huang
Contributor III

Worked it out! - but I don't know why.

Previously I had the scope as users - and I had my own name in it.
Therefore any Macbook logged on as me, would see the software (XAMPP) within Self Service.
With this setup, I can see the software, but when I click on install, all it did was "gather information"

I now added my Macbook's serial number to the policy's scope. So (again), my computer is registered to be be able to see the software.
This time, when I click install, it starts downloading (Woo Hoo!)

Now that the issue is resolved, anyone can explain why add a user doesn't work, but adding a computer to scope does?

pat_best
Contributor III

I might be wrong in this, but I think that you need to scope computer software installs by device and you can limit access by users

mpermann
Valued Contributor II

@pat.best the administrators guide states here that scope can include "individual computers, mobile devices, or users" amongst other items. I too am experiencing the same issue as @huangbe and I'm currently working with support on why the policy will not install from self service. If I type

sudo jamf policy -id id_number_of_policy

the policy will execute normally on the computer. It just will not execute when I try and run it from Self Service. I'll post back if they ever determine what is causing the problem and how to resolve it.

pat_best
Contributor III

I wasn't aware of the issue, thanks @mpermann for straightening me out!

scottb
Honored Contributor

OK, are you requiring logging in to Self Service?
Are you using AD accounts for this?
We do both and scoping to users/groups (AD) works great.
I've not tried it with any other type of user account though...
PS - on JSS 9.82.

mpermann
Valued Contributor II

@pat.best I'm currently using 9.82 so maybe what I'm experiencing isn't happening to folks on other versions. I'm hoping to get to the bottom of this as I'd really like to start scoping to groups of users and not just groups of computers. @huangbe didn't mention what version of the JSS they are using so I can't say if we have that in common.

mpermann
Valued Contributor II

@scottb we have no requirement to log into Self Service and we don't use AD in any way. Don't you have to scope the policy to all users then limit it to the specific AD group(s) you want it to install on when using the method your speaking of? The only time I've done AD related group scoping was in my CCA training so I don't do this in my regular day to day work.

What I am doing is scoping a Self Service policy to a static group of computers and a static group of users. The static group of users is simply made up of users from the Users tab in the JSS. Nearly all of our computers have a user from the Users tab associated with the User and Location payload in the computer record. The computers in the static group of computers are able to run the policy normally and have the software installed without issue. When a user from the static group attempt to install it on a computer assigned to their username it behaves as mentioned by @huangbe.

scottb
Honored Contributor

@mpermann - we scope "all computers" and then use AD groups as the "limitation". Works great.
I have not tried your method as we do everything based on AD (sans some admins for testing). I'd have to try that method to see what happens...
Are you saying you have all your users in the JSS/Users? Or are you talking about a smaller set of say desktop folks?

mpermann
Valued Contributor II

@scottb we have all of our users in the Users tab not in Gear -> JSS User Accounts & Groups. I'm not sure what is preventing the policy from executing from Self Service when it will run with sudo jamf policy -id id# from terminal.

scottb
Honored Contributor

@mpermann - I'll have to check this as I'm not on the VPN right now, but I use (I think):

sudo jamf policy -username <jssadmin> -id 3

We don't have anything setup in Users tab (never used it). *Edit: Looks like I have to do the user Migration process to utilize this feature. Anyone see any issues in doing that? Looks like you get to repair conflicts first, then migrate. Off to RTFM first...

Bernard_Huang
Contributor III

Hmmm... didn't know I would be opening a big can of worms here.

@mpermann - We too are using JSS V9.82. Would it be just a bug in this version of JSS?
If adding users to scope does not fully allow the policy/package to be downloaded, then it shouldn't show up in Self-Service.
V.Weird.

mattbeef
New Contributor

Don't know if this will work for anyone else but i have had the exact same issue with Self-Service. We are using JSS 9.82 as well and had no login set for Self-Service. The strange thing is that we enrol machines using AD so they are assigned to users and our policies are scoped to AD groups.
I tried the following to resolve.
Turn off package verification. Repackaging and uploading to the DP as both DMG and PKG. Specifying the DP. Changing the scope of the policy.

The thing that fixed it for me was changing the Self-Service Login Method to "Allow Users To login to the login menu......."
Hopefully this will save someone else struggling.