I've created a SQL Agent Job that executes a SSIS package as one of the job steps. I'm trying to get configure the SSIS job step to be set to execute the package on "localhost" (or whatever I need to call it to reference the same SQL server instance the job is on) so that I can script it the job out, and deploy between environments using the same script.
This is SQL Server 2012, so I'm trying to run it using the SSIS Catalog that's installed on the local SQL instance. I don't want to have to go into the script and change server names as we push the script from development, to the test environment, and eventually production.
I've tried putting "localhost" in the "Server" textbox, then clicking the "..." by the "Package" setting, but I get an error saying "Verify the instance name is correct and that SQL Server is configured to allow remote connections" -- which I take to mean that it's attempting to connect to a server that is actually named localhost, as opposed to just checking itself.
Anyone know how to solve this?
How about in your script:
DECLARE #Command NVARCHAR(MAX) =
N'/ISSERVER "\"\SSISDB\....dtsx\"" /SERVER "\"' + ##SERVERNAME + '\"" ...'
And then pass it (#command = #Command) to sp_add_jobstep instead.
You might have to handle non-default instances returned by ##SERVERNAME special because SSIS doesn't use the instance name, I guess, but I didn't try it out.
Related
I am in trouble with running SSIS packages in my etl process.
There is a table that includes etl steps with different types. i.e. Stored Procedure steps, cmd (copy-move files) steps, sending mail, SSIS steps.
A main Stored procedures runs these steps according to type of steps and logs begin-end times, errors etc. This main stored procedure is
triggered by an sql server job.
When I scheduled this job, SSIS steps takes error which is below;
Error: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has
occurred. Error code: 0x80040E4D. An OLE DB record is available.
Source: "Microsoft SQL Server Native Client 11.0" Hresult: 0x80040E4D
Description: "Login failed for user 'server\user$'.".
Yet, when I run this main procedure manually (with my windows user login) it runs successfully.
I checked this running with proxy account, it didn't work for me. Because inside the sql server job, i run my main stored procedure not SSIS package.
proxy account reference link;
https://www.mssqltips.com/sqlservertip/2163/running-a-ssis-package-from-sql-server-agent-using-a-proxy-account/
It should work so long as your connection to the database is valid. The error message is telling you that server\user$ is not a valid login.
If the SSIS Package is connecting to the DB with a username and password (i.e., a SQL user), then it should be straight forward to set up / configure the login to have access to the server and database where your proc resides, and when you next run the job it should be able to successfully execute the proc.
If instead the SSIS Package is connecting with Windows Authentication, then you'll need to use a Proxy that specifies a Credential that references a Windows / Active Directory account with database access. In SSMS:
Server >> Security >> Credentials
create a new credential
give it a name
specify a windows account that has permissions to execute your proc
Server >> SQL Server Agent >> Proxies >> SSIS Package Execution
create a new proxy
select the credential you just created
Select "SQL Server Integration Services Package" subsystem
Server >> SQL Server Agent >> Jobs >> Your Job >> SSIS Job Step
in the "Run as" field, pick the proxy you just created
Now when you kick off the job, your SSIS package should make a connection to the database using the windows account specified in the credential set up in step 1, which should be able to successfully execute the stored proc.
does your package of SSIS any password? if not,set password for it .then edit your job and write password there too.
If you have a password in your SSIS package, make sure that the ProtectionLevel is set to "EncryptSensitiveWithPassword". If you use "EncryptSensitiveWithUserKey" then you'll be the only user who can run it.
This is the situation: The Dacpac and ISpac files are deployed with a Powershell script.
The result of the dacpac goes to Server1, the ISpac to Server2.
In post-deploy of the dacpac an account and credentials are added on Server1 along with some other configurations.
When that is done, the connection should be changed to Server2 done by :connect Server2, for some additional setup .
When testing in SSMS SQLCMD mode this works fine, but VS complains with error 72006: Fatal scripting error: Command Connect is not supported.
So, can it be done? And if it can, how?
TIA
Make sure that VS have activated the sql cmd mode that is a button in the query toolbar
It looks like what I try to do is not possible, but there is a workaround.
Create a dummy database project with an essentially empty database.
You can either use a publish script to basically not create anything, or you
can drop the database afterwards in your Powershell script.
Put your code in Postdeploy of the dummy project.
Test and deploy
I have a Powershell script that loops through a list of SQL Servers and creates server logins and database users.
The script runs on a separate server, under the administrator credentials on that server, and connects to the other SQL Servers via linked servers.
#Get administrator credentials
$password = get-content C:\Powershell\General\password.txt | convertto-securestring;
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist "DOMAIN\administrator",$password;
When this script is run manually (either directly through a Powershell window or using a batch file through a command prompt) it works perfectly well. I am logged onto the executing server as administrator when running the script manually.
I then tried to run this Powershell script using an SSIS package on the executing server, using the Execute Process Task to run a batch file. The package was executed from a SQL Agent Job. Although both the job and the package seemed to execute successfully, the DDL statements were not executed against the linked servers.
SQL Agent on the executing server is run under a designated Service Account. SSIS runs under the Network Service account.
Does anybody have any thoughts on what I might be doing wrong? I am happy to provide details of the script or anything else that is required.
Thanks
Ash
UPDATE: ok we have a little more information.
I took out the lines I posted above as I have discovered I don't actually need the administrator credentials I was retrieving.
I logged onto the server with the script on it using the service account. As per #ElecticLlama's suggestion I set a Profiler trace on the destination server. When running the script manually (or running a batch file manually that runs the Powershell script) everything works well and the Profiler shows the DDL actions, under the service account login.
When running a job through SQL Agent (either a CmdExec job or an SSIS package) that runs the same batch file, I get the following error:
'Login failed for user 'DOMAIN\ServiceAccount'. Reason: Token-based server access validation failed with an infrastructure error.'
Anybody have any further thoughts?
Thnaks to everyone for their help. Once I got that last error a quick search revealed I just had to restart SQL Agent and now everything works as it should. Thanks in particular to #ElecticLlama for pointing me in the right direction.
Ash
I am creating user creation script in an SQL Server 2008 Database Server project in Visual Studio 2010.
The script looks like this...
CREATE LOGIN Domain\User FROM WINDOWS
I will be developing on both my desktop PC and laptop. Neither run on a domain and use local users e.g. DESKTOP\TestUser and LAPTOP\TestUser.
What I need to do is to somehow inject a variable into the script that automatically sets the domain name. I believe in SQL Server this is ##SERVERNAME. Then I can work on both my PCs and the script will work. At present if I run it on say my laptop I get an error as DESKTOP\TestUser is not a Windows Principal on my laptop.
I have looked at the .sqlcmdvars files and I can set a variable in there that gets injected into the script. However I cannot seem to get this to something dynamic such as ##SERVERNAME.
I have also looked at running EXEC from my post deployment script but I get an error saying that this command is not valid in this context - I believe that means that EXEC is not accepted in the VS2010 DB project.
You can use the following script to achieve that. It works for me well and creates a login for the local user:
declare #sql nvarchar(max) = N'create login [' + ##SERVERNAME + N'\TestUser] from windows'
exec(#sql)
I am trying to move all .zip in a specific folder to another folder. the source folder is located on another server, currently i am using
EXECUTE xp_cmdshell 'copy \\server1\e$\ETL\*.zip \\server2\e$\ETL\'
GO
Which is working if I am logged into both server, but the goal is to automate this process VIA sql server job agent. I have tried
EXECUTE sp_xp_cmdshell_proxy_account 'domain\useracc','pass'
GO
EXECUTE xp_cmdshell 'copy \\server1\e$\ETL\*.zip \\server2\e$\ETL\'
GO
but I am receiving the following error;
An error occurred during the execution of sp_xp_cmdshell_proxy_account. Possible reasons: the provided account was invalid or the '##xp_cmdshell_proxy_account##' credential could not be created. Error code: '0'.
And also not sure if this is my solution. Please help with how I can achieve this. The file names on server1 change name and quantity everyday.
I would strongly advise...Do not use xp_cmdshell. It opens up large security wholes in your surface area and makes you vulnerable to attack. xp_cmdshell should be disabled!
Instead, if you want to automate this with server agent you have 2 options. My preference would be to write a simple SSIS package with a file system task and schedule this package with server agent. SSIS is underutilized for this kind of task but is actually pretty good at it.
Alternatively re-write your script to use Server Agent CmdExec job steps. This does not require xp_cmdshell to be enabled and reduces the attack surface.
I Found that the following worked for me;
In the command prompt, type services.msc, this would open the list of all services on the server.
In the list of services, look for SQL Server Agent, Right Click -> Properties. Go to Logon Tab
Change the logon to a user with access on both servers. then re-write your script to use Server Agent CmdExec job steps(Thank you Pete Carter)