Articles

The previous article described the basic options for using replication in Veeam Backup & Replication. Today we will build on that and look at a less typical situation, where we use replication to migrate a Hyper-V VM between two different Hyper-V clusters.

Veeam Backup & Replication is a well-known solution for data protection and disaster recovery. Many people think of it as just backup. But the name itself also contains a second function, which is replication. In this article we will look at the basic options for using replication.

Object First Ootbi is an on-premises hardware appliance specifically designed as a secure backup object storage (S3-compatible) for Veeam. It is built on simplicity, security, and performance. The previous article covered basic information and described the cabling and configuration. Today we will look at actual usage together with Veeam Backup & Replication (VBR). Specifically creating an access key and a bucket, and adding it as a Backup Repository in VBR.

Object First is an American company that primarily manufactures on-premises backup storage called Ootbi (Out-of-the-Box Immutability). This object storage is specifically designed for Veeam Backup & Replication. It is built on simplicity, security, and sufficient performance. Support for Immutability to protect backups against ransomware and access via S3 API are standard features.

gMSA is a special type of account in Active Directory used for service accounts. It can be used on Windows for services, applications (that support it), or scripts (scheduled tasks). The administrator does not know its strong password, which is changed automatically. We will describe the options for using gMSA within Veeam Backup & Replication (VBR), where it is supported for Application-Aware Processing. We will also look more closely at Guest Processing on Windows and what accounts we need for certain situations.

One day, the Veeam ONE Reporting Service stopped starting without any warning. As a result, most Veeam ONE features stopped working. The cause turned out to be straightforward, a self-signed certificate for the Web API had disappeared from the system certificate store. How this happened could not be determined, but the fix was quick and simple.

In this article, we will look at the various ways to find out which authentication methods a user has registered (available) in their Microsoft Entra ID work account. Authentication methods represent the ways in which users sign in to resources protected by Microsoft Entra. The first part of the article covers the options available to a regular user for viewing their own registered methods. The second part describes tools intended for Entra ID administrators, who can view information about a specific user's methods or obtain a summary overview across the entire tenant.

We have another update on using passkeys for user authentication within Microsoft Entra ID. This is a new way to register (add) passkeys to a Windows computer into Windows Hello. It works for both managed devices (joined or registered to Entra ID) and unmanaged devices. It is currently in Public Preview, but hopefully will reach GA soon.

Microsoft continues to expand the options for using passkeys for user authentication. Since March, new capabilities within Microsoft Entra ID for corporate accounts have become Generally Available. These are passkey profiles assigned to user groups. Instead of a single global setting, we can now configure allowed passkeys more granularly. The second new feature is support for synced passkeys, which are not tied to a single device.

This article describes my experience with replacing Fortinet FortiGate devices that are reaching end of support with new ones. Obviously, we want to transfer the current configuration as simply as possible and achieve minimal downtime during the switchover. We will use the FortiConverter service for configuration migration. The situation is somewhat more complex because the solution is built as a High Availability FGCP cluster with two nodes. Less significant is the use of VDOMs. FortiGate is currently running on FortiOS 7.4.11. The final device switchover went (after prior preparation) very well with only a five-minute outage.