After 9.7 Upgrade no scripts will run using HTTP (path duplicates script name at end)

[aamjohns]

No scripts will run now. The paths appear to be incorrect. They all end in script.ext/script.ext

Example:

Downloading https://xx-xxxx-casper.xxx.xx.edu/CasperShare/Scripts/AppleUpdates.pl/AppleUpdates.pl...
Error running script: The script could not be found on the server..

In addition, as I have seen on other posts, any packages with spaces in the name will not run.

I hope this is fixed soon.

Thanks.

[msnowdon]

I just upgraded to 9.7 on Friday and I'm noticing that behavior as well. We have an internal server and an external server to process off site requests. For some reason some of the on site devices look to the external server which uses HTTP. Those devices seem to have their scripts and packages failing.

Thanks

Mark Snowdon

[aamjohns]

Hi Mark,
Do you specifically see the script name and extension twice in the path?

I first noticed packages were failing. That is when I got on here and saw that people had found if using HTTP deployment, packages with spaces in the file name failed. If I took out the spaces the packages then work.

But then I saw scripts were failing. And I don't know what to do to work around that. It just seems like the path is being created incorrectly.

Thank you,
Aaron.

[msnowdon]

Hi Aaron,

Yes I am seeing the the script name twice. I'm not even sure why some of my internal (on site) computers are looking to my external server first.

[aamjohns]

I am hoping this is patched soon. Thank you for sharing your information with me. Aaron.

[mm2270]

Thanks to both of you for posting this information. It will be interesting to hear if there is some specific environment variable causing this, or if its just a general defect in this version. Please do keep the community up to date on your findings. Have either of you filed a ticket with JAMF Support?

It kind of pains me to say it, but looking back on release history, we're likely going to skip any Casper Suite 9.x releases and wait for the 9.xx version from here on. It seems more often than not when that 2nd digit revs, too many critical things get broken.
Scripts not running from HTTP shares would completely derail us here with the amount of scripts we run as part of policies, so I'm glad we haven't done anything with this version yet.

[aamjohns]

Hi Mike,
I learned a lesson. I am going to start waiting to do upgrades. This is bad. I rely heavily on script and I'm pretty much out of commission.

No I have not created a ticket but I am going to do that now. I would have to assume this is known already but to play it safe I'm going to go ahead and put one in.

Thanks,
Aaron.

[mm2270]

I wouldn't make an assumption they know, so yes, I'd go ahead and put in a ticket as soon as possible. Honestly, if its a consistent issue that scripts are failing to run from HTTP/S shares, it seems almost serious enough to pull the update if you ask me. Its like saying that packages won't download. That's pretty major functionality. That is assuming its affecting any Casper Suite installation, and not just some. That might not be the case.

Just a question, but what OS is your JSS running on, and what OS are your distribution points on, assuming they are separate instances? I wonder if its only isolated to a certain OS type.

Also, it might be a good time to ask for a simple dev server setup to test out JSS upgrades on. Doesn't need to be anything super special. Ours is just a Mac mini sitting in a lab.

[rtrouton]

Having a test environment really helps with catching these types of issues. I upgraded my test environment to 9.7 and hit this similar-sounding issue there:

https://jamfnation.jamfsoftware.com/discussion.html?id=13952

Running into problems in a test enviroment means that my users weren't affected ny them, only me and my test machines. That can help reduce the stress level considerably when you hit problems, and helps remove time pressures from your troubleshooting.

Once you're satisfied you've got the problem sorted (either by JAMF releasing a fix or you developing a solution), you can then upgrade your production JSS.

[msnowdon]

My main internal server running the JSS is running Windows 2008 R2 and my external distribution point using HTTPS is running Windows 2012.

[aamjohns]

Hi Mike,
I've already sent in my report.

Yes, test environment excellent idea. Once you install the update and the binaries start upgrading, it is a mess to try and roll back. So I agree, a test environment is going to have to be in my future.

The JSS is running on Server 2008 R2. I only have one distribution point and it is on the same server. We have less than 100 devices in our environment at this time.

I still thinking waiting is just as helpful as a test server. There may be things I don't catch in my test environment that someone else does, and posts on here. I'm just saying it is good to utilize both resources. Sometimes I feel like I test in an 'ideal' environment so often I don't learn of an issue until it is out there and pops up in the real world.

Hopefully I will hear back before long. If not I will probably switch to SMB.

Thanks,
Aaron.

[mm2270]

Yeah, you'll get no argument from me here. Testing can catch issues, but it can only catch so much, which is part of why updates get shipped with issues. JAMF tests these updates thoroughly, but they can't possibly catch every issue that will show up in a real world setup. Still, you'd think something like scripts failing to run after the upgrade would have been seen internally, so its also just as good an idea to hold on any updates until the dust settles and issues get reported, or aren't reported.

We're also on Windows Server 2008 R2 for our JSS, but most of our DPs are on Mac minis, with the only exception being our external DP for the Limited Access JSS, also running on a Windows server. I wonder if HTTP running on a Windows server has something to do with the duplication of the script names in the path, since both you and @msnowdon are using Windows 2008 R2 for your DPs. Interesting.

Whatever it is, something obviously changed with 9.7, so JAMF is going to need to look into it. Hopefully soon.

[were_wulff]

@aamjohns @msnowdon

We were able to replicate the behavior you’re describing here in house and I got it filed this morning. For reference, the defect ID is D-008907.

Migrating your packages and scripts should take care of the issue you’re seeing with the scripts. In the testing we did yesterday, everything worked as expected after the migration.

We have a short KB article on migrating packages and scripts here.
I would encourage you to read through it as, after the migration, there will be a couple of minor changes to how we deal with scripts using the JSS.

If you open up Casper Admin, there should be a Migrate button near the upper right. I’ve attached a screenshot below just for a reference. Clicking that button will migrate your packages and scripts.

If you do NOT see a Migrate button, please contact your Technical Account Manager as we may have to manually get it back through running a couple of commands in MySQL.

If you have additional questions, please feel free to either ask here or get in touch with your Technical Account Manager by giving them a call, sending an e-mail to support@jamfsoftware.com, or by using the My Support section of JAMF Nation.

Thanks!
Amanda Wulff
JAMF Software Support

[mm2270]

@amanda.wulff Thanks for the info as always.
So, this is only an issue if the scripts are still physical files in the CasperShare and not migrated into the db? If so, then for us this is a non-issue, so that's good information.

I would encourage both @aamjohns and @msnowdon to follow Amanda's instructions and migrate your scripts into the db. In addition to making the use of scripts more reliable, it makes editing and adding scripts to the JSS a breeze in comparison to needing to upload individual script files. You'll be much happier with the setup afterwards.

[CasperSally]

There was a reason I didn't migrate when I upgraded to 9.x.. now I just wish I remember what it was. There's no easy way to test the ramifications of doing it in test env.

[were_wulff]

@mm2270

From what I saw in my testing, it only seems to be an issue if the scripts are still physical files on the CasperShare; once I hit the Migrate button and the scripts moved to the database, they all worked as expected.

The main thing to be aware of, with the migration, is that compiled scripts no longer work and will need to be converted.

We have a KB on converting AppleScripts from .scpt to .applescript, which would be something that would need to be done in the event that someone is using compiled scripts.

Other than that, the changes that happen after migrating packages and scripts are detailed in this KB.

Amanda Wulff
JAMF Software Support

[msnowdon]

@amanda.wulff

I have several scripts that mount network shares using the jamf mount command. These were working great until I upgraded from 9.62 to 9.7. There are no spaces in the script names. In the policy logs, they show as complete but do not show up on the desktop. I have an MCX setting to show all server mounts on the desktop. I do see my home directory get mounted but none of the other shares.

The strange part is that if I open the Volumes folder on the client, it will show the network shares in there and I disconnect myself from the network, they will show as getting interrupted.

So it seems like its working, yet I dont see them on the desktop or in the sidebar of Finder.

Thanks

Mark

[jaferguson]

I don't want to migrate because I would no longer be able to use my non-flat packages.

I have several mission critical scripts that quit functioning due to the same defect reported here.

I have condensed several of them to one line commands and placed them in the "Files and Processes -> Execute Command" I don't like having to do that but it is working on the critical Policies.

Jim

[mm2270]

@jaferguson What do you mean you can't use your non flat packages? They just get zipped when they are added to your repository. We continue to use non flat packages in many cases, and others are flat, but both work in our case after migrating. The bundle style packages get added to our CasperShare as zipped files, but they still work.

[aamjohns]

@Jim,
I can understand why you do not want to update. I am curious about your script issue. Are these stand-alone scripts? Is there any pattern? Like script language or anything? You have me worried now. I migrated my scripts this morning but there are so many I have no way of knowing if any of them have stopped functioning.

I just wondered what would cause a text based script to stop working when stored in a db. Could it be encoding? I'm just wildly guessing here but if the encoding format was different somehow I could see how that would break a script.

I guess I will just have to start going through them one by one and testing.

Thanks,
Aaron.

[aamjohns]

@Jim,
Also, when you say they quit working, do you get errors in the log? Any indication why they are not working? Or do they not run at all?

[were_wulff]

@mm2270

@jaferguson may be referring to this bit in the KB article I linked earlier:

You are no longer able to deploy non-flat PKGs using Casper Imaging v8.5 or earlier, or Casper Remote v8.x.

In that particular situation, non-flat PKG files would not be able to be deployed.

If we're not using an 8.x version of Remote or Imaging 8.5 (or earlier), there shouldn't be problems with non-flat PKG files.

Amanda Wulff
JAMF Software Support

[CasperSally]

I'm also confused about the non flat packages. Can someone enlighten me? I'm not sure which of my packages are non-flat :(

from the KB Amanda linked to "You are no longer able to deploy non-flat PKGs using Casper Imaging v8.5 or earlier, or Casper Remote v8.x."

Does this mean they work with Casper imaging/Remote 9.x?

[mm2270]

@amanda.wulff thanks for the clarification. I wasn't even aware of that particular issue, but it begs a question... is there a valid reason anyone would be on Casper Suite/JSS 9.x and using Casper Imaging and/or Casper Remote 8.x? If there's a reason for this, I can't think of it. It seems like a recipe for problems to me.
I can see perhaps being a rev or two behind but still using a 9.x version, but to be using an 8.x version of those apps.. honestly I'm surprised they work at all!

[were_wulff]

@mm2270

After doing some poking around, the only reasons we could come up with here as to why someone might be using a 9.x JSS and Casper Imaging or Casper Remote 8.x were:

1) Using a Netboot image that was never updated away from the old version of Imaging.

…and that was it, really! It's a fairly easy thing to overlook, especially if imaging is something that's usually a 'once or twice per year' situation and, as long as it works, it may not even be noticed that the version of Casper Imaging vs. the JSS are different.

Using a version of Casper Imaging that is 8.5x or older may result in the imaged devices getting a binary that could not be upgraded to 9.x, however, so if that were the case it’s likely someone who was doing that would have opened a support ticket and had the issue taken care of by upgrading the version of Casper Imaging on their Netboot image.

If those older versions of Imaging or Remote still work without issue with certain versions of 9.x, it would likely be a situation of, ‘just forgot to upgrade the apps’, which happens fairly often. I'm guilty of having done that more than once!

While there may be specific troubleshooting situations in which we might recommend using a slightly (typically within 2-3 versions) older version of a Casper application as a temporary workaround for an issue, we would not recommend using 8.x Casper applications with a 9.x JSS, as it may cause unexpected (and probably undesirable) behavior.

Amanda Wulff
JAMF Software Support

[chriscollins]

@CasperSally If you can right click on a package and do a "Show Package Contents" and actually browse around inside the .pkg file since its really a directory, then its not flat. If you upload a package into a v.9x version of Casper Admin and it zips up the file and adds the .zip extension on to the end of it, then its not flat. (Casper will download that .zip file and unzip it locally on the machine, then install the package.)

If you are using version 9x of Casper you shouldn't ever have to worry about that being an issue for you.

[mm2270]

Yes, I suppose if Casper Imaging continues to work with the upgraded JSS, then I guess it could be overlooked. It would, I imagine, eventually get you though, as at some point the version drift is sure to create some headaches, not to mention that features or critical bug fixes may get added to the new version that won't be available to the admin still using the older version. A prime example is the fix for Yosemite's Core Storage volume format out of the box with new systems. Casper Imaging 8.5 isn't going to know how to handle that and the admin will have imaging problems. (I guess it would then get updated though)

If its an oversight, that's one thing, but I would hope there isn't anyone out there actively trying to stay on an older version of those applications. That doesn't sound like a good idea. :)

[bentoms]

@amanda.wulff Migrating scripts to the DB keeps the originals on the share, but makes a copy in the DB & all new scripts are then only in the DB.. Right?

Also, does that mean a client will run the script from the JSS & not a local DP UNLESS that DP is a JDS?

[jaferguson]

@aamjohns - Arron - I have been experiencing the same problems as described by Mark Snowdon in his second post above, including the duplication of the script name in the log file.

@Amanda Wulff - With respect to the non-flat packages, I may have misunderstood what difficulties migrating may or may not cause me.

@CasperSally - some of my installer packages include pre and/or post install scripts... Composer indicates that these cannot be compiled as flat packages. Since my background is as a kindergarten teacher I will admit to ignorance for the exact definition of a flat or non-flat package. By far the majority of my packages are in fact dmgs rather than pkgs so not migrating for that reason may in fact be bogus.

[bentoms]

FWIW.. seems like this is an issue on 9.71 too.

[bentoms]

@amanda.wulff Migrating scripts to the DB keeps the originals on the share, but makes a copy in the DB & all new scripts are then only in the DB.. Right?

Also, does that mean a client will run the script from the JSS & not a local DP UNLESS that DP is a JDS?

[bentoms]

Has this been resolved in 9.72?

[fuzzylogiq]

Trying to get clarification from JAMF on this today, as it only says that the other defect around spaces/special characters in filenames has been fixed in 9.72

[mmacpherson]

Anyone have updates on this issue? I am seeing it with a script I just tried using to set the computer name to DNS name. This script I need is a result of my computer names randomly getting changes to "localhost." I have a simple script to set the computer name to the dns name then update the name in jamf, but it keeps failing.

Executing Policy Set Computer Name to DNS Name
Creating directory structure for /Library/Application Support/JAMF/Downloads/
Downloading https://10.193.58.11/CasperShare/Scripts/setcomputername.sh...
Error running script: The script could not be found on the server..