Has anyone ever seen an issue where you can print from crystal preview, but you can’t print from auto print direct to APM. Just randomly this morning it stopped working. Jobs printed directly to APM from Epicor or printed from crystal preview hit the spooler and are picked up, but for some reason they vaporize when printed direct, but are printed and routed when printed from print preview. Even better auto print and previewed print both work for myself and @EarlGrei but not other folks around the building.
It’s a wacky one and I don’t know who’s fault it is Task Agent? APM? Windows? Epicor? AD Permissions/GPO I have no idea.
For some additional things we found.
The print jobs are the same Sales Order Acknowledgements.
When Auto-Printed the actual “Page” looks like this (blurred to protect customer data)
@jgiese.wci@EarlGrei Is it possible the APM laserjet driver got updated on the other users machines, but since your in IT it has not yet. I know we had to be careful to use a really old LJ5 driver.
You would think that would impact printing for preview and auto print. Both go to the same shared printer on their PC. It also worked auto print as @EarlGrei on a PC that it doesn’t work with another user. We are narrowing in on that it’s something with the Crystal Runtime and that it’s User level, but that’s as far as we are right now.
I’d have said the same thing a @gpayne but I’d also check that the CR form doesn’t have a bogus printer associated with it (CR forms retain printer settings, so I’d check/change that to see if the behavior changes).
It’s very odd that a single CR Form would behave differently across the user community, and since you mention the CR runtime - did a recent MS patch cause this? Along the lines @gpayne mentioned, but in reverse - users got a MS update that you did not that alters a system-level printing function that the CR runtime uses?
We’ve confirmed the issue follows the windows user. Doesn’t matter who is logged into Epicor and will work for one user on the same PC as it does not work for another.
Because it’s windows user related any changes to the .rtp are futile.
Patching is 100% disabled in our network managed by patch management software that does not schedule patching mid week. That it went from working yesterday to not working today with the only change of note was adding a network label printer to the server is infuriating say the least. I would feel better that adding that printer was the issue if it wasn’t client windows user level and it didn’t work for anyone.
So I re-did the drivers, I validated EMF, I did absolutely freaking everything I could think of. I measured the size of the print output on physical paper to see if anything made sense. I was getting pretty damned desperate. Then I did a quick google search at like 1030 last night and it hit me in the face.
So we installed a small label printer the other day that installs a few User-Defined form sizes. It does not set them as defaults on anything. They in no-way get associated with the APM printer. However I deleted the forms that it installed any did a print and everything worked. The form doesn’t even have some kind of overlapping name. It’s called “My Custom Paper - 100-210mm”. This printer was not setup to be deployed to anyone. It was not installed on any of the end users computers. This form was not called anywhere. However somehow… Magically… It was being used.
I am calling this ‘Chapter 24: Lessons in Why Printers of any kind are awful’ of my memoirs. Thanks for all the input everyone.
Should note the forms are installed in the print management console on this particular server. Even with this revelation it still doesn’t make any sense why it was only some users and not others, and the working or not working followed users from PC to PC.
