The Managed Object Browser (MOB) is powerful—and sensitive. Starting with vSphere 6.0, the ESXi MOB is disabled by default for security reasons. The exact advanced setting to control it is Config.HostAgent.plugins.solo.enableMob (per VMware guidance: The Managed Object Browser is disabled by default).

This article explains when and how to use the MOB safely, how to enable it temporarily with automatic rollback, how to audit its use, and how to translate findings into automation using PowerCLI and govc.

Overview

The Managed Object Browser is a lightweight web interface that exposes the vSphere Web Services API object model as a browsable tree. It exists on ESXi and vCenter Server endpoints at the /mob path and is invaluable for quick discovery of object references (moRef), property names, and relationships. When you open the MOB, you are looking directly at the same object types, properties, and methods documented in the vSphere Web Services API Reference.

In day-to-day operations, administrators use the MOB to confirm a VM’s moRef (e.g., vm-123), inspect datastore capacity and free space, or trace where a specific setting lives in the API before writing a script. Because the MOB also surfaces methods that can change configuration, it must be approached with a security-first mindset in production. The rest of this guide shows how to keep that balance—leverage the MOB for discovery while enforcing least privilege, auditing, and time-bound access.

What the Managed Object Browser is and when to use it

The MOB is a read/write view of the vSphere API delivered from the ESXi hostd service or the vCenter vpxd service at https://<host-or-vcenter>/mob. It mirrors the API object model—ServiceInstance, ServiceContent, Datacenter, Datastore, VirtualMachine, HostSystem, and so on—exposing properties and methods for each object.

It’s best used for quick, read-only exploration: verifying a property’s exact name and path, locating an object’s moRef, or confirming how relationships are represented in the API.

Choose the MOB when you need fast, visual confirmation of object paths and property names. Prefer alternatives for routine or production tasks: the vSphere API Explorer for schema discovery with built-in authentication, PowerCLI’s Get-View for repeatable read-only queries, and the govc CLI for scriptable inspections. This split lets you benefit from the MOB’s clarity without leaving it enabled or relying on it for ongoing automation.

Availability and defaults by version (ESXi 6.x–8.x and vCenter)

VMware hardened the ESXi Managed Object Browser starting in vSphere 6.0 by disabling it out of the box, and that default continues through ESXi 6.x, 7.x, and 8.x (see The Managed Object Browser is disabled by default).

The vSphere Security Configuration Guide reinforces the principle of minimizing exposed management interfaces and enabling only what’s necessary for the task at hand (vSphere Security Configuration Guide). As a result, production workflows should treat any exposure of /mob as exceptional, tightly controlled, and time-bound.

vCenter Server continues to host a /mob endpoint for object inspection, but many enterprises restrict or proxy access to it according to internal policy. Whether you’re using the vCenter Managed Object Browser or the ESXi Managed Object Browser, think of /mob as a diagnostic interface—not a normal administration surface—and wrap it with the same change control you’d use for SSH access or firewall changes.

ESXi defaults and the enablement key

On ESXi, the single source of truth for enablement is the advanced setting Config.HostAgent.plugins.solo.enableMob. Setting it to true enables the ESXi Managed Object Browser at https://<esxi-host>/mob; setting it to false disables it again. You can toggle it via the ESXi Shell or programmatically, and the change takes effect immediately in most environments.

A practical sequence is: authenticate to the host, set the key to true, perform read-only discovery, and set the key back to false.

For ESXi Shell, use vim-cmd hostsvc/advopt/update Config.HostAgent.plugins.solo.enableMob bool true to enable and the same with false to disable; verify with vim-cmd hostsvc/advopt/view Config.HostAgent.plugins.solo.enableMob.

If the session is long-lived or the hostd service is under load, re-verify that /mob is disabled at the end. If necessary, restart hostd during a maintenance window.

vCenter Server availability and stance

vCenter exposes the MOB at https://<vcenter-fqdn>/mob and authenticates via vCenter Single Sign-On (SSO). Access is often mediated by the vCenter reverse proxy and corporate security controls, and some organizations block the path entirely.

Treat vCenter /mob access as a diagnostic privilege: review internal policy, ensure you’re using SSO with a least-privilege account, and prefer the vSphere Client, the vSphere API Explorer, or automation tools for recurring needs.

Accessing the MOB on vCenter vs ESXi and in VMware Cloud

The vCenter Managed Object Browser and the ESXi Managed Object Browser share the same URL path (/mob) over HTTPS on port 443, but authentication and scope differ. vCenter /mob relies on SSO and shows inventory across the vCenter, while ESXi /mob uses local or directory-backed host authentication and shows objects local to that host. If the host is joined to Active Directory, ESXi authentication differs from vCenter SSO; use the correct domain qualifier when logging in.

Cloud-hosted deployments, such as VMware Cloud environments, may restrict direct access to host or vCenter /mob endpoints to meet security and compliance requirements. Before planning a workflow around /mob in these environments, verify provider and corporate policies and be prepared to use sanctioned alternatives like the API Explorer, PowerCLI, or govc with appropriate API tokens. This avoids surprises mid-incident and keeps you aligned with managed service guardrails.

Security risks and hardening guidance for MOB

The main risks of enabling the MOB are inventory disclosure and unintended write operations via exposed methods. Even if you intend to browse read-only properties, a user with broader privileges could trigger actions like VM reconfiguration or deletion from the same interface. The security posture recommended by the vSphere Security Configuration Guide is clear: minimize exposed management surfaces and apply least privilege and segmentation wherever possible.

Mitigate risk with a layered approach. Limit network reachability to /mob through firewall rules, enable the ESXi Managed Object Browser only when required and for a short window, and use an account with a read-only role scoped to the minimum inventory.

Monitor access in real time by tailing the relevant logs (hostd or vpxd) and confirming rollback once your task is finished. If you routinely need property visibility, standardize on Get-View or govc so you avoid enabling /mob at all.

Roles, permissions, and least-privilege access

You do not need full Administrator rights just to view properties in the MOB. A read-only role scoped to the specific objects you need to inspect is sufficient for most discovery tasks. The goal is to restrict write methods from being executable in your session, even if the UI surfaces them.

This separation also helps auditability—administrators retain the ability to change, while auditors or engineers performing discovery keep a smaller blast radius. Model your approach on the vSphere permissions architecture described in VMware’s security documentation and use inheritance sparingly to avoid overscoping. Where you need to inspect host-level objects via ESXi /mob, consider creating a temporary directory service group mapped to a read-only role and remove it once your task is complete.

For cross-team work, couple that role with time-bound local firewall rules or a jump host to create a narrow, auditable window.

Recommended least-privilege pattern

Create a narrow, read-only browsing role and bind it only where required.

Auditing and logging MOB usage

You can and should audit access to the Managed Object Browser using standard vSphere logs. On ESXi, the hostd service records web requests and session activity in /var/log/hostd.log; on vCenter, vpxd logs requests and SSO session context in the vCenter Server logs (ESXi log locations, vCenter Server log locations).

On ESXi, search for URL fragments and usernames—for example, run grep -i "/mob" /var/log/hostd.log and grep -i "user" /var/log/hostd.log to correlate sessions and actions. Typical entries include HTTP verbs against /mob and the moid being accessed (e.g., GET /mob/?moid=ha-host with a session or user reference).

On vCenter, examine vpxd.log for session creation and access, and use journalctl -u vmdird or SSO logs if authentication anomalies appear. Close the loop by capturing a final log sample after rollback and attaching it to the change record.

From MOB to API and automation building blocks

The MOB is a visual on-ramp to a few foundational API objects you’ll use in every script: ServiceInstance (the API root), ServiceContent (a struct of entry points), PropertyCollector (bulk property retrieval), SearchIndex (find objects by name, path, UUID, or IP), and ViewManager (views and containers for efficient queries). When you click through ServiceInstance → content in the MOB, you’re literally following the same pointers you’ll call from code. The vSphere Web Services API Reference maps 1:1 to what you see.

Here’s the mental model: use SearchIndex to find a specific object when you know a name or UUID; use PropertyCollector or a View from ViewManager to collect properties in bulk across a container (e.g., all VMs in a folder). Practice mapping what you inspect in the MOB to code so you can switch smoothly from one-time discovery to repeatable automation. This is where PowerCLI Get-View and govc shine.

Reproducing read-only lookups in PowerCLI and govc

Map common MOB paths to automation tools for safe, scriptable reads.

Use these equivalents as your default for recurring checks. Keep the MOB for spot discovery of a property you’re unsure about, then codify it with Get-View or govc so you never need to enable /mob again for that task.

Read-only vs write operations in MOB

The MOB shows both properties and methods for each object. Properties are safe to view; methods execute changes and should not be invoked in production outside a formal change window. You will see methods such as ReconfigVM_Task, Destroy_Task, CloneVM_Task, EnterMaintenanceMode, and more—these map directly to powerful operations you would normally run from the vSphere Client or automation.

Treat the presence of methods as a reminder that your privileges matter. If your role includes configuration rights on a given object, clicking a method link can initiate a change. Keep your browsing accounts limited to read-only wherever possible and consider using a separate, more privileged account only when you actually need to perform an approved change through supported tools.

Temporary enablement with automatic rollback

A safe pattern for ESXi is to enable the Managed Object Browser for a fixed window and schedule an automatic disable so it rolls back even if you’re interrupted. Start by setting a 30‑minute timer to flip the key back to false, then enable it and do your work. This creates a built-in safety net.

Two practical workflows:

After the window closes, verify that /mob returns unauthorized on the ESXi URL and that the advanced setting reads false. Capture a quick log snippet from hostd.log showing the enable/disable timestamps for your audit trail.

Finding moRef IDs and performing quick lookups

You can map inventory items in the vSphere Client to moRef IDs quickly in the MOB. From https://<vcenter>/mob, click ServiceInstance, then content, then SearchIndex to use find methods (for example, use FindByDnsName with your VM’s FQDN). The returned object link includes the moRef (e.g., vm-123).

You can then click to inspect properties like config.uuid, runtime.powerState, or datastore references.

Mirror the same lookups with automation to keep your workflow repeatable. In PowerCLI, run Get-View -ViewType VirtualMachine -Filter @{'Name'='^MyVM$'} and read $vm.MoRef and $vm.Config.Uuid. With govc, run govc find -type m -name MyVM to return the moRef and then govc object.collect -s vm-123 config.uuid runtime.powerState. For datastores, browse to the Datastore object in the MOB and read summary.capacity and summary.freeSpace, or use PowerCLI Get-Datastore -Name DS1 and govc datastore.info to get the same values.

MOB vs alternatives for API discovery and debugging

Use the right tool for the job to reduce risk and speed up discovery. The vSphere MOB is the fastest visual way to understand relationships and property names, but you shouldn’t depend on it for repetitive work. Favor official, scriptable tools that align with enterprise security controls.

Troubleshooting authentication and connectivity

If you see repeated 401 prompts, redirect loops, or blank pages when accessing /mob, focus on SSO, cookies, DNS, and certificate trust first. vCenter /mob uses SSO cookies; stale sessions or clock skew can cause loops or auth failures. ESXi /mob uses local authentication and can fail if you’re using an unexpected domain or if the account is locked.

Start with these checks: ensure you’re using the FQDN that matches the vCenter certificate, clear browser cookies for the vCenter domain (or use a private window), and confirm NTP time sync on both the client and vCenter/ESXi. Verify DNS forward and reverse resolution for the vCenter and host names, and import the vCenter certificate chain into your OS/browser trust store if you use a custom CA.

For proxy or load balancer deployments, confirm that /mob is allowed through the reverse proxy and that it isn’t being rewritten to HTTP.

SSO, cookies, and certificate trust

SSO relies on cookies scoped to the vCenter FQDN; mismatched hostnames, short-lived cookies, or blocked third-party cookies can break the flow. A quick fix is to access the exact FQDN shown on the certificate, clear cookies for that domain, and try again in a private window. If trust warnings appear, import the vCenter CA root certificate and intermediate certificates to your system store to avoid the browser downgrading or blocking secure sessions.

If issues persist, test with a direct API call using a tool like curl -v -k -u 'user@domain' https://<vcenter>/mob/?moid=ServiceInstance to observe redirects and headers. Review vCenter SSO and reverse proxy logs via the vCenter log bundle and correlate timestamps with your attempts.

Compliance and change-control for production environments

Treat /mob access like any sensitive change: plan it, limit it, record it, and roll it back. A simple, auditable procedure keeps you aligned with separation of duties and reduces risk to production.

By pairing the Managed Object Browser with least privilege, tight time windows, and strong auditing, you can safely gain the visibility you need without expanding your attack surface. You’ll end each session with repeatable commands in PowerCLI or govc so you rarely need to re-open /mob.