Printing stuck in Scheduled Tasks - uninstall and reinstalled task agent and restarted it - no help

Hi

Just upgraded Live from 10.2.300.17 to 10.2.300.28 over this weekend.

As per update guide, I’ve uninstalled then reinstalled the task agent - as we do not yet have the task agent changes implement in version 10.2.300.20

It looks ok, but isn’t all requests to print get stuck in scheduled tasks.
We didn’t find this problem in testing.

As well as multiple uninstall and reinstalls from the defualt Task agent configuration button, I’ve tried:

  • stopping/starting the task agent,
  • and also deploying it from the supplemental install folder for 10.2.300.28\172.20.247.50\Epicor\ERP10\ERP10.2.300.0\Updates\ERP10.2.300.28\SupplementalInstalls

What else can I do?
Why is’t it working?

Thank You!

scheduled%20tasks|690x234

Can you login as the user ‘print’ using your Epicor Client and the Password you believe to be correct.

Also do you have any errors when on the Screenshot Window above you go to Actions -> Event Log (something like that).

Because I see it says User ID: blank

Make sure you set the print user and password. I know Print Agent for us didnt work with SSO so we had to make sure we use a user/pw (or was it the other way around).
image

Perhaps your Endpoint Binding also needs to be UserNameWindowsChannel

image

Thankyou for such a quick reply, and on a Saturday! Just checked our test setup and it’s normal for user id and password to be blank.

I’ve never tried or had t login as ‘print’ or any other user, we use SSO via windows.

I’ve looked at the event viewer and it doesn’t seem to record anything when an attempt to print get stuck in scheduled tasks, but I have found some information which will help me debug a separate issue, so thank you :slight_smile:

AHA

The server event viewer has answers

Task Agent ERPProduction failed to start with the following error:
NT AUTHORITY\SYSTEM is not setup for single sign-on.

When you use SSO you need a separate user for printing that’s not a SSO user. We run a non-SSO instance of each environment setup with Username Windows Channel pointing to the same database as the SSO instance. That gives you an environment to manage non-SSO accounts. Comes in handy when connecting third party add-ons as well.

1 Like

I typically don’t run the Agent as NT AUTHORITY\SYSTEM - if you do use SSO, perhaps you need to specify a proper User Account in services.msc
image

Just a random Service to show where to set a proper Domain User Account:

Anyways, the Event Log should show you the right path (Errors to fix).

We do the same like @chaddb and use a non-sso user for printing.

2 Likes

Have you tried stopping and restarting the service? Not the agent, the service.

1 Like

You need to set a username on the service in the console as highlighted above (Services.msc). If you need to know which username, look in Epicor for your “print” or “task agent” user - the windows login name that you need is the “Domain User ID”.

1 Like

I had, thanks Calvin

Thank you SO much, this has now been fixed by setting the logon user on the task agent service in service