Remove protected VMwareViewComposerReplicaFolder without sviconfig

Did you find yourself with a VMwareViewComposerReplicaFolder object in your Inventory after playing around with Omnissa or VMware Horizon, and no way to delete it because you'd already uninstalled all the Horizon bits?

That's where I found myself this week, and I kept finding posts about using "sviconfig" —one of the management tools for Horizon— but nothing about how to do it without it.

Luckily, I found a couple of different posts (linked below in the References section) that allowed me to accomplish the task.

It's a 3-step process:

1. Find the "Managed Object ID" for the folder
2. Use the vCenter MOB to enable deletion
3. Use vCenter to remove the folder from inventory

Step 1: Find the MOB ID

1. Open a supported browser to the MOB: https://<vcenter fqdn>/mob/
2. After logging in, click content in the Properties section
3. Find and click on the group-d1 (Datacenter) link. It's in the VALUE column for the row with "rootFolder" in the NAME column.
4. In the "childEntity" row, there will be a listing of the datacenter(s) in inventory, and links to those objects. Click on the one for the datacenter that holds the folder.
5. At the Datacenter object, there will be several folder types to choose from. The folder we're trying to get rid of is a VM folder, so select the link to the VM folders.
6. Again, in the "childEntity" row, there will be a handful of folders (with links) enumerated. If you don't see the VMwareViewComposerReplicaFolder entry, click more... until you do. If your folder is nested under other folders, keep clicking through child folders until you get to the parent folder that holds it. You're mirroring the tree that's displayed in vCenter "VMs and Templates"
   
7. The text in the link (e.g., group-v13561) is the MOB ID for the folder. Make a note.

Step 2: Enable deletion

1. Open a supported browser to the MOB: https://<vcenter fqdn>/mob/
   If you wish, you can duplicate the tab used above, or just remove the parameters in the current window.
2. Open the AuthorizationManager section of the MOB with a specific URL:
   https://<vcenter fqdn>/mob/?moid=AuthorizationManager&methods=enableMethods
   note: you cannot navigate to this URL through the UI. You can get to the AuthorizationManager, but enableMethods is not a publicly-available method!
3. In the "entity" field, replace "MOID" in the XML string with the MOB ID you found in Step 1
4. <entity type="MethodName" xsi:type="string">vim.ManagedEntity.destroy</entity>
5. <entity type="MethodName" xsi:type="string">vim.Folder.unregisterAndDestroy</entity>
6. In the "method" field, paste the following:
   
7. Click "Invoke Method"

Step 3: Delete the folder

At this point, the folder should be removable from inventory; it was for me.

References:

Find the MOID of a vSphere Cluster

Remove protection from former VMware Horizon instant clone templates

SSL Reverse Proxy using Citrix NetScaler VPX Express

Part 6 in a series

In previous posts I covered the configuration of the NetScaler VPX Express for use as an intelligent reverse proxy, allowing the use of a single public IP address with multiple interior hosts.

In recent days, I've been working on adding Horizon View to my home lab; in addition to requisite Connection Servers, I'm using the EUC Access Point virtual appliance as a security gateway instead of Security Servers paired with dedicated Connection Servers.

The procedure I outline for the creation of a content-switching configuration works as you'd expect...to a point.

I found that I kept getting "Tunnel reconnection is not permitted" errors when trying to login using the dedicated Horizon Client; this was extremely frustrating because HTML access (using nothing but an HTML5-compatible browser) was working flawlessly.

Upon reviewing the client logs, I noticed that the response from the tunnel connection (HTTP/1.1 404 Not Found) was from IIS, not a Linux or other non-Windows webserver. In my configuration, my content-switching plan uses a Windows IIS server as the fall-through (default/no-match).

Theory: for whatever reason, while the registration process for the Horizon Client was being properly switched to the Access Point, login via tunnel was not.

By capturing a trace (including SSL decoding) at the NetScaler and reviewing it in Wireshark, I was able to see that the client is using two different host strings, one during the initial login followed by a second one during tunnel creation.

What's the difference? The initial login doesn't include the port number in the host string; the tunnel request includes it...

Login: vdi.corp.com
Tunnel: vdi.corp.com:433

The fix is to add an additional match criteria for your content switching policy:

Before: HTTP.REQ.HOSTNAME.EQ("vdi.corp.com")
After: HTTP.REQ.HOSTNAME.EQ("vdi.corp.com")||HTTP.REQ.HOSTNAME.EQ("vdi.corp.com:443")

You can also create an additional policy with the "fqdn:443" match, but editing the policy was faster to implement.

UPDATE: I've done some more digging, and there are additional arguments/functions that would also work—and would've worked transparently had I used them in the first place—instead of the EQ("") expression:

HTTP.REQ.HOSTNAME.CONTAINS("vdi.corp.com")
HTTP.REQ.HOSTNAME.SERVER=="vdi.corp.com"
HTTP.REQ.HOSTNAME.STARTSWITH("vdi.corp.com")
HTTP.REQ.HOSTNAME.PREFIX('.',0).EQ("vdi")