I have the following problem. I have a SSIS Package that works fine when I execute it from visual studio, but when I execute it through the SQL Server Agent it gives me this error (I have it in spanish so I'll translate it and it might be a bit different from the normal message):
"Can't find connection "{(the id of one of my database connections)}". The Connections collection returns this error when it can't find the specific connection element.".
The SQLSERVERAGENT user has privilegies in the project's folder.
When planning the execution, I used the package file as a origin, if that has something to do.
I ran out of ideas and don't know what to do. Any help would be greatly appreciated.
Thanks in advance,
Khor
I finally made it work.
The problem was that the user who created the packages had permissions on the server I was accessing with the ODBC to but the SQLSERVERAGENT user didn't.
I changed the user in the SQL Server Agent service from SQLSERVERAGENT to the user who created the packages to make sure that this was the problem and it worked fine, so the solution is either leave the service with this user or give permission on the other server to the SQLSERVERAGENT user.
Related
I am building a package that performs multiple tasks and sends a success email (from script task) as last step of the package.
When running the package manually from Visual Studio the email is sent correctly. However, when running the deployed package from a Job in SQL Server the email is never sent (I have checked in the Gmail account that sends the email and it does not appear in the "Sent" folder).
I also checked the report for the package execution and I can't find the send email task, so it seems that it never actually get to the script task that sends the email.
Any ideas what the problem might be?
Thanks!
Ensure that you can send mail in SQL Server without Visual Studio involved. Also, the job from SQL Server sometimes runs as a different user than you when you login and run via Visual Studio. The problem may be that the script isn't running because the SQL Server user does not have permission to run a portion of the script. I would set this to run as an SSIS job in SQL Server and then check the SSIS log in SQL Server to see where the failure is occurring. If it is a different user issue, you can solve a multiple number of ways. You can give the SQL Server user the necessary permissions or you can setup a proxy account in SQL Server that has permission to run the job
The following link answers this question. Before deploying to SSIS, change the SQL Server version:
SSIS: script task (vs15) not work when deploy on sql server 2014
I have noticed something else while looking at the execution report, and now I am even more confused... (since other jobs that tigger emails are executed and everything is fine).
1) When executing the job from a job (executed by SQLSERVERAGENT) it seems like the task runs (since logs appear), but still the email is not sent:
2) When executing in SQL Server manually (with my user which is SysAdmin) an error appears:
I am running a SQL Server Job and I'm getting the following error.
The job failed. The job was invoked by the user sa. The last step to run was step 1. Executed as user. NT service\SQLAgent$SQL2014. Miscrosoft (R) SQL Server Execute Package Utility version 12.0.50000.0 for 32-bit.
Can anyone tell me why this happening?
Based on your pastebin of the error, it looks like the oledb source connection in your package is setup to login as sa. On a side note, this is bad practice...
This error usually indicates one of two things. Either the server instance is setup to only allow windows auth or the password entered in the connection manager for user sa is not correct.
I have a problem while trying to deploy a ssis package from a job. I have created the ssidb folder of the package, and I have not problems to execute it successfully. But when I use a job, by choosing the package from the ssisdb folder, I always get the same error message:
Failed to acquire connection "database". Connection may not be
configured correctly or you may not have the right permissions on this
connection.
The ProtectionLevel of the project and the package is "DontSaveSensitive", but apart of this I do not know what else can I do.
I would appreciate any advice you could give me.
Using SQL Server 2014.
Regards.
It sound's like you have almost worked this out yourself :-) The connection string will most likely not be valid because, when you deployed the package, the password would not have been carried across.
Easiest option if running via SSDB:
On the deployed server right click on the package.
Click configure
Amend your connection manager accordingly.
Easiest option if running via SQL Agent Job:
Right click job and select properties
Click Steps
Edit your step.
Click on configuration tab.
click on connection managers tab.
Amend accordingly.
There are, of course, other ways - have a look up Environments.
FWIW We store all our packages with sensitive data secured by a password.
SQL Server Reporting Services, in SSRS it seems like Schedules never fire, however a look at the SQL Agent reveals a permission issue related to not being able to resolve a user account.
Seems SQL Agent does not rely on caching or whatever voodoo Windows magically works.
link text
Fix is listed here...
edit --
Above is the fix I used to workaround this issue, has any one found any other work arounds or resolutions to this issue?
It seems that by default the SSRS Generated Schedules are run as this phantom user account. How do I change this default? Is SSRS creating the jobs as the user the service runs as?
Thanks Remus
I was running into the same issue. Here is how I fixed it.
Problem description
When setting an SSRS report subscription to run at a given time, I would wait for the time to pass and then find that the "Last Run" timestamp did not change. My subscription appears not to have run.
Relevant troubleshooting info
SSRS report subscriptions are executed as SQL Jobs that the Report Server web UI creates for you behind the scenes.
When looking at the job that was created for my report subscription, I saw that it always failed with the error:
The job failed. Unable to determine if the owner (domain\userName) of job 0814588B-D590-4C45-A304-6086D5C1F559 has server access (reason: Could not obtain information about Windows NT group/user 'domain\userName', error code 0x5. [SQLSTATE 42000] (Error 15404)).
In the Sql Server Configuration Manager I could see that the "SQL Server Reporting Services" service was configured to run using an AD user account.
In the Sql Server Configuration Manager I could see that the "SQL Server" service was configured to run using a local Windows account.
As #Remus Resanu pointed out, the SQL error 15404 refers to an exception when EXECUTE AS context cannot be impersonated.
Solution
Bingo! #4 and #5 are the key to the problem. The SQL Server service (a local Windows user account) was trying to authenticate the user "domain\userName" in AD, which it could not do because it does not have the right/permission to access AD resources.
I changed the SQL Server service to us an AD user account, restarted the SQL Server and SQL Server Agent services, re-ran the SQL job and, blamo, success!
15404 is the exception when EXECUTE AS context cannot be impersonated. Reasons for these error are plenty. The most common reasons are:
when the SQL Server instance does not have access to the AD server because is running as a local user or as 'local service' (this would have an error code 0x5, ACCESS_DENIED)
when the SQL Server is asked to impersonate an unknown user, like an user from a domain the SQL Server has not idea about (this would have the error code 0x54b, ERROR_NO_SUCH_DOMAIN)
The proper solution is always dependent on the error code, which is the OS error when trying to obtain the impersonated user identity token: one searches first for the error code in the System Error Codes table (or fires up windbg, does a loopback non-invasive kernel debug connection and goes !error, which is what I prefer cause is faster...).
So, John... do you actually have a question, or just posted a random piece of partial information?
I did 2 things and it's now working.
1) Go to "SQL Server Configuration", change the "SQL Server Agent" - "Log On As" to match the "SQL Server" above.
2) Secondly, open "Microsoft SQL Management Studio", at the "SQL Server Agent", expand the "Jobs" and you should be able to see your created job. Right click on it and go to "Properties".
3) Change the owner to also match the "SQL Server Agent" above.
After, I'm able to execute the Maintenance Plan without any issue.
Just follow this steps in images
Greetings – To automate testing of our database SPROCs, we’ve been using dynamically created databases inside of a User Instance. This has been working very well – the build server and, until very recently, all the developers could all run the tests. However, one of our developer machines is now returning the following error when we try to connect to the user instance:
Failed to generate a user instance of
SQL Server due to a failure in
starting the process for the user
instance. The connection will be
closed.
Here is what the log file says:
2008-12-04 10:46:29.77 Logon
Error: 15372, Severity: 16, State: 1.
2008-12-04 10:46:29.77 Logon
Failed to generate a user instance of
SQL Server due to a failure in
starting the process for the user
instance. The connection will be
closed. [CLIENT: ]
What I’ve done to fix it so far
Deleted C:\Documents and Settings[username]\Local Settings\Application Data\Microsoft\Microsoft SQL Server Data
Changed SQL Service to run as “Local System” instead of “Network Service”
Uninstalled SQL Express, deleted ALL data directories (e.g. “MSSQL.1”), and reinstalled SQL Express
None of these “fixes” have fixed the problem. It used to work on the machine in question, and we would like not to have to repave it.
Please help!!!
Thanks - Jordan
Okay, I tried all of the above fixes again, and then I restarted the entire system and it appears to work. Strange! I had restarted my system in the past, but it looks like you have to apply these fixes first and then restart. I think I'll try switching the service back to logging in as Network Service.
Thanks - Jordan
I found the same issue on my azure VM. Then I opened the SQL Server Configuration Manager, opened SQL Server Network Configuration, -Protocols for and found that "Named Pipes" and "TCP/IP" were disabled. I enabled them, and the error went away.