upgraded to 9.81 from 9.65, replication problem persists

AVmcclint
Honored Contributor

We were running JSS 9.65 on a Windows server until I decided to upgrade to 9.81 in preparation for El Capitan. I upgraded. It seemed to go ok. When it finished I logged in to make sure everything looked OK and then ran jamf policy on my Mac to get the new binary. I ran Self Service to make sure that worked because of some of the reports I saw here. Self Service works fine. I then tried to test Casper Admin and it fails to replicate to any of our distribution points. I get the dreaded "Server could not be mounted" error. However, /Volumes does list the share point as mounted: CasperShare, CasperShare 1, CasperShare 2...

I originally had this problem when I upgraded from 9.62 to 9.65 but I worked around it by substituting the server FQDNs with IP addresses to get around the *@#&$ kerberos problem that caused it. I would also sometimes use Casper Admin 9.62 since it never had a problem connecting. I figured I'd try using the IP address entries for the servers again now but it continues to fail every time. I have no kerberos tickets related to any of the Casper service accounts on the servers. I have no idea why it's failing to mount (when in fact it does mount). I also tried falling back to Casper Admin 9.62 since that worked before... NOOO! It tells me "This version of Casper Admin does not match the version of the JSS that you are running..." So I can't use my Plan B nor Plan C to replicate packages on the servers.

Our servers are a mixture Windows Server 2008 and 2012. What on earth broke in 9.65 (and continues to stay broken in 9.81) while 9.62 never had a problem (until I upgraded)?

1 ACCEPTED SOLUTION

AVmcclint
Honored Contributor

I reached out to tech support and I was given a workaround. I made a copy of the 9.62 version of Casper Admin (the last version that worked right out of the box) and edited Casper Admin.app/Contents/Info.plist with TextWrangler. I changed the following from 9.62 to 9.81:

    <key>CFBundleGetInfoString</key>
    <string>9.81</string>
...
    <key>CFBundleShortVersionString</key>
    <string>9.81</string>

This tricks the JSS into allowing it to connect. I don't have to mess with unmounting volumes or killing kerberos tickets. It replicates to the servers using either DNS entries or IPs. It just works. Obviously SOMETHING significant changed after v9.62 but our TAM is going to try and get engineering to look closely to determine what that was. Meanwhile, I'm using the older Casper Admin app to upload and replicate packages. Luckily there is very little functionality that's needed beyond that.

If you do use this method to modify the old version of the app be aware that if you Get Info on the app it will report itself as being 9.81. To make sure you keep this modified app separate from the real 9.81 version, you may want to change the icon or add a comment in the Get Info window or add "[modified]" to the file name.

View solution in original post

16 REPLIES 16

NickKoval
Contributor
Contributor

Check the /Volumes folder from terminal. Newer versions of Casper mount the caspershare volume invisibly to the Finder.

AVmcclint
Honored Contributor

Yup. that's where I verified that the CasperShares were mounting. I checked the Windows server logs and it also confirms that the Casper write account did successfully connect. I see the CasperShare of the JSS it connects to and then CasperShare 1, 2, and 3 of the distribution points as they mount. I even tried replicating to just 1 server after umounting all the extra CasperShares. Still no change.

The local logs on my Mac don'y say anything other than "the server could not be mounted" I have no kerberos tickets for that account. I am able to manually connect to the servers via Connect to Server.. in the Finder using the Casper write account. I am at a loss for why Casper Admin refuses to connect to any of our distribution points. The good news is that Self Service so far appears to still work.

scottb
Honored Contributor

The other thing we did aside from the DNS>IP change was to remove all complex characters from the two JSS install/admin accounts.

Don't know if you've tried that @AVmcclint , but a thought.

alexjdale
Valued Contributor III

Just started seeing this with 9.81 after upgrading from 9.63.

I tried to sync a series of DPs. It looked like every other DP would mount properly, so half of them failed to replicate. Afterwards, the /Volumes folder had "Casper 1" through "Casper 6" and I was able to manually umount those and sync individual DPs once that was done.

Something is buggy, 9.63 worked incredibly well and 9.81 is unreliable.

scottb
Honored Contributor

This issue seems to be on/off throughout versions. Not sure why as it seems like a simple task to unmount DP's, but even when I try to do just one, I see it, or don't. All I know is that I now use rsync because Admin is not usable a lot of the time for that reason.

NickKoval
Contributor
Contributor

If your distribution points are hosted on a windows server, are you using a local account on the server to connect to the DPs or are you using a network account? I've seen the connection fail if there is already a network user logged in and you try to connect to a server (both the same one and a different server) as a different, network user.

scottb
Honored Contributor

My setup uses Windows SMB DP's. Mac is logged in as a local Admin, but the two Casper JSS accounts are AD.

Aranzazu
New Contributor

I'm seeing the same issue and the only thing that seems to work consistently for me is running the kdestroy -a command prior to replication.

NickKoval
Contributor
Contributor

Just for Ss&Gs (smiles and giggles?) try creating a local account for the file sharing and see if you get the same error.

alexjdale
Valued Contributor III

I am using Windows SMB DPs as well, with AD service accounts. Local accounts on the servers will not be an option even if it works.

My new workflow:
1) Launch Casper Admin, get message that primary DP can not be mounted
2) umount /Volumes/Casper (which did not exist prior to step 1)
3) Launch Casper Admin, which now is able to mount primary DP at /Volumes/Casper
4) Attempt to replicate DP, share cannot be mounted
5) umount /Volumes/Casper 1 (which did not exist prior to step 4)
6) Attempt to replicate DP, successful this time
7 ) Repeat 4-6 for each of my 39 DPs

Doesn't matter which OS I use or how I am logged into the Mac doing the replication, same results.

The mounts are actually successful, I can navigate them in Terminal before umounting them and the files are there, it appears that Casper Admin is not detecting them properly.

As I've read in some other threads, a "kdestroy -a" before trying to replicate a new share seems to work sometimes.

AVmcclint
Honored Contributor

I reached out to tech support and I was given a workaround. I made a copy of the 9.62 version of Casper Admin (the last version that worked right out of the box) and edited Casper Admin.app/Contents/Info.plist with TextWrangler. I changed the following from 9.62 to 9.81:

    <key>CFBundleGetInfoString</key>
    <string>9.81</string>
...
    <key>CFBundleShortVersionString</key>
    <string>9.81</string>

This tricks the JSS into allowing it to connect. I don't have to mess with unmounting volumes or killing kerberos tickets. It replicates to the servers using either DNS entries or IPs. It just works. Obviously SOMETHING significant changed after v9.62 but our TAM is going to try and get engineering to look closely to determine what that was. Meanwhile, I'm using the older Casper Admin app to upload and replicate packages. Luckily there is very little functionality that's needed beyond that.

If you do use this method to modify the old version of the app be aware that if you Get Info on the app it will report itself as being 9.81. To make sure you keep this modified app separate from the real 9.81 version, you may want to change the icon or add a comment in the Get Info window or add "[modified]" to the file name.

alexjdale
Valued Contributor III

Yep, this worked for me, good tip thanks!

psliequ
Contributor III

What's worked for me as of today is to take the workgroup/domain settings away from any secondary servers I need to replicate to. It's totally counter intuitive, but the client is able to mount the share despite the fact that there is no domain information set for what is a domain service account.

nwiseman
Contributor

That worked for me as well. Wish I would've known about this for the past 7 months ha. Thanks for the info.

AVmcclint
Honored Contributor

I think this will continue to work for us as long as there is no major change in the functionality and the basic communication between the Admin app and the JSS. For all we know this trick won't work at all when we get to Casper 10.x. if that's the case, I hope the JAMF engineers have fixed the underlying problem.

mpermann
Valued Contributor II

Thanks for the tip @AVmcclint! I used your suggestion to change the version of the 9.81 Casper Admin to report as 9.73 so I can get it to connect to my 9.73 JSS on El Capitan systems. I haven't done much other than verify that it launches and connects. But at least it will launch.