I've googled my issue all weekend, but can't seem to solve the problem
So basically, I have a query, when I run it manually in a query window, it works fine and my job executes, resulting in an email being sent. However, when I set up a schedule, I get the following error:
If you can't read it, the error message says,
"The job failed. The job was invoked by Schedule 9. The last step to run was step 1."
Then underneath it says,
"Executed as user 'adminName(not sa)'. Failed to initialize sqlcmd library with error number -2147467259 (SQLSTATE 42000) (Error 22050). The step failed"
So I log in with user sa, and apparently this user needs to have SQL Agent permissions in the msdb database. According to this screenshot, sa is the owner:
So since sa is the owner, it would mean it has all the SQL Agent related permissions, right? Furthermore, the code I'm using executes from the CompanyDB, so I think perhaps this may be the issue. If I look at properties, under sa, I get this window:
So the CompanyDB is unchecked for user sa, so in order to allow sa to query CompanyDB in SQL Agent, what permissions would it need? I'm assuming this is the issue, but I'm not really sure, I can't seem to figure it out, any help is greatly appreciated.
Jobs should have dbAdmin permissions. That being said, it depends on whether you wrote to the db, update, or just send the email.
The better option would be to create a webservice and call it when you want to send the email.
Related
I am trying to execute an ant sql task, which is supposed to execute a number of queries to a local database. I already enabled the 'sa' user, it is the dbo of of the database, the authentication to the server is mixed mode and I still get the following exception, when trying to run it:
sql-exception
I already read and tried everything possible about the exception, so if somebody has any idea how to solve this, I would really appreciate it.
We are running into a few issues with our TFS installation (TFS 2013 Update 4, SQL 2014 Standard) as a result of email alerts. Most notably, Work Items cannot be created, because this triggers an email.
Any time a process or user attempts to create a Work Item, the error
TF30040: The database is not correctly configured. Contact your Team Foundation Server administrator.
is received. Further, when I check the Event Viewer on the server, I can see the error and it reports that the inner exception is:
Exception Message: The EXECUTE permission was denied on the object 'sp_send_dbmail', database 'msdb', schema 'dbo'. (type SqlException)
I have worked with the DBA and we have enabled Email Alerts on the server. We have verified that, in general, the alerts work by using the test button on the administration console. I can also set up a check-in alert through the web interface and receive said alerts without issue. This seems to be specifically affecting Work Item creation alerts (which apparently are just automatically and irrevocably enabled).
Presumably, we could correct this by giving appropriate permissions to use that stored procedure. To do so, we need to know what user to give permissions to. So far we have tried giving execute permissions to my AD user, the service account used by the build service, and the Network Service account (which appears to be the TFS Service Account).
There is no indication in any error message as to what user is being used to execute that procedure. So, my question: What SQL user is used to send alerts when creating Work Items?
Edit:
For the record, this started working of its own accord. We decided Monday to call Microsoft to get this fixed. Before that happened, failed builds magically created some work items (on Tuesday, a full day after we gave up), and we are now able to create work items. Everyone involved states not doing anything. We are baffled, but in a good way.
I'm going to advise you that a DBA should not be making changes to the TFS databases. I suggest opening a ticket with MSFT and getting assistance from the product support group.
Put differently, should I always set the job owner to sa for a SQL job, even though it defaults to the user who created it?
Any jobs that are owned by a user will cease to run if that user is disabled or deleted. The jobs may also not run if there is an Active Directory problem at run time. Brent Ozar has an article about this on his website:
http://www.brentozar.com/blitz/jobs-owned-by-user-accounts/
You're gonna have to bear with me. Because I'm going by memory.
Looking at some old scripts, I have this code.
select #jobOwnerNameVeryImportantToSetCorrectly = 'someSqlAuthenticatonUser'
Now. In my scenario, I allowed a non 'sa' user to schedule and run the jobs.
Thus why I made the owner a non 'sa' user.
The question I think to answer is, "who runs the jobs". If it is always 'sa', then its not an issue.
But, if you want a non 'sa' account to run it, then how is a less privileged account going to run a job owned by the super-mack-daddy account?
My test would be.
Create a job. Let 'sa' own it.
Create a temp sql-authentication account.
Login to the database as this sql-authentication account.
See if you can run the job.
My memory is saying "the lesser account won't be able to". However, I dealt with jobs on Sql Server 2005. So even if I remember correctly for 2005, it may not be the same for 2008 or 2008R2.
But I remember having issues with this. And thus my variable declaration:
select #jobOwnerNameVeryImportantToSetCorrectly = 'someSqlAuthenticatonUser'
I read Brent Ozar's article as well and am in a similar situation where there are a lot of jobs not owned by SA that are enabled. From what I have researched, I haven't found any compelling reason NOT to change the ownership to 'SA' but two good reasons mentioned above why you should.
You don't have to worry about them not being able to run from this change. The only two things I would be cautious about are:
1) Jobs that you run as SA and
2) If you are coming into an environment, enabling jobs that have been disabled after you've made this change.
Why someone would ever do those two things, IDK but you can always back up msdb and then test these changes in a dev or training server. Just note the jobs that you change in case something unexpected happens.
PROBLEM BACKGROUND
Sorry if this is a bit tedious to read, but please bear with me.
I have been tasked to determine the most restrictive security permissions...or rather investigate if more restrictive security settings can be configured for the SQL server login our program uses, yet still function as normal.
Currently the program runs as a Windows service configured to log on using a Windows user account that has been configured in SQL server with trusted auth. The login used has been assigned a db_owner role and the service works fine like that.
So to narrow the permissions for this user I removed the db_owner rights and assigned it to the db_datareader and db_datawriter roles. Unfortunately this causes a problem and when I start up the service I get an error dialogue displaying:
Error 1053: the service did not respond to the start or control request in a timely fashion.
and in the event viewer under the System events are logged:
event 7009 (timeout waiting for..to connenct)
event 7000 (the service did not respond to the start or control )
My problem is the code base is really large and I'm not sure what exactly to look for that would require db_owner permissions (it sets permissions maybe?).
QUESTION
What should I be looking for in a program that executes SQL that would cause it to require db_owner permissions?
In case the first question is too general: is there an easy way/any tools I can use to figure out what a Windows service is trying to do during start-up 'SQL wise' if I get system error events logged:
event 7009 (Timeout (30000 milliseconds) waiting for the ... service to connect)
event 7000 (The service did not respond to the start or control request in a timely fashion).
BTW I tried running profiler with all audit events selected, but still get nothing logged when starting the service.
This is such a broad question without knowing the architecture of your service and how it communicates with SQL Server. Are you using in-line SQL? Stored Procedures?
I think you'd best tackle this issue by starting from the service's code and tracing the execution path from the start and see what is being executed on/against SQL Server.
Alternatively, if you are using stored procedures, you may want to script them all out into a file and search on some common T-SQL commands limited to a db_owner, such as CREATE, DROP, ALTER.
The Current Action cannot be completed because the user data source credentials that are required to execute this report are not stored in the report server database
Take a look at your datasources for your reports. There are two settings.
User can supply them.
Or they can be stored in DB.
They need to be stored in DB for subscriptions (at least that's how the error reads). See if you can modify your datsources.
please ignore if you had already solved it.
This issue may also happen if default user credentials (like windows userID) do not have enough permissions to run a piece of SQL script or a SP. We can go to SQL server report configuration and select an option to ask for credentials every time you run a report.
You can provide the correct user id paswd when prompted?
Praveen