Casper Remote doesn't always work

[pty10]

Wanting to use Casper Remote to login to teachers Macbook for troubleshooting, etc. I'm testing at the moment and I got a Macbook right next to me where sometimes I can connect, sometimes I can't.

In Sharing, both remote login and management are enable. 'Allow access for' is set for All Users (tried only these users as well) to observe, control, show being observed and restart and shut down. On the Image attached the last line (opening SSH connection...) is where I'm trying to connect to the other Macbook and after a few minutes fails. Under 'SSH' it just goes to yes

The line that says 'connection closed' is where it actually worked. It went through a few commands, I was then asked if I wanted to connect to the Macbook, I got the sharing screen icon on my Macbook and I was able to control the other Macbook. Then I closed the connection.

Any ideas as to why is patchy? firewall isn't enable on the MacBooks. We also made a mistake of not enabling the settings in sharing when we rolled out the computers. If I composer, enable to settings, create a package, and deploy it would work or I need a script?

Thanks,

Henry

[kerouak]

TBH, You'd be better off all round spending a few quid (Dollars) on Apple Remote Desktop.

It just works

g,luck

[blackholemac]

This sounds like a problem with your management account... does the management account that you have defined in the JSS for that Mac reflect the reality on the Mac itself. If not you can either adjust your management account in the JSS with the correct creds or consider re-running Recon or your QuickAdd.

[BaddMann]

Just went through this with my deployment.
It's that pesky casperscreensharing.

It's an account that is created upon enrollment to help assist in creating a login free vnc session that is tunneled through the ssh tunnel that casper remote creates.

I've created a new fix script for my helpdesk staff for when they run into this issue.
It simply deletes the account from the mac that is not allowing the staff to remote in.

Once the account is deleted the helpdesk initiate another sharing session and the account is re-created.

Please Jamf, stop allowing this account to become a stain on your reputation and add some error checking to its execution, creation and deletion or syncing. If a connection can't be made the tunnel should not just be sitting there waiting for someone to make a connection for hours.

here is my script:

#!/bin/sh
#remove that pesky account
dscl . delete /Users/casperscreensharing

[BaddMann]

Wow I need screenshots in my Jamf Digest email.
You're having a completely different issue than I.

It's most probably a mismatch in admin accounts, and expired client cert, a blocking of ssh traffic between vlans or just plain bum luck.
Good luck

Ps: Also make sure your Casper remote and the clients Casper Binary are in sync.

[BaddMann]

As a side note, when I contacted Jamf they gave the ability to create casper debug logs, here is how:

Thanks for reaching out about this! We can put Remote into debug mode, go ahead and open up your Casper Suite Folder (if necessary, you can re-download the JSSInstaller from JAMF Nation and that zip will contain the Casper Suite Applications folder). Then do a Control + Click on the Remote application and select Show Package Contents. Contents>Support>Then create a folder in the Support folder titled "debug". Once you do that go ahead and image and the log should be found in ~/Library/Logs/JAMF/CaspeRemoteDebug.log

Try this out and tell us what the log file says about you multiple attempts to connect.
Hope it helps

[donmontalvo]

@blackholemac wrote:

This sounds like a problem with your management account... does the management account that you have defined in the JSS for that Mac reflect the reality on the Mac itself. If not you can either adjust your management account in the JSS with the correct credentials or consider re-running Recon or your QuickAdd.

Yep, that can happen when someone does a sudo jamf enroll -prompt to re-enroll, since the account entered at the prompts becomes the new management account, drives Casper Remote crazy.

An example of what we've done in the past.

(1) Create an EA using API to pull the management account name for the computer in JSS:

#!/bin/bash

apiUsername="apiaccount"   
apiPassword="apipassword" 
jssBase="https://server.domain.com:8443"       

function getComputerUUID() {
  computerUUID="$( /usr/sbin/system_profiler SPHardwareDataType | /usr/bin/grep 'Hardware UUID' | /usr/bin/awk -F ' ' {'print $3'} )"
}
function getComputerManagementUserViaUUID() {
  computerManagementUser=`/usr/bin/curl -H "Accept: application/xml" -H "Content-type: application/xml" -skfu "${apiUsername}:${apiPassword}" "${jssBase}/JSSResource/computers/udid/${computerUUID}/subset/general" | xmllint --format - 2>/dev/null | awk -F'>|<' '/management_username/{print $3}'`
}

getComputerUUID
getComputerManagementUserViaUUID

if [ ! -z "$computerManagementUser" ]; then
    echo "<result>$computerManagementUser</result>"
else
    echo "<result>NotAvailable</result>"
fi

(2) Create a Smart Computer Group where that EA value is not the management account name.
(3) Create a policy, scoped to members of the Smart Computer Group, to install QuickAdd, which will set management account back to what it should be. Have the policy set to ongoing.

This way if anyone ever has to re-enroll a computer using sudo jamf enroll -prompt, it'll fall into the group and correct iteslf.

As @blackholemac mentioned, Casper Remote is well behaved as long as the management account in JSS is what it should be.

PS, my colleague @SeanA turned me on to the hidden sudo jamf reenroll -prompt option, not sure if that option preserves the original management account...haven't tested...would be cool if it did.

PS#2, the API stuff either lifted from forum posts, or cobbled together from same.

HTH,
Don

[pty10]

@blackholemac: Computers where re-imaged (using deploy studio) using the same management account

[pty10]

Thanks guys for the input and apologies for the late reply. Will look into this..