Running sudo jamf manage seemed to fix 1 computer for me so far. No idea about any others yet.

@scottb - this error is occurring for me on 10.10...

@jordanfleuriet - FWIW, I saw that too on 10.10.5 with both 9.8 betas. Not running 9.8 release.

9.81 beta on on both 10.10 and 10.11 so far work.

This is happening to me as well on a 10.10 client. Somehow I missed this thread before the upgrade last night, and running "sudo jamf manage" did not fix the issue for me, I had to follow the process @jordanfleuriet posted above.

My client seemed to be pulling policies, but if it cannot download the script, it would be hard to automate. Ugh.

I upgraded to 9.8 today and set up a policy to run the following script on Macs that now had the 9.8 agent. The launchdaemon and accompanying script created by running this script verifies that the Mac can communicate with the Casper server. Once communication is verified, it takes the following actions:

1. Runs jamf manage to enforce Casper management (which reportedly fixes this issue and isn't otherwise harmful.)
2. Runs recon to send an updated inventory to the JSS, to report that the fix has happened.

In the event that the machine isn't checking in, this script could also be run via ARD or installed with a payload-free package.

#!/bin/bash

# If any previous instances of the postcasper98upgrade LaunchDaemon and script exist,
# unload the LaunchDaemon and remove the LaunchDaemon and script files

if [[ -f "/Library/LaunchDaemons/org.github.postcasper98upgrade.plist" ]]; then
   /bin/launchctl unload "/Library/LaunchDaemons/org.github.postcasper98upgrade.plist"
   /bin/rm "/Library/LaunchDaemons/org.github.postcasper98upgrade.plist"
fi

if [[ -f "/var/root/postcasper98upgradefix.sh" ]]; then
   /bin/rm "/var/root/postcasper98upgradefix.sh"
fi

# Create the postcasper98upgrade LaunchDaemon by using cat input redirection
# to write the XML contained below to a new file.
#
# The LaunchDaemon will run at load and every ten minutes thereafter.

/bin/cat > "/tmp/org.github.postcasper98upgrade.plist" << 'CASPER_POST_UPGRADE_LAUNCHDAEMON'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>org.github.postcasper98upgrade</string>
    <key>ProgramArguments</key>
    <array>
        <string>sh</string>
        <string>/var/root/postcasper98upgradefix.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>StartInterval</key>
    <integer>600</integer>
</dict>
</plist>
CASPER_POST_UPGRADE_LAUNCHDAEMON

# Create the postcasper98upgrade script by using cat input redirection
# to write the shell script contained below to a new file.
#
# You will need to change the "jss_server_address" variable in the
# script below. Please put the complete fully qualified domain name 
# address of your Casper server.
#
# You may need to change the "jss_server_port" variable in the
# script below. Please put the port number of your Casper server
# if it is different than 8443.

/bin/cat > "/tmp/postcasper98upgradefix.sh" << 'CASPER_POST_UPGRADE_SCRIPT'
#!/bin/bash

#
# User-editable variables
#

# For the jss_server_address variable, put the complete 
# fully qualified domain name address of your Casper server

jss_server_address="casper.server.goes.here"

# For the jss_server_address variable, put the port number 
# of your Casper server. This is usually 8443; change as
# appropriate.

jss_server_port="8443"

CheckBinary (){

# Identify location of jamf binary.

jamf_binary=`/usr/bin/which jamf`

 if [[ "$jamf_binary" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ ! -e "/usr/local/bin/jamf" ]]; then
    jamf_binary="/usr/sbin/jamf"
 elif [[ "$jamf_binary" == "" ]] && [[ ! -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]]; then
    jamf_binary="/usr/local/bin/jamf"
 elif [[ "$jamf_binary" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]]; then
    jamf_binary="/usr/local/bin/jamf"
 fi
}

CheckSiteNetwork (){

  #  CheckSiteNetwork function adapted from Facebook's check_corp function script.
  #  check_corp script available on Facebook's IT-CPE Github repo:
  #
  # check_corp:
  #   This script verifies a system is on the corporate network.
  #   Input: CORP_URL= set this to a hostname on your corp network
  #   Optional ($1) contains a parameter that is used for testing.
  #   Output: Returns a check_corp variable that will return "True" if on 
  #   corp network, "False" otherwise.
  #   If a parameter is passed ($1), the check_corp variable will return it
  #   This is useful for testing scripts where you want to force check_corp
  #   to be either "True" or "False"
  # USAGE: 
  #   check_corp        # No parameter passed
  #   check_corp "True"  # Parameter of "True" is passed and returned


  site_network="False"
  ping=`host -W .5 $jss_server_address`

  # If the ping fails - site_network="False"
  [[ $? -eq 0 ]] && site_network="True"

  # Check if we are using a test
  [[ -n "$1" ]] && site_network="$1"
}

CheckTomcat (){

# Verifies that the JSS's Tomcat service is responding via its assigned port.


tomcat_chk=`nc -z -w 5 $jss_server_address $jss_server_port > /dev/null; echo $?`

if [ "$tomcat_chk" -eq 0 ]; then
       /usr/bin/logger "Machine can connect to $jss_server_address over port $jss_server_port. Proceeding."
else
       /usr/bin/logger "Machine cannot connect to $jss_server_address over port $jss_server_port. Exiting."
       exit 0
fi

}

CheckLogAge (){

# Verifies that the /var/log/jamf.log hasn't been written to for at least five minutes.
# This should help ensure that jamf manage can run and not have to wait for a policy to
# finish running.

jamf_log="/var/log/jamf.log"
current_time=`date +%s`
last_modified=`stat -f %m "$jamf_log"`

if [[ $(($current_time-$last_modified)) -gt 300 ]]; then 
     /usr/bin/logger "Log has not been modified in the past five minutes. Proceeding." 
else 
     /usr/bin/logger "Log has been modified in the past five minutes. Exiting."
     exit 0
fi

}

UpdateManagementAndInventory (){

# Verifies that the Mac can communicate with the Casper server.
# Once communication is verified, it takes the following actions:
#
# 1. Runs jamf manage to enforce Casper management 
# 2. Runs a recon to send an updated inventory to the JSS to report
#    that the OS upgrade has happened.
#

CheckBinary

jss_comm_chk=`$jamf_binary checkJSSConnection > /dev/null; echo $?`

if [[ "$jss_comm_chk" -gt 0 ]]; then
       /usr/bin/logger "Machine cannot connect to the JSS. Exiting."
       exit 0
elif [[ "$jss_comm_chk" -eq 0 ]]; then
       /usr/bin/logger "Machine can connect to the JSS. Enforcing management and updating inventory."
       $jamf_binary manage -verbose
       $jamf_binary recon
fi
}

SelfDestruct (){

# Removes script and associated LaunchDaemon

if [[ -f "/Library/LaunchDaemons/org.github.postcasper98upgrade.plist" ]]; then
   /bin/rm "/Library/LaunchDaemons/org.github.postcasper98upgrade.plist"
fi
srm $0
}

CheckSiteNetwork

if [[ "$site_network" == "False" ]]; then
    /usr/bin/logger "Unable to verify access to site network. Exiting."
fi 


if [[ "$site_network" == "True" ]]; then
    /usr/bin/logger "Access to site network verified"
    CheckTomcat
    CheckLogAge
    CheckBinary
    UpdateManagementAndInventory
    SelfDestruct
fi
exit 0
CASPER_POST_UPGRADE_SCRIPT

# Once the LaunchDaemon file has been created, fix the permissions
# so that the file is owned by root:wheel and set to not be executable
# After the permissions have been updated, move the LaunchDaemon into 
# place in /Library/LaunchDaemons.

/usr/sbin/chown root:wheel "/tmp/org.github.postcasper98upgrade.plist"
/bin/chmod 755 "/tmp/org.github.postcasper98upgrade.plist"
/bin/chmod a-x "/tmp/org.github.postcasper98upgrade.plist"
/bin/mv "/tmp/org.github.postcasper98upgrade.plist" "/Library/LaunchDaemons/org.github.postcasper98upgrade.plist"

# Once the script file has been created, fix the permissions
# so that the file is owned by root:wheel and set to be executable
# After the permissions have been updated, move the script into the
# place that it will be executed from.

/usr/sbin/chown root:wheel "/tmp/postcasper98upgradefix.sh"
/bin/chmod 755 "/tmp/postcasper98upgradefix.sh"
/bin/chmod a+x "/tmp/postcasper98upgradefix.sh"
/bin/mv "/tmp/postcasper98upgradefix.sh" "/var/root/postcasper98upgradefix.sh"

# After the LaunchDaemon and script are in place with proper permissions,
# load the LaunchDaemon to begin the script's execution.

if [[ -f "/Library/LaunchDaemons/org.github.postcasper98upgrade.plist" ]]; then 
   /bin/launchctl load -w "/Library/LaunchDaemons/org.github.postcasper98upgrade.plist" 
fi 

exit 0

I am not seeing this issue with 9.8 in our DEV JSS environment (Red Hat Linux)

I am able to do Casper Imaging, run policies via triggers, and use Self Service 9.8,logged in via AD user name, and thus getting AD security groups (this has broken on upgrades in the past).

I am getting apps installed via Self Service, and I have a 8-10 GB Adobe CC 2015 install coming down and it is actually installing. Often times when Self Service is funky, that is where I see issues.

Is there a specific thing within / related to Self Service?

I was going to update our PROD JSS tonight, should we wait for 9.81

Thx,

johnk

@johnklimeck If history indicates anything, JAMF will probably release 9.81 when OS X 10.11 releases which is currently slated for Sept 30th. That's 6 days from today.

good point

So, it looks like I was premature, now for whatever reason, I cannot install / run anything from Self Service, in 9.8

sudo jamf manage Error installing the computer level mdm profile: profiles install for file:'/Library/Application Support/JAMF/tmp/mdm.mobileconfig' and user:'root' returned -915 (Unable to contact the SCEP server at “https://server.domain.com:8443/CA/SCEP”.) Problem installing MDM profile. Problem detecting MDM profile after installation.

This is on a test 10.11 Mac, that's what 9.81 is probably for.

I may just wait for 9.81

This is a known issue with the 9.8 binary which causes a partial migration from the old location to the new. When this issue is encountered, it causes the launchd services that we use to manage a machine to point to the old location after the executables have been migrated. We depend on these services for various things to work, such as recurring checkin, and installing policies through self service. We have been able to reproduce the issue at JAMF and are working on a fix. In the meantime, if your affected machines have SSH enabled, the most efficient thing to do would be to use Casper Remote or a script to remote into each machine, one by one, and run the following commands:

rm -rf /Library/LaunchDaemons/com.jamfsoftware.checkForTasks.plist
jamf manage -rebootIfNeeded -deleteLaunchdTask

and then reboot the machine. This will ensure that the launchd services are pointing again to the correct location, and that they are reloaded. I apologize for the inconvenience, and thank you for your patience while we work to resolve the issue.

Hi again!
We can't see a common denominator what has caused this - different OSs, different networks, different uptimes. Of over 900 machines, a minority has failed, but we don't have any exact numbers yet. I'm currently doing recon on all machines via Casper Remote, @bollman having added a new EA which checks for com.jamfsoftware.task.checkForTasks.plist.

There are several problems with this method of checking, of course, since many computers last reported in from a WiFi or home network. We need to replace all IPs in the database with their registered fixed IPs to contect all of them when at work.

Also, the fix posted by @Ghanbarzadeh works, but we will need to ask all users to reboot their computers, since the reboot script will not run. We can't do a shutdown -r +1 on all computers without warning the users. At the same time, we can't really call 100-200 users (guesstimate) and ask them to reboot. Sure, we can throw up a Management Action that asks them to do it, but you know how users tend to ignore those messages.

Thing is, the problem is huge in itself, but it becomes an even bigger issue for us, since we sync the computers' Home Folders on a jamf trigger. This means that a big number of users no longer will receive file sync and backup. This has the potential to really hurt our reputation with the userbase.

Note!
The file is called: com.jamfsoftware.task.checkForTasks.plist
not com.jamfsoftware.checkForTasks.plist as Ghanbarzadeh stated.

I did a fresh reimage this morning (wipe and reload) of 10.11 and 9.8, I had the SS issue. I tried @Ghanbarzadeh 's commands and @bollman 's version, rebooted and neither way solved the issue for me.

It might be worth trying @rtrouton's CasperCheck as an automated solution to the issue:
https://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/

Correct me if I'm wrong but if you've already upgraded to 9.8 and don't already have @rtrouton's CasperCheck in place then there really isn't a way to get it deployed to the machines that are experiencing the problem. Short of using ARD, SSH or physically touching the affected computers.

Correct, and that's where the real hurt is.

Machines actually responds to Casper Admin, so, right now we are pushing a recon with an EA that checks for that file.
That only works if the computers are reachable and all the laptops spread around the world will not be easy to assess. I'm guessing, next week we'll send an email to people who we have no update from and ask them to run something from Self Service. If that fails, we know they need the fix.

Still, since most of our users aren't admins, that means we have to find a way to apply the fix...

Would it be be possible to use Casper Remote to send the commands line by line (Advanced tab)? It would be arduous but would not require a download AFAIK.

Yes, we are planning on doing that, but there is no way to nicely ask the users to restart, other than using phone or email. It's not possible to use the jamf binary to restart nicely, it doesn't work in the state things are, the screen only flickers.

I would do just sudo jamf manage for the second command and send a message to affected users to restart at their convenience, if feasible.

You could run a script command to send up a jamfHelper dialog explaining they must restart. Or cocoaDialog if you have that installed. Yes, its more commands you need to run, but it might be better/faster than getting on the phone with every user.

All I can is I'm very glad we decided to wait on upgrading our JSS to 9.8. We didn't see the need since it was mostly to support iOS 9, and we don't manage iOS devices with Casper here. Patiently waiting for 9.81 to see if this is resolved. Honestly, I know bugs happen, but a bug like this is very troubling and not acceptable in my opinion.

There are a million ways to tell the user to restart, the number one problem is to get to the computers! As long as they are here at the uni, no problem, but so far we have made contact with 284 out of 906 computers :(
254 with working recurring and 30 without.

Guys,
remember that if you are deploying @rtrouton 's solution (i have been using it for a while),
that you make sure your copy is updated to look for the jamf binary in the right locations going forward...

To follow up on @kstrick , I've got a post discussing the updated script available here:

https://derflounder.wordpress.com/2015/07/29/updated-caspercheck-now-available/

Latest rev of CasperCheck is available from here:

https://github.com/rtrouton/CasperCheck

Our self service policies are failing to run unless done as an admin. 9.8 go figure.