I migrated from SQL Server 2008 to 2019. On the old server there is set up a job, which calls a dtsx file. It needs database access, file system access because it saves tmp files to disk, and internet conneciton to send this file.
The connection string is defined followings:
<DTS:ConnectionManager
DTS:ConnectionString="Provider=SQLOLEDB.1;Password=p#ssword;Persist Security Info=True;User ID=MyUser;Initial Catalog=MyDB;Data Source=SQLServer\Instance;" />
If I run it using the Execute Package Utility it works. If I run it through the SQLServer Job, I get the error that the user is not granted to access the file system. The owner of the job is the same I am logged in and run the package using the Utility.
In the history i see:
The job failed. The Job was invoked by User Domain\RightUser.....
where RightUser is the Owner (and same as before, the same user run the package using the utility)
but the second row of the error:
Executed as user: NT Service\SQLAgent$AnotherUser.
And I have no idea where this AnotherUser comes from.
Whats wrong?
Furthermore, I don't really like the hardcoded password in the connection string, If the job run in its owner context, should it work changing the connection string to Integrated Security=True;, right?
This is a very common problem with running SSIS packages. That other user is SQL Agent, which in reality runs the package (this is the default user running the steps in jobs). Job owner has got nothing to do with running the SSIS packages. SQL Agent user name is set during the SQL Server installation. If it's omitted, the installer creates automatically a username like you described.
To the second question, yes you are right. If the user, who executes the package, has the correct permissions to the SQL Server described in the connection string, the userid and password are unnecessary. But in your case, the package is run by the SQL Agent with NT Service -level username, so it might be impossible to add that username to the SQL Server. You should set up a proper username for running the SSIS package and set it as a proxy account to the SQL Server, like described here: https://community.spiceworks.com/how_to/129293-configure-an-ssis-package-to-execute-as-a-proxy-account
Related
Problem: I cannot get the SSIS proxy and SQL credentials configured correctly to use a restricted access domain account (Domain\UserName) for a SQL Agent job step that runs an SSIS package. The Domain\UserName account has all the required permissions and privileges and the SSIS package is also designed correctly. I have read much material on this subject and would like some help in case I missed something.
More Details: I have an SSIS package which simply reads data from one SQL Server database table and pushes that data to another database table on a different server. I have got a special identity (Domain\UserName) created to perform this operation because this needs to be run on a daily basis.
Now everything runs perfectly fine when I run visual studio with that Domain\UserName and manually run that SSIS package. But it is not running when I deploy that to SSISDB. I have created SQL Server Security Credentials with same user account and created an SSIS Package Executing Proxy using that credential and configured the SQL Agent Job step to Run as that proxy account.
But It always gives the following error when I try to execute that SQL Agent Job Step:
Message
Executed as user: Domain\UserName. Microsoft (R) SQL Server Execute Package
Utility Version 11.0.6020.0 for 64-bit Copyright (C) Microsoft Corporation.
All rights reserved. Started: 10:00:26 AM Failed to execute IS server package
because of error 0x80131904. Server: XXXXXXXXXXXX, Package path: XXXXXXXXXX,
Environment reference Id: 36. Description: Login failed for user 'Domain\UserName'.
Source: .Net SqlClient Data Provider Started: 10:00:26 AM Finished: 10:00:26 AM
Elapsed: 0.578 seconds. The package execution failed. The step failed.
I found the issue. I missed one step to grant permission for Domain\UserName to use the proxy.
Explanation
You need to grant permissions to logins/roles who will be using the created proxy account using sp_grant_login_to_proxy system stored procedure. You can use sp_enum_login_for_proxy system stored procedure to view all the logins/roles who have access to the proxies.
Script - Granting proxy access to security principals :
USE msdb
GO
--Grant proxy account access to security principals that could be
--either login name or fixed server role or msdb role
--Please note, Members of sysadmin server role are allowed to use any proxy
EXEC msdb.dbo.sp_grant_login_to_proxy
#proxy_name=N'SSISProxyDemo'
,#login_name=N'Domain\UserName'
--,#fixed_server_role=N''
--,#msdb_role=N''
GO
--View logins provided access to proxies
EXEC dbo.sp_enum_login_for_proxy
GO
I get this error when deploying a package to SQL 2012 SSISDB catalog:
A .NET Framework error occurred during execution user-defined routine or aggregate "deploy-project-internal":
System.Data.SqlClient.SqlException: The locale identifier (LCID) 9242 is not supported by SQL Server
......
I had a very similar issue (different LCID) and took me weeks to resolve it but I hope is the same issue you where having and it helps for any other users.
So somehow something got bad installed on the SQL Server, the service account that is setup to run the SQL Server Service doesn't have all the necessary permissions.
I tracked this issue down to a very specific procedure, try to execute on the SSISDB the procedure [catalog].[check_schema_version] and you should be getting the same error message you are getting.
If executing the procedure gives you the same error, then the soultion is going to be the same. You basically need to change the account that is running SQL Server Service (not Integration Services) to be a local admin, and change the Locale on the RegEdit for that Local Admin acccount to be the one you want.
TO do so, do the following:
Execute on Command Prompt the following to get the SID:
wmic useraccount where name='Administrator' get sid (Replace
Administrator by your Local Admin Account)
Go to RegEdit -> HKEY_USERS -> [SID Local Admin] -> Control Panel ->
International and change keys "Locale" and "LocaleName" for the
desired region,(in my case it was Locale 00000409, LocaleName en-US)
Open Windows Services, look for the SQL SERVER (MSSQLSERVER) and
change the running account to be your local admin
Restart the Service
That should be it. I figured all that out thanks to the combination of these 2 pages:
https://www.facebook.com/allaboutssis/posts/329497130467714
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/9f409937-772a-41bd-8270-7804fdd5b94e/failure-in-deploying-ssis-project-from-ssdt-to-sqlserver-2014?forum=sqlintegrationservices&prof=required
Also I had a similar issue with the LCID for the Palestinian State which was added recently to windows and it seems that the SSIS doesn't recognize this LCID. So changing the windows LCID to another one solved the problem (from contorl panel then regions)
I solved it in the following way.
First, check in Services which user SQL Server (MSSQLSERVER) runs as:
Next, open the Registry Editor and navigate to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\. Find which ID the user has. In my case, the user MSSQLSERVER has the ID S-1-5-80-3880718306-3832830129-1677859214-2598158968-1052248003:
When you have the user's ID, in the Registry Editor, go to the path Computer\HKEY_USERS\[USER ID]\Control Panel\International. In my case, the path is Computer\HKEY_USERS\S-1-5-80-3880718306-3832830129-1677859214-2598158968-1052248003\Control Panel\International. There you will find two keys named Locale and LocaleName:
In my case, they had the following values:
Locale = 00000c00
LocaleName = en-SE
Change them to:
Locale = 00000409
LocaleName = en-US
Next, restart the service SQL Server (MSSQLSERVER).
After that, I was able to deploy the project:
I have a SSIS 2008 package. In one of the Script task I am calling a stored procedure which is using Openquery using linked server. I deployed this package with protection level as "EncryptWithPassword" and gave a password to the package. Created a SQL job and edited its command line to include the password. If I login to SQL Server Mgmt Studio with Windows Authentication and run the job manually it runs fine. But when I schedule it then I get an error that "The Communication link to Linked server failed".
Please help
Most likely that you launch job from default Run as login.
You should create credential with your login, so package will have access and priveleges to linked database under your login.
You may read this article for better explanation.
I have an SSIS package that takes data from a MySQL database and puts it in to a SQL Server table. The connection to MySQL is ADO.net. The package runs fine in BIDS.
I would like to deploy the package to be run as a Job on SQL Server 2008. The MySQL connection requires sensitive data to be either stored within the package or held in some external configuration source. If it is stored within the package it will either by encrypted with a key specific to my windows user profile or must be protected via a password.
I have tried three methods of setting up a SQL Server Agent job to execute this pacakge, and all fail:
Using a Password
I set the ProtectionLevel of the package to EncryptSensitiveWithPassword and supply a password for the package. I then save a copy of the package to the msdb. I can then connect to SSIS and run the package, at which point I am prompted for a password.
When I try to schedule this as a job in SQL Server I am prompted to enter the password by clicking on the Configurations tab of the Job Step Properties and I can see that the /DECRYPT switch has been added to the Command Line tab. The Run As property is set to the SQL Server Agent Service Account, which is mapped to a database login that has sysadmin server role. When I attempt to start this job I get the following error:
Executed as user: DOMAIN\UserROLE. Microsoft (R) SQL Server Execute Package Utility Version 10.0.5500.0 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 12:31:30 Error: 2012-07-03 12:31:31.20 Code: 0xC00291EC Source: Get Data Execute SQL Task Description: Failed to acquire connection "DATA_SOURCE". Connection may not be configured correctly or you may not have the right permissions on this connection. End Error DTExec: The package execution returned DTSER_FAILURE
It seems that using this method the package password itself is not stored anywhere for the job to access it.
Using an XML configuration file
I then created a copy of the package and set the ProtectionLevel to DontSaveSensitive and I set up a package configuration to store the MySQL credentials in an XML file. I then save this to the msdb and then when I run the package from
Integration Services I can provide a path to the config file, and all is well. However, once again when I set up a job for the package I point to a configuration file on the server but the job fails with the same error. I am wondering whether this is because the SQL Server Agent does not have an associated windows account that would allow it to read from the XML file stored in the file system.
Using a SQL Server table configuration
This time I created a copy of the package and set the ProtectionLevel to ServerStorage. I then created a [SSIS Configurations] table in the target SQL Server database. I modified the entries in this table to contain the password for the MySQL data source. Again, the package runs successfully from Integration Services, but fails with the same error as previously when run from a job. I have checked that the SQL Server Agent is able to read from the [SSIS Configurations] table ok - I set up a standalone job to test this.
Does anyone have any suggestions about what else I should do here?
I am thinking of giving up on SQL Server Agent Jobs for this and going back to having the package scheduled simply by the windows scheduler but thought before throwing in the towel I would try here first.
I am using the method of encrypting the password by setting EncryptSensitiveWithPassword as you discribed above and don't see anything you do wrong. Remember to use option keep protection level of the original package when importing the package with integration services, but it looks like you're doing that, too.
Try setting the role SQLAgentOperatorRole to your SQL Server Agent Service Account, you didn't mention that and i am not sure if you did. This could possibly solve your permission problems. (liked to answer by commenting this, but i lack of permissions here, too :)
I Have a package stored in SQL Server which works properly with logging when I run it directly by right-clicking it in SQL Server, with logging.
Logging is set to 'SSIS log provider for Text File'.
When I run it from an SQL Server Agent Job, it works fine, without errors but the logging isn't done.
The job runs with the my user, the same one that I use to start the package from SQL Server
Anyone know why and how to make it log
Thanks
I found my problem, my job is own by my user but each step is executed by SQL Server Agent Service Account, which didn't have access to rhe folder containing my logs.
I don't understand why there are no errors raised by this...