Deploying the Veeam Infrastructure Appliance: A Complete Step-by-Step Guide
Deploying the Veeam Infrastructure Appliance: A Complete Step-by-Step Guide
Veeam v13 introduces the Veeam Infrastructure Appliance (VIA) — a purpose-built, DISA STIG-compliant Linux appliance based on Rocky Linux that deploys backup proxies, hardened repositories, and mount servers without any manual OS hardening required. This guide walks through the full deployment: from booting the JeOS ISO to registering the finished appliance as a VMware proxy in Veeam Backup & Replication.
Overview: VSA vs VIA — What's the Difference?
Veeam v13 ships two distinct JeOS-based appliances, both built on Rocky Linux and pre-hardened to DISA STIG standards. They look similar on the surface, but they serve entirely different purposes — and it's worth understanding the split before you deploy anything.
| Specification | VSA Veeam Software Appliance | VIA Veeam Infrastructure Appliance |
|---|---|---|
| Role | Central management plane | Edge data plane — proxy, repository, or mount server |
| What runs on it | Backup & Replication Server, Enterprise Manager | Backup Proxies, Hardened Repositories, Mount Servers |
| OS base | Veeam JeOS (Rocky Linux) | Veeam JeOS (Rocky Linux) |
| Security baseline | DISA STIG compliant, TOTP MFA enforced | DISA STIG compliant, TOTP MFA enforced |
| High availability | Active-passive HA cluster supported | Deployed as standalone resilient nodes |
The reason for having two separate appliances comes back to Veeam's Zero Trust Data Resilience (ZTDR) principle: keep the management plane physically and logically separate from the storage plane. If your Backup & Replication server is ever compromised, a properly configured Hardened Repository on a VIA node cannot have its backup data deleted or encrypted — they're isolated by design.
This guide covers the VIA deployed as a VMware backup proxy. The wizard flow is identical for a Hardened Repository deployment; the key difference is which option you select at the GRUB boot menu right at the start.
All screenshots in this guide were captured from a live deployment on March 5, 2026. The appliance was deployed with static IP 192.168.1.11, hostname vprx-435bac4a, and registered into a VBR v13 instance running at 192.168.1.7.
Booting the JeOS ISO
Download the Veeam Infrastructure Appliance ISO from the Veeam portal and mount it to your VM or physical server. The ISO bundles the Veeam JeOS installer — version 13.0.1.1071 at the time of this guide — running on Rocky Linux.
Selecting Your Appliance Type at the GRUB Menu
The very first thing you'll see after booting is a GRUB menu with four options. This is the most consequential decision in the entire process — it determines what role the node will serve and how the disks get formatted. You can't change it without reinstalling.
- Veeam Infrastructure Appliance — The standard option for VMware/Hyper-V proxies and mount servers. This is what we're using in this guide.
- Veeam Infrastructure Appliance (with iSCSI & NVMe/TCP) — Same as above, but with the kernel modules needed for Direct SAN access and hardware snapshot-based backups pre-loaded. Choose this if you're doing SAN-mode backups.
- Veeam Hardened Repository — Formats data disks with XFS and enables the immutability daemons required for WORM storage. Only choose this if the node's sole purpose is an immutable backup repository.
- UEFI Firmware Settings — Drops into the server's BIOS/UEFI setup.
Fresh Install vs. Reinstall
After selecting your appliance type, you'll see two installation mode options:
For any new deployment, choose Install. The "Reinstall" option exists specifically for Hardened Repository nodes where you need to rebuild a failed OS without losing your stored backup chains on the data partition. It's not relevant here.
After selecting Install, you'll get one more confirmation since this operation is destructive and can't be undone:
There's no undo. It's worth taking an extra moment to confirm the server you're about to wipe is actually the one you intend to deploy the VIA on.
Automated OS Installation
Once confirmed, the installer runs completely hands-off. You'll see the system work through its shutdown and handover sequence as the RAM-based installer environment is discarded and the server boots into the freshly formatted JeOS filesystem:
When the installation finishes, the server reboots and immediately launches the configuration wizard at the terminal. Don't walk away — it's waiting for input.
The Configuration Wizard
The wizard is a terminal-based (TUI) interface that steps through six sequential tasks. A few of these settings cannot be changed after the fact without a full reinstall, so it's worth reading through this section before you start.
- Step 1
Accept the license agreement
- Step 2
Set the hostname — this becomes the TLS certificate anchor and cannot be changed later
- Step 3
Configure network interfaces — static IP, optional NIC bonding
- Step 4
Set the time zone and NTP servers — critical for MFA to work
- Step 5
Create the Host Administrator account and enroll TOTP MFA
- Step 6
Configure the Security Officer account — also a one-time opportunity
Use arrow keys and Tab to move between fields. Enter confirms a selection. You may notice the wizard title bar is inconsistent across screens — you'll see "Initial Configuration Wizard," "Host Configuration Wizard," and "Startup Wizard" depending on the step. These are all part of the same first-boot flow.
Step 1 — License Agreement
Step 2 — Hostname
This isn't an exaggeration. The hostname you enter here is immediately used by the system's OpenSSL library to generate the self-signed TLS certificates for both the Host Management Console (port 10443) and the certificate-based pairing with the VBR server. If you change the hostname after deployment, those certificates become invalid — all existing management server connectivity breaks, and you'll need to manually re-pair everything from scratch. Use a stable, permanent identifier from the start rather than accepting the randomized default.
Step 3 — Network Configuration
Always use a static IP address in production. DHCP technically works, but the appliance's TLS certificate and VBR server pairing are both tied to the IP — a DHCP lease change would break connectivity.
If you need redundancy or throughput aggregation, the wizard supports NIC bonding. 802.3ad (LACP) gives you real bandwidth aggregation but requires matching configuration on the upstream switch. Adaptive Load Balancing (ALB) requires no switch changes at all, making it the easier option when you don't control the network infrastructure. One important note: bond architectures set here are very difficult to modify through the Web UI after the fact, so plan your network layout before you start the wizard.
Step 4 — Time Zone and NTP
The MFA system you'll configure in the next step is TOTP-based, meaning it generates time-synchronized one-time codes. If the appliance clock drifts significantly relative to the admin's authenticator app, the tokens won't match and authentication fails. Use reliable NTP servers — ideally internal stratum 1 or 2 servers with an external fallback. In VM environments, also be aware that a suspended/resumed VM can wake up with a wrong clock; reliable NTP is what keeps it corrected.
Step 5 — Host Administrator Account and MFA Enrollment
veeamadmin. Enter a password that meets the DISA STIG complexity requirements. The field will reject non-compliant passwords inline before you can proceed.The password must satisfy all of the DISA STIG PAM requirements enforced on the appliance. These include:
- Must meet the DISA STIG minimum length requirement (see Veeam KB4740 for the exact length enforced on this appliance)
- Must include at least one uppercase letter, one lowercase letter, one number, and one special character
- Must not contain more than four consecutive characters from the same character class — a string like apple (five consecutive lowercase letters) or 12345 (five consecutive digits) will be rejected. This is controlled by the
maxrepeatparameter in/etc/security/pwquality.conf - The
veeamadminandveeamsopasswords must be completely distinct from each other — the system verifies they don't share overlapping sequences
Once a compliant password is accepted, the wizard immediately requires MFA enrollment. There's no way around this step:
The system also generates a hexadecimal emergency recovery token at this point. Write it down and store it somewhere physically secure — offline storage in a locked safe is the right call. If you ever lose access to your MFA device, only the Security Officer account can reset your TOTP enrollment. Without the recovery token or SO access, lockout is permanent.
If you set up NTP correctly in Step 4 and the clock is synchronized, enrollment will work fine. If the appliance clock is wrong, the token you generate in your authenticator app will immediately mismatch and enrollment will fail. If that happens, fix NTP first, then try again.
Step 6 — Security Officer Account
veeamso. The screen describes the role's purpose clearly: "Security Officer approves sensitive actions of host admins (Zero Trust concept)." This role is typically assigned to someone from the information security team — not the same person as the backup administrator.If you check "Skip setting up Security Officer" and complete the wizard, the four-eyes authorization model is permanently disabled for the lifetime of this appliance. There's no way to add it back later — you'd need to wipe the block storage and reinstall from scratch. For any production deployment, always configure the Security Officer. The only scenario where skipping makes sense is a deliberate decision in a non-critical lab environment where the reduced security posture is acceptable.
One important detail here: the Security Officer's MFA enrollment does not happen in this wizard step. The password you create here is a temporary bootstrap credential only. The first time the SO logs into the Host Management Web UI at https://<VIA-IP>:10443, they'll be required to change their password and complete their own TOTP enrollment before they can access anything. This is deliberate — it ensures the SO performs their own enrollment independently rather than having the backup admin set it up on their behalf.
Step 7 — Summary and Commit
Take a moment to scroll through everything and confirm it looks right before pressing [Finish]. Once you commit, the system restarts its internal networking and cryptographic services and generates the TLS thumbprints needed for the web management interface. After that, the appliance is operational.
When the wizard finishes, the appliance is reachable at https://<VIA-IP>:10443 for the Host Management Console. You can now proceed to add it to Veeam Backup & Replication.
The Two-Role Access Model
Before moving on to registering the appliance in VBR, it helps to understand the access model you just configured — because it will affect how you manage the node day-to-day.
The VIA enforces a strict two-account system. The Host Administrator (veeamadmin) handles operational tasks like network config, updates, and normal administration. The Security Officer (veeamso) acts as an independent gatekeeper for any action that could be used to undermine security — enabling SSH, resetting passwords, disabling MFA. Neither account can do everything on its own.
| Capability | Host Admin (veeamadmin) | Security Officer (veeamso) |
|---|---|---|
| TUI console access | ✔ Authorized | ✘ Denied |
| Web UI (HTTPS port 10443) | ✔ Authorized | ✔ Authorized |
| Configure IP, DNS, NTP, bonding | ✔ Authorized | ✘ Denied |
| Initiate software updates | ✔ Authorized | ✘ Denied |
| Enable SSH / root shell access | Submits request only | ✔ Approves or declines |
| Reset standard user passwords | ✘ Denied | ✔ Authorized |
| Reset lost or desynchronized MFA tokens | ✘ Denied | ✔ Authorized |
| Manage configuration backup passphrases | ✘ Denied | ✔ Authorized |
In practice this means: if an attacker compromises the veeamadmin account, they still can't enable SSH, disable MFA, or reset credentials without a separate, independent approval from veeamso through its own authenticated session. The two accounts are intended to be held by different people — typically the backup administrator and a member of the security team respectively. That separation is what makes the model meaningful.
Both accounts access the Host Management Console at https://<VIA-IP>:10443 using their username, STIG-compliant password, and TOTP token. One thing to note for Hardened Repository deployments specifically: the Web UI on port 10443 may be disabled by default as an additional security measure. If that's the case, you'll need physical console access to temporarily enable it, perform your configuration, then disable it again.
Adding the Appliance to Veeam Backup & Replication
With the appliance configured and online, open the VBR web console and go to Infrastructure → Managed Servers. At this point you should only see "This server" — the VBR server itself.
Add Server Wizard
Click + Add Server. The dialog presents four server type options:
Select Veeam Infrastructure Appliance. This is an important distinction from older Veeam workflows — you're not choosing "Linux" here and going through an SSH credential flow. The VIA has the Veeam Deployment Kit pre-installed, which sets up a cryptographic listener service that VBR connects to directly using certificate exchange.
Certificate Trust Validation
After entering the IP and clicking Next, VBR contacts the appliance and retrieves its TLS certificate. You'll be asked to verify the fingerprint:
Older Veeam Linux integrations required temporarily enabling SSH, opening port 22, and sending root credentials across the network — all real attack surface. With the VIA, the pairing is done entirely through certificate exchange with no SSH port opened and no credentials transmitted. The fingerprint verification step here is your manual confirmation that the certificate is legitimate.
Component Review and Deployment
Next, the wizard shows you exactly which components it will install and which are already present on the appliance:
After clicking Finish, VBR pushes and installs the listed components to the appliance. You can watch the deployment in real time:
Verifying in Managed Servers
The appliance is now a managed Veeam infrastructure node. The next step is assigning it the VMware proxy role.
Assigning the VMware Backup Proxy Role
Navigate to Infrastructure → Proxies and click Add VMware Proxy. This opens the New VMware Proxy wizard.
A few things worth knowing about the settings on this screen:
- Transport mode — Automatic selection is the right default for most environments. VBR negotiates the fastest available mode at job runtime — HotAdd if running in a VM on the same host, Direct SAN if configured, or NBD as a fallback. You can restrict this via the Choose button if your specific environment requires it.
- Connected datastores — Automatic detection means the proxy discovers accessible datastores at runtime. You'd only restrict this if you want specific proxies handling specific datastores in a larger environment.
- Max tasks — defaults to a value based on the system's CPU count (16 in this case). This is the number of concurrent backup streams. Adjust it based on the appliance's available CPU and network resources and how much parallel work you want it handling.
Veeam now installs the VMware VDDK (Virtual Disk Development Kit) on the appliance and registers it as a proxy. This runs as a background infrastructure job you can watch:
✅ Deployment Complete
- Veeam Infrastructure Appliance deployed on Rocky Linux JeOS 13.0.1.1071
- DISA STIG-compliant password policy and TOTP MFA enforced for both accounts
- Security Officer (veeamso) configured for Zero Trust four-eyes authorization
- Appliance paired to VBR server via certificate-based authentication — no SSH required
- Veeam Data Mover, Guest Interaction Proxy, and third-party storage libraries installed
- VMware VDDK installed, proxy role registered — ready to run backup jobs
When to Choose Hardened Repository Instead
If your goal is immutable backup storage, select Veeam Hardened Repository in the GRUB menu instead of the standard appliance option. The wizard flow is identical, but the OS installation formats the secondary data disks differently, and additional immutability daemons are enabled:
- Data disks are formatted with XFS, which supports Fast Clone (reflink) technology. Instead of physically copying duplicate data blocks during synthetic full backups, XFS creates lightweight metadata pointers to the existing blocks. The result is dramatically better storage efficiency on long-retention chains — without needing expensive hardware deduplication appliances.
- Backup files receive a WORM immutability flag in the XFS metadata. During the defined retention period, those files cannot be modified, encrypted by ransomware, or deleted by any user — including a compromised
veeamadminaccount or even a fully compromised VBR management server. This is the key architectural promise of the Hardened Repository. - This directly satisfies regulatory requirements for non-rewritable, non-erasable storage under frameworks like SEC Rule 17a-4, FINRA, and HIPAA.
- The Web UI on port 10443 may be disabled by default on Hardened Repository nodes as an added security measure. If you can't reach the interface, you'll need physical console access to temporarily enable it, complete your configuration, then disable it again.
For robust ransomware resilience, the recommended architecture is: VSA (management plane) + VIA proxy nodes + VIA Hardened Repository (immutable on-premises copy) + an offsite or cloud copy. The Hardened Repository is the piece that guarantees a clean recovery point even if the entire management layer is compromised — the backup data is protected at the filesystem level, independent of Veeam software.
Key Takeaways and Things to Watch Out For
The hostname becomes the CN of the appliance's TLS certificate. Changing it after deployment breaks all management server connectivity and requires re-pairing from scratch. Don't accept the randomized default — set a meaningful, stable name like proxy-01.yourdomain.local right from the start.
There's no "configure Security Officer later" option. If you skip it in the wizard, the four-eyes authorization model is permanently disabled for that appliance and the only fix is a full wipe and reinstall. Even in test environments, configuring it is worth doing — you learn the workflow and you've got proper access controls in place if that test environment turns into production.
TOTP tokens depend on the appliance and the admin's authenticator app agreeing on the current time. If NTP goes down and the appliance clock drifts, authentication fails for everyone. Configure reliable NTP servers — internal stratum 1/2 with external fallback — and verify sync is working before you complete the wizard. In VM environments, also be aware that a suspended/resumed VM can wake up with a wrong clock; NTP corrects that automatically if it's configured properly.
It's an easy mistake if you're used to older Veeam workflows. Choosing "Linux" in the Add Server dialog triggers the SSH-based credential flow, which will fail on a VIA because SSH is disabled by default. The VIA has the Deployment Kit pre-installed specifically so it can be paired via certificate exchange without any of that.
Standard VMware/Hyper-V proxy → "Veeam Infrastructure Appliance." SAN-mode or hardware snapshot backups → "…with iSCSI & NVMe/TCP." Immutable storage → "Veeam Hardened Repository." You can't switch roles after installation without wiping the node and starting over, so be clear on what the node is for before you boot from the ISO.
If the appliance can't reach Veeam's update servers — air-gapped deployments, strict outbound firewall rules — the Update Status column in Managed Servers will show a warning. This has no effect on backup operations. Manage updates manually via the Host Management Console at port 10443, or through the Manage Updates workflow in the VBR console.
Logs are stored in /var/log/VeeamBackup/ on a partition sized at roughly 12% of the OS disk (typically 30–200 GB depending on disk geometry). On nodes processing large numbers of VMs this can fill faster than expected. You can request relocation of the log path to /var/lib/veeam/ through the Host Management Console — just be aware this change requires Security Officer approval, since it modifies daemon configuration and could theoretically be used to hide activity.