Evend ID 19050 when exporting VMs via scheduled Powershell script RRS feed

  • Question

  • I have several servers that export their running VMs using Mike Galvin's script here:

    In short this script checks for running VMs, exports the running VMs to a particular location, logs it, and can email if desired.

    All but one of our servers runs this script fine. On the server in question I can log personally, open powershell in admin mode and successfully run this script with zero errors. However sometime in the last year the automated way we run this script stopped working... sort of.

    On this server there are 7 VMs running. When the script is kicked off via Scheduled Tasks, 6 of the 7 VMs take the following error:
    Event ID 19050 'ServerX' failed to perform the operation. The virtual machine is not in a valid state to perform the operation. (Virtual machine ID 7B70D5A0-F71C-45BA-8506-AB5A983594AF)

    We have a dedicated account that runs these scripts. Again all other servers running this script have zero errors. I changed the account running this script to my own since I can successfully run it manually. Still pulls that error.

    I've done a little searching on it and most of the data I find doesn't help. Does anyone have any ideas?

    Friday, December 6, 2019 5:21 PM

All replies

  • Might want to reach out to Mike Galvin.  He may have run into that issue during his testing.


    Saturday, December 7, 2019 1:31 PM
  • Hi,

    Better reach out to the author of the script, you can contact him over here: https://gal.vin/about/

    Best regards,

    Blog: https://thesystemcenterblog.com LinkedIn:

    Saturday, December 7, 2019 1:33 PM
  • Thanks but I doubt it's related to his script. He's calling:

    ## Do a regular export of the VMs
            $Vms | Export-VM -Path "$Backup"

    Export-VM is a powershell command.

    Tuesday, December 10, 2019 7:04 PM
  • It does call the built-in Export-VM, true. It also does not appear to call any API to verify the status of the VM first. It's entirely possible that it's failing for some environmental reason. It's also possible that my quick skim of the preceding hundreds of lines of script did not reveal some state change he makes that inadvertently causes this error. It could even be that the way he builds the "$Vms" variable results in duplicate attempts, which would cause this error. Nobody is saying his script is definitely doing something wrong. We are saying that sorting out why this particular script does not work would necessitate a code review. We're also saying that the author would have more familiarity with the way that his script tends to operate. Filing an issue on his GitHub page just might result in a response of, "Oh yeah, I've seen that before, and..." That's better than us guessing, wouldn't you say?

    If you want to schedule a clean Export-VM, then we might be able to help on that. But for that particular error, I would tell you to check the status of the VM before calling Export-VM.

    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.

    Tuesday, December 10, 2019 8:13 PM
  • Thanks for all the help but I found the problem.

    Looks like someone had set up a backup through Windows Server Backup to run every night at 6pm. It didn’t finish until after 1130pm and was locking the VMs which is why we were getting that error. I've since removed the offending and unnecessary backup and this script now runs fine!

    Thursday, December 12, 2019 12:52 PM
  • That's great, thanks for your sharing!

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Friday, December 13, 2019 7:31 AM