Could not mount a distribution point

[aamjohns]

A while back I could not mount our distribution point (Win Server 2008 R2) through Casper Admin but could manually mount it. After talking with JAMF support I found out it was because the password had spaces in it.

Now I am seeing a lot of hit or miss distribution point mounting failures when policy executes. For example, I am testing a Acrobat Pro Update policy and in the logs the last two attempts have failed because 'Error: Could not mount a distribution point.'. But true to the hit or miss nature of this, on the third reboot it mounted and installed. I see as much red failure log entries as a do successes.

I'm not really finding a patter here. Does anyone have any suggestions on how I might troubleshoot this?

Thanks,
Aaron.

[mscottblake]

I have seen this in the past and have found that if the drive is already mapped by a policy on another trigger, it will fail because the system cannot map the drive twice. It has caused me to rethink how some of my policies are triggered.

[donmontalvo]

That's strange. OS X should be able to access the Distribution Point since it's already mounted, and policies just need read access. I can see there being issues if the Distribution Point is already mounted read only and then you launch Casper Admin, it'll complain because it needs read and write access. How did you make the determination?

[cvgs]

The jamf binary does indeed try to mount the SMB DP twice, it doesn't care if the share is already mounted. You might contact JAMF support about that - the more bug reports about that, the better...

[aamjohns]

I am also having issues in self service. Typically, the first time I click something I get 'failed' almost immediately. If I click it again two seconds later, it works. That seems to be the pattern. But...I just click something and 4 fails, and then success. In the logs I can see, it is failing to mount the distribution point.

If it is trying to mount something already mounted, I wonder why first click fails, second click works, or 4 clicks fail, 5th click works. There are occasions where it works on the first click.

[JPDyson]

I've observed this happening; it mounts the dp, and then later I get a "failed to mount". In the specific case that happened most recently, it was a policy that actually calls several other manually-triggered policies, and EACH of them failed to mount the dp (though it was successfully mounted earlier in the process).

Contact support, I guess.

[mscottblake]

@Don: OS X can, yes, but the jamf binary is trying to mount it regardless of whether it is already mounted. It's part of the policy script. First it mounts, then it runs the policy, then unmounts. If you have a policy trigger (say every15) and it has 3 policies to run, it will mount and unmount the DP 3 separate times.

If the binary could be smarter and know that it is already mounted, that would be great, but there is a lot to consider in this approach. When a policy ends, does it need to unmount? If it does, does it kill another policy that is also running? If it's a different trigger entirely, how does the binary know anything else is currently using the DP? I can see why they did it the way they do, but I also agree that some sort of change should be made to make it smarter.

[Kumarasinghe]

Consider HTTPS distribution points?
We are using HTTPS Distribution Points (Win Server 2008 R2 with IIS) and no issues.

[donmontalvo]

Interesting, I'm starting to wonder if this bug is the reason we've been having problems deploying CS6 to some test users. SMB shares are on NAS (no HTTP), and the policy had two packages. The main CS6 package (using DMG and script method), and the EXCEPTIONS package (MPKG). The main CS6 package would begin to cache, then the EXCEPTIONS package would hang (no real error in the log file). If we removed the EXCEPTIONS package, the main CS6 package cached and installed smoothly.

This thread is an eye opener, I'm sitting here wondering if Casper can handle mounting/detaching volumes differently so mounted shares are recognized and used? Unlike windows where shares are MAPPED (latent until accessed), in our world shares are MOUNTED (OS X works to keep connection active). Not sure what to make out of it being a problem even if no volume is mounted. :/

Does this happen with AFP shares too?

Don

[SeanA]

Maybe I missed it, but was this behavior resolved in any release since this thread was posted?

[donmontalvo]

Hey Sean! Long time no see!

We moved away from AFP/SMB since JSS 9 was released. Works great, except in our current environment the mix of Wi-Fi/VPN for remote users sometimes cause deployment failures. JAMF are aware (D-005954) and are hot on the trail of a fix.

Doesn't eliminate the need for AFP/SMB since Casper Admin requires it, haven't checked if anyone submitted a Feature Request to lift the dependency on AFP/SMB.