Error: "Deployment failed on machine..."

[mtbgithub]

Log as requested - I have obscured some identifying details with [...].

2018-07-05T00:40:52.6715641Z ##[section]Starting: Install ADSM via Topshelf 2018-07-05T00:40:52.6715641Z ============================================================================== 2018-07-05T00:40:52.6715641Z Task : Install Topshelf Service 2018-07-05T00:40:52.6715641Z Description : Installs a TopShelf service using the standard command line options for Topshelf 4.0. 2018-07-05T00:40:52.6715641Z Version : 8.0.0 2018-07-05T00:40:52.6715641Z Author : Michael Barry 2018-07-05T00:40:52.6715641Z Help : [More Information](https://github.com/jabbera/my-vsts-tasks) 2018-07-05T00:40:52.6715641Z ============================================================================== 2018-07-05T00:40:53.8746776Z Installing TopShelf service: \\[**servername**]\DataStorage\Deployed\Dev\ADSM\service\ADSM.WinSvc\ADSM.WinSvc.exe with instanceName: . 2018-07-05T00:40:53.9059253Z CMD: $env:DT_DISABLEINITIALLOGGING='true' 2018-07-05T00:40:53.9059253Z $env:DT_LOGLEVELCON='NONE' 2018-07-05T00:40:53.9059253Z Stop-Process -name mmc,taskmgr -Force -ErrorAction SilentlyContinue 2018-07-05T00:40:53.9059253Z & "\\[**servername**]\DataStorage\Deployed\Dev\ADSM\service\ADSM.WinSvc\ADSM.WinSvc.exe" uninstall -username "[**username**]" -password:"********" 2018-07-05T00:40:53.9059253Z & "\\[**servername**]\DataStorage\Deployed\Dev\ADSM\service\ADSM.WinSvc\ADSM.WinSvc.exe" install -username "[**username**]" -password:"********" --delayed 2018-07-05T00:40:53.9059253Z 2018-07-05T00:40:53.9996758Z Performing deployment in parallel on all the machines. 2018-07-05T00:40:54.0152978Z Deployment started for machine: [**servername**].[**domain**] with port 5985. 2018-07-05T00:41:04.7809441Z Deployment status for machine [**servername**].[**domain**] : Failed 2018-07-05T00:41:04.7965760Z Deployment failed on machine [**servername**].[**domain**] with following message : System.Exception: The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: System.Management.Automation.RemoteException 2018-07-05T00:41:04.9684470Z ##[error]Deployment on one or more machines failed. System.Exception: The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: System.Management.Automation.RemoteException For more info please google. 2018-07-05T00:41:04.9840715Z ##[section]Finishing: Install ADSM via Topshelf

[jabbera]

Hi,

It doesn’t appear that the system.debug variable is created and set to true. Can you rerun with this variable?

Another thing. I see you are installing from a network share. This requires Kerberos and spns to be set properly and is rife with potential errors. The preferred solution is to use the windows file copy to copy services to the local machine.

Either way, you can debug the remoting script by copying it from the log and trying to run it via winrm: invoke-command as the deployment account. This will likely show specifically what the issue is.

Mike

[mtbgithub]

system.debug can only be set on the build, this is a release, which appears to have no such option and it would appear that the system.debug flag does not propagate through.

It's a unc path but to the same machine on which the files have been copied from the drop artifacts from the build step, problems with kerberos are that actual reason why I chose this route, clearly you've been there too! ;-)

I'd still appreciate an answer to the question I posed in the other thread - does this require PS5 and on the build or target box?

Cheers

[jabbera]

Hi,

The install probably doesn’t require ps5 anywhere. Start/Stop do on the Target. I’ve never tested without it so I never bothered to differentiate when people started reporting issues on ps4.

You can actually just set a release variable called: system.debug with a value of true and it will do the same thing as in a build. Why there is no UI for it or a variable created by default is a mystery to me. It works. I promise:-)

Mike

[jabbera]

Are you saying you are running the TFS/vsts release agent on the machine you are deploying the software on?

If so you can check the deployment group option in the task and it won’t use remoting at all.

[mtbgithub]

"You can actually just set a release variable called: system.debug with a value of true" - slap me for missing that one!!

Mislead you it seems. The build agent is on one box and the service is on the other, where the files have been copied to (unc path).

Debug log attached adsm release debug.log

[mtbgithub]

Did some further digging based on the log.

The command...

Stop-Process -name mmc,taskmgr -Force -ErrorAction SilentlyContinue "\\[**server**]\DataStorage\Deployed\Dev\ADSM\service\ADSM.WinSvc\ADSM.WinSvc.exe" uninstall -username "[**username**]" -password:"********" "\\[**server**]\DataStorage\Deployed\Dev\ADSM\service\ADSM.WinSvc\ADSM.WinSvc.exe" install -username "[**username**]" -password:"********" --delayed

...gives a bunch of issues. Running the install part...

"\\[**server**]\DataStorage\Deployed\Dev\ADSM\service\ADSM.WinSvc\ADSM.WinSvc.exe" install -username "[**username**]" -password:"********" --delayed

...on its own in a command prompt works just fine but does not work in PS ISE, gives the following error...

`At line:1 char:83 ... SM.WinSvc.exe" install -username "[username]" -password:"****" --d ...

Unexpected token 'install' in expression or statement.
     CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
     FullyQualifiedErrorId : UnexpectedToken`

[jabbera]

If that command doesn’t work in a stand-alone powershell environment we need to figure out what is wrong.

I just accepted a PR w.r.t. the username parameter. Can you try replacing the space in -username “username” with -username:”username”?

If that doesn’t work can you add one command line argument at a time until you figure out which is wrong. It could be anything. Space, special character, etc.

[mtbgithub]

Sorry I haven't got back to you sooner. I eventually found an alternative way to address the issue by running the install/uninstall commands directly via remote powershell.