Casper Imaging - the script could not be found

[scharman]

Hi all I am having an issue when imaging my macs, if I try a include a postflight script to call on other settings and software updates I get an error in my jamf.log saying

The script could not be found.

All other packages work fine and these scripts work fine if deployed via a policy or ran manually in the terminal.
the only information I found so far is https://jamfnation.jamfsoftware.com/article.html?id=151 which assumes theres an error with the script itself,
I'm running 9.81.
Any ideas?

[Look]

Are you setting the script to run After Restart? scripts run directly during imaging tend to behave a bit wonky, included in imaging but set to run After Restart tends to work pretty reliably.

[scharman]

Yep, At reboot, it seems the script(or any scripts) isnt making its way into FirstRun: /Library/Application support/JAMF/FirstRun with the packages to be installed. The scripts are definitely on the share as they run fine in a policy.
Could this be a permissions issue?

[Look]

Are the scripts stored on the share or in the database.
We had the option to migrate them during one of the upgrades and did so without any issues. It seems to be better this way as they are always available even when the distribution points aren't.
We are on 9.81

[scharman]

Casper admin says stored in database for all scripts

[Look]

Thats very odd, I frequently use scripts from the database set to run at reboot without issue.

[scharman]

trying again with one uploaded to the share with 777 permissions applied, seeing if theres any difference

[Look]

You don't just create / paste them straight into the JSS through the web interface? I always do it that way, perhaps it makes a difference.

[scharman]

Yep i normally do, yet trying a different way

No go

still get the same error,

opened the jamf.log when it was installing all the First run packages, packages installed without an issue, then it reached the script and threw the same error again.

[scharman]

[scharman]

Ok, after a bit more testing I got it to find the script

had to keep just the script in first Run section with no packages in there,
it still failed though with the error
Could not connect to the JSS. Looking for cached policies...

So its a bit of a step in the right direction, yet still not working, it can connect to the JSS for other polices, any ideas?

[Look]

Will think on it and if anything comes to mind will let you know, it's pretty odd it connects for somethings but not others!
One thing we have in our work flow just because it seemed to help and machines sometimes didn't in enroll is we have the QuickAdd set to run on reboot as well.

[RobertHammen]

Just ran into this same issue with Casper Imaging 9.93. 3 scripts set to run At Reboot. Configuration is Base OS, AD bind, 33 packages all set to be installed after imaging. Everything works up until it is supposed to run the 3 scripts, then "There was an error. The script could not be found." Scripts stored in DB/if I create a policy scoped to my freshly-imaged Macs, with the 3 scripts as part of it, they run successfully... seems like a bug or issue with Casper Imaging. Tomorrow I'll try re-imaging the Mac and checking the FirstRun directory and see if they are actually there...

[evrenvarol]

Just ran exactly same issue and after doing some troubleshooting, I have found the '/' characters in the script name was causing the issue.

I have renamed my "Disable Apple iCloud / Diagnostics / Siri / TouchID Prompts" script to "Disable Apple iCloud - Diagnostics - Siri - TouchID Prompts" and it worked without any issues.

[dzhang]

Hi Guys, this issue happens on our site after upgrading from 9.92 to 9.97, there are some scripts could not be copied to First Run folder during Casper Imaging version 9.97, if i check the log, it shows The script could not be found. or Could not download "the script" to the cache in Casper imaging log. I have tried changing script names , re-editing , or creating new script with same codes in , the issue still occurs. But the scripts in the policies work, has anyone solved this issue?

[gachowski]

@dzhang

Are using 9.97.1488392992? if so reach out to jamf. I think it's a known issue.. I don't have the defect ID with me sorry.

I made a .dmg of the scripts without the .sh and then add that to my prestage.

It will also work if you don't have it set to auto run. : ) You have configure it to require you to log in to Casper imaging.

C

[dzhang]

@gachowski

Yes, we are using 9.97.1488392992 now, we have this issue since the previous version 9.97.1482356336. After upgrading to 9.97.1488392992, the issue has not been solved. I have already reached out to Jamf support, hopefully they can help solve the issue.
I will try your method if needed, thanks for your help Chris.

[neilmartin83]

Also noticing this only with autorun imaging, since upgrading to 9.97.1488392992 (was working in 9.97.1482356336). We have a first run script that runs at reboot. Have tried renaming the script, getting rid of spaces, replacing them with underscores etc to no avail.

[CasperSally]

Just as a data point, we didn't migrate in casper admin (I know, I know) so our scripts are outside our db... am not seeing this issue.

[gachowski]

@dzhang

Here is the defect number PI-003666

@neil.martin83

Jamf support said the issue is in prestage and autotrun, I also see the issue with scripts added in a configuration.

It's an easy fix to just build a .dmg with the scripts and put them in the same location. I had to remove the .sh to get it working.

C

[musat]

Ugh, we have several scripts that run at imaging. Now to go and package all of those scripts to fix this.

One question about having a defect number. Is this just to be able to have the information when contacting my TAM? Or is there a web site that I can search on that defect to see the status?

[neilmartin83]

9.98 released but no mention of PI-003666 in the release notes. http://docs.jamf.com/9.98/casper-suite/release-notes/Bug_Fixes_and_Enhancements.html

Ho hum.

[neilmartin83]

9.98 released but no mention of PI-003666 in the release notes. http://docs.jamf.com/9.98/casper-suite/release-notes/Bug_Fixes_and_Enhancements.html

Ho hum.

[musat]

@gachowski, When you say to create a dmg of the scripts in the same location, what location is that? I am guessing you mean to just package those script files to some particular folder so that when the imaging process gets around to running them it can find them, but what location is it looking to find them in?

[gachowski]

Double check my my work but it should be

/Library/Application Support/JAMF/FirstRun/PostIntall/Resources

[musat]

Was just coming back to say that I just interrupted imaging a Mac here and looked through the scripts and found that same location that you found. I am in the process of packaging my scripts and adding it to my image configuration.

[musat]

Ok, that worked. I downloaded all of the scripts from the webpage (we reference 6 in our image configurations) and removed the '.sh' that was added during the download. Then packaged all of these scripts in Composer, putting them in the /Library/Application Support/JAMF/FirstRun/PostIntall/Resources folder. I then uploaded this packaged DMG to the server using Casper Admin, and set it to Priority 5 (before anything else) and Install on Boot. The final step was to add this DMG to all imaging configurations. After doing this, imaging is now working properly again. Thankfully, none of these scripts change, so I shouldn't need to update this package before Jamf gets the issue fixed.

Thanks so much for the suggestion and the follow nudging into the right direction. This was going to be a pretty major issue for us if we hadn't had a workaround.

[jmahlman]

I just told my TAM that I'm also having this issue. I'm trying the DMG workaround now.

It really is bad that this wasn't listed in the known issues for 9.98, if we would have known this we would never have upgraded.

[CypherCookie]

@jmahlman This one of several issues that were closed off in previous versions of the JSS, only to be reintroduced back in since (from what i can see) 9.97.1488. Currently I have 3 calls open for problems which had been previously fixed in previous JSS versions.

[jmahlman]

After reaching out to jamf I was sent this response:

We have noted that you are affected by this particular product issue. I did want to let you know that this issue is not planned to be fixed because it is related to a security hole that we fixed in our 9.97 hot fix. We are advising users to instead deploy scripts via a package after enrollment so that we can proceed with the automated imaging and not requiring authentication when Casper Imaging is opened up.

So this isn't a bug...it's a feature.

The workaround we went with was putting the script in a pkg as a postinstall script. Works fine for us, luckily we have only one script at image time.

[LRZ_Jamf]

In regards to your questions, the Product Issue: PI-003666, was marked as Closed, with no fix. The reason why this happened is that this workflow creates a Security Risk, and for that reason it was closed with no fix. The workflows accepted for this are following: 1 Use Composer to deploy a script to a temp directory and then add a post install script to execute the script and then delete the script from the temp directory once complete. 2 Execute the scripts via a Package, Policy 3 Configure Prestage so that Account Information is not Passed Automatically, that will require the Technician to manually authenticate into Casper Imaging and start the process of imaging. This will not break then the download for the Scripts during Imaging [...] You are correct, but due to this being flagged as a Security Risk only since 9.97, after longer testing, and consideration for Security, it was decided to apply this since 9.97 only. About the option to use Scripts during Imaging, while having Autorun option enabled, I would assume it will be removed, or changed accordingly in a future release (can't estimate or give a sure answer on an ETA for this though).

According to this, I'd say all people who used "flushPolicyHistoryAtReboot" within their (re-)imaging Workflow have a problem now.

And if I remember right, you cant change autorundata by API?!

[jrippy]

@jmahlman Thanks for sharing.
I was hit with this fairly early as we moved from 9.91 to 9.97.1488392992 very shortly after release. I thought it was just a bug and was told it was related to the security fixes they were trying to implement. My support person was just as puzzled as I and thought it would be fixed fairly quickly. Until that time, we reverted to 9.91, then went back up to 9.97.1428356336 which we had been testing. We only opted for the newer hotfix given the urgency jamf was pushing on it.

Then like others, I saw it was not addressed in 9.98 so I reached out and confirmed it was still an issue that hadn't been addressed.
However, this is the first I'm hearing it won't be fixed at all.
I understand they discovered the issue with scripts but jamf's communication on this specific issue has been horrendous.
This should have been front and center on the 9.98 notes after the decision was made not to fix it as it was now intended behavior.

I'm really displeased in how they have handled this situation and given us the (lack of) information we need to move forward with the 9.98 release in our environments.

[tim_rees]

I normally don't come on here to whinge... but...

What the hell JAMF?????!!!!!

way to comunicate!

Can someone please confirm that the scripts now need to be in /Library/Application support/JAMF/FirstRun as an .sh file? (deployed by DMG at imaging I expect). This is what I have gathered from the rest of this post. I'll be testing it this afternoon if I can't get around it any other way first!

Thanks!

[CasperSally]

Maybe jamf should provide a button to 'unmigrate' scripts out of the database to avoid this "working as designed" behavior. I assume that's why I'm not seeing this - haven't clicked the migrate button yet. Scripts are copied down as part of imaging and ran locally versus getting them out of the db.

[barnesaw]

@CasperSally That shouldn't be an option, that should be a REQUIREMENT. Since they see this as a security issue, the scripts should be copied down by Imaging.

Telling us to "Use Composer to deploy scripts" is a crapshoot hack, since it implies that our scripts never change. Mine change regularly. Though I have not been bit by this particular defect yet, I would love an option to pull my scripts out of the db so that I can actually do change management on them.

[marklamont]

I just followed @musat 's advice and it worked a treat.
created script files of all the required scripts.
Added them to a package in composer like so
Made sure the permissions were set like so

Saved as a dmg
Load into jamf and set to install after reboot and priority 1

added that into the configuration and off you go.

[snovak]

I love finding this sort of stuff just before we start imaging labs for the Summer.

So fun.

[jrippy]

@snovak Hey, at least you did find it BEFORE imaging.
It's worth it to delay a week and get it right then realize you have to go back and do it all again!
Good luck

[skinford]

@jmahlman Glad I read this and was pointed to it by another JAMF user. I've never built a script package and post install, how would I go about doing that? I have 8 scripts to run. Do you have a post somewhere describing that.

Thank you for your assistance, have a great day today!

[gachowski]

This might help

https://soundmacguy.wordpress.com/2017/04/05/casper-imaging-wot-no-scripts-after-autorun/