Regkey of the Month: December

Advanced Object Storage I/O Optimization: Fine-Tuning Veeam Block Generation

Within Veeam Backup & Replication (VBR), achieving effective immutability while maintaining operational efficiency relies heavily on an internal mechanism known as block generation.

What is Block Generation and why is it used?

Block Generation is defined as a time period during which all data blocks contained within backup files—both full and incremental—are assigned the same immutability period.

The core purpose of implementing Block Generation is to reduce the number of requests (API calls) to the object storage repository, thereby saving network traffic and significantly reducing costs associated with cloud providers who charge for these I/O operations (S3 operations).

This mechanism functions as internal background optimization, akin to filesystem housekeeping for immutability blocks,. Since Veeam leverages an incremental forever approach, data objects in the cloud naturally belong to newer restore points over time,. Without Block Generation, Veeam would be forced to update the immutability value daily for the majority of objects (approximately 97% of a full backup) to extend their protection by one day, resulting in excessively I/O intensive and costly operations,. Block Generation serves as a mathematical prediction to set a slightly longer immutability date for blocks expected to be needed longer, thus preventing frequent updates to the immutability value.

The advantage of adding days and why the default values

The advantage of this process is purely operational efficiency: optimizing I/O and reducing cloud costs. 

It is important to understand that block generation does NOT add additional immutable days to your restore points or affect the guaranteed retention configured in the VBR job. 

The proces only marks some blocks as immutable for a longer period to optimize storage I/O in the background. The actual added immutability for a given block ranges between 0 and 30 days, depending on the timing of the backup run and the target object storage.

The block generation setting is applied automatically and does not require explicit configuration during repository setup. The default duration of the block generation period varies based on the underlying object storage type:

• 30 days are automatically added for Amazon S3 object storage (AWS), IBM Cloud object storage, and 11:11 Cloud Object Storage,.
• 10 days are automatically added for all other types of object storage repositories. (eg. Wasabi, Cubixion,...)

Consequently, the "exact" immutable time for a data block is the configured immutability time plus the block generation days, depending on the service provider. For instance, a 30-day immutability period would result in the data blocks initially having an immutability set for 30 days plus 10 days of block generation.

Influencing this behavior via a registry key

Although Veeam strongly advises against modifying this internal optimization mechanism,, the default block generation period can be influenced using a specific registry value.

For Veeam Backup & Replication v12 and later, the configuration is managed using the following specific registry key:

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
• Name: ObjectStorageImmutabilityGenerationDays (DWORD (32-bit))
• Value: the desired number of days, starting at 1

Note that setting the value to 0 is useless, as 1 is the lowest value that makes sense. 

Important: modifying this key does not require a reboot of the VBR server or a restart of any services to take effect. The previous key name, SOBRCapacityImmutabilityGenerationDays (used in VBR v11), is now invalid in VBR v12.

What is the effect wen this registry key is modified ?

New Blocks/Chains: New data blocks written to the object storage will utilize the newly defined, reduced block generation value for calculating their immutability expiration date.

Existing Backup Chains: Veeam is capable of extending the immutability expiration for all data blocks across the entire backup chain (including both active and inactive parts) and assigning them to a new generation to maintain backup consistency,. However, if blocks were previously marked with a longer immutability period based on the old, higher block generation setting, they will remain marked according to the original, longer period and will only expire when that specific date is reached.

Use Case and Associated Risks

A typical motivation for wishing to adjust the block generation days stems from a misconception that this value unnecessarily extends the actual immutable retention period specified in the job settings,. Veeam confirms that block generation is strictly an internal optimization that prevents the need to update a huge amount of objects daily, not a method to extend restore point availability.

Use Case for Reduction

A justifiable, but highly niche, use case for lowering this value might apply to a a big enterprise or service provider utilizing private, on-premises S3-compatible storage where no monetary API call charges are incurred. In this environment, minimizing the block generation value might be seen as a way to slightly tighten the lifecycle management and align the object expiration more closely with the configured immutability window, despite eliminating the primary I/O benefit. 

Significant risks of this reduction

Veeam strongly advises against manipulating this key because the inherent risks generally outweigh any perceived benefits.

Reducing  ObjectStorageImmutabilityGenerationDays dramatically increases the number of necessary API calls/IO operations,. If this change is applied to an environment using a public cloud provider (like AWS or Azure) that charges per S3 operation, the primary consequence is an immediate and significant surge in API costs. Furthermore, this intensified frequency of IO operations could potentially overload the object storage or result in the cloud provider implementing throttling, leading to unpredictable side-effects impacting backup and retention processing. Be carefull with applying this to not overload your local object storage with an API-call storm. See alsy my previous post on optimizing lightweight Object Storage API load.

In essence, tampering with block generation undermines the sophisticated background optimizations Veeam designed to reduce IO demand and save operational expenditure, whether in the cloud or on-premises. So you've been warned ;-)

Regkey of the Month: November

Changing the order of Guest Processing Methods in Veeam VBR

Why and How (vSphere & Hyper-V)

When protecting virtual machines at scale, the way your backup software communicates with the guest OS matters—especially in secure or isolated environments. In many organizations, VMs live in DMZs, private networks, or tightly firewalled segments where traditional RPC-based communication simply isn’t allowed.

In these cases, backups may fail not because the VM is unreachable, but because the guest-processing traffic is blocked. To overcome this, Veeam offers networkless guest processing methods for both vSphere and Hyper-V that use hypervisor channels instead of direct network access.

Even better—you can change the order in which Veeam attempts these methods, ensuring it always tries the most appropriate connection type first.

In this post, we’ll explore why you might want to change that order and how to configure it for both VMware vSphere and Microsoft Hyper-V environments.

 

Why Change the Guest Processing Connection Order?

By default, Veeam uses the following logic:

1. Try network communication first (RPC / Admin$).

2. If that fails, fall back to a networkless hypervisor-based method.

This works well in open networks, but not in cases such as:

• VMs in DMZ segments
• Isolated networks with zero direct connectivity
• Service provider or multi-tenant environments
• Highly restricted firewalls
• Scenarios where you never want guest network access attempted

In these situations, repeatedly attempting RPC adds needless delays, logging noise, and potential security concerns. For a cleaner and more predictable process, you can instruct Veeam VBR to try:

• VIX first in vSphere

• PowerShell Direct first in Hyper-V

Let’s walk through how.

Networkless Guest Processing in vSphere

In VMware environments, Veeam can use VMware VIX / vSphere Web Services to push runtime components into the VM without requiring network connectivity. This works through VMware Tools and is especially useful for:

• Windows VMs without reachable Admin$ shares

• Firewalled or isolated network segments

• Service provider environments where guest traffic is restricted

Forcing VIX to be Tried First

To make Veeam attempt VIX before RPC, create this registry key on the Veeam Backup & Replication server:

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
• Name: InverseVssProtocolOrder (DWORD (32-bit))
• Value: 0 = Try RPC first, then VIX (default) / 1 = Try VIX first, then RPC

You do not need to restart services—changes apply on the next job run.

This simple adjustment ensures that Veeam uses vSphere’s built-in communication channels first, improving reliability in locked-down environments.

Networkless Guest Processing in Hyper-V

In Hyper-V environments, Veeam uses PowerShell Direct for networkless communication. This method works between the host and Windows guest as long as Integration Services are running—even if the VM has zero network access.

This is extremely helpful for:

• Secure VMs with no NIC
• Isolated Hyper-V clusters
• Environments where firewall rules block all RPC traffic

Forcing PowerShell Direct to Be Tried First

To prioritize PowerShell Direct over RPC, create:

Registry Path:

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
• Name: HvVssPowerShellDirectPriorityOverNetwork (DWORD (32-bit))
• Value: 0 = Try RPC first, then PowerShell Direct (default) / 1 = Try PowerShell Direct first, then RPC

Again, Veeam services do not need to be restarted. 

Conclusion

Changing Veeam’s guest processing connection order is a simple but effective way to streamline backups in isolated or heavily secured environments. Whether you run vSphere or Hyper-V, reordering VIX or PowerShell Direct to be attempted first can significantly improve backup reliability and reduce failed RPC attempts.

For anyone running workloads in DMZs, air-gapped networks, or multi-tenant platforms, this tweak is not just useful—it’s a must-have.

 

Regkey of the Month: October

Visually classify your environment

How to Configure a Custom Banner in Veeam Backup & Replication Console

Have you ever logged into a critical system and wished there was an immediate, unmistakable visual indicator of the environment's security level or purpose? For system administrators managing multiple Veeam environments—such as production, test, HQ, branch-office, and highly classified systems—a simple, consistent warning or label can be a lifesaver.

This post walks you through implementing the Classified Stripe feature in Veeam Backup & Replication (VBR), allowing you to display a custom text banner prominently across all connected consoles.

The use case: The Need for Immediate Context ⚠️

In environments where multiple VBR servers exist for different purposes (e.g., development/test, federal compliance, or critical production), administrative mistakes can happen. Accidentally performing a destructive action on a production server when you thought you were on a test box is a nightmare scenario.

The Veeam Classified Stripe (described in KB4458) is a powerful, yet simple, security feature designed to solve this by providing a persistent, configurable text banner at the top of the VBR console. This banner acts as an immediate visual cue, helping administrators identify the security level or nature of the Veeam Backup Server they are connected to, thus reducing the risk of administrative errors.

The Solution: The Classified Stripe Feature

The solution is to enable a specific set of registry values on the Veeam Backup Server. Once enabled, this banner will appear not only on the server's local console (in Windows based deployments) but also on every remote Veeam Backup & Replication Console that connects to it.

 

The feature requires configuring three main registry values: one to enable the stripe, one to set the text message, and an optional one to define the background color.

How to Implement the Banner 💻

The following steps and registry details must be applied on the Veeam Backup Server itself.

The first mandatory step is to activate the banner. Herefore, create a key named UIClassifiedMode and set the value to 1.

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\ 
• Name: UIClassifiedMode (DWORD 32 Bit)  
• Default Value: 1 (decimal)

With only this key, the default message "CONFIDENTIAL" is shown in a banner which had a default dark red background.

To set your own message in the banner, you should create a second key.

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\ 
• Name: UIClassifiedStripeText (String Value (REG_SZ)
• Value: THIS IS MY TEXT FOR THE BANNER

 

Optional you can set the background color. Default, the stripe uses a dark red background. You can customize the color using a hexadecimal color code (the preceding hash sign must be included in the value)

You can find an easy to use ColorWheel to hex-value here.

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\ 
• Name: UIClassifiedStripeBackgroundColor (String Value (REG_SZ)
• Value: #008000 (this value represents dark green)

Example:

To create a banner that says "DEV/TEST - DO NOT USE FOR PROD" with a light yellow/orange background (#FFCC00), you could run the following three PowerShell commands on the Veeam Backup Server:

# 1. Enable the stripe
New-ItemProperty -Path 'HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication\' -Name 'UIClassifiedMode' -Value "1" -PropertyType DWORD -Force

# 2. Set the custom text
New-ItemProperty -Path 'HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication\' -Name 'UIClassifiedStripeText' -Value "DEV/TEST - DO NOT USE FOR PROD" -PropertyType String -Force

# 3. Set the background color to light yellow/orange
New-ItemProperty -Path 'HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication\' -Name 'UIClassifiedStripeBackgroundColor' -Value "#FFCC00" -PropertyType String -Force

Hey regkey-man, how do we do this on JeOS based VBR deployments ?

The new appliance based VBR deployments are using JeOS (Just Enough OS) which is based on Rocky Linux with some specific tweaking and further hardening. So there is no such thing as a registry.

Don't be afraid, all your registry tweaks are not gone. They're just located in config files.

 

Applying Custom Settings in Veeam Software Appliance (VSA)

Custom settings (like the banner settings discussed above) are applied by editing configuration files within the VSA environment. These configuration files correspond directly to the Windows Registry keys used in Veeam Backup & Replication (VBR) on a Windows server.

To access and modify these files, you must use the Veeam Host Management Console Web UI. Within the console, you navigate to Logs and Services and then select Host Configuration. This interface allows you to search for and manage the configuration files.

The recommended process for implementing a custom setting is:

•     Export the existing configuration file
•     Modify the exported file by adding the necessary settings under the correct section.
•     Import the modified configuration file back into the VSA.

Important remarks:

I always use Notepad++ to edit this type of files since the LF and CR/LF may vary between Linux and Windows environments.

If the Security Officer role is enabled, importing an updated configuration file will require approval from the Security Officer before the changes take effect. If no security officer role is defined during the setup, the changes are applied immediately.

Configuration File Structure

The VSA configuration files use a structure with sections denoted in square brackets (e.g., [root]). A section header corresponds to a specific subkey within the original Windows Registry path. 

For example, in the /etc/veeam/veeam_backup_and_replication.conf file:

The section header [root] is the equivalent of the primary registry key: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\.

A section header like [API] corresponds to the subkey HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\API\.

To apply the custom banner settings (e.g., UIClassifiedMode, UIClassifiedStripeText, UIClassifiedStripeBackgroundColor), you would add the corresponding values directly under the [root] section of the primary configuration file.

Registry Key to Configuration File Overview

The list below provides an overview of common Windows Registry keys and their corresponding configuration files in the Veeam Software Appliance.

Windows Registry Key                                                                    Veeam Software Appliance Configuration File 

HKLM\SOFTWARE\Veeam\Veeam Backup and Replication          /etc/veeam/veeam_backup_and_replication.conf
HKLM\SOFTWARE\Veeam\Veeam Mount Service                         /etc/veeam/veeam_mount_service.conf
HKLM\SOFTWARE\Veeam\Veeam Backup Catalog                       /etc/veeam/veeam_backup_catalog.conf
HKLM\SOFTWARE\Veeam\Veeam Threat Hunter\                         /etc/veeam/veeam_threat_hunter.conf

Final Thoughts 💭

While the Classified Stripe feature is simple to implement, its value in a large or complex IT infrastructure is significant. This small, persistent visual element adds a crucial layer of operational safety and compliance:
Minimizing Errors: It forces administrators to confirm the context of the server, especially when juggling multiple remote console connections.

Compliance: For environments requiring strict classification markings (e.g., government, finance), the stripe helps meet internal policy requirements by clearly labeling the system's data sensitivity.
 

Organizational Clarity: You can use it to display maintenance warnings, security classifications ("NIS2 compliancy," "PCI DATA"), or just simple reminders ("DR SITE").

Implement this feature today to enhance security, reduce administrative mistakes, and bring operational clarity to your Veeam infrastructure!