Improving PowerCLI Support with Get-ErrorReport

Improving PowerCLI Support with Get-ErrorReport

This post was originally published on this site ---

I am always surprised at the shock some people have when it comes to PowerCLI being supported by VMware! We highlighted this in a prior blog post: PowerCLI Support Breakdown However, in that blog post, there was one item that wasn’t covered which can really help streamline the process of receiving support. This item is a cmdlet by the name of Get-ErrorReport and it received a big update as part of PowerCLI 11.

Let’s walk through an example of creating a PowerCLI support bundle using Get-ErrorReport.

Receiving an Error

The first thing we need to do is receive an error! In this case, I’ll be using a known issue with the Move-VM cmdlet which occurs when attempting to move a VM into a vApp.

Example: Generating an error

The error we received was:

Move-VM : 11/14/2018 1:12:31 PM Move-VM         A specified parameter was not correct:

This is a pretty straightforward issue where the Move-VM cmdlet is not operating in the way which was been documented. We can now open a support request!

PowerCLI Support Bundle

Normally, when you open a support request, the first ask is for a support bundle from either the vCenter, an ESXi host/s, or even all of the above. Since this is a PowerCLI issue, those standard support bundles may not help. Plus, some of the more advanced PowerCLI troubleshooting options are not easy, or not readily available, in most environments. One example of which would be to use a tool like Fiddler or Wireshark to sniff the network traffic in order to determine what API methods are being used under the covers and hopefully identify the issue.

Instead of going through the process of installing Fiddler or Wireshare, we can retrieve all the required information by making use of the Get-ErrorReport cmdlet!

The Get-ErrorReport cmdlet has a couple important parameters we’re going to be making use of:
Note: If you’ve used Get-ErrorReport before, these parameters have changed

Destination Location of where the PowerCLI support bundle will be placed
IncludeServerLogs Specify whether we want to pull logs from the connected server
ProblemDescription Provide a description and/or support number
ProblemScript Scriptblock which contains the cmdlet causing the error

Continuing with our Move-VM example, we can use the following code to create our support bundle:

$errorCode = {
  $appsvr = Get-VM -Name appsvr02
  $vapp = Get-VApp -Name DemovApp
  Move-VM -VM $appsvr -Destination $vapp
Get-ErrorReport -ProblemScript $errorCode -Destination .Documents -ProblemDescription "Using Move-VM to place a VM into a vApp"

Example: Get-ErrorReport command being run

We can now take that output and upload it to our support request!

Support Bundle Examination

If you happen to be curious about what information is contained within the support bundle, like I was, we can unzip the bundle and read through the contents fairly easy. Note: this section is purely educational as the support engineer will handle the actual diagnosis.

The support bundle contains the following files:

  • PowerCLI-Main-Log.svclog
  • Powershell-Debug-Stream.txt
  • Powershell-Error-Stream.txt
  • Powershell-Info-Stream.txt
  • Powershell-Verbose-Stream.txt
  • Powershell-Warning-Stream.txt

The contents of those files should be fairly straight forward, with the exception of the first one. The PowerCLI-Main-Log.svclog is a collection of diagnostic traces. These traces contain all of the pertinent information about the cmdlets being used, how it is being interpreted by PowerShell, and then the underlying call to the vCenter. The svclog file can be opened with the Microsoft Service Stack Trace Viewer. This application is available as part of the Windows SDK, available here: Windows SDK Archive

The following screenshot is a look at the actual exception being returned by the API service:
Example: Reading the svclog exception

We can see the server response was an internal server error, which has a status code of 500. We can then further read through the individual trace to see the properties and methods being used. We also have the option to look at the traces before and after the call happened to see each of the steps being performed as part of the code entered in our $errorCode scriptblock.


PowerCLI is supported by VMware and the Get-ErrorReport cmdlet was recently improved in PowerCLI 11. The upgrade helps to streamline the support experience by creating a PowerCLI support bundle which can be provided to VMware support. This support bundle includes all of the required environmental information that VMware support will need to start troubleshooting the issue being reported.

The next time you need to open a support ticket on PowerCLI, make sure to use Get-ErrorReport and let us know your feedback!

The post Improving PowerCLI Support with Get-ErrorReport appeared first on VMware PowerCLI Blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.