Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2005
»
Administering
»
SQL Agent Job Sudden Failure, Login failed...
11 posts, Page 1 of 2
1
2
»»
SQL Agent Job Sudden Failure, Login failed for user NT AUTHORITY\SYSTEM.
Rate Topic
Display Mode
Topic Options
Author
Message
DB_Newbie2007
DB_Newbie2007
Posted Friday, February 01, 2013 8:52 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Yesterday @ 6:09 AM
Points: 179,
Visits: 1,091
I have a scheduled job (runs every Friday at 5am) that has been running since 9/2011. Suddenly, the job failed this morning with a "Login failed for user 'NT AUTHORITY\SYSTEM'... " error message.
1) There are other jobs that run using the same account. Just to test, I re-started a different job this morning and it ran fine.
2) I took all of the code from the original job (that is now failing), created a new job that is identical (except for the names) and it runs fine.
Without getting into the pro(s) and con(s) of running services under NETWORK SERVICE or the BUILTIN\Administrator (
PLEASE!
), has anyone seen this before? Is this just some incident of a job becoming corrupt?
Argue your limitations and sure enough they will be yours (Richard Bach, Illusions)
Post #1414716
opc.three
opc.three
Posted Monday, February 04, 2013 1:10 PM
SSCertifiable
Group: General Forum Members
Last Login: Today @ 1:24 PM
Points: 6,826,
Visits: 11,950
When you say "run using the same account" do you mean the jobs have the same owner?
Are there any job steps that use proxies?
__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Believe you can and you're halfway there.
--Theodore Roosevelt
Everything Should Be Made as Simple as Possible, But Not Simpler
--Albert Einstein
The significant problems we face cannot be solved at the same level of thinking we were at when we created them.
--Albert Einstein
1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples.
--Giordy
Post #1415472
philcart
philcart
Posted Tuesday, February 05, 2013 5:03 AM
SSCrazy
Group: General Forum Members
Last Login: Yesterday @ 9:10 PM
Points: 2,693,
Visits: 1,080
DB_Newbie2007 (2/1/2013)
"Login failed for user 'NT AUTHORITY\SYSTEM'... "
Is that message coming from the SQL Agent Job, or the code that the job is running?
Are there any other errors or warnings in the Windows Event Viewer?
Hope this helps
Phill Carter
--------------------
Colt 45 - the original point and click interface
Australian SQL Server User Groups
-
My profile
Phills Philosophies
Murrumbeena Cricket Club
Post #1415750
DB_Newbie2007
DB_Newbie2007
Posted Monday, February 11, 2013 7:32 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Yesterday @ 6:09 AM
Points: 179,
Visits: 1,091
Sorry for taking so long to response back on this... I know I personally do not like it when a thread suddenly "quits" without any resolution, especially when I am trying to research a problem.
- There were no errors in the Events log.
- The error was from SQL Agent (the code, run manually, executed fine).
- Yes, all of the jobs have the same "owner".
As mentioned in the original post, "I took all of the code from the original job (that is now failing), created a new job that is identical (except for the names) and it runs fine.", so the problem was resolved. However, I am still curious if anyone else ever experienced this kind of a problem or might have some insight as to the cause?
Thanks!
Argue your limitations and sure enough they will be yours (Richard Bach, Illusions)
Post #1418421
opc.three
opc.three
Posted Monday, February 11, 2013 7:36 AM
SSCertifiable
Group: General Forum Members
Last Login: Today @ 1:24 PM
Points: 6,826,
Visits: 11,950
Any proxies in play?
__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Believe you can and you're halfway there.
--Theodore Roosevelt
Everything Should Be Made as Simple as Possible, But Not Simpler
--Albert Einstein
The significant problems we face cannot be solved at the same level of thinking we were at when we created them.
--Albert Einstein
1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples.
--Giordy
Post #1418427
DB_Newbie2007
DB_Newbie2007
Posted Monday, February 11, 2013 7:54 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Yesterday @ 6:09 AM
Points: 179,
Visits: 1,091
Nope. No proxies.
The job is actually run with a custom higher level account with full permissions in every database. Yes, it has full SA permissions... again,
please
no discussions on the use of an "SA" level account to run the job... focus on the particular issue at hand, thanks!
Argue your limitations and sure enough they will be yours (Richard Bach, Illusions)
Post #1418447
opc.three
opc.three
Posted Monday, February 11, 2013 11:00 AM
SSCertifiable
Group: General Forum Members
Last Login: Today @ 1:24 PM
Points: 6,826,
Visits: 11,950
DB_Newbie2007 (2/11/2013)
Nope. No proxies.
The job is actually run with a custom higher level account
with full permissions in every database. Yes, it has full SA permissions... again,
please
no discussions on the use of an "SA" level account to run the job... focus on the particular issue at hand, thanks!
What do you mean by that? The Login running the job has nothing to do with the security context the job runs under.
I am thinking the job owner of the original job left the company and their Active Directory account was deleted. Or if it was a SQL Login the login was deleted or they were removed from the sysadmin Role and that is why the job started failing.
When you recreated the job the owner is now you, or maybe you made it sa or some other valid login so now it works.
__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Believe you can and you're halfway there.
--Theodore Roosevelt
Everything Should Be Made as Simple as Possible, But Not Simpler
--Albert Einstein
The significant problems we face cannot be solved at the same level of thinking we were at when we created them.
--Albert Einstein
1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples.
--Giordy
Post #1418571
DB_Newbie2007
DB_Newbie2007
Posted Monday, February 11, 2013 11:59 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Yesterday @ 6:09 AM
Points: 179,
Visits: 1,091
Sorry for any confusion... I believe there are a few levels of "ownership" (http://www.sqlservercentral.com/articles/SQL+Jobs/68764/) per my understanding?
1) The account that is configured to run SQL Server Agent service.
2) The account that has "ownership" of the job (which is what I was referring to previously):
SELECT j.[name] AS 'JobName',
Enabled = CASE WHEN j.Enabled = 0 THEN 'No'
ELSE 'Yes'
END,
l.[name] AS 'OwnerName'
FROM MSDB.dbo.sysjobs j
INNER JOIN Master.dbo.syslogins l
ON j.owner_sid = l.sid
ORDER BY j.[name]
GO
3) The Step "run as" (i.e., proxy account).
The "job owner" (listed from the query above) is an account that is in the sysadmin fixed server role, so I believe the step should be executed under the account used by the SQL Server Agent service (NT AUTHORITY\SYSTEM in our case), as are all of the jobs on this server. We use a specific account for all of the "job owners".... we try to not do anything using the "sa" account (I could not tell you what the sa pwd is... it is locked away in a drawer).
The job step has the "run as" left blank (i.e., the "Proxy account").
Thanks!
Argue your limitations and sure enough they will be yours (Richard Bach, Illusions)
Post #1418591
opc.three
opc.three
Posted Monday, February 11, 2013 12:31 PM
SSCertifiable
Group: General Forum Members
Last Login: Today @ 1:24 PM
Points: 6,826,
Visits: 11,950
DB_Newbie2007 (2/11/2013)
Sorry for any confusion... I believe there are a few levels of "ownership" (http://www.sqlservercentral.com/articles/SQL+Jobs/68764/) per my understanding?
1) The account that is configured to run SQL Server Agent service.
2) The account that has "ownership" of the job (which is what I was referring to previously):
SELECT j.[name] AS 'JobName',
Enabled = CASE WHEN j.Enabled = 0 THEN 'No'
ELSE 'Yes'
END,
l.[name] AS 'OwnerName'
FROM MSDB.dbo.sysjobs j
INNER JOIN Master.dbo.syslogins l
ON j.owner_sid = l.sid
ORDER BY j.[name]
GO
3) The Step "run as" (i.e., proxy account).
The "job owner" (listed from the query above) is an account that is in the sysadmin fixed server role, so I believe the step should be executed under the account used by the SQL Server Agent service (NT AUTHORITY\SYSTEM in our case), as are all of the jobs on this server. We use a specific account for all of the "job owners".... we try to not do anything using the "sa" account (I could not tell you what the sa pwd is... it is locked away in a drawer).
The job step has the "run as" left blank (i.e., the "Proxy account").
Thanks!
You can still allow jobs to be owned by sa even if the Login is disabled or the password is unknown. In fact it's actually a pretty common thing for people to do by default. If done this way the job always runs in the context of the SQL Server Agent service account even if proxies for specific steps are defined.
__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Believe you can and you're halfway there.
--Theodore Roosevelt
Everything Should Be Made as Simple as Possible, But Not Simpler
--Albert Einstein
The significant problems we face cannot be solved at the same level of thinking we were at when we created them.
--Albert Einstein
1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples.
--Giordy
Post #1418603
mmartin1
mmartin1
Posted Thursday, February 14, 2013 3:16 PM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Thursday, June 13, 2013 2:02 PM
Points: 198,
Visits: 656
Could it be there was a momentary loss of connectivity to the domain controller and the credentials passed could not be verified? I don't recall if I've encountered this particular error or not, probably.
Post #1420323
« Prev Topic
|
Next Topic »
11 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.