I'm trying to setup new job step in SQL Server Agent.
I need to do with powershell with administrator. What I am trying is:
$env:Path += ';C:\Program Files\Amazon\AWSCLI'
aws s3 sync D:\MSSQLBackups\ s3://myfolder/DB_backups
If I do it from powershell it works well.
But, if I create job step with powershell type or cmd, it does not work.
Where is my mistake?
Problem fixed. As i understood Job step launch from user SQLSERVERAGENT. So, i just copied folder .aws from C:\Users\Administrator to C:\Users\SQLSERVERAGENT (but before i have setup aws configure. In .aws folder you should have 2 files: config, credentilas).
Related
I have a windows instance set up on AWS. I have Jmeter and Ant installed on that machine to run API test cases.So I can successfully run tests on remote server. I need to set up a job on corporate Jenkins to run those test cases on aws server. I have server's IP address and username and password to log in to aws server.
How do I set up a job on corporate Jenkins which will run my test cases on remoter aws server? (Execute windows command)
Thank you.
did you connect this AWS machine as a slave to the master ? or you can't do it ?
I think that the best is connect this machine as a slave and create a dedicated job to run on the windows machine
Setting up a new Ant task to run JMeter test in Jenkins is fairly easy, here is a simple Pipeline script which executes Ant task using build.xml file in the "extras" folder of JMeter installation and publishes resulting HTML report on the build artifacts page:
node {
ws('c:\\jmeter\\extras') {
stage 'Run JMeter Test with Apache Ant'
def antHome = tool 'ant'
bat "pushd c:\\jmeter\\extras && ${antHome}\\bin\\ant -f build.xml"
step([$class: 'ArtifactArchiver', artifacts: 'Test.html', fingerprint: true])
}
}
You will need to define ant tool so Jenkins would know what is "ant" and where it lives. See Running a JMeter Test via Jenkins Pipeline - A Tutorial article for details.
Alternative options are:
If you have Jenkins admin access or your user has "Job - Configure" role you have "Configure" button where you can see (and change) all the build steps
You can copy the whole Jenkins installation over to your corporate intranet (don't forget JENKINS_HOME folder)
Thank you both for your response. I have set it my windows AWS machine as Slave. And I was able to run the job on AWS server from corporate jenkins.
SSIS Job was able to run and create CSV files to shared location until last week when it was executed from scheduled job. The ssis package reports success but does not write file to shared location. When I run the package manually from visual studio it works fine. Please help
Permissions to the file share seem to be your issue.
When running the package as a scheduled job from SQL Agent. It is executed under the context of the service account for the SQL Agent Service. So make sure the the sql agent account has the appropriate read/write access to the file share, and/or set the job to execute as a user with enough permissions.
You need to give Modify permissions to the file share for the SQL Server Agent account. Executing an SSIS package in Visual Studio is executing it under the context of your account (or the account that you are logged onto the server with if doing it from a server). But when you use SQL jobs to execute the ssis package, then it runs under the context of the service account that SQL Server Agent is running under.
I am writing a PowerShell script to archive compressed C2 Audit files to a file share. What is possibly the last problem I am having is giving the .Net compression routine the privilege to manipulate the files. During development, I could flaunt my account's admin role to propagate Full Access privileges to the files in the DATA directory. However, the script is to run from a PowerShell step in an Agent job, and I want to automate the ACL change as well.
For an added level of difficulty, I am doing this under SQL Server 2012, so I am stuck with PowerShell 2.0. I am using .Net 4.5 compression routines via a process of loading $RunActivationConfigPath with a temporary config file. I was not able to find a way to change that config file to promote the admin role, though.
This is a segment of a script by Benjamin Armstrong that checks if the connection is using Administrator privileges.
# Get the ID and security principal of the current user account
$runtimeWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent();
$runtimeWindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($runtimeWindowsID);
# Get the security principal for the administrator role
$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator;
Write-Output ("Running under "+$runtimeWindowsID.Name)
Write-Output ("PS Version "+$PSVersionTable.PSVersion.Major)
# Check to see if we are currently running as an administrator
if ($runtimeWindowsPrincipal.IsInRole($adminRole) -eq $true) {
Write-Output "We are strong."
} else {
Write-Output "We are not strong."
}
Running the script as an Agent Job step produces:
Running under NT Service\SQLSERVERAGENT
PS Version 2
We are not strong.
Running the script from sqlps in Admin mode produces:
Running under DOMAIN\myusername
PS Version 2
We are strong.
All the ways I've seen to elevate a script involve using a script file. For example, creating a new process and executing it with RunAs as the Verb. I want to avoid script files and have everything in the step. I like the added security (however small) of needing SSMS privileges to view the code.
So, here are my questions:
1) Is there a way to elevate commands in a script block?
2) Is there a way to have the PowerShell step in an Agent Job run in Admin mode?
Extra credit question:
3) If I do need to add the Agent service account to a Windows User Group, which of the two dozen groups would give that account the minimum privileges needed to alter an ACL for a file, then eventually delete it?
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 have an SSIS package with the Execute Process Task, which runs 7zip exe to zip a file. This works fine when I run the SSIS. But when I run this SSIS from the SQL Agent it hangs. I assume this is something to do with the permission. I have given full control to Network Services and sqlsvc to the folder which has the zip exe and the folder it is extracting to. Still no luck. What should I do to make this SSIS run from the SQL agent.
I have created a proxy account which has administrator privilege and change the Job Step "Run As" property to the new proxy account instead of SQL Agent Service Account. I think the SQL Agent Service account doesnt have the access to run the process. You can also change the SQL Agent Serice Account group policies to make it work.
I would change the WindowStyle property to Hidden - the SQL Server agent may be hanging when it tries to create a Windowed process.