Error with Syntax. Error:You must provide a path to the PPD

@kegs5901

I took a look at your recent cases, but didn’t see one for this particular issue; I let your Technical Account Manager know about this thread since you’d mentioned you’ve spoken with us and haven’t yet had a resolution.

One thing that pops immediately to mind: If you go to Computer Management >> Printers >> Select the printer >> Definition, is the “Use generic PPD file” box checked?

Thanks!

Amanda Wulff
JAMF Software Support

Thanks for the reply Amanda. My account manger is out of the office right now.

To answer you, Yes. The box is checked by after i capture the printer. When I attempt to alter that and define a path I still get the same result. I also attempt to to upload a PPD and i get an error Stating "The file receive was invalid". I'm not sure if its an issue because ppd isn't in the file name or not. It looks like xerox removed the .ppd for some reason in their driver package. I talked to Matt Boyle yesterday briefly but haven't been able to follow up today due to other issues. Its the joy of being the only Mac Admin/Tech at my job.

@kegs5901

I was guessing that might be the case; we have a couple of open defects that describe the exact behavior that you’re seeing.

This sounds most like D-006326, possibly being caused by D-006653, if the printers are being added via the webapp instead of in Casper Admin or are being edited in the webapp after being added with Admin.

The workaround we have listed for D-006326, in my experience testing, doesn’t work 100% of the time, especially if we’re uploading/editing from the webapp.

However, if you’d like to give it a try, the listed workaround is to upload (or re-upload) the Generic.ppd file from /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Resources/Generic.ppd

I’ve had not 100% luck doing it through the webapp before, and did open a defect for that odd behavior when I ran into it as well (D-006653).

It should be noted, because of D-006653, which has behavior of edits made to packages and printers saving in the webapp but not saving to the distribution point, it’s not currently recommended to make edits to packages, printers, etc…though the webapp and I’d recommend we stick to using Casper Admin until we have that one fixed.

It doesn’t fail all the time, and the majority of the time it works just fine, and it seems to be pretty intermittent with no pattern as to when it will fail and when it will work as we expect, but it can save a lot of head scratching to both be aware of those two defects and to do the edits in Admin when possible just to avoid it entirely.

Both defects are still listed as open, so they’ll be an issue in 9.4 as well as in the 9.3x series when we ran into them initially.
Development is aware of the problem and they are working to get it fixed.

There are two other things we could try to get around it, if the workaround above doesn’t do it:

1) Try unchecking the “Use Generic PPD” box and see if it fills in the correct .ppd on its own. I had about 80/20 success using that method when I tested it.

2) The second option would be to temporarily put Casper Admin on a Mac that already has the printer(s) installed, and add the printers to the JSS using the Casper Admin application.
If there isn’t a Mac with the printer already installed, we’ll need to just manually install those printers on that Mac first, then use Admin to get them added to the JSS.

Please let us know if that gets it going.

Thanks!
Amanda Wulff
JAMF Software Support

@kegs5901

Found the case, and left some notes on it for Matt just to let him know about this thread and what it looks like we're running into here.

Amanda Wulff
JAMF Software Support

Repointing the printer via the webapp to the generic PPD works temporarily. I have only been using CasperAdmin to capture my printers, not the web app at all. i tried capturing two different printers from two different Macs and I see the same result. Which ever printer is captured last will work fine, but any previous captured printer turns red in CasperAdmin. I'm glad to see it's not just happening to me but disheartening to see it so random.

@kegs5901

Yep, that’s the exact behavior of the defects. Wish I had better news there, we know it’s a super frustrating one to run into, especially since it seems to manifest intermittently.

That seems to happen somewhat intermittently/randomly whenever we edit something that was uploaded or captured via Admin in the Webapp.

It is something development is aware of, and something I always remember as I ended up creating the defect after almost two weeks of trying to figure out what was going on in another customer’s environment with printers ‘disappearing’ or showing up in the webapp but throwing errors about files missing or not being found when they tried to install them.

For a few days, I think both the customer and I thought we were losing our minds as it seemed to be totally random as to when a printer would go red in Admin but still be in the webapp, until there was a, “…wait a minute…” moment during one of the WebExes. At that point, we figured out that it only seemed to happen if we made any edits to the captured printer in the webapp and saved them.

In that particular case, we were able to get around it by capturing in Admin and just never even going into the Printers section of the webapp after that. If a change needed to be made, we’d make the change on one of the Macs with the printer installed, delete the printer from Admin, and re-capture it that way.
I believe that particular customer also elected to take away permissions for those objects for all users but himself just to make sure nobody else went in to try and edit anything in the webapp (or even in Admin) without him knowing, since they’d have to ask for him to log in for them, but I do realize that that’s not feasible in all situations.

Were we able to test to see if unchecking the box for Use Generic PPD on captured printers made any difference?

That would still be only a workaround and it may pop up on and off in the future and require going through the workaround steps again (or possibly re-capturing it again), but it may be worth a shot to see if it lasts a bit longer.

I do apologize that we don’t have a more stable workaround; from the looks of the two defects, it seems that one directly affects the other, which is what makes the workaround need to be re-done now and again.

I’ll make sure the case that you’ve got open gets attached to the relevant defects for tracking and will update Matt to make sure he’s on the same page.

Thanks!

Amanda Wulff
JAMF Software Support

Thanks Amanda. Unchecking the Box didn't effect anything. The only way thing I was able to do was manually repoint them to the generic ppd file. It strange because I've never touched them in the webapp. They turn red after a few minutes of being captured via Admin for me. I guess I can try to disable to printer portion of the web app and see what happens.

@kegs5901

That's certainly odd; normally, when I've run into that it's been after an edit. I know it sounds ridiculous to ask, but we're also certain that nobody else is doing anything in Admin somewhere else at the same time, yes (always rule out the simple, silly things!)?

It might be worth putting the JSS into debug mode, then going through the steps to capture the printer in Admin, save it, and wait for it to go red just to see if we see any errors in the JSS itself.
Full debug will give us every tiny Tomcat message and MySQL query (and response) that's going on so hopefully something will show up in there.

I'll send instructions on how to do that on the case you have open with Matt.

Amanda Wulff
JAMF Software Support

I just went in and made sure no one other than myself and my backup have rights to use CasperAdmin. I'll try again and if there is still a problem, I'll turn on debug mode.

@kegs5901

Sounds good.

Matt and I are both watching your regular TAM's queue while she's out, so one of us will see the logs when they come in.

Thanks!

Amanda Wulff
JAMF Software Support

We're experiencing the same thing :(

JSS v9.22, setup 57 IP printers on a machine the used Casper Admin to import them into the JSS as normal.
20 of these printers go red, tried deleting them and re-adding them and they're fine for a short while, save and close Casper Admin and open up again an they're red again.

When I try to deploy via Casper Remote it fails as expected with "Error: You must provide a path to the PPD. "
PPD is listed in the printer record and when I try and upload it I get "The File recieved was not valid" if the PPD is compressed or not.

@steveadams

That behavior could be the defect mentioned in my previous replies, however, we've also found that it can sometimes be caused by MySQL's max_allowed_packet not being set large enough.

Try adding the through the webapp (not using Casper Admin at all) and see if it gives a proper error in the JAMFSoftwareServer.log; we currently have a defect where Admin will not write an error to that log and it makes it difficult to figure out.

However, the last time I saw the behavior you’re describing, it was because MySQL’s max_allowed_packet size was smaller than 512M. Once we tried adding the printer directly through the webapp, we were able to see the error that confirmed that in the JAMFSoftwareServer.log.

Thanks!
Amanda Wulff
JAMF Software Support

Thanks for the lightening fast response Amanda,
I'll give your suggestions a try and let you know how I get on

Hi Amanda,
I've created the printer in the JSS but wasnt able to upload the PPD in its compressed or uncompressed form for it (Its a Xerox ColorQube 9301) which would be a problem as well as not being able to set the defaults in CUPS.

Unless I'm missing something?

@steveadams

When you were unable to upload the PPD through the webapp, did it give an error telling you to look at the JAMFSoftwareServer.log for more information? If so, what was written to that log file?

The behavior you were describing, when it's caused by D-006326, has pretty easy workaround steps that are both in this thread and that it looks like you've already tried.

If changing MySQL's max_allowed_packet to 512M (for some printers, especially Xerox, we've seen failures if max_allowed_packet is 256 or under; by default, MySQL will either be set to 1M, 4M, or 16M.)from whatever it's at now didn't make a difference either, there's likely something else going on that will probably require at least a little bit of log file reading or taking a closer look at workflow or environment variables so it may be best to get in touch with your Technical Account Manager if you haven't already got an open case with them.

Thanks!
Amanda Wulff
JAMF Software Support

Hi Amanda,
AIl I got from trying to upload a PPD was "The File recieved was not valid" could it be because its a compressed GZip file?
I've had a look at the max_allowed_packet size and its set to 1GB.
I'll get hold of the JAMFSoftwareServer.log files and contact my Account Manager, thanks for all your help

@steveadams

That .gzip would be the problem!

The JSS is really looking for an actual .ppd file and it tends to not accept any other file format; is there a way you could get the actual PPD to use instead of the compressed file?

Amanda Wulff
JAMF Software Support

Based on the issues i am running into now, I'd say i am encountering that defect as well...

The problem i have is that due to the architecture and structure of the system the Web interface is the only way to upload printers and packages to JSS. I am slowly moving over packages and printers, while recreating the user focused Self Service environment i have now.

I figured Printers and Printer Drivers would be an easy way to get started and would also help to fine tune, Install and Uninstall logic for Users. But two printers into the migration and i keep getting the

There is a problem with your syntax. Error: You must provide a path to the PPD.

error message as well.

I attempted to Use the file path to the PPD/GZip PPD file since JSS is not liking the compressed or extension-less files for the upload option. And i when that didn't work i tried using the Generic.ppd since that was what it seemed like everyone else was using.

Are there any workarounds for a system that was designed to use the Web Interface as the primary point of entry?

Has anyone found a solution to this problem. It seems to be related to Xerox printers, as my company is replacing our Ricoh printers with Xerox printers and I am getting the exact same error message when attempting to add these new Xerox printers. While using Casper Admin 9.62 or using the JSS web interface.

Error: You must provide a path to the PPD.

We were on an older JSS version, was told there was a defect but couldn't upgrade so was forced to use lpadmin like this

lpadmin -L "<Location>" -v lpd://<IP of Printer> -P /Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 4260.gz -o printer-is-shared=false -o PageSize=A4 -o MediaType=SystemDefault -o MediaColor=Auto -o XRSeparatorMediaColor=Auto -E'

Are you also using Xerox printers??? I would like to know if this issue only occurs with these Xerox printers. I have found a script using the lpadmin command that allows me to add the printers that way instead.

Thanks for the help.