I've tried everything I can think of and now need help.
I'm trying to run a SQL Server Agent job that has one step in it which executes a SSAS Command that processes a dimension.
When running it, the job fails with the following error:
<Error ErrorCode="3238395904" Description="OLE DB error: OLE DB or ODBC error:
Login failed for user 'MyDomain\MyUserName'.; 28000; Cannot open database
"MyDatabase" requested by the login. The login failed.; 42000."
Source="Microsoft SQL Server 2012 Analysis Services" HelpFile="" />
The error message is pretty clear, but I cannot figure out where the issue is to fix it.
This is running on a named instance that is a test copy of the main instance on the same server.
The named instance service for both the database engine and SQL server agent are running under the "MyDomain\MyUserName" account.
The "MyDomain\MyUserName" account is set up as a "sysadmin" on the instance and has rights to "MyDatabase"
The SSAS Database uses "MyDomain\MyUserName" as impersonation (which is the same setup as the original, which works).
The SSAS Command within the job step is set to "Run as" a "SQL Server Agent Service Account"
The job owner is "MyDomain\MyUserName".
I've added the "MyDomain\MyUserName" as a server administrator under SSAS security.
I've even added the "NT Service\SQLServerAgent" (from the main instance) and the the "NT Service\SQLAgent$MyNamedInstance" (from the named instance) as a server administrators under SSAS security.
Geesh. It was the Server that was being used in the step calling the SSAS Command. It was still pointing to the old instance. Updating it the point to the new instance worked.
Related
I have a basic SSIS package that pulls data from a Redshift database ODBC DSN connection and puts it in a SQL Server database using an OLEDB connection. When I test the connections in Visual Studio everything is successful. When I run the package in Visiual Studio and the SSIS instance from SQL Server, they both are successful. However, when I try to run it from a SQL Sever agent job it fails with the AcquireConnection method failed error.
The VS solution/project is targeted to SQL Server 2014 same as the server.
The VS solution/project 64bitRunTime property is set to false so it will run as 32bit.
The configuration for the job step in SQL Agent is also set to 32bit.
Both the job owner and the step's login to the package are set to "sa" (just to test).
Still not working. Any ideas?
The difference between cases is the user credentials. When you run the package - it runs under your credentials, when SQL Server Agent runs it - it (by default) runs under service account.
Ways to test and fix:
Create a SQL Credential, SSIS execution proxy and configure Job step to use it in run as dropdown.
For testing - create a credential mapped to your account.
Change account under which SQL Agent starts or add privileges to the service account.
I opt for the first method, since it is more granular and affects only your job.
We currently have a SQL Server 2012 job that fails to execute because of an account lock out. The message found within the Event Viewer is the following:
SQL Error: The referenced account is currently locked out and may not be logged on to.
The SQL Agent runs a local account and have verified it is not currently locked out within System Admin on the server. Have also verified that account is not locked out on the SQL Server box. The SQL Server job runs a SSIS package. If I run the SSIS package by itself the job will execute just fine. It is when it is executed via the job that it fails.
Has anyone else had a mysterious account locking problem with a SQL Server Job?
Follow below steps:
Right click sql agent job name -> view history -> check error. It gives exact details of what has gone wrong.
SSIS Jobs via SQL Agent needs proxy account, which contains credentials of SQL Server login. Hence Security -> Credentials and update the username and password.
Once done, make sure it is reflected in Proxy (SQL Server Agent -> Proxies -> SSIS Package Execution.
Make sure the referenced account is added under Security -> Login
I have a SQL statement that merges 2 databases together, from 2 different servers (SQL Server 2012 for both).
The two servers are linked, so when executing the statement in a query window from Management Studio with the SA account it works perfectly.
However, I need to automatize this. I created a Job in the SQL Server Agent, and I keep getting an authentication error. This is because the user that is executing the SQL Server Agent service doesn't have the SA rights on both servers.
This is the error:
The OLE DB provider 'providerName' for the connection server
'serverName' reported an error. Authentication failed.
I tried setting a superadmin user from the Active Directory with all rights on both servers to execute the SQL Server Agent, but I still get the error.
Is there any way to fix this?
Thanks
You can store your linked server credentials with your linked server definition (forbid my picture editing skills ;-)):
Alternatively - and much more preferabele from security point of view - setup same account on both servers (you can then limit the account privileges as you need) and use the third option ('Be made using the login's current security context')
We have 2 SQL Servers in each of our environments. Server A is our Data Warehouse SQL Server and Server B is our OLTP server. We have the following environments PROD, STAGE, SIT, DEV. We have configured a linked sever on Server A in each environment to read, write and Exec a stored procedure on Server B. A SQL job was created on Server A to do a simple select statement from Server B to test the connection. The service account that will be running all of the jobs was configured as the job owner and "Run as User". In Prod, STAGE and SIT the test job is working. In DEV the test job is failing with the message "Access to the Remote Server is Denied because the current security context is not trusted"
I have logged in to server A as the service account and run the exact select command to server B in a query window and the command successfully returns results.
I tried a SQL job on Server A in DEV that calls an SSIS package. It uses the same service account as the test job via a proxy & credential. The SSIS package is calling a stored procedure on Server B. When I run this job it succeeds and executes a stored procedure on Server B that writes data to server B.
I validated that the Service account has administrator privileges set the same across all environments.
I validated that the Linked server has the same configuration across all environments.
I have tried to set up the Linked Server to link the service account on Server A to a SQL account on Server B
I have tried to set up the Linked Server to "Be made using the login's current security context" on Server B
I have tried changing the SQL job to run as an operating system CmdExec. SQLCMD -E -Q "select * from [Server].[Database].[Schema].table" using the same proxy and credential as the job that is working. This resulted in the following error
"A network-related or instance-specific effor has occured while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections."
I validated that the servers can ping each other.
I ran SQLCMD -L via the command line to validate that the servers are both present.
I enabled the Named Pipes protocol on both servers A and B in the configuration manager.
I tried running the test job under my credentials as an SA and got the same
"Access to the Remote Server is Denied because the current security context is not trusted" message.
I tried copying and pasting the SQL from the test job into a query window on Server A using my credentials and was able to run the query successfully.
I tried recreating the SQL job.
I tried restarting the SQL Services.
The only appreciable difference I can think of between this environment and the others is that Server A is a named instance and Server B is a default instance.
Also of note, the SQL Browser service on Server B is being run by a local account instead of a service account. SQL Browser on Server A is being run by a service account.
this is a new staging server with SQL 2008. I'm not famliary with SSIS that much so trying to deploy a couple packages. So I do the following in BIDS..which is probably typical:
Right-click my solution, go to properties, then go to the deployment utility tab
Change CreateDeploymentUtility to true
Go and find the .SSISDeploymentManifest file locally on my machine
Run it and try to perform a SQL Server deployment to the customer's remote server (we're running vpn to get to it)
I put in the fully qualified remote server's name, my windows auth or SQL account (I tried both ways)
Try to click now the Package Path and get this:
TITLE: Package Installation Wizard
An OLE DB error 0x80040E09 (The EXECUTE permission was denied on the object 'sp_ssis_listpackages', database 'msdb', schema 'dbo'.) occurred while enumerating packages. A SQL statement was issued and failed.
ADDITIONAL INFORMATION:
An OLE DB error 0x80040E09 (The EXECUTE permission was denied on the object 'sp_ssis_listpackages', database 'msdb', schema 'dbo'.) occurred while enumerating packages. A SQL statement was issued and failed.
BUTTONS:
OK
So what do I do? How do I essentially run this as an administrator to get past this stupid elevated rights security error?
You should add your windows / sql account to sysadmin role.
In SQL Server Management Studio, go to Security -> Server Roles and double click sysadmin. Add your login and it should work when you try again.