How to Install and Configure Symantec Backup Exec System Recovery Manager

— ny_wk

Symantec Backup Exec System Recovery Manager is a centralized console that lets a system administrator deploy, schedule, and monitor disk-image backups across many Windows machines from one server. This guide walks through a clean install of the Recovery Manager server, pushing the management agent to client computers, and building a scheduled backup job that protects your data drives.

The product was an enterprise add-on for Backup Exec System Recovery (BESR) 8.x, designed for shops that needed to manage image-based backups on dozens of endpoints without touching each one individually. Because this is legacy, end-of-life software, the final section maps every concept here to its modern equivalent so you can apply the same workflow with a supported tool.

Before you begin: prerequisites for the Recovery Manager server

Centralized backup management only works if the server, the network, and the clients all line up first. Confirm the following before you run the installer.

• A dedicated host for the Recovery Manager service. In the original deployment this role lived on a server named sysdev-dms-2; pick a stable machine that is always on.
• Local administrator rights on both the server and every client you plan to manage.
• The installation media — the ESD package BackupExecSystemRecoveryManager802_ESD (version 8.0.2).
• A SQL database for the management catalog. The installer can deploy a bundled SQL Server Express instance or connect to an existing SQL Server.
• Network reachability and firewall rules so the console and the client agents can talk to each other (the agent communicates back to the server over its management port).
• A backup destination with enough free space — a local data drive such as D:\backup or, better for disaster recovery, a network share or NAS.

Plan your storage first. Disk-image backups (called recovery points in BESR) grow quickly. If the backup target fills up, every job in the console fails, so size the destination for your full image plus several incremental recovery points.

Step 1: Install the Backup Exec System Recovery Manager server

The server component installs the console, the management service, and the catalog database. Run it directly on the host that will coordinate every client.

1. Log on to the server with a local administrator account.
2. Browse to the installation package location and double-click autorun.exe to launch the installer menu. (If the disc does not auto-start, run autorun.exe from the media root manually.)
3. Choose to install Backup Exec System Recovery Manager and accept the license agreement.
4. Accept the default installation settings unless your environment requires a custom path or an existing SQL instance. The defaults install the management service plus a local catalog database.
5. Let the installer finish copying files and registering the service.
6. Restart the server. A reboot is required after installation so the management service starts cleanly and registers its listener.

After the reboot, the management service runs in the background and the console is available from the Start menu. If you ever need to reinstall, return to the package location and run autorun.exe again — the original deployment did exactly this on sysdev-dms-2.

Step 2: Open the console and retrieve the management password

The Recovery Manager console is password-protected so only authorized admins can deploy agents and read backup status.

1. From the server's Start menu, launch Symantec Backup Exec System Recovery Manager.
2. When the sign-in prompt appears, enter the management password. Store this credential in your team's documented secrets location — never leave it on a sticky note or in a shared spreadsheet.
3. The console loads with an empty computer list. Until you push the agent to clients, no machines appear here.

Security note: the legacy installer historically shipped with a weak default download password (literally download) for fetching the client agent package. If you are maintaining a system that still uses it, treat that value as public and rely on network controls — restrict who can reach the server's download link.

Step 3: Download and deploy the Client Management Control agent

A client computer will only appear in the console after its management agent — the Client Management Control — is installed. The console hands you a small bootstrap installer to run on each endpoint.

1. In the console, locate the link to download the Management Control (the popup that appears the first time you open the console points to it).
2. If prompted for a download password, supply the agent download credential noted above.
3. Save the downloaded EasyInstaller.exe to a network share the clients can reach.
4. On each client computer, double-click EasyInstaller.exe.
5. Click OK / accept the defaults to install the agent. The installer registers the client with the management server automatically.
6. Return to the console — the client now appears in the computer list. (Allow a minute for the first check-in.)

Repeat the EasyInstaller.exe step on every machine you want to protect. For large fleets, push EasyInstaller.exe through Group Policy software installation or a deployment tool instead of visiting each desk.

Step 4: Create a computer group

Groups let you assign one backup policy to many machines at once. Build groups around how machines are backed up — for example, by department, by criticality, or by backup window.

1. In the console, click Manage.
2. Under Create, click Group.
3. Type a descriptive group name (for example, File-Servers or Finance-PCs) and click OK.
4. Highlight the computer(s) you want, then click Assign Computers to Group.
5. Select the target group and click OK.

The machines are now members of the group and will inherit any backup job you assign to it. This is the key efficiency win of the Recovery Manager: change the schedule once, and every member follows.

Step 5: Build a scheduled backup job

A backup job defines what to image, where to store the recovery points, how many to keep, and when to run. Create it once, then attach it to a group.

1. Under Create, click Backup Job.
2. Select the source volumes. Choose the drive(s) to protect — for a full-system recovery image, select the C: system drive; add data drives such as D: as needed. Click Next.
3. Choose the backup type (recovery point set vs. independent recovery point) and continue with Next.
4. Set the destination. Enter the storage path, for example D:\backup for a local target — though a network share or NAS is strongly preferred so the backup survives a failure of the protected machine. Click Next.
5. Set retention. Change the maximum number of recovery points to keep — for example 20 — so old images are pruned automatically and the destination does not fill up. Click Next.
6. Leave compression and options at sensible defaults (or enable compression to save space) and click Next.
7. Choose the schedule. Pick a window outside business hours — a weekly full plus daily incrementals is a common pattern. Click Next.
8. Review the summary and click Finish to save the job.

Why retention matters: capping recovery points (the 20 in the example) is what keeps your destination from overflowing. Match the number to your storage size and your recovery-window requirements — finance might need 30 days of points, a lab PC might need 5.

Step 6: Assign the backup job to the group

The job does nothing until it is attached to the machines that should run it. Linking it to a group applies it to every member at once.

1. Click the Group tab.
2. Highlight the target group.
3. Click Assign Backup Job to Group.
4. Select the backup job you created and click OK.

Every computer in that group now follows the job's source, destination, retention, and schedule. Add a new machine to the group later and it automatically picks up the same policy — no per-machine setup.

Common pitfalls and how to avoid them

Most centralized-backup problems come down to a handful of recurring mistakes. Watch for these.

• The client never appears in the console. The Management Control agent is not installed or cannot reach the server. Re-run EasyInstaller.exe on the client and confirm the management port is open through the firewall.
• Skipping the post-install reboot. The management service may not register its listener until the server restarts. If the console behaves oddly right after install, reboot first.
• Backing up to the same physical disk. Storing recovery points on D:\backup on the very machine you are protecting means a disk or hardware failure destroys both the data and its backup. Use a separate disk, share, or NAS.
• No retention limit set. Without a maximum recovery-point count, the destination fills up and every job in the group starts failing silently.
• Including C: only when you also need data. A system-drive image restores the OS, but if your users keep files on D:, those drives must be in the job too.
• Backup window collides with patching or AV scans. Heavy I/O during the same window slows everything and can cause incomplete recovery points. Stagger schedules across groups.
• Untested restores. A backup you have never restored is a hope, not a backup. Periodically perform a test recovery of a recovery point to verify it is usable.

Verification: confirm backups are actually working

Do not assume the job is healthy because it was created. Verify the full chain — agent check-in, job execution, and recovery-point integrity.

1. Confirm agent status. In the console, the assigned computers should show as online/connected, not greyed out.
2. Check job history. After the first scheduled run, open the job's status and confirm it completed with no errors and that the recovery-point count is increasing.
3. Inspect the destination. Browse to the storage path (for example D:\backup) and confirm recovery-point files (.v2i/.iv2i for BESR) exist and have recent timestamps.
4. Validate retention. After more runs than your maximum, confirm the oldest points are being pruned and the destination is not growing unbounded.
5. Run a test restore. Recover a single file from a recovery point, and at least once perform a full image restore to spare hardware or a VM to prove disaster recovery works end to end.

Important: this is end-of-life software — use the modern equivalent

Backup Exec System Recovery Manager 8.x and the standalone Backup Exec System Recovery line are no longer supported. Symantec rebranded BESR to Symantec System Recovery (SSR), and the technology later moved to Veritas. Running EOL backup software is risky: no security patches, no driver updates for new hardware, and no vendor support when a restore fails. The workflow in this guide still teaches the right model — agent, group, policy, retention, off-host destination — but apply it with a current tool.

The table below maps the concepts here to modern, supported alternatives that offer the same centralized, image-based backup management.

If you are standing up new endpoint or server image backups today, choose a supported product, store recovery points off-host with at least one immutable or offline copy, and keep encryption on by default.

Key Takeaways

• Backup Exec System Recovery Manager centralizes image-based backups: install the server, push the agent to clients, group machines, assign a job — then manage everyone from one console.
• The agent comes first — a client only appears in the console after EasyInstaller.exe (Client Management Control) is installed and checks in.
• Groups + a single backup job are the efficiency win: set source drives, destination, retention max, and schedule once, and every member follows.
• Store recovery points off the protected host and always set a retention limit, or a disk failure (or a full destination) will defeat the whole backup.
• This is EOL software — the workflow is sound, but deploy it on a supported tool like Veeam or Veritas System Recovery with immutable, encrypted, off-host storage.

Frequently Asked Questions

Why doesn't my client computer show up in the Recovery Manager console?

A client only appears after the Client Management Control agent is installed via EasyInstaller.exe and successfully checks in. If it is missing, re-run the installer on the client, confirm the machine can reach the management server over the network, and make sure the management port is allowed through the firewall on both ends.

What does the maximum recovery points setting do?

It caps how many backup images (recovery points) the job keeps at the destination. When the count exceeds the maximum — for example 20 — the oldest point is pruned automatically. Setting this prevents the backup drive from filling up, which would otherwise cause every job to fail.

Should I back up only the C: drive or all drives?

Back up C: to capture the operating system and applications for a full bare-metal restore, and add any data volumes such as D: where users actually store files. A C-only image restores Windows but not the data your users depend on, so include every drive that holds important content.

Is Symantec Backup Exec System Recovery Manager still supported?

No. Version 8.x and the Backup Exec System Recovery line are end-of-life. The product evolved into Symantec/Veritas System Recovery. Keep this guide for understanding existing legacy systems, but build new backup infrastructure on a currently supported, patched product.

For more hands-on sysadmin and backup walkthroughs, subscribe to @explorenystream on YouTube.