Running RVTools without asking for domain admin

Before you connect

RVTools is a Windows desktop application and needs a recent .NET Framework runtime; the installer states the version it requires and current Windows Server and Windows 11 builds already carry it. Run it from a management jump box rather than your laptop if your vCenter sits behind a jump host, because the machine running RVTools needs direct HTTPS (443) reachability to the vCenter appliance.

Three things to settle before you launch it:

• The account. A dedicated service account with the built-in Read-only role at the vCenter root, with propagation to child objects. Not your named admin account, and not a member of Administrators.
• The scope. Read-only assigned at the top of the inventory tree. Assign it lower and the export silently omits everything outside that scope, which is the single most common cause of an export that looks complete but is missing half the estate.
• The timing. Outside backup windows and change windows on anything large. See the load note below.

Why read-only, specifically

RVTools has no write path. Every call it makes against the vSphere web services API is a query, so an account with more privilege than Read-only buys you nothing operationally, and it costs you in three places: the change request is harder to get approved, the credential is worth more if the machine running it is compromised, and the audit trail is less useful because a privileged account touching vCenter looks the same whether it read the inventory or reconfigured a cluster.

A read-only account is also what makes RVTools defensible to run during an active vendor negotiation. If you are exporting inventory to build a case for leaving VMware, "we ran a read-only query against the API with a read-only account" is a materially easier sentence than the alternative.

The run itself

• Connect. Enter the vCenter FQDN (not the IP, if certificate validation matters to you), the service account, and its password. Use the FQDN that matches the certificate subject or you will spend the next ten minutes on the TLS error covered in when the export fails.
• Wait for the tabs to populate. RVTools collects everything up front and then renders the worksheets. On a few hundred VMs this is quick. On several thousand it is minutes, and the window will look unresponsive while it works.
• Export all tabs to xlsx. Export the whole workbook, not the single tab you think you need. The tabs cross-reference each other, and the tab you skipped is invariably the one that answers the question that comes up in the next meeting.
• Record what you ran. The RVTools version, the vCenter version, the account, and the timestamp. An inventory export without provenance is not evidence, and if this feeds a migration business case it will be treated as evidence.

Scheduling it, without leaving a password in a scheduled task

RVTools includes a command-line mode that connects, writes an export, and exits, which is what you want if you are tracking estate drift month over month rather than taking a single snapshot. Drive it from Task Scheduler on the management host under the same read-only service account.

The part people get wrong is the credential. RVTools supports supplying an encrypted password rather than a plaintext one on the command line; use that mechanism, and check that the scheduled-task action is not logging the full command line somewhere readable. A plaintext vCenter credential sitting in a scheduled task definition is a real finding in an audit, and it is an entirely avoidable one.

For migration work specifically, a monthly export is more useful than a one-off. Estates move, and the delta between two exports tells you whether the scope you costed in January is still the scope you are migrating in June. The renewal planner assumes a scope that holds; a drifting estate is exactly how a plan that fit stops fitting.

What it costs vCenter

The collection is a burst of read queries, not a trickle. On a large estate RVTools will hold vCenter's attention for several minutes and the appliance will show it in CPU and API-session metrics. Nothing is at risk of being modified, but a vCenter that is already struggling during a backup window does not need a full inventory walk on top of it.

Practical rule: on anything above roughly a thousand VMs, treat the run as a scheduled activity rather than something you fire off mid-incident. If vCenter is the thing you are currently troubleshooting, RVTools is not the tool to reach for first.