September 17, 2010 at 6:38 am
We were running under a domain account and it still happened.
Steve
May 20, 2011 at 10:52 am
Please verify that the SQL Server services Windows account has the Local Security Policy "Lock pages in memory". I had the same issue, but the owner of the services was "slightly" different from the user with the Security Policy. Once I changed the login as for the SQL Server services (and Agent) the problem disappeared.
February 25, 2015 at 8:45 am
I know this is an old post. But I am having this exact problem now.
I'm a newly hired DBA at this company and have found one of the SQL boxes with the SQL agent behaving like this. with no event log errors just the start and stopping. and is not security, there is another instance running on this box with the same log on AS, and its SQL Agent is running.
Any Help????
February 26, 2015 at 1:22 am
When SQL Server is installed (2008 anyway) it creates some local windows groups with names like SQLServerSQLAgentUser$Myserver$MSSQLSERVER and you'll see they have descriptions such as "Members in the group have the required access and privileges to be assigned as the log on account for the associated instance of SQL Server Agent." Log onto the server and look at "local users and groups" to see them.
Your service accounts should each be members of the group for the service they are running. If you've gone for the local system account you'll probably see NT SERVICE\SQL SERVERAGENT in there but if it's a domain account you are using then you may need to add it to the group.
If you have multiple instances of SQL Server on one server you will find a set of groups for each instance or rather for each service - you only get one Integration Services and one Browser service on a server.
This goes a long way to ensure that the account running sql agent has the permissions to access all the disks it needs to read/write.
June 12, 2015 at 7:54 pm
I had a similar problem with a slightly different cause, so I thought I would throw this out in case any one else gets burned like I did. My SQL Server Agent stopped working and would stop immediately when restarted. The Windows Event viewer yielded nothing useful. I found that I could start the Agent if the server was set to use the Local Service, but never with my domain based accounts being in control of the service.
What happened was that a new group policy had been rolled out. The new group policy restricted access to the D:, E:, & F: drives of our server for domain based accounts. As it turned out, the SQL Server Agent was setup to write its log out to the E: drive. So when this policy was applied on the server, the Agent service could no longer access the E:. The service would just silently quit. As a temporary workaround, I changed the location of the Agent log file to go to the C:, which the domain based accounts still had access to. The Agent service immediately came up.
If this solution ends up helping you in the future, please reply. I would love to know if I save just one other person on the planet the misery I went through to figure out what was going on. 🙂
June 13, 2015 at 4:12 pm
rnolan 96369 (6/12/2015)
I had a similar problem with a slightly different cause, so I thought I would throw this out in case any one else gets burned like I did. My SQL Server Agent stopped working and would stop immediately when restarted. The Windows Event viewer yielded nothing useful. I found that I could start the Agent if the server was set to use the Local Service, but never with my domain based accounts being in control of the service.What happened was that a new group policy had been rolled out. The new group policy restricted access to the D:, E:, & F: drives of our server for domain based accounts. As it turned out, the SQL Server Agent was setup to write its log out to the E: drive. So when this policy was applied on the server, the Agent service could no longer access the E:. The service would just silently quit. As a temporary workaround, I changed the location of the Agent log file to go to the C:, which the domain based accounts still had access to. The Agent service immediately came up.
If this solution ends up helping you in the future, please reply. I would love to know if I save just one other person on the planet the misery I went through to figure out what was going on. 🙂
Welcome aboard and thanks for the tip!
As a bit of a sidebar, this is why it's so important for operations folks and DBAs to understand that they're on the same team and talk with each other before doing something that could have so easily been avoided with a 2 minute conversation.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 6 posts - 31 through 35 (of 35 total)
You must be logged in to reply to this topic. Login to reply