July 12, 2017 at 9:21 am
I've got some very puzzling job failure notifications for scheduled jobs that actually ran successfully. These jobs have been running fine for years.
MESSAGES: The job failed. Unable to determine if the owner xxx of job xxx has server access (reason: Could not obtain information about Windows NT group/user 'xxxx', error code 0x6fd. [SQLSTATE 42000] (Error 15404)).
Also odd is, if I manually run the jobs, I would not get such failure notifications.
Don't know if it has anything to do with it but IT restarted the DC server the day before the problem appeared.
Any thoughts?
July 12, 2017 at 10:13 am
Michelle-138172 - Wednesday, July 12, 2017 9:21 AMI've got some very puzzling job failure notifications for scheduled jobs that actually ran successfully. These jobs have been running fine for years.MESSAGES: The job failed. Unable to determine if the owner xxx of job xxx has server access (reason: Could not obtain information about Windows NT group/user 'xxxx', error code 0x6fd. [SQLSTATE 42000] (Error 15404)).
Also odd is, if I manually run the jobs, I would not get such failure notifications.
Don't know if it has anything to do with it but IT restarted the DC server the day before the problem appeared.
Any thoughts?
Could be related - you'd need to ask why they restarted and if there are issues with all the DCs being in sync. Maybe there is just one DC so the being in sync doesn't apply but the reason for the restart still could. I'd probably just ask why they needed to restart.
That error can happen if the server looses connectivity to the domain, AD..along those lines. I'd probably start looking though the Windows logs and see if I can find any related issues during the same time as the job failures.
Sue
July 12, 2017 at 10:30 am
I disabled the failure notification for the jobs, but I'm still getting the failure email. So it might be some kind of runaway process. How can I kill it?
July 12, 2017 at 10:35 am
Sue_H - Wednesday, July 12, 2017 10:13 AMCould be related - you'd need to ask why they restarted and if there are issues with all the DCs being in sync. Maybe there is just one DC so the being in sync doesn't apply but the reason for the restart still could. I'd probably just ask why they needed to restart.
That error can happen if the server looses connectivity to the domain, AD..along those lines. I'd probably start looking though the Windows logs and see if I can find any related issues during the same time as the job failures.Sue
Thanks, Sue. The DC is on AWS and I thought it was a planned maintenance. I'll find out more. But I don't see any related issues on Windows logs.
July 12, 2017 at 11:16 am
Michelle-138172 - Wednesday, July 12, 2017 10:30 AMI disabled the failure notification for the jobs, but I'm still getting the failure email. So it might be some kind of runaway process. How can I kill it?
Are you querying msdb or checking the Job Activity? Checking the history for the Job?
Maybe you disabled the notification on the wrong jobs or maybe their is an issue with the notification itself? Or did you disable the notifications for all jobs?
You can also check the jobs by running Profiler and just filter on application name like 'SQLAgent%'
You could also start poking around in sys.dm_exec_sessions which has program name as well as request times that could help you track things down.
Sue
July 12, 2017 at 1:25 pm
Does the user or group the job is running as (xxxx in your OP) exist and have permissions to the server?
Better yet, is the account locked? We got this message when the account got locked.
July 13, 2017 at 9:42 am
Thanks, guys. I checked everything I can think of, but to no avail. I even used sysmail_stop_sp to stop Database Mail queue, but same notifications are still coming in.
Yes, the user/group has access to the server. It was myself and I can rdp onto the server and do whatever without any issues. I asked the sysadmin to disable and re-enable my credential, but it didn't do anything.
I think it must be some kind of orphaned thread that got stuck when the DC was rebooted. It may go away if I restart the server, but I can't reboot the server just because of this.
July 13, 2017 at 11:06 am
Check the status of database mail with: msdb.dbo.sysmail_help_status_sp
You could also check by just trying to send a test email - right click on Database Mail and send test email
If it's stopped, try checking other servers, environments other than production.
Sue
July 20, 2017 at 8:22 am
Mysteriously, the alert email finally stopped by itself. Most puzzling thing...
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply