I am trying to run a powershell to create a .csv file. I have executed the script several times in powershell but I am having difficulty executing it in SSIS. I have an Execute Process Task control. The executable is pointing to my powershell .exe, and the arguments are the path and filename. When it executes I get an error:
[Execute Process Task] Error: In Executing
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
"-ExecutionPolicy ByPass -command".
'c:\MIMPasswordImport\PowerShellScript\MIMImport.ps1'" " at "", The
process exit code was "1" while the expected was "0".
Any help would be appreciated.
Is this the only thing in the SSIS package? If so you don't need a package to create a SQL Agent job to use powershell you can do that directly. If you want to use the code as it exists you can also adapt your powershell script to a script task in an SSIS Package. Of if you just want to populate and create a csv how about using SSIS itself for the purpose. And if you want to run it exactly how it is you likely have an issue in your script that is returning information when it shouldn't as SSIS interprets the returned data differently than you think and has a specific success code that it will expect when used in a process task.
Related
I'm using TFS 2015 Update 2 along with the new Build/Release system. I have a powershell script I'm executing via the Powershell Task. This task executes a powershell script that needs access to the $distributedExecutionContext magic variable I see in many different VSTS Task code samples.
This script in question is not technically a task, but instead is being executed by the Powershell task that comes delivered with TFS.
No matter what I do, I can't see to obtain the $distributedExecutionContext variable. It's always null. Here is an example:
Import-Module "Microsoft.TeamFoundation.DistributedTask.Task.Internal"
if($distributedTaskContext)
{
#... this never happens
}
Is this variable only available if the powershell being run is being run inside an actual task?
The default powershell task that you are using runs the script entirely as a different process and the $distributedTaskContext variable is not available to the script.
It is only available only to the task's powershell script.
If you are going to write a custom task, I would like you to use the new vsts-task-lib SDK which improves a lot over old SDK.
I'm trying to run a Sync from MSBuild (From Powershell) that also includes Pre Sync Commands.
I am unable to get the commands right. I've tried multiple ways, but the final way I'm up to is :
[string[]]$msdeployArgs = #(
"-verb:sync",
"-preSync:runCommand='$preSyncCommand',waitInterval=30000",
"-source:dirPath=$sourceFolder",
"-dest:computerName=$serverName,userName=$username,password=$password,authType=basic,dirPath=$serviceFolder",
"-postSync:runCommand=$postSyncCommand,waitInterval=30000"
)
& "C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" $msdeployArgs
I get the following error.
Error: Unrecognized argument
'"-preSync:runCommand='F:\Projects\Unleashed\Release_Scripts\WindowsServices\deployTopShelfServicePreCommands.cmd
Unleashed.Maintenance.JobScheduler
C:\MyCompany\Services\MyCompany.Maintenance.JobScheduler',waitInterval=30000"'.
All arguments must begin with "-".
Note that after the PreSyncCommand, is params that I want to pass to the CMD file (For it to know where to uninstall the existing service from etc.
I've ran that params via EchoArgs.exe, and the args are fine.
If it matters (It might), I'm running the powershell script from TeamCity.
I've found the issue. As it turns out, it isn't powershell with the issue, but MSDeploy. MSDeploy as far as I can see does not allow you to pass batch files with parameters. Removing the parameters works fine (But then you need to hardcode them in your batch file, or work out some other way of generating the bat files on the fly).
I am currently in the process of implementing a deployment method using Teamcity, which runs a Powershell script on my Build Agent, which then configures my Production environment etc.
I have a problem with the Powershell script though, in that it can't seem to run the batch file from it.
The script runs perfectly if I run it manually, it only fails when run via TeamCity.
In the build log I am getting the error:
'myBatchFile.bat' is not recognized as an internal or external command, operable program or batch file.
The batch file and the powershell script are in the same directory and the batch file is called as such:
cmd /c Deploy.bat
I have my TeamCity configuration set up to have the build step for this as:
Script: File
ScriptExecutionMode: Execute script with -File argument
Script Arguments: None
Additional CMD line params: None
I had originally not used the cmd to try to execute the batch file, but executing the batch file like .\Deploy.bat did not seem to work either.
Is there an additional thing I need to set up in order to get the batch file to run? The rest of the script runs fine, just the call to the batch that doesn't.
This is a bit of a wild stab as it's difficult to predict what's happening, but from the description it seems like the path is been altered in the script and it's also dynamic as TeamCity creates temp directories, but if you replace:
cmd /c Deploy.bat
with
cmd /c "$(Split-Path $myinvocation.MyCommand.Path)\Deploy.bat"
then I think this will be able to located the deploy script.
Let me know how it goes.
I have a Jenkins (1.493) project that uses the Jenkins PowerShell build step to execute a PowerShell script. Inside that script I want to invoke another script that is stored inside a file. I have now reduced it to the following:
Script inside Jenkins PowerShell build step:
& "\\stemmer.local\sidevelopment\cvdev\devbase\jenkins\PowerShell\Test.ps1"
Content of Test.ps1:
write-host 'Hello world!'
Whenever this Jenkins project executes, the PowerShell build step hangs indefinitely.
Things I have tried/verified so far:
Adding some output before the invocation of Test.ps1 shows me that the Jenkins PowerShell script is being execute normally up to the point where Test.ps1 is called.
The file Test.ps1 exists and is reachable from the build slave that executes the script. If I alter the file's name, I get the expected error message from PowerShell...
Exchanging the " for ' in the 1st script does not change anything. Also, using dot-sourcing rather than & does not help.
The file Test.ps1 can be executed properly from the powershell itself using the same command line that is being used in the Jenkins PowerShell script.
The execution policy for PowerShell has been set to unrestricted on my development host as well as on the Jenkins build slave.
I've tried replacing the PowerShell build step with a Windows batch command build step that looks like this:powershell.exe -InputFormat None -File "\\stemmer.local\sidevelopment\cvdev\devbase\jenkins\PowerShell\Test.ps1"and played around a little with the parameters of powershell.exe, but the results were - in those cases that were syntactically and otherwise correct as far as I can tell - always the same.
I only found few references to problems that sounded similar, but none of the approaches mentioned elsewhere did help me fix this. I am absolutely puzzled, and wondering whether someone encountered this issue before (and maybe even got a scenario like the one I have in mind running).
Thanks a lot for any input!
Volker
have you tried to set execution policy to bypass ?
Copy the script file locally, then invoke it from within the Jenkins PowerShell plugin - that way it works as expected.
If I am having MoveIT execute a batch file, which then executes a powershell file. Is there a way for powershell to tell moveIT that the entire powershell script was successful without having to create another file?
I don't know what this MoveIT is, but the Powershell script should be able to do a exit 0 (for a successful completion) and the batch file can do a exit %errorlevel% to communicate success or failure. Using exit codes is the standard way of communicating success or failure while executing scripts.
Sounds like MOVEit Central "command line app" script is being used to launch the bat file. If the bat does nothing else, consider launching the ps script directly, or even better port the ps script to VB and import as a custom script.
What you can do is when power shell completes the job, create an acknowledgment in the folder and setup additional condition on moveit to watch the creation of acknowledgment file. I hope MOVEit Central Advance task creation should be more appropriate.