VRA remove waiting on retry status

From time to time you’ll see machines in vRA that have the status “On (Reconfigure failed, waiting to retry)”. In some cases this status will never go away, because in reality the retry is already done and everything went well but the status in vRA still says “Waiting for retry”.

The problem with a “Waiting on retry” status is that you cannot edit the machine properties, as vRA thinks that the machine is still waiting for other changes to be applied.

In vRealize Automation there is no option to reset the status of a machine. The only solution to reset the machines status to “On” again, is to edit the database of vRA. You would think that editing the database is the worst option to get a status back to normal, but it is actually recommended by VMware in some cases (see and

So we login to the vRA database server (in this case a MSSQL server) and select the vRA database. As you can see in the table view, there are many different tables containing everything that vRA is made of.

The table that contains the machines and its status is “dbo.Virtualmachine”. You can check the contents of this table by starting a new query like select * from [dbo].[virtualmachine]

To check what the current state of a machine is, you can query select CurrentTask from [dbo].[virtualmachine] where VirtualMachineName in ('VM_name').

Now as we want to reset this status to the default, we have to reset the CurrentTask field to nothing. To do this we execute the following SQL statement: update [dbo].[virtualmachine] set CurrentTask = NULL where VirtualMachineName in ('VM_name ').

When we run the previous query (select from) again, we can check the new status of the current task. And when we check in vRA we will see that the status is back to “On” and we can make modifications to the machine again.

RES One Automation PowerShell Module

Note: This blogpost is also posted on my personal blog –


When you’re a system administrator and a PowerShell enthusiast a single solution to a problem can result in something big and elaborate. A while ago I was implementing a MDT environment for a customer. I wanted to fill the MDT database with all existing client computers. For that I needed all the clients names and their MAC addresses. Client names weren’t the issue but MAC addresses were a little bit more challenging. I decided to turn to RES One Automation (RES AM) for help. I knew RES AM has the ability to identify agents by their MAC address so it has to store all agent MAC addresses in the datastore. After figuring out how to pry this information from the database I started to wonder what else I could find in there. This resulted in a complete PowerShell module (my first!) for RES One Automation!  Read more

Migrating PowerFuse 2008 to 2010

When upgrading your RES PowerFuse 2008 environment to a RES PowerFuse 2010 beware of the fact that the database structure has changes. Although the upgrade path should be pretty straight forward, there are some risks you should consider.
During the migration you should be aware of the fact that because of the changes in the database, and the way the management console reads/writes the objects, the changed made to the one version might not be available to the other version.
Read more

vCenter server services won’t start.

Sometimes it happened that you’re vCenter server service (vpxd.exe) stops working or won’t start and you are the one to find out why.  It is possible to dig in to the log files and try to find out what went wrong at a certain point in time. But the vpxd-*.log ( * =0 to 9) can be a 5 MB log file to go trough. The vpxd.exe is the executable that is running as a service (VMware VirtualCenter Server)  on the vCenter server. When I get a error starting this server I directly go to the location of the file and start it by hand. The default when location of the file  is :C:Program Files (x86)VMwareInfrastructureVirtualCenter Server . There are some options(Flags)  to start the vpxd.exe

Read more