I made an SSIS package that exports data from Microsoft SQL Server and imports it into a .csv and mysql file. I start to use proxy account and it work, but only when user is logged. How make it works when user is logged off !? Thank you in advance.
I solved this problem. Firstly, created System DSN.
link for this
Does any connection manager in the package use ODBC DSN? If any ODBC
DSN is used, please make sure the DSN type is System DSN rather than
User DSN. The user DSN may not be accessible when the user that create
the DSN logs off.
Secondly, create new proxy and give him credentials
link for this
Use master
CREATE CREDENTIAL [MyCredential] WITH IDENTITY = 'yourdomain\myWindowAccount', secret = 'WindowLoginPassword'
Use msdb
Sp_add_proxy #proxy_name='MyProxy', #credential_name='MyCredential'
Sp_grant_login_to_proxy #login_name=' devlogin', #proxy_name='MyProxy'
Sp_grant_proxy_to_subsystem #proxy_name='MyProxy', #subsystem_name='SSIS'
Related
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
Im having trouble using the MySQL ODBC connector.
I have a MS access frontend that im trying to connect to a MySQL DB. It connects fine when running the frontend and DB on my dev machine.
I have moved the front end and DB onto the clients server. The clients assess the fornt end via a shared folder on the individual user PCs. I have set up a file DSN ODBC connection as below. When i open the front end on one of the clients PCs i get the ODBC--call failed.
How do i get the linked tables to look at the server MySQL DB considering ms access is not installed on the server. I have tried to set uo the file DSN via the users pc i.e. open linked table manager and open the File DSN get the ODBC--call failed on connect.
File DSN set up
[ODBC]
DRIVER=MySQL ODBC 5.3 Unicode Driver
UID=root
PASSWORD=root
DFLT_BIGINT_BIND_STR=1
PORT=3306
DATABASE=productionlist_be
SERVER=localhost
thanks in advance Kelly
Welcome to stack-overflow Kelly.
You are missing few points.
The MySQL database Server must be accessible by all your clients.
Either a local machine hosting MySQL server or from internet its up
to you
Must have a static IP or domain name.
Access Front-Ends should not be shared but sent to all of your clients/employees
(This way you are achieving true "multi user access" and thats the main idea behind front and back ends)
All of your client PC must have MySQL ODBC driver installed
All of your clients must have required version of Access or Access Runtime installed
Only after setting up all this, you can think about distributing your application to your clients.
Modify your File DSN replace the localhost with the MySQL Database server ip
like
SERVER=SERVER_NAME_OR_IP
Also it is best to refresh the odbc links via VBA code
you will find much help here:
How do you programmatically update a linked table in Access that will refresh data types too?
OR
Relinking database tables: Access, VBA
hope this helps to get started :)
Do you think it is possible to create a SQL server ODBC Connection for an active directory user who doesn't log in into the windows.
Ideally this type of users will be used in the batch process. So, Another person logs in and creates a batch process and runs it with another user.
Note: I dont want to create a SQL server authentication. Instead would like to use active directory.
Thanks.
You can't save alternate windows authentication credentials into an ODBC connection for SQL Server. You can only save credentials into the ODBC setting if you use SQL Server authentication.
There are other options though.
You can create a windows authentication ODBC connection to SQL server even if the account you create the connection with doesn't have database access. You just have to untick the "Connect to SQL Server to obtain default settings for the additional configuration options" and you can't use the "Test connection" feature. You just have to create the connection on faith.
With that connection, it will only work if your batch process or application is running as a different account to the logged-in user. Services that run as system accounts do this sort of thing. If you create an application that can be run as a service then you can change the account it runs under.
You can also run as another account manually. Using explorer you can [shift] + right-click on an application and choose "Run As different user" and then enter the other account credentials. Then when the process or application uses the ODBC connection, it will be the correct credentials and work.
There's also "ShellRunAs" https://technet.microsoft.com/en-us/sysinternals/shellrunas.aspx
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 :)
Where is a place to look for db settings in ColdFusion? I would like to connect to the db via sequel pro.
Is there a DSN set up on the server that the CF is using? That can be used to connect to the database, and would specify the name, password, database and a bit more. That's accessed through the CFAdministrator page, not in the CF code itself. Only the DSN name is used in the code.
Edit: In the CF admin page, go to the Data & Services tab, then choose Data Sources. That is where the list of DSNs exist. Select a data source to see the connection information. The password is masked.