Job Queue not (always) works

Business Central/NAV Technical Forum
1

I’ll try to explain, because is not easy.

We have some Job Queue Entry in a customer Database. From a day in april, Job Queue is not working any more. There are not any error, and if the Job Queue Entry is marked as recurrent job, the mark is cleared but the job is not executed and remains in state “Ready”, there are no log entry, no messages in my notifications… anything.

In Windows Event Viewer, I can see a security error (but no application error):

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          2018-05-28 17:09:26
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      ########################
Description:
An account failed to log on.

Subject:
	Security ID:		NE\customer_service_account
	Account Name:		customer_service_account
	Account Domain:		NE
	Logon ID:		#######

Logon Type:			3

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		
	Account Domain:		

Failure Information:
	Failure Reason:		Unknown user name or bad password.
	Status:			0xC000006D
	Sub Status:		0xC0000064

Process Information:
	Caller Process ID:	0x1e90
	Caller Process Name:	C:\Program Files\Microsoft Dynamics NAV\110\Service\Microsoft.Dynamics.Nav.Server.exe

Network Information:
	Workstation Name:	#############
	Source Network Address:	-
	Source Port:		-

Detailed Authentication Information:
	Logon Process:		Authz   
	Authentication Package:	Kerberos
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

I have made a test. I created the NAV service user as a user in Dynamics NAV, and I created a Job Queue Entry as this user, and it works!!! But only works if the Job Queue Entry has the NAV service user as the user who created the task.

I think that NAV service user can’t create a NAV session on behalf other users. The NAV Service is administrator in NAV Server, but not in domain.

Does NAV Service User need special domain permissions? I’ve read all NAV documentation and I can’t see anything about this.

Any help will be appreciated!!!

2

Hi Ponc,

Yes, the NAV Service user must have permissions to run as a service. And it must be a local administrator.

3

Yes, it has, if not, the NAV Service would not started.

4

But is it also a member of the local admins?

5

Yes, it is.

6

What about this one:

Account For Which Logon Failed:
Security ID: NULL SID

Did you look into that one?

Are the users in the same domain?

7

All users and NAV service user are in same domain, NE. I have seen that before, but I don’t know what it means exactly and I don’t if I can do anything about it.

8

Finally, we have implemented a workaround.

We can’t find a definitive solution because we can’t do anything in customer system, we suspect that is an active directory problem (probably related to the server, we think is not correctly added to AD), but the customer don’t understand what we propose to try to solve the problem (this is a common problem when you talk to an intermediary who is not a sysadmin).

The workaround is a codeunit that filter Job Queue Entry for State = Ready and Scheduled = FALSE, and do a restart if find any. We put this codeunit to be run as Job Queue Entry, with the same user as NAV Service (we know that Job Queue Entry created by this user works fine). It’s a periodic task, it runs every minute.

It’s not a perfect solution, but the system is working properly… the only thing is that all processes are runing as service NAV user, if process saves user information in some place, will show this user not the user who create the Job Queue Entry.

9

Just want to add that you might be correct with the assessment that this has to do with user permissions. I had job queue set up and it was running ok for a month then suddenly it stops but like you said there was no error message or any obvious clue to debug from. I swapped out the account that was used for the NAS service and the jobs started working like before.

10

Thanks Sean. We suspect is a problem with NAV Server user permissions or with AD, related to the server… If we can resolve it definitively, I’ll inform in this thread.