Setting Up Veeam Backup Enterprise Manager

Veeam Backup Enterprise Manager is the federation layer for multi-server VBR deployments. If you have a single backup server protecting one site, you do not need it. If you have two or more backup servers - or if you need centralized RBAC, self-service restore for application teams, password loss protection, or centralized licensing visibility - Enterprise Manager is what ties everything together.

At its core, EM does five things. It federates multiple VBR servers under a single web UI so you can see job status, restore points, and infrastructure health across all of them from one place. It provides role-based access control with restore scope limiting - you can give a SQL DBA the ability to restore files from their own VMs without being able to touch anything else. It hosts the encryption key management infrastructure that backs password loss protection. It provides centralized license management and usage reporting, which matters if you are reporting to a customer or managing VUL consumption across a distributed environment. And in v13 it exposes a REST API that allows programmatic management of jobs, restore operations, and encryption passwords across all connected backup servers.

Run Enterprise Manager if any of these apply to your environment: you have more than one VBR backup server, you need to delegate restore rights to non-admin users, you have job-level encryption enabled and want password loss protection, you need SAML-based SSO for the backup management web UI, or you need centralized license reporting across sites.

Skip it if you have a single backup server with no delegation requirements and you are managing encryption passwords manually with no recovery need. EM adds infrastructure overhead - another server to maintain, patch, and back up. Only run it when the operational value outweighs that overhead.

The hardware requirements for Enterprise Manager are not heavy, but they are not trivial either. The numbers below are from the official v13 system requirements documentation.

In v13, Enterprise Manager can run on Windows Server (the traditional deployment path from previous versions) or on the Veeam Software Appliance - the same hardened Linux-based appliance used for VBR itself. This is a new option in v13 and it changes the deployment conversation.

The Windows deployment is the path most teams upgrading from v12 will take. You install the EM setup wizard from the same ISO as VBR, point it at an existing SQL Server or PostgreSQL instance, configure a service account, and it is up in 11 wizard steps. The guest file system catalog data lands on the Windows filesystem. Updates are managed through standard Windows patching and Veeam update mechanisms.

The Linux VSA deployment runs EM on the same hardened appliance base as the v13 VBR Linux installer. You deploy the VSA from ISO or OVA, select Enterprise Manager during setup, and it installs with a minimal attack surface - no unnecessary Windows services, no RDP by default, access via the Host Management Console. The tradeoff is that the VSA image is Veeam-maintained, not a general Linux install you can configure freely, and storage layout requires two separate disks configured during initial setup.

For greenfield v13 deployments where the rest of your VBR infrastructure is already on the Linux VSA, deploying EM on VSA as well is the cleaner choice. For teams upgrading from v12 with an existing Windows-based EM, staying on Windows is perfectly valid - there is no functional difference between the two deployment platforms once EM is running.

The Windows installation wizard runs 11 steps. Here is what to have ready before you start: a service account with local administrator rights on the EM server, a PostgreSQL or SQL Server instance accessible from the EM server, and the Veeam license file if you are installing the license at this point (you can also add it post-install).

The Linux VSA path deploys Enterprise Manager as part of the Veeam Software Appliance, the same hardened image used for the VBR Linux appliance. You can deploy from ISO or OVA. The 10-step wizard runs in a text-based console during initial system configuration, not through a GUI installer.

Once EM is installed, the first configuration task is connecting your VBR backup servers. In the EM web UI, go to Configuration > Backup Servers and click Add. Enter the backup server hostname or IP, credentials, and click Connect.

EM establishes a TLS connection to the backup server and begins pulling data. The initial data collection pull can take several minutes for large environments with many jobs and restore points. You can monitor collection progress from the backup server entry in the EM console.

Each backup server you add gets a server role configured. The available roles are Standard (full management access from EM), and options to scope what EM can see and manage on that server. For most deployments, leave the default role in place. Role scoping matters in multi-tenant or managed service scenarios where you want EM to federate servers but limit which jobs and data are visible to specific EM user accounts.

Enterprise Manager has four built-in roles. The Portal Administrator has full access to all EM functionality including configuration, job management, and user administration. The Portal User can view backup infrastructure and initiate restore operations within their assigned restore scope. The Restore Operator is a read-only role focused specifically on restore operations. The Portal Reporter has read-only access to dashboards and reports.

The restore scope is the part of this configuration that matters most for day-to-day operations. When you assign a user the Portal User role, you also define their restore scope - which VMs, which machines, or which folders they are permitted to restore from. A SQL DBA can have restore access scoped to their specific VMs only, with no visibility into other backup data. This is the feature that makes self-service restore viable in environments where you cannot give application teams full Veeam console access.

Configure accounts and roles under Configuration > Roles and Users. Add the Active Directory user or group, assign the role, and then define the restore scope. The restore scope can be specified by vCenter folder, resource pool, host, VM name, or by individual VM selection across all connected backup servers.

Enterprise Manager supports SAML 2.0 for single sign-on through an external identity provider. In v13 the documented IdP path is Active Directory Federation Services (AD FS), but any SAML 2.0-compliant IdP works with the same configuration pattern.

To configure SAML, go to Configuration > SAML Authentication. Download the EM service provider metadata XML from that page and import it into your IdP to register EM as a trusted service provider. Then take the IdP metadata XML and import it back into EM. Once both sides are configured and the SAML handshake is tested, users can authenticate to the EM web UI via their IdP credentials rather than local EM accounts.

SAML authentication in EM applies to the web UI only. The EM REST API uses token-based authentication separate from SAML. If you are integrating EM into an automation pipeline via the REST API, configure API credentials independently of any SAML setup.

If you covered the encryption article in this series, you already know the role Enterprise Manager plays in password loss protection. This section covers the EM-side configuration tasks specifically.

When EM is first installed, it generates an initial encryption keyset. This keyset consists of a public/private key pair. The public key is distributed to all connected backup servers and embedded in encrypted backup files, enabling password loss recovery. The private key stays on the EM server.

The key management workflow lives under Configuration > Key Management. From there you can generate new keysets, activate a keyset (making it the current public key pushed to backup servers), set retention for old keysets, and export keysets to a file for offsite storage.

Enterprise Manager's notification system covers job results, restore operations, licensing thresholds, key management events, and update availability. Configure the mail server under Configuration > Notifications > Mail Server Settings. EM supports SMTP with basic authentication, Microsoft 365 OAuth (requiring an Azure app registration), and Google Workspace OAuth (requiring a Google Cloud Console app registration).

Once the mail server is configured, enable the notification categories relevant to your environment. At minimum, enable notifications for job failures and license alerts. If you are using EM for encryption key management, enable key management notifications - these alert you when a keyset is nearing expiry or when a password recovery request is submitted by a connected backup server.

For reporting, the EM dashboard provides a real-time view of job status and infrastructure health across all connected backup servers. Reports can be exported to PDF or Microsoft Excel from the Reports tab. The audit report under Configuration > Backup Servers > Audit Reports logs all operations performed through EM including restore initiations, job modifications, and configuration changes - this is the audit trail most compliance frameworks will ask for.

If you are running Enterprise Manager v12 on Windows and upgrading to v13, the upgrade wizard handles the migration in 7 steps. The prerequisites are that your VBR backup servers are already upgraded to v13 (or at minimum v12.3.1 build 12.3.1.1139 before starting the EM upgrade), and that the EM server OS is on a supported Windows Server version.

Before starting the upgrade, export your active keyset and confirm you have a current EM configuration backup. These are the two recovery assets that cannot be recreated if something goes wrong mid-upgrade.

Run the upgrade wizard from the v13 ISO. It detects the existing v12 EM installation, steps through license acceptance and prerequisite checks, then upgrades the EM software in place. Configuration, keyset data, backup server connections, roles and accounts, and SAML settings all carry over. No manual reconfiguration is needed post-upgrade in a standard upgrade scenario.