I'm using Azure DevOps pipelines, and have a PowerShell task that runs stuff with Invoke-Sqlcmd. The PowerShell works fine when run from my computer, but when it runs through the pipeline it says it can't find or doesn't have access to the server. I don't see anything in the failed connection logs on my sql servers...
I assume whatever account the pipeline is attempting to connect under does not have access. How can I find out what that account is?
If you're curious, here's the simple PS, it just updates a table:
Invoke-Sqlcmd -ServerInstance "myremoteserver" -Query "--update the table"
You can add a powershell task to run below script to get the current user account that your pipeline is using
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
Related
I have a encryption job set, it executes just fine in Visual studio but give the following error in SSMS job agent-->
Error retrieving emailid#domain.com via WKD:No data gpg
skipped: No Data
Using SQL 2017. I tried using CMDEXEC instead of SSIS Package in job settings but it doesn't solve the problem
Arguments:
--quiet --yes --trust-model always --passphrase mypassphrase --recipient XXX#XXX.com --trust-model always --output D:\Folder\File.csv.gpg --encrypt D:\Folder\file.csv
So I was executing job from the proxy account and apparently proxy and own account is different when it comes to gpg key import. Meaning- I had imported keys using gpg/Kleopatra in my desktop using my windows credentials and was calling the job with my proxy account from job agent. Hence the proxy account was not able to access the keys. This is what solved my problem- https://superuser.com/questions/1176705/windows-account-cant-see-gpg-key#new-answer
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 setup a build server at the company I work for.
This build server interactively works with Visual Studio Team Services.
Building works great and so does publish. The issue I am running in to is the ability to run "dotnet test" as a different user.
This is needed because currently the user the agent runs under is a service account. It has access to IIS and has the ability to move files where they need to be. But it does not have access to the database.
Since we have a few integration tests that we utilize, it errors out when connecting to the database because it is trying to connect as the service user.
So far I have not found a way to run "dotnet test" as a different user, specifically one that has access to query the database.
I tried utilizing the VSTS Task "Run Powershell on Remote Machines" since it lets me supply a username and password. But it seems to have issues trying to remotely connect to itself (which is probably understandable).
I am at a loss. I have no idea how to get this to work. Except giving the service user the ability to run those queries on the database.
Any help is greatly appreciated!
SQL authentication is the better way. So change connectionstring to use SQL authentication.
Server=myServerName\myInstanceName;Database=myDataBase;User Id=myUsername;
Password=myPassword;
Authentication article: Choose an Authentication Mode
You could start a process with the desired identity by passing appropriate credentials, e.g.
param($user, $pwd)
Start-Process $DOTNET_TEST_COMMAND -WorkingDirectory $DESIREDCURRENTWORKINGDIR -Credential (New-Object System.Management.Automation.PSCredential -ArgumentList #($user,(ConvertTo-SecureString -String $pwd -AsPlainText -Force)))
My opinion is that during a build only unit tests should be executed, as you could have side effects on the shared build machine if you execute more convoluted tests as functional tests.
Instead than running the functional tests on the build machine, I would suggest to use the Run Functional Tests task during a Release of VSTS, as it would allow you to:
distribute the tests on a pool of machines where you installed the test agent by means of the Deploy Test Agent task);
provide the credentials of the identity the tests run for, this functionality is present out of the box in the task, i.e. solve your problem at the root;
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.