Veeam announced Veeam Backup for M365 v8 at VeeamON 2024. I had the opportunity to explore the Technical Preview beforehand and would like to provide an initial overview here.
Environment:
I set up a demo environment within Microsoft Azure (dedicated tenant) and deployed a Microsoft CDX tenant with a duration of 90 days as the source data. This tenant was connected to Veeam Backup for M365 and used as the data foundation. The components are designated as follows:
| Hostname: | OS: | Function: |
| Lab-Veeam-V365B | Windows Server 2022 Datacenter | Veeam M365 Backup Server |
| Lab-Veeam-V365P1 | Windows Server 2022 Datacenter | Veeam M365 Backup Proxy |
| Lab-Veeam-V365P2 | Windows Server 2022 Datacenter | Veeam M365 Backup Proxy |
| Lab-Veeam-V365P3 | Windows Server 2022 Datacenter | Veeam M365 Backup Proxy |
| Lab-Veeam-V365P4 | Windows Server 2022 Datacenter | Veeam M365 Backup Proxy |
Following Veeam’s recommendation, I configured the systems using the local hosts file on each system:
Installation:
With the introduction of the new version, Veeam has implemented the „Customize Settings“ button, familiar from VBR, into the installation wizard of Veeam for M365. Among other features, this allows the configuration of Service Accounting:
It is now possible to configure the PostgreSQL database, allowing Veeam to connect with an existing installation:
Unfortunately, this process encountered errors, which resulted in the following messages:
I used the built-in administrator account created during the PostgreSQL installation. Even with the default settings (no native authentication), an error message was encountered:
The installation was performed with PostgreSQL v15.7, as currently only v15 releases are supported by Veeam. This applies to both VBR and M365 installations. The error message was reported to Veeam.
Conclusion: To continue testing, I reset the environment and did not install PostgreSQL separately in advance. This worked without any errors or issues.
Basic Configuration:
Adding an M365 organization:
As mentioned earlier, I am using a Microsoft CDX tenant as the source to ensure that we have more than just empty accounts, allowing for testing with sample data. Within Veeam, the wizard has not significantly changed:
Note: I am not performing Teams chat backup to save costs, as Microsoft has recently introduced fees for the required API calls.
For authentication, I am using Modern Authentication in accordance with current standards and best practices:
Next, as usual, is the app registration within M365, which I allowed Veeam to perform automatically:
I provided the app with a descriptive name to closely resemble a production scenario:
In conclusion there were no further errors and the organization was successfully added:
Configuration of Proxy Servers:
I have two scenarios that I plan to test:
Scenario 1: Use of a single proxy (tested in this post)
Scenario 2: Use of a proxy pool (new in v8)
For both scenarios, I am using the aforementioned CDX tenant and backing up to the Wasabi Cloud (initially without immutability). The conditions are identical for both scenarios.
Following Veeam’s recommendation, I addressed the proxies by hostname and added the individual servers:
I used the local administrator account of the target server for the connection:
Subsequently, I tested one of the new features and configured it so that the wizard automatically creates a service account (with the appropriate parameters) on the target system:
Here I encountered the first errors:
The errors indicate missing .NET Runtime and the appropriate version of PowerShell. According to the Veeam manual, the following prerequisites are required for an M365 proxy server:
After installing the required components I made another attempt which resulted in the following error message:
Here, I had to delve deeper for the first time. Veeam documentation specifies that ports 9191 and 9193 are used for communication between the Veeam M365 server and the proxy server. Connections towards Microsoft 365 are not relevant at this stage.
A review of the Windows Firewall log on the proxy server reveals the following:
A review of the Windows Firewall log on the Veeam M365 server reveals the following:
In the first screenshot, port 135 on the proxy server is being accessed; this is an RPC port. I have allowed inbound traffic on this port on the proxy server.
On the M365 server, we see that port 5432 is being accessed. This port is used by the PostgreSQL server. It appears the proxy server is trying to connect to the database through this port. I have also allowed this port.
In addition to port 5432, port 4222 is being accessed. This port is used for communication with the NATS server on the Veeam M365 server. I have also allowed inbound traffic on this port.
Conclusion: I found no mention of these ports as prerequisites in the documentation and reported this to Veeam (via one of the SE colleagues).
Once the appropriate ports were opened in the Windows Firewall, the installation proceeded without errors.
Note: The aforementioned warning pertains to the memory of the proxies. Due to resource availability, I intentionally undershot the minimum requirement slightly and increased it for subsequent tests.
Automatically created service accounts:
As mentioned earlier, Veeam has integrated the creation of service accounts into the wizard. This means that on the target system (in this case, the proxy server), a corresponding account is created and granted the necessary permissions. For a Windows server, the account is created as follows:
Conclusion: The following actions are automatically carried out:
- Creation of a local Windows account
- Setting the account password to „Never expires“
- Adding the account to the „Performance Monitor Users“ group
- Granting the permission to run services