I am trying to deploy my SQL Server project into another database using Execute Azure SQL Tak:Dacpactask in VSTS. But I am getting a error that can't find the user that was in Source Database. I am using Admin credentials to deploy the scripts in target environment, But it shows that the source user is not available in target environment. Since user and logins are database specific, I don't want to make any changes in the users and logins. I want it to remain same. I have attached error in below link.
[Error that I recieved during deployment]
[1]: https://i.stack.imgur.com/IdrsD.jpg. Please let me know how to solve . I have added below Additional SQL Package.exe arguments,
/p:DropObjectsNotInSource=False/p:DropObjectsNotInSource=True /p:ExcludeObjectTypes=Users;Logins;RoleMembership;Permissions
Do we need to provide any delimiter for multiple arguments?
Related
Setup: A pretty standard data export SSIS package (SQL Server 2016 compatible), created in VS2019/Data Tools and deployed using the SSIS Project Deployment model to the Integration Services Catalog of a SQL Server 2016 instance. The package creates files in a network folder before sending the file out via FTP and putting a copy of the file in a Sent folder.
The project requirements include having the package running on a schedule using "default" parameter values, as well as allowing users to manually run the package using "non-default" parameter values from within a stand-alone application.
Current behavior: the package behaves correctly when run from a SQL Server Agent Job that is configured with a SQL proxy and credentials mapped to a domain login with the proper permissions for the network folder.
Problem: the Data Flow task fails to create the file with a "Cannot open the datafile" error when running the package directly using any of the following methods (even when the "current" session is using the same credentials as the SQL Server Credentials/Proxy used by the SQL Server Agent Job):
Using SSMS to right-click on the package and selecting Execute
Using the DTEXEC SQL utility
Using the SSISDB.catalog.start_execution SQL Server stored procedure
As far as I'm aware, these are the only methods capable of starting a SSIS package and changing the package's parameter values. I either need to get one of the latter 2 methods to work, find another option that allows for changing the parameter values while launching the package, or use one of 2 techniques I'm aware of (detailed below) that would add yet another failure point to the process as well as other potential issues.
Note: If the process is changed to initially create the file on the SQL Server's local harddrive, then the Data Flow task succeeds, but the later copy to Sent folder task fails with a very similar permissions error.
Alternative #1: this technique requires creating a new table, loading the parameter values to the table, changing the package to check the table and potentially set it's parameters/variables based on what it finds. The package can then be launched using a SQL Server Agent Job (for which there are multiple methods to manually launch them) and if the calling object has correctly populated the table, the package will behave as if it's parameters were changed at runtime otherwise it will run with the default values.
Alternative #2: Change all folders used by the package to point to folders local to the SQL Server instance and then create a separate scheduled task/application/whatever, with the valid credentials, that would synchronize or move the files to their proper network folders.
even when the "current" session is using the same credentials as the SQL Server Credentials/Proxy used by the SQL Server Agent Job
This is probably because the account is not logged on locally at the SQL Server, and so it's a Double-Hop Impersonation scenario, and would require Kerberos Constrained Delegation to be configured.
And you are correct in assessing the options. The general solution is to invoke catalog.start_execution from a session running on the SQL Server, and an Agent Job is the simplest built-in way to do this (the others being xp_cmdshell, Service Broker Activation, or SQL CLR).
I have been able to set up an active directory login for my Azure database.
Now I want to add additional active directory logins and set their permissions
I understand that I need to use Management Studio to do this and have installed SSMS v17.8.1
I have been studying docs but I can't find the instructions
[Update]
After reading Conor's answer I was able to create the user
CREATE USER [jobuser#mydomain] FROM EXTERNAL PROVIDER WITH DEFAULT_SCHEMA=[dbo]
However if I try to login using MSSMS with Active Directory - Password authentication I get
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' (MIcrosoft SQL Server, Error 18456)
[Update]
In the Connection Properties Tab
I had to overtype with the database name
That particular page only shows an example using a SQL login/user, so I can understand why you are confused.
Please read through this page:
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql?view=sql-server-2017
Specifically, you want to create a user using the AS EXTERNAL PROVIDER example. This tells SQL Azure (and SQL DW) to use Azure Active Directory instead of creating a SQL user. Please note that this does not (as of today) work in SQL Server. (SQL Server supports integrated authentication against a local Active Directory, but it just does not currently support the Azure Active Directory service).
Also, there is no specific requirement that you use SSMS to do this step. You can do it within SSMS, SQL Operation Studio, through one of the SQL client drivers in a program you write (or some third party program that can invoke SQL over them), sqlcmd, etc. You don't even need to have the latest SSMS to make things work (though it is recommend to get the best experience against SQL Azure including syntax highlighting).
Please give that a try and see if it gets you unblocked.
Best of Luck!
Question
Sign in to vote
0
Sign in to vote
VS2013 Community html project, SQL2014 Standard db
Does anyone have a good walkthrough of deploying with an intrinsic db? Deployment with external db works fine, but not with intrinsic.
F5 build works fine on localhost with external or intrinsic db, server deploy to IIS/SQL works fine with external db... just not with intrinsic db...
None of the docs I have found are real detailed about how to setup sql server to handle the intrinsic deployment.
Created the sql project, selected that in LS app properties. Do I create a DB on the SQL server or does LS do that? The Publish dialog on the database step says the admin account will be used to "create and update" the db. Have tried sql admin account with and without specifying a target db. Can the user account be the same as the admin account? Tried that both ways.
Moved from RDS to a fully managed SQL instance and now works. – user5050939 just now edit delete
I have got a ssis package which runs when I manually run from Integration Services. But when I try to run it from a job. Then it runs but no data is seen in the data. There seems to be some permission issue. Can somebody tell me what permissions are required for running a package from a SQL Server Job?
State the error message.
If you are using a flat file connection manager, and that's where the error is occurring, click 'start' then 'computer' then check to make sure you are mapped to that drive. If not, click the tab upper right corner to map to the drive then when you access the file through SSIS you shouldn't have an error.
If the package runs successfully as a job using the SQL Server Agent then you have the permissions set right for the database side.
However make sure if you are accessing any external data such as flat files that the agent is able to access these locations. You may have permissions on your Windows account to access the locations when you run the package in Visual Studio but the agent service running the job requires those permissions too.
If this is not the case can you clarify what your package does and any messages you receive from the catalog reports so I can help further.
I have an SSIS package that transfers some tables to CSV files on a network drive; it runs fine from my computer manually. I store it on the server in the MSDB database and execute it from there and it runs fine, but when I create a job that has one step that runs the SSIS package from MSDB it fails saying it can't find the CSV file name.
I spent all day yesterday figuring out this means a permissions issue with whatever logon credentials are being used through the job. The job owner shows to be domain/myuserid and step properties show they are using windows authentication with my username. The problem is, I know I have access to this folder.
The first line of the error log says: "Executed as user: servername\SYSTEM". So I made sure user "SYSTEM" has access to the network folder I want to load the files on, but I still get the same error.
The command line looks like #command=N'/SQL "\SSIS package name" /SERVER servername /CHECKPOINTING OFF /REPORTING E'
edit: I found SQL Server agent job account issue where someone asks who the job is run under and marc_s says "I can't seem to find any definitive answers on that one, really. Since my Jobs typically select and update stuff in the database, I am lead to assume that the "Owner" account will be used by default, unless you specify some other account on a given step"
Which also leads me to believe it is using my logon information that has access
The best practice that we've been able to come up with here is to make a domain account for SSIS and then set up a Proxy in SQL Server that is used to run the SSIS Package in a SQL Job.
I would say that the servername\SYSTEM account is a local account, and therefore won't have access to network folders on other servers.
You probably want to run this as a domain account of some sort, which does have access.
Typically this will be the SQL Server Agent, so check in the Services list, in the control panel, and see what account is running the agent, and if necessary change it to the appropriate account.
This may have knock on consequences though, so be careful what other jobs are running.