3

I'm using PowerShell remoting to execute an exe file on a remote server. The problem is that the exe needs to have its Working Directory set to the directory that the exe is in for it to run properly. If I run the exe locally (on the server) from a command prompt it works fine, and if I use Enter-PSSession (from my workstation) and then use Start-Process -FilePath [PathToExe] -WorkingDirectory [DirectoryPath] that works fine, but if I use Invoke-Command -ComputerName [Blah] -ScriptBlock [MyScriptBlock] or $session = New-PSSession -ComputerName [Blah]; Invoke-Command -Session $session -ScriptBlock [MyScriptBlock] (from my workstation) then the working directory does not get set.

This is what [MyScriptBlock] looks like:

$scriptBlock = {
        param($version, $database)
        $hubSyncronizerExeDirectoryPath = "C:\inetpubLive\ScheduledJobs\$version\"
        $hubSyncronizerExePath = Join-Path $hubSyncronizerExeDirectoryPath 'Test.exe'
        Set-Location -Path $hubSyncronizerExeDirectoryPath
        Get-Location
        Write-Output "$version $database"
        Start-Process -FilePath $hubSyncronizerExePath -WorkingDirectory $hubSyncronizerExeDirectoryPath -ArgumentList '/database',$database
}

I've also tried using Invoke-Command instead of Start-Process, but it has the same effect; the Working Directory does not get set.

I've verified this by using the SysInternals Process Explorer, right-clicking on the process and choosing Properties. When I launch it locally or use Enter-PSSession, the Command Line and Current Directory properties are set, but not when using New-PSSession or just Invoke-Command with ComputerName.

enter image description here

I'm using both Set-Location and setting the -WorkingDirectory, which are the 2 typical recommended approaches for setting the working directory, and Get-Location does display the expected (server's local) path (e.g. C:\inetpubLive\ScheduledJobs\1.2.3.4). I'm guessing that this is just a bug with PowerShell (I'm using V4 on workstation and server), or maybe there's something I'm missing?


UPDATE

It turns out that the working directory was a red herring (at least, I think it was). For some reason everything works fine if I called my executable from a command prompt.

So in my Invoke-Command (I replaced Start-Process with Invoke-Command), changing this:

& ""$hubSyncronizerExePath"" /database $database

to this:

& cmd /c ""$hubSyncronizerExePath"" /database $database

fixed the problem.

Thanks for all of the suggestions guys :)

deadlydog
  • 22,611
  • 14
  • 112
  • 118
  • Two additional options I can think of, one is to set `[Environment]::CurrentDirectory` in the script as well before starting the process. Another is to create an instance of `System.Diagnostics.ProcessStartInfo`, set the working directory, and then call `Process.Start` directly. – Mike Zboray May 15 '15 at 02:18
  • Thanks for the suggestions @mikez. I tried both, but still have the same result :( – deadlydog May 15 '15 at 20:12

1 Answers1

0

Try looking at New-PSDrive and see if that helps

I guess you'll want something like

New-PSDrive -Name WorkingDir -PSProvider FileSystem -Root "\\RemoteServer\c$\inetpubLive\ScheduledJobs\1.2.3.4"

CD WorkingDir:

I assume you should be able to amend your script to include and put in the $version variable in to the path on the New-PSDrive command...

Not certain this will do what you need it to do, but it's the first thing that sprang to mind...

Alternatively, try amending your script as follows:

$hubSyncronizerExeDirectoryPath = "\\remoteserver\C$\inetpubLive\ScheduledJobs\$version\"

Charlosa
  • 111
  • 1
  • 3
  • Thanks for the suggestion. I tried specifying the fully qualified remote server path, but that caused the exe to never get launched at all. I'll give your suggestion of New-PSDrive a try a little later. Thanks. – deadlydog May 15 '15 at 20:15