A few weeks ago, the town I live in had extremely severe thunderstorms roll through. When the tornado sirens went off and all our mobile devices started screaming “Warning: tornado sighted in your immediate area. Take shelter immediately!”, I did not bother doing a proper shutdown of all my lab equipment. The tornado did extensive damage in our town but missed our house by about a mile or two as the crow flies. We were without power most of the night. The power outage lasted longer than the batteries in all my battery backup systems. Needless to say, all my XenServer, vSphere, and vCenter hosts did an ungraceful power off. My two Synology NAS units have USB connections to their UPS and are configured for proper shutdowns in the event of power loss. For the past few weeks, I thought all was well in my lab, but that wasn’t the case I found out.

After the storms passed, I was able to power on all the UPS units and all the XenServer, vSphere and vCenter hosts came to life with no reported errors. It wasn’t until I went to update my XenApp and XenDesktop 7.12 Machine Catalogs that I discovered major issues. None of the catalogs would update. They would go through the process and eventually abort with “no compatible storage sets for secondary disk provisioning” as shown in Figure 1.

I spent quite a bit of time trying to recover from this but was unsuccessful. Since I have just about everything in my lab scripted, I decided to just remove all my “stuff” in Studio and just start over.

What I was unable to remove was the Hosting Connection or the Resource Connection. I kept getting an error message saying “There is currently an active background action”. But I had no Applications or Delivery Groups or Machine Catalogs and no Desktops or Machines, how could there be anything considered a background action? After digging around with Get-Command and Get-Help, I eventually (OK it took me two hours) figured out what I needed to do to get rid of the Hosting Connection. I decided to write this article so I could have these steps for reference if I ever run into this fiasco again.

If this were a common occurrence, I would write a script to do all this but this is the first time I have run into this specific issue.

Update 7-Nov-2017: I have written a script to automate this process.

Step 1: Get a list of tasks that are currently running within the MachineCreation Service

Steps 2 and 3: Stop and then Remove the task returned

Apparently, Get-ProvTask -active $true only returns one task at a time. Repeat Steps 1 through 3 until all tasks are found, stopped, and removed.

Step 4: Get hosting units.

Steps 5 and 6: Get, Stop and Remove the provisioning tasks associated with the HostingUnitUid.

Steps 7, 8, and 9: Remove the resource connection, the hypervisor connection, and finally the hosting connection.

Now refresh the Hosting node in Studio and the Hosting Connection is gone as shown in Figure 2.

In the south, we don’t mess around when a tornado is spotted very close to where we live. My office and lab are located in the attic of our house. An attic is the LAST place you need to be in a tornado warning. I would rather deal with storage issues than mess around with a tornado. I hope neither even happens again in my lifetime but if either happens, I now know the steps to start over (at least with my lab).

Thanks

Webster