VMware Managed Object Browser (MOB): Updated 2026 Administrator Guide

VMware Managed Object Browser (MOB): Updated 2026 Administrator Guide

The VMware Managed Object Browser (MOB) remains one of the most powerful, direct, and authoritative diagnostic interfaces available in enterprise VMware vSphere environments. Built directly into every VMware ESXi hypervisor host and VMware vCenter Server Appliance (VCSA), the Managed Object Browser provides a low-level, real-time graphical reflection of the vSphere Web Services API (VIM API) object hierarchy. In the modern cloud-native virtualization landscape of 2026—spanning vSphere 8.0 Update 3 and next-generation hybrid infrastructures—understanding how to safely leverage, navigate, and secure the Managed Object Browser is an indispensable skill for virtualization architects, Site Reliability Engineers (SREs), and systems administrators.

While modern vSphere administration heavily emphasizes declarative infrastructure-as-code tools like Terraform, Ansible, and the vSphere Automation REST APIs, the underlying engine governing state, distributed locking, MoRef (Managed Object Reference) identifiers, and service managers remains the VIM API. When the standard vSphere HTML5 Client fails to render an inventory object, when an orphaned virtual machine resists removal due to a stale database lock, or when an obsolete third-party backup extension corrupts the vCenter plugin repository, the MOB is the ultimate tool of last resort.

In this updated 2026 guide, we explore the complete architecture of the Managed Object Browser, step-by-step methods for enabling and accessing it across ESXi and vCenter, deep MoRef object traversal techniques, essential troubleshooting workflows, and vital security hardening protocols compliant with CIS Benchmarks and DISA STIG guidelines.

What is the VMware Managed Object Browser?

The Managed Object Browser is a server-side web application running internally within the VMware hostd daemon on standalone ESXi hosts and the vpxd service on vCenter Server. It exposes the live, in-memory object hierarchy of the hypervisor or management cluster through an interactive HTML DOM interface accessible over HTTPS at https://<vcenter-or-esxi-hostname>/mob.

Every entity within a vSphere environment—including virtual machines, datastores, virtual switches, compute resources, clusters, licenses, and background asynchronous tasks—is represented as a Managed Object. Each Managed Object contains:

1. Properties: Data values representing state, hardware configuration, performance counters, runtime statuses, and metadata.
2. Methods: Callable API operations (such as PowerOnVM_Task, Destroy_Task, ReconfigVM_Task, or UnregisterExtension) that execute directly against the hypervisor kernel or database.
3. ManagedObjectReferences (MoRefs): Globally unique string identifiers within a single management context (e.g., vm-1042, host-12, datastore-88, domain-c20) that act as programmatic pointers across the vSphere inventory.

When you interact with the MOB, you are not merely viewing a cached dashboard; you are executing authenticated, raw SOAP/VIM API calls directly against the live hypervisor runtime. Inspecting network payloads and API headers with our HTTP Header Analyzer or parsing web endpoint configurations with the URL Parser allows infrastructure engineers to verify session security, cookie headers, and TLS parameters when connecting to critical virtualization management interfaces.

Architectural Comparison: MOB vs vSphere Client vs REST APIs

To understand where the Managed Object Browser fits into modern data center operations, consider how the various VMware management surfaces interact with the underlying hypervisor engine:

| Management Interface | Underlying Protocol | Primary Use Case | Granularity & Object Scope | Default Status in 2026 |

| :--- | :--- | :--- | :--- | :--- |

| Managed Object Browser (MOB) | VIM SOAP API (/mob) | Low-level debugging, extension cleanup, emergency MoRef manipulation | 100% of internal VIM object tree and hidden properties | Disabled by default (Strict Hardening) |

| vSphere Client (HTML5) | REST API & VIM Gateway | Daily administrative tasks, VM lifecycle, cluster maintenance | Abstracted UI views; hides internal locks and stale MoRefs | Enabled (Standard UI) |

| PowerCLI / pyVmomi | VIM API & REST Endpoints | Enterprise automation, CI/CD provisioning, bulk reporting | Complete programmatic access to all managed objects | Programmatic Access (Scripted) |

| vSphere Automation REST API | REST / JSON (/api) | Cloud automation, Terraform providers, modern integrations | Resource-oriented abstractions (VMs, tags, appliances) | Enabled by default |

When developing automation pipelines that interact with these APIs, formatting and sanitizing complex JSON payloads using our JSON Formatter or generating API request syntax with the cURL Command Generator ensures structured, error-free API communication.

Enabling and Accessing the MOB in 2026

Because the Managed Object Browser grants unrestricted read and write execution capabilities to authenticated administrative accounts, modern security baselines (including VMware vSphere Security Configuration Guides and CIS vSphere Benchmarks) require MOB to be disabled by default.

Attempting to access https://<vcenter-fqdn>/mob without prior enablement will result in an HTTP 503 Service Unavailable or a 404 Not Found error. Below are the standard, production-tested procedures for temporarily enabling MOB on both ESXi hypervisors and vCenter Server.

Method 1: Enabling MOB on Standalone VMware ESXi Hosts

You can enable MOB on an ESXi host via the ESXi Command Line (SSH or Local Shell) using the esxcli utility or through the ESXi Host Client.

#### Option A: ESXi Shell CLI (Recommended for Automation)

# Log in to ESXi via SSH as root
ssh root@esxi-host-01.corp.local

# Check the current status of the MOB service plugin
esxcli system settings advanced list -o /Config/HostAgent/plugins/solo/enableMob

# Enable the MOB plugin immediately
esxcli system settings advanced set -o /Config/HostAgent/plugins/solo/enableMob -d true

# Verify that the parameter value is now set to true
esxcli system settings advanced list -o /Config/HostAgent/plugins/solo/enableMob | grep "   Value:"

#### Option B: ESXi Host Client UI

1. Open your web browser and navigate to https://<esxi-ip>/ui.
2. Authenticate as root or an account with the Administrator role.
3. In the left navigation pane, select Manage -> System -> Advanced settings.
4. In the filter search bar, type Config.HostAgent.plugins.solo.enableMob.
5. Right-click the parameter, select Edit option, change the boolean value to true, and click Save.

Method 2: Enabling MOB on VMware vCenter Server Appliance (VCSA 8.x)

Enabling MOB on vCenter Server requires modifying the vpxd.mob.enable advanced configuration parameter within the vCenter Server inventory.

#### Option A: Using PowerCLI (Non-disruptive)

# Connect to your vCenter Server instance
Connect-VIServer -Server vcenter.corp.local -User administrator@vsphere.local

# Retrieve current vCenter advanced configuration for MOB
Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vpxd.mob.enable

# Enable MOB on vCenter Server
Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vpxd.mob.enable | Set-AdvancedSetting -Value $true -Confirm:$false

#### Option B: Using vSphere Client Advanced Settings

1. Log into the vSphere Client (https://<vcenter-fqdn>) as administrator@vsphere.local.
2. Select the top-level vCenter Server object in the inventory tree.
3. Navigate to the Configure tab and select Advanced Settings.
4. Click Edit Settings, locate or add the key vpxd.mob.enable, and set its value to true.
5. Click Save. Changes take effect immediately without requiring a restart of the vpxd service.

Navigating the MOB Object Hierarchy: Step-by-Step

Once enabled, open a secure browser session and navigate to:

https://<vcenter-or-esxi-fqdn>/mob

You will be prompted to authenticate. Enter your administrative credentials (e.g., administrator@vsphere.local or ESXi root).

ServiceInstance (ServiceInstance)
 ├── capability (ServiceInstanceCapability)
 └── content (ServiceContent)
      ├── rootFolder (group-d1 / Datacenters)
      │    └── childEntity (datacenter-2)
      │         ├── hostFolder (group-h4) -> ComputeResource / HostSystem (host-12)
      │         ├── vmFolder (group-v3) -> VirtualMachine (vm-401)
      │         ├── datastoreFolder (group-s5) -> Datastore (datastore-11)
      │         └── networkFolder (group-n6) -> DistributedVirtualSwitch (dvs-22)
      ├── sessionManager (SessionManager)
      ├── customFieldsManager (CustomFieldsManager)
      ├── extensionManager (ExtensionManager)
      ├── taskManager (TaskManager)
      └── viewManager (ViewManager)

1. ServiceInstance: The Root Entry Point

Upon authentication, the browser displays the ServiceInstance object (MoRef: ServiceInstance). Click on the link for content (ServiceContent).

2. ServiceContent: The Core Management Catalog

The ServiceContent page displays pointers to every fundamental subsystem manager in vSphere:

• rootFolder: The entry point to all Datacenters, Clusters, Hosts, and Virtual Machines (group-d1).
• extensionManager: Catalog of all registered vCenter plugins and third-party extensions.
• customFieldsManager: Defines custom attribute schema across VMs and hosts.
• sessionManager: Active client sessions and authentication tokens. Inspecting active session tokens or decoding JWT payloads can be done safely with our JWT Decoder.
• taskManager and eventManager: Active and historical system operations.

3. Traversal to a Specific Virtual Machine

To locate a specific virtual machine (e.g., vm-1042):

1. Click rootFolder (group-d1).
2. Click childEntity and select your target Datacenter (e.g., datacenter-2).
3. Click vmFolder (group-v3).
4. Click childEntity to browse folder levels or locate the target VirtualMachine reference.
5. Once inside the VM view, you can inspect config, runtime, summary, guest, and datastore arrays.

Practical Troubleshooting Workflows with MOB

Workflow 1: Removing an Orphaned / Inaccessible Virtual Machine

When a virtual machine is removed from storage directly or deleted outside of vCenter, vCenter may display the VM as (orphaned) or (inaccessible) with the standard "Delete from Disk" and "Remove from Inventory" buttons grayed out.

+---------------------------------------------------------+
|                  VirtualMachine (vm-502)                |
+---------------------------------------------------------+
| Properties:                                             |
|  - name: "Production-DB-Legacy"                         |
|  - runtime.connectionState: "orphaned"                  |
|  - config.uuid: "421a9c84-18e3-53d9-..."               |
+---------------------------------------------------------+
| Methods:                                                |
|  -> Destroy_Task()      <-- Permanently purges MoRef    |
|  -> UnregisterVM()      <-- Removes from inventory      |
|  -> Reload()            <-- Re-reads VMX configuration  |
+---------------------------------------------------------+

1. Navigate to https://<vcenter-fqdn>/mob/?moid=vm-502 (replace vm-502 with the actual MoRef ID).
2. Verify the name property under summary.config.name to confirm you have targeted the correct VM.
3. Scroll down to the Methods table at the bottom of the page.
4. Click on UnregisterVM (or Destroy_Task if the VM registration has completely corrupted the database).
5. A popup dialog titled UnregisterVM will appear. Click Invoke Method.
6. The method executes immediately, returns a void or task confirmation, and permanently removes the ghost record from the vCenter inventory database.

Workflow 2: Unregistering Obsolete or Corrupted vCenter Extensions

Old backup tools, monitoring agents, or storage plugins (such as deprecated vSphere Web Client Flash plugins or decommissioned SRM extensions) frequently leave stale entries in ExtensionManager. These can cause vSphere Client upgrade failures, SSL certificate warnings, or slow UI rendering.

# Example: Inspecting and removing a stale extension via PowerCLI
$vcenter = Connect-VIServer vcenter.corp.local -User administrator@vsphere.local
$extMgr = Get-View -Id ExtensionManager

# List all registered third-party extension keys
$extMgr.ExtensionList | Select-Object Key, Version | Format-Table -AutoSize

# Unregister an obsolete extension directly through VIM API method
$extMgr.UnregisterExtension("com.vendor.oldbackup.plugin")

To perform this inside the MOB interface:

1. Navigate to https://<vcenter-fqdn>/mob/?moid=ExtensionManager.
2. Inspect the extensionList array to find the exact extension key (e.g., com.example.monitoring).
3. Under the Methods section, click on UnregisterExtension.
4. In the extensionKey text box, enter the exact string name: com.example.monitoring.
5. Click Invoke Method. Refresh the vSphere Client to confirm the stale plugin has been purged.

Programmatic MoRef Querying with Python (pyVmomi)

While the MOB web interface is exceptional for visual inspection, programmatic access via Python using pyVmomi allows automated verification of object properties. Notice how the programmatic script mirrors the MOB hierarchy:

#!/usr/bin/env python3
# vSphere MoRef Inspector - Interacts directly with VIM API ServiceContent
import ssl
from pyVim.connect import SmartConnectNoSSL, Disconnect
from pyVmomi import vim

def inspect_mob_hierarchy(host, user, password):
    context = ssl._create_unverified_context()
    si = SmartConnectNoSSL(host=host, user=user, pwd=password, sslContext=context)
    
    try:
        content = si.RetrieveContent()
        print(f"[+] Connected to: {content.about.fullName}")
        print(f"[+] Root Folder MoRef: {content.rootFolder._moId}")
        
        container = content.viewManager.CreateContainerView(
            content.rootFolder, [vim.VirtualMachine], True
        )
        
        print("
--- Discovered Virtual Machine MoRefs ---")
        for vm in container.view:
            print(f"Name: {vm.name:<30} | MoRef: {vm._moId:<10} | PowerState: {vm.runtime.powerState}")
            
    finally:
        Disconnect(si)

if __name__ == "__main__":
    inspect_mob_hierarchy("vcenter.corp.local", "administrator@vsphere.local", "SecurePassword2026!")

Comparing raw JSON responses or hashing configuration dumps with our Hash Generator or Diff Checker helps verify configuration state before and after performing invasive MOB modifications.

2026 Security Hardening & Zero-Trust Guidelines for MOB

Because of its extensive administrative power, an unauthenticated or persistently enabled MOB presents a severe security risk. Attackers with compromised credentials can bypass UI auditing, invoke destructive tasks, export sensitive VM descriptors, or unregister security agents.

Mandatory Post-Maintenance MOB Disabling Checklist

1. Disable MOB immediately upon completing troubleshooting:

• Standalone ESXi: esxcli system settings advanced set -o /Config/HostAgent/plugins/solo/enableMob -d false
• vCenter Server via PowerCLI: Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vpxd.mob.enable | Set-AdvancedSetting -Value $false -Confirm:$false

1. Audit Administrative Sessions: Inspect /var/log/vpxd.log on vCenter and /var/log/hostd.log on ESXi to ensure no unauthorized MOB methods were invoked during the window of enablement.
2. Automate Scheduled Re-check: Implement scheduled audit tasks using cron expressions generated with our Cron Expression Generator to periodically verify that all production hosts have enableMob = false.

Frequently Asked Questions (FAQs)

1. Why is the Managed Object Browser disabled by default in vSphere 8.x?

The MOB is disabled by default to adhere to enterprise security baselines such as the CIS VMware vSphere Benchmark and DISA STIGs. An exposed MOB provides an attack surface where compromised credentials can be used to invoke raw hypervisor API methods without standard UI guardrails or validation checks.

2. Can invoking methods in the MOB cause data loss or service disruption?

Yes. The MOB executes API methods directly against the hypervisor or vCenter database. Methods like Destroy_Task, ResetVM_Task, or FormatDatastore do not prompt with secondary confirmation warnings. Always verify the target MoRef ID before executing any method.

3. What is the difference between accessing the MOB on ESXi vs vCenter Server?

Connecting to an ESXi host's MOB (https://<esxi-ip>/mob) inspects only the resources, VMs, and datastores managed directly by that standalone hypervisor daemon (hostd). Connecting to vCenter's MOB (https://<vcenter-ip>/mob) inspects the entire datacenter cluster inventory, distributed switches, storage DRS clusters, and cross-host management objects managed by vpxd.

4. How can I find the MoRef ID of a Virtual Machine using the MOB?

Navigate to ServiceContent -> rootFolder -> Datacenter -> vmFolder. Click through the child entity links until you find your virtual machine's name. The browser address bar and the top header of the page will display the MoRef ID (e.g., moid=vm-108).

5. Does changing an advanced setting in the MOB require a vCenter restart?

Most property modifications and method invocations executed in the MOB (such as UnregisterExtension or ReconfigVM_Task) take effect immediately in memory and persist in the database without requiring a restart of the vpxd or hostd services.