Return an Error Message from a Remote Computer when an Attempt to Install a Package using the OneGet Module Fails

This blog article will walk you through the issue of the OneGet module not returning an error message when an attempt to install a package fails on a remote computer via the Install-Package cmdlet and PowerShell remoting.

Attempting to install a package such as WireShark on a remote computer gives you a quick flash across the screen that’s too quick to read and then it gives your prompt back with no errors and no feedback about whether or not the package was installed:

2014-04-10_19-30-15

Checking the remote machine, shows that the WireShark package was not installed:

2014-04-10_19-31-03

Trying to install the WireShark package locally gives you a prompt about the chocolately package source being untrusted which I blogged about earlier in the week. I’ll now attempt to install it using the -Force parameter which allows the install to complete for several other packages when using the same method to install them on a remote computer:

2014-04-10_19-53-18

Initially, it seems to be working properly by specifying the -Force parameter as shown in the previous example, but then you end up with the following results:

2014-04-10_19-53-52

These are actually dependencies and had this command to install the WireShark package been run interactively on the local computer, you would have seen that in the progress:

2014-04-10_19-36-05

I decided to add some error handling to see what happened and that’s where the strange behavior part of this begins (you’ve just entered the twilight zone):

2014-04-10_20-06-09

An error has occurred. Error details: System.Management.Automation.ActionPreferenceStopException: The running command
stopped because the preference variable “ErrorActionPreference” or common parameter is set to Stop: Process Execution Failed:’AutoHotkey’ — The system cannot find the file specified at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception) at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame) at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame) at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException
+ PSComputerName : pc06

The strange part isn’t the error message itself, but that I was able to interact with the remote session just like it was run locally and I was able to see the progress as if it were run locally. I actually thought maybe it did run locally until I verified the prerequisites that were installed, were indeed installed on the remote computer and not the local one:

2014-04-10_20-13-28

I ran the same command against a different computer and received a different error:

2014-04-10_19-36-43

Then I thought about adding the -Force parameter since that worked with other packages:

2014-04-10_20-24-25

What I learned is, at least for now, if you want to receive errors back from a failure when attempting to install packages on remote computers using the OneGet module and PowerShell remoting is to add error handling and generate a terminating error if an error occurs (Try-Catch only handles terminating errors).

Attempting to install that package on the local computer fails as well with the same type of problem which appears to be an issue with a dependency either being unavailable or being unable to be installed on this particular operating system (Windows 8.1).

2014-04-10_20-34-10

µ

Leave a Reply

%d bloggers like this: