Recently, NAKIVO released the latest update for NAKIVO Backup & Replication v11, now available as Nakivo Backup & Replication V11.0.1

Introducing NAKIVO Backup & Replication v11.0.1

Enjoy a more tailored data protection experience with new language options in BETA, including French, German, Italian, Polish, and Chinese, alongside complete support for English and Spanish.

Improved Multilingual Support
The NAKIVO solution is now accessible in additional languages.
Navigate NAKIVO Backup & Replication in the new BETA languages: French, German, Italian, Polish, and Chinese, in addition to full support for English and Spanish.
Easily manage backup and recovery tasks without language barriers and reduce training time by using the interface in your preferred language.

Enhanced Microsoft 365 Backup Workflows
Improve data protection operations with quicker processing times for Microsoft 365 workloads.
Rapidly recover lost or corrupted emails, attachments, folders, files, or any other items from backups to minimize downtime and ensure business continuity.

With the addition of multilingual support and exciting new features, NAKIVO Backup & Replication v11.0.1 takes data protection to a global level, ensuring seamless, secure, and efficient backup and recovery for users worldwide.

The post NAKIVO Backup & Replication v11.0.1: Expanding Global Reach with Multilingual Support! appeared first on VMware Arena.

After a successful closed beta testing phase, NAKIVO Backup & Replication version 11 is now available for download!

This update brings agentless backup support for Proxmox VE, offering a more efficient method for managing and protecting virtual machine backups. Additionally, it introduces major improvements to the Microsoft 365 and NAS backup functionalities, including cloud backup integration, enhanced ransomware protection, and new features for MSP management.

Get your free trial of NAKIVO Backup & Replication v11 today to explore the latest features in your environment.

What’s new with NAKIVO Backup & Replication v11

Agentless Backup for Proxmox VE
Organizations using Proxmox VE can now safeguard their virtual environments more effectively and with reduced overhead. The solution allows direct VM backups at the host level, eliminating the need for agents on each VM. Incremental backups at the block level are performed using native change-tracking technology, ensuring only modified data blocks are copied.

Backups can be stored on a variety of destinations, including local storage, cloud, and S3-compatible services, deduplication appliances, CIFS/NFS shares, or Tape. Additionally, offsite backup copies can be created to support the 3-2-1 or 3-2-1-1 backup strategies for enhanced data availability in all scenarios.

Recovery options include restoring entire Proxmox VMs with full data or quickly recovering individual files and application objects to their original or alternative locations. Immutability can be enabled for both local and cloud backups, or air-gapped backups on tape, to protect against ransomware, with encryption added to prevent unauthorized access during the backup lifecycle.

Cloud Backup for Microsoft 365
NAKIVO Backup for Microsoft 365 reaches a new milestone with the introduction of additional storage options, ransomware-proof backup support, and automated backup tiering.

With version 11, you can back up Microsoft 365 data to local folders as well as cloud platforms like Amazon S3, Wasabi, Azure Blob, and Backblaze B2, along with S3-compatible services, NFS/SMB shares, and deduplication appliances. The ability to create additional backup copies and automate their transfer to various storage destinations—including tape—using job chaining is now available.

This new flexibility allows for easier migration between storage platforms, ensuring better storage utilization and improved data resilience. Immutability is also supported for backups in both local and cloud repositories to safeguard against ransomware, deletion, and modification.

NAS Backup
NAKIVO NAS Backup offers the ability to back up SMB and NFS file shares located on NAS devices, Windows, and Linux systems. Version 11 expands the backup destination options, allowing backups to be sent to cloud platforms, S3-compatible services, local folders, NFS/SMB shares, and deduplication appliances. Support for backup copy and job chaining is also now available, enabling automatic movement of backups between different storage locations, including tape.

Immutability options are also included for both local and cloud repositories, offering enhanced protection against ransomware and unauthorized deletions, ensuring the durability of file share backups.

Source-Side Backup Encryption
In response to the rising number of data breaches, NAKIVO version 11 introduces source-side encryption for backups. This allows backups to be encrypted before they are transferred or stored, ensuring the highest level of security. Integration with AWS KMS is supported to mitigate the risk of losing decryption keys.

Self-backups that contain system configurations can also be encrypted, with backups stored across various platforms, including local folders, public cloud services, and S3-compatible storage. For even greater security, combining backup encryption with immutable storage offers stronger protection against cyber threats.

Backup from NetApp Storage Snapshots
Version 11 enhances the Backup from Storage Snapshots feature by adding support for NetApp FAS and NetApp AFF storage arrays. This feature allows VM backups to be created from storage snapshots rather than regular VM snapshots for supported storage devices like HPE 3PAR, Nimble Storage, Primera, and Alletra. Using storage snapshots minimizes the performance impact on production environments during backup operations.

Federated Repository
The Federated Repository, introduced in version 11, provides a scalable and flexible backup repository solution. This expandable storage pool consists of multiple standalone repositories, called “members,” that can be added to quickly without complicated configurations. If a repository fails or reaches full capacity, backup operations can continue uninterrupted using other available members, and data can be recovered from accessible recovery points.

This functionality improves storage expansion, resource utilization, and overall backup reliability, creating a more consistent framework for data protection.

Tenant Overview Dashboard
The Tenant Overview Dashboard in the MSP Console enhances visibility for Managed Service Providers (MSPs) by providing a centralized view of all tenant environments and data protection activities. Version 11 offers real-time insights, such as node status, available resources, scheduled tasks, and inventory details. MSPs can easily manage tenants, resolve issues, and optimize resource and license allocation more efficiently.

Additional Enhancements

• Immutable Storage on NEC HYDRAstor: Version 11 adds support for the WORM (write-once, read-many) technology in NEC HYDRAstor to create immutable backups, offering enhanced protection against ransomware and other unwanted modifications.
• Real-Time Replication BETA for VMware: The introduction of support for VMware vSphere 8.0 expands the Real-Time ReplicationBETA, allowing for disaster recovery with RPOs as low as 1 second, even when upgrading to vSphere 8.0.
• Spanish Interface: Version 11 is now fully available in Spanish, improving the user experience for Spanish-speaking users across all aspects of the solution.

Try NAKIVO Backup & Replication v11 for Free
Explore the advanced features of NAKIVO Backup & Replication v11 with a fully-featured free trial. Install and start using version 11 in minutes to experience its powerful, latest enhancements.

The post Unlocking the Power of Data Protection: NAKIVO Backup & Replication v11 appeared first on VMware Arena.

As organizations increasingly migrate their workloads to cloud environments, safeguarding critical data has become paramount. One of the key players in this virtualization arena is VMware vCloud Director (vCD), a powerful platform for managing and automating the provisioning of cloud infrastructure resources. While vCD offers many features geared toward improving efficiency and optimizing resource allocation, its effectiveness can be significantly undermined if data backup strategies are not put in place.

In this article, we will explain the step-by-step procedure to back up the vCloud director Embedded database using vCloud director admin UI and also via CLI.

Log in as root to the appliance management UI of the primary, standby, or application cell at https://cell_eth0_ip_address:5480.

Click on the Backup Tab.

In the left panel, click the Backup tab. On the Backup page, you can see a list of previous backups. Click Backup Now.

To confirm the backup, click Backup.

VMware Cloud Director appliance creates the backup files in the  /opt/vmware/vcloud-director/data/transfer/backups directory. The backups for the earlier VMware Cloud Director versions are located in the /opt/vmware/vcloud-director/data/transfer/pgdb-backup directory. However, earlier version backups are incompatible with VMware Cloud Director 10.3.1 and later.

When the backup finishes, click Close.

The newly created file appears in the list of backups. The backup name is in the format  backup-date-time–format.tgz. For VMware Cloud Director appliance 10.3.2 and later, the backup name is in the format backup-date-time–format.zip.

You can also Initiate the backup via CLI by logging into one of the cloud cells, preferably the primary cell node. CD into /opt/vmware/appliance/bin

Type the command to run the backup script in the vCloud director

./create-backup.sh

That’s it. We have gone through the two different methods to back up the vCloud director via admin UI and also via Shell. I hope this is informative for you. Thanks for Reading!!. Be social and share it on social media, if you feel worth sharing it.

The post How to Backup vCloud Director Appliance appeared first on VMware Arena.

Exchange Server heavily dependent on the Active Directory as all the configuration is stored in the Active Directory Schema. On the other hand, all the users’ data and other important items are stored in the Exchange Database (EDB) file. In addition, the Exchange Server uses Transaction Logs to temporarily hold information, until it is committed to the database. The transaction log files act as a buffer between the database and the requests from users or systems. If the transaction log files get damaged/corrupted or one of the files is missing, then the database will not be able to mount and the state of the database will be marked as Dirty Shutdown. Until the state is changed to Clean Shutdown, the Exchange Server will not allow you to mount the database, resulting in users not being able to access their mailboxes.

Some other factors or reasons, like human errors, sudden loss of power, malware infection, natural disasters, etc. can also damage your database. In such situations, restoring the database from backup would fix the problem but you will suffer data loss from when the backup was executed to when the issue has occurred. Another option is to repair the corrupted database. In this article, we will be going through the process of repairing the corrupt database in the Exchange Server setup.

How to Repair the Corrupt Database In Exchange Server?

In Exchange Server, the Extensible Storage Engine Utilities (ESEUtil) is a command-line tool that is used to check the database integrity and repair the databases. You can use the ESEUtil commands to repair an Exchange Server database or salvage the data. Let see the step-by-step process.

Step 1: Locate the Scripts and Commands

You need to first locate the scripts and commands. Usually, the location is <Exchange Server installation folder>\V15\Bin. If the installation is at the default path, open a command prompt with administrator privileges and run the following command.

cd “C:\Program Files\Microsoft\Exchange Server\V15\Bin”

Step 2: Check the Database Status

Next, you need to check the status of the database by using the MH switch with the ESEUtil command as given below:

eseutil /mh “M:\ExchangeDatabases\mydatabase.edb”

Note: Replace the path in parenthesis with the path of your Exchange Server database.

If the database or the supporting files are damaged, you should see the State as Dirty Shutdown. This means that the database needs to be repaired as it is not healthy to operate.

Step 3: Perform Database Recovery

There are two repair options – Soft Recovery and Hard Recovery. Soft Recovery is used in cases of small corruption issues in the database. This will try to restore the database to a consistent state without any data loss. To perform soft recovery, you can run the ESEUtil command with the R switch (see the below example).

eseutil /R “M:\ExchangeDatabases\mydatabase.edb”

Once the recovery process is completed, you can rerun the command with the MH switch to check the database state. If it shows the State as Clean Shutdown, then you can go ahead and mount the database.

If the above fails, you need to perform the hard recovery. However, you need to remember that the hard recovery process results in data loss. In hard recovery, anything which is deemed as corrupted will be purged from the database and there might be false positives. Depending on the damage, there will be data loss. So, it is important to backup the database before performing such operation. 

In addition, you need to have enough storage space (almost double) available as this operation creates a new database and you might end up with no space on the server. The operation will take some time to finish and cannot be stopped once started.

To perform hard recovery, execute the ESEUtil command using the P switch (see the below example).

eseutil /P “M:\ExchangeDatabases\mydatabase.edb”

When you execute the command, you will get a warning of data loss. You need to accept the data loss to proceed with the operation. After the process is complete, run the command with the MH switch to check the state of database. Mount the database if it is in Healthy Shutdown state.

After a successful repair of the database, it is suggested to create a new database and move all the mailboxes to the new database.

An Easy and Quick Solution to Repair Corrupt Exchange Database

When a situation arises, there is a lot of pressure on Exchange admins to get the services up and running within minimal downtime and no data loss. This means that every minute and every email counts for the business continuity. For quick recovery of data, you can rely on specialized Exchange database recovery software, such as Stellar Repair for Exchange. This tool is renowned for its performance and compatibility. It allows you to directly open Exchange Server databases from any version, of any size, and in any state. After a quick/deep scan, you will be able to view the entire structure of the database and then granularly export the recovered data to PST and other file formats. You can also use the tool to directly export the recovered user mailboxes, shared mailboxes, user archives, disabled mailboxes, purged/deleted items, and public folders, to a live Exchange Server database or Microsoft 365 tenant. This helps reduce the recovery time, while ensuring no data loss.

Best Practices to Follow

• Before attempting to repair any database, it is imperative to take its backup.
• Always check the Event Viewer to find out where the problem is.
• Daily backups should be used to ensure that the transaction logs are committed. This helps reduce the risk of corruption and increase the chances of recoverability.
• Monitor the services, operating system, performance, and storage of the server. This helps find the issue before more damage is caused.
• Ensure that you have the right tools in hand that can help meet the company’s RPO and RTO and restore the services with minimal impact.
• Set up Database Availability Groups (DAG) to ensure business resilience and disaster recovery.

Conclusion

Above, we have explained the process of repairing a corrupt database using the ESEUtil commands in the Exchange Server. This is a delicate process which would need precision. In addition, there are chances of data loss when performing hard recovery on the database. As an alternative solution, you can use an Exchange repair tool, like Stellar Repair for Exchange. This tool can easily repair the corrupt database and recover all the mailboxes and other items without any data loss. It can also export the recovered mailboxes and other items to a live Exchange database or Office 365 (Microsoft) account.

The post How to Repair a Corrupt Exchange Database? appeared first on VMware Arena.

Proxmox Virtual Environment (VE) is a free, open-source virtualization management platform based on Debian Linux with a custom kernel. This solution fully integrates the KVM hypervisor, allowing users to deploy and manage virtual machines via a user-friendly GUI web interface.

Proxmox comes with Proxmox Backup Server, a native tool to back up virtual machines. However, you may need to use advanced backup/recovery features such as direct backup to the cloud, application-aware backup, flexible scheduling and retention, immutability, granular recovery, etc. Moreover, in hybrid and mixed environments, it is easier to use a single third-party backup solution like NAKIVO Backup & Replication to manage all data protection activities from a centralized interface.

Nakivo Backup & Replication now supports Backup for Proxmox VE as well along with other industry-leading virtualization platforms like VMware, Hyper-V, Nutanix AHV.

Powerful Proxmox VE Backup Solution by NAKIVO

With Nakivo Porxmox backup solution, you can protect your VM data and ensure business continuity with reliable, fast and agent-based Proxmox backup and recovery from NAKIVO with below features:

• Full and instant object recovery
• Ransomware resilience
• Affordable subscription and perpetual licenses
• Top-rated solution on review platforms

NAKIVO Backup & Replication provides reliable agent-based backup, instant granular recovery and ransomware protection for Proxmox VM data. With flexible storage and retention options, strong security controls and excellent performance, the solution helps you keep critical data protected and available at all times.

Nakivo Backup & Replication for Proxmox provides comprehensive protection with handfull of below benefits:

Efficient, agent-based backups
Perform agent-based incremental backups of Proxmox VM data to improve transfer speed and save storage space. After an initial full backup, only data that has changed since the last backup cycle is copied in subsequent backup runs.

Application support

Ensure data consistency for applications and databases (e.g., Microsoft SQL Server, Exchange Server, Active Directory) with app-aware backup processing.

Flexible retention
Create hundreds of recovery points and rotate them daily, weekly, monthly or yearly, or based on a custom period.

Diverse storage targets
Send Proxmox VM data backups to local repositories, public clouds, S3-compatible storage, NAS and tape.

Direct backup to cloud
Transfer backups directly to public cloud platforms like Amazon S3, Wasabi, Azure Blob and Backblaze B2 and other S3-compatible storage targets.

Ransomware protection
Enable immutability for VM data backups stored in local and cloud-based repositories to protect against unwanted modification and ransomware encryption.

Malware detection
Check backups for viruses and ransomware before recovering the data to isolate potential threats.

Impressed with the feature set of Nakivo Backup and Replication for ProxMox? What’s Next? I would recommend downloading Nakivo Backup & Replication for ProxMox and trialing the new feature sets of Nakivo Backup and Replication for ProxMox VM. I hope this is informative for you. Thanks for Reading. Be social and share it on social media, if you feel worth sharing it.

The post Back-Up Proxmox VM with NAKIVO Backup & Replication appeared first on VMware Arena.

Known Attack Vectors

A malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine’s VMX process running on the host. On ESXi, the exploitation is contained within the VMX sandbox whereas, on Workstation and Fusion, this may lead to code execution on the machine where Workstation or Fusion is installed.

VMWare also released a Response Matrix for these vulnerabilities, which includes Fixed Version and Workarounds. It is always good to upgrade and patch our systems to fix any vulnerabilities. However, In some cases, applying a workaround would also give us an option to remediate the reported vulnerabilities.

Response Matrix

Steps to remove a USB controller from a VMware ESXi virtual machine

ESXi host supports the hot-removal of a USB controller, the guest operating system of the virtual machine must also support the hot-removal functionality. In the event that the guest operating system does not support hot removal of a USB controller, then the VM will need to be powered off.

In addition, please ensure that the USB controller is not in-use prior to removing it from the virtual machine.The vSphere UI (vCenter Server, ESXi Embedded Host Client) only allows for the configuration of virtual USB 2.0 or virtual USB 3.0 controllers in VMs.

When a virtual USB 2.0 controller is added to a VM in vSphere, both a virtual USB 1.1 AND a virtual USB 2.0 controller are added to the VM by default.
Removing the virtual USB 2.0 controller will also remove the virtual USB 1.1 controller from the VM.

Remove USB Controller from vSphere UI

1) Ensure that the USB controller is not in use

2) Power off the Virtual machine (If required – No requirement to power off if the guestOS supports hot removal”

3) Right-click the virtual machine and click “Edit Settings“.

4) Remove all USB controllers from the VM. 

PowerCLI command to get list of VM’s attached with USB Controller

Below Powercli command can be used to list all the virtual machines with a USB controller.
Any VM reported should be investigated to determine if it can be safely removed

Get-VM | ?{$_.ExtensionData.Config.Hardware.Device.DeviceInfo.Label -match “USB”}

PowerCLI Script to Remove USB Controller from the VM list

With VMware KB 87617, Provided the powercli script to remove the USB controller from all VMs in specific vCenter Server. You can use the script in the KB article to remove the USB controller from all VMs in the Specific script.

In the majority of the production environment, We will not be able to remove the USB controller from all VMs at the same time. Either we might have to go by customer-by-customer VMs or by cluster or even only for the specific list of the VMs provided by some input file. I have a use case to remove USB controllers from VMs only belonging to specific customers. In that case, I can specify the VM list that belongs to a specific customer in the text file. So below script will only remove the USB controller from the provided list of VMs input via text file in the specific vCenter server.

#Script To Remove USB controller from Virtual Machines
#
 
#Import PowerCLI modules
Add-PSSnapIn VMware* -ErrorAction SilentlyContinue
$ErrorActionPreference = "Stop"
$errresult = 0


#VC FQDN or IP Address variable
#$VCFQDN = "x.x.x.x"
$VCFQDN = Read-Host -Prompt "`nPlease enter vCenter Server IP or FQDN"

#Array to store results
$USBFinalCheck = @()

#Result files names
$FinalResultFilename = "C:\Temp\USB_Controller_Final_Result.csv"

#Read Credentials and Connect to vCenter Server
if (Test-Connection $VCFQDN -Count 1 -ErrorAction SilentlyContinue)
{
    $VCCredentials = Get-Credential -Message "Please Enter User Name and Password which has Administrator permission on vCenter Server" -UserName Administrator@vsphere.local
    Connect-VIServer -Server $VCFQDN -Credential $VCCredentials
}
else
{
    write-host "VC FQDN or IP is Not Reachable, please retry with right entry"
    Exit
}

# Get all VMs with a USB controller
$VMlist = Get-Content "vmname.txt"
$VMs = Get-VM $vmlist | ? {$_.ExtensionData.Config.Hardware.Device.DeviceInfo.Label -match "USB"}

$ListofConnectedVMs = 0

# Identify the number of Connected VMs with USB Controller
$VMs | % { 
       
            if ($_.ExtensionData.Runtime.ConnectionState -eq "connected")
            {
                $ListofConnectedVMs = $ListofConnectedVMs+1
            } 
         }

# User Confirmation to remove the USB Controllers
$Confirmation = Read-Host -Prompt "`nScript will remove USB Controller from $ListofConnectedVMs VMs, please confirm with ('Y or Yes') to continue ?"

if ($Confirmation -eq "y" -or $Confirmation -eq "Y" -or $Confirmation -eq "Yes" -or $Confirmation -eq "yes" -or $Confirmation -eq "YES" )
{
    echo "`nContinuing with the Script Execution as per user selection"    
}
else
{
    echo "`nTerminating the script based on user selection"
    exit
}

#Now loop through that list and remove the controller from the VM
foreach ($vmx in $VMs)
{
    if ($vmx.ExtensionData.Runtime.ConnectionState -eq "connected")
    {
        echo "Found VM $vmx with USB Controller"

        $vmxv = $vmx | Get-View
        $vmxv.Config.Hardware.Device | where {$_.DeviceInfo.Label -match "USB"} | %{
            $myObj = "" | select Dev
            $myObj.Dev = $_
            $vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
            $vmConfigSpec.DeviceChange += New-Object VMware.Vim.VirtualDeviceConfigSpec
            $vmConfigSpec.DeviceChange[-1].device = $myObj.Dev
            $vmConfigSpec.DeviceChange[-1].operation = "remove"
            sleep 5
            Write-Host "Removing USB Device From $vmx`n"
			Try 
			{
			$vmxv.ReconfigVM($vmConfigSpec)
			}
			Catch
			{
			$_.exception.message
			$errresult = 1
			Write-Host "Error removing USB controller from $vmx`n*******************************`n"
			} 
			
			If ($errresult -ne 1)
			{
			Write-Host "Removed USB controller from $vmx`n*******************************`n"
			}
			$errresult = 0
			sleep 5
         }
    }
}

Write-Host "`nVerifying the USB Controller Status on Virtual Machines"

#Verification of USB Controller post removal task
sleep 10
$VMs = Get-VM

foreach ($vmx in $VMs)
{
    $USBResult = new-object PSObject
    $USBResult | add-member -type NoteProperty -Name VMName -Value $vmx.Name
    $USBResult | add-member -type NoteProperty -Name VMStatus -Value $vmx.ExtensionData.Runtime.ConnectionState
    
    if ($vmx.ExtensionData.Runtime.ConnectionState -eq "connected")
    {
        if ($vmx.ExtensionData.Config.Hardware.Device.DeviceInfo.Label -match "USB")
        {
            $USBResult | add-member -type NoteProperty -Name USB_Controller_Status -Value "Virtual Machine Has a USB controller configured"
        }
        else
        {
            $USBResult | add-member -type NoteProperty -Name USB_Controller_Status -Value "No USB Controller configured"
        }
    }
    else
    {
        $USBResult | add-member -type NoteProperty -Name USB_Controller_Status -Value "Not Checked (VM Not in Connected State)"
    }
    
    $USBFinalCheck+=$USBResult
}

try
{
    $USBFinalCheck | export-csv $FinalResultFilename -notype -ErrorAction Stop
    Write-Host "`nPlease check the verification result of VMs with USB Controller - " $FinalResultFilename
}

catch
{
    $ResultFilename = "USB_Controller_Verification_Result" + (Get-Date).tostring("dd-MM-yyyy-hh-mm-ss") + ".csv"
    $USBFinalCheck | export-csv $ResultFilename -notype
    $result = Get-Item $ResultFilename
    Write-Host "`nPlease check the verification result of VMs with USB Controller - " $result.fullname
}

How to Run the Powercli Script to Remove the USB Controller from the VM list?

1. Save the list of the VM’s in the text file named “vmname.txt” in the same directory as your powercli script is located

2. Save the powercli script as “Remove_USBController_Vmlist.ps1” and Run the Powercli script.

3. It will ask to enter the vCenter Server IP or FQDN address and  Prompt the user to allow for the USB controllers to be removed

4. Find all virtual machines with a USB controller and attempt to remove the USB controller from the virtual machines

5. Review the environment and provide a CSV file output detailing whether a virtual machine has a USB controller or not

I hope this is informative for you. This post will help you with automation steps to remove the USB controller from the list of virtual machines. Thanks for Reading. Be social and share it with social media, if you feel worth sharing it.

The post Remove USB Controller from the VMware Virtual Machine – PowerCLI Script appeared first on VMware Arena.

NSX Edges provides routing services and connectivity to networks that are external to the NSX-T deployment. You use an NSX-T Edge for establishing external connectivity from the NSX-T domain by using a Tier-0 router using BGP or static routing.

How to Replace Faulty NSX-T Edge Node in Edge Cluster

Recently I came across a situation in one of my production environments, The Customer has a Tier-0 gateway and edge cluster associated with it. My Tier-0 is Active -Passive node. We noticed an issue of all TCP packets failing when the traffic goes through one of the edge nodes.

To identify the issue, We have manually powered off the active edge node of the Tier-0 gateway. You can take a look at my article How to Identify the Active Edge Node of NSX-T Tier-0/Tier-1 Gateway

Other Edge node in the edge cluster became active and everything started working. No issues were found. This behavior is only observed when the faulty edge node becomes Active. We did involve VMware support for the same. They also suggested replacing the faulty edge node with the new node.

In this article, I will explain to you the detailed step-by-step procedure to replace the faulty NSX-T edge node in the Edge cluster.

Note: If the NSX Edge node to be replaced is not running, the new NSX Edge node can have the same name, management IP address, and TEP IP address. If the NSX Edge node to be replaced is running, the new NSX Edge node must have a different name, management IP address and TEP IP address.

In my case, My faulty edge node is edgenode-02a which is currently up and running. So I have deployed the edgenode-03a with the same configuration as edgenode2a but with a different name, Management IP, and TEP IP (Auto assigned by IP Pool).

You can also verify the edge nodes under Fabric -> Node -> Edge Transport Nodes which are part of the Edge cluster. In my case , Edgenode01a and 02a is part of the edge cluster “EdgeCluster-01a”

You can also validate the same from the Edge cluster view. Expand fabric -> Edge Clusters -> Click cluster name. It will show the transport node (edge nodes) part of this edge cluster.

Before replacing the faulty edge with a new node, We have to place the faulty edge node “edgenode-02a” into NSX Maintenance Mode.

To place the NSX-T edge node into maintenance mode, Select the NSX-T Edge node -> Select “Enter NSX Maintenance Mode” under actions

Click YES to confirm to keep the edge node ” edgenode-02a” in NSX Maintenance Mode.

Faulty edge node edgenode-02a is entered into “NSX Maintenance Mode” and Node status is showing as “Down” as well.

To replace the faulty edge node. Go to the Edge cluster from System -> Fabric ->Edge Cluster -> Select the Edge cluster “EdgeCluster-01a”.

Select Replace Edge Cluster Member under Actions.

Select the faulty NSX-T edge node from the drop-down under the Replace option. In my case, select Edgenode-02a.

Select the newly deployed edge node from the drop-down under With Option. In my case, my newly deployed edge node is edgnode-03a and click Save.

After the edge node replacement, edge node edgnode-01a and edgenode-03a is part of the edge cluster “Edgecluster-01a” now and Tunnel is up and also Node status also became UP.

You can also validate the edge cluster members from the edge cluster view. Now edge cluster members are edgnode-01a and edgenode-03a.

Post Faulty Edge node replacement, you can also validate the traffic and Tier-0 gateway status. In my case, Everything turned be healthy. That’s it. We are done with replacing the faulty NSX-T edge node in the Edge cluster.

You can also watch the detailed step-by-step video on How to Replace the Faulty NSX-T Edge node in the NSX-T edge cluster from my YouTube channel.

I hope this is informative for you. Thanks for Reading!!. Be social and share it with social media, if you feel worth sharing it.

The post How to Replace a Faulty NSX-T Edge Node in Edge Cluster appeared first on VMware Arena.

A multi-node edge cluster of NSX Edges helps ensure that at least one NSX Edge is always available. In order to create a tier-0 logical router or a tier-1 router with stateful services such as NAT, load balancer, and so on, you must associate it with an NSX Edge cluster.

Within a single NSX Edge cluster, all NSX Edge nodes must be the same type – either physical servers (bare metal) or VMs. When you create a T0 or T1, you can configure the HA (high availability) mode of a tier-0 gateway to be active-active or active-standby.

In the active-active mode, traffic is load-balanced across all members. In active-standby mode, all traffic is processed by an elected active member. If the active member fails, a new member is elected to be active.

How to Identify the Active Edge Node of  NSX-T Tier-0/Tier-1 gateway?

Now when you perform any maintenance on the Edge nodes. How do you identify which edge node is an active node that is forwarding traffic for a specific T-0 router? This is extremely important to know which is an active edge node before you perform any maintenance on your edge nodes of an edge cluster.

In NSX-T 4.x or later, it is very easy to identify the Active Edge node of the NSX-T Tier-0/Tier-1 gateway but this is not easy in NSX-T 3.x version. I tried to search the options around the different views in the NSX-T 3.x UI and even in CLI to identify the active edge node of NSX-T Tier0/Tier1.  Don’t worry. I will explain you the procedure in the blog post.

Find the Active Edge Node of NSX-T Tier-1 gateway

This will pop up the Edge node names along with the HA status of the Edge nodes for the particular Tier-1 Gateway. This is a straightforward option. isn’t it?

Find the Active Edge Node of NSX-T Tier-0 gateway

Finding the Active edge of the NSX-T Tier-1 gateway is simple but it is not the case with finding the active edge node of the Tier-0 gateway. How do to find the active edge for the Tier-0 gateway in NSX-T? It is not straightforward. Let me explain the detailed step-by-step option to identify the active edge node.

In the Tier-0 gateways, It only shows the HA mode of the T0  gateway whether it is Active Active or Active-Standby but not the active or passive edge node.

Tip: We are in Policy View now. which is the default view of NSX-T Manager UI in NSX-T 3.x or later. We can identify the active edge node of the Tier-0 gateway in NSX-T Manager UI – Manager View.

Let’s find a way how to change the default view of the NSX-T Manager UI. To Change the Default Mode, go to System -> General Settings -> User Interface ->  Click Edit option in “User Interface Mode Toggle”

You can control Toggle visibility to a specific group of people like “Visible to users with Enterprise Admine role only or Visible to All Users”. The default option is “Hidden from All users”.

In my case, I have selected ” Visible only to Enterprise Admin role only”. Click Save.

Select the respective option for toggle visibility and click Save.

Now, we have set the toggle visibility to users with Enterprise Admin roles. Let’s log in with a user account with an enterprise admin role.

I have logged into the NSX-T manager with an admin account here. Now I have the view to toggle between Policy and Manager view in NSX-T UI.

Let’s identify the Active-standby edge node of the Tier-0 gateway. Click on Manager view. 

Under Networking -> Tier-0 Logical Routers -> Click the Active-Standby (link type) under High Availability Mode of particular Tier-0 Logical Routes.

In the NSX-T UI Manager View,   It now shows which the Active and Standby Edge nodes is the Tier-0 gateway. In my case, Edge-03 is Active node and edge-4 is the standby node.

That’s it. We have identified how to find the active edge node of the Tier-0 gateway in NSX-T 3. x. This is a simple post but really valuable when it comes to troubleshooting your NSX-T Tier-1/Tier-0 connectivity issues.

I hope this is informative for you. Thanks for reading. Be social and share it with social media, if you feel worth sharing it.

The post How to Identify the Active Edge Node of NSX-T Tier-0/Tier-1 Gateway appeared first on VMware Arena.

VMware vSphere also provides a mechanism to replace Self-signed certificates with custom CA-signed certificates as well for securing communications using signed certificates. In this article, I will explain detailed information about vCenter server certificates, how to check the certificate validity, replace with vCenter server self-signed certificate with custom CA-signed certificates.

How to find the expiration date of vCenter Server certificates?

You can check the vCenter server certificate expiry from various methods. Let’s check each method.

Check Cert validity from vCenter Server appliance SSH :

It is very important to understand the expiration date of your vCenter Server certificates. Run the below command to get the status of the environment’s certificates.

for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list | grep -v TRUSTED_ROOT_CRLS); do echo "[*] Store :" $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $store --text | grep -ie "Alias" -ie "Not After";done;

Check Cert validity from Web Browser:

When you open the vCenter Server URL in the web browser. You will receive a Certificate error if it is a Self-signed certificate. Click on View Certificate. This will show the Certificate’s validity.

If click on Certification details, it will show you the full certificate details including the issuer, Signature algorithm, valid from and to, etc.

Check Cert validity from vSphere Client:

Log in to the vCenter server using vSphere Client (HTML5 client) -> Click on Administration -> Certificate Management. This will list all the vCenter server certificates.

Replace vCenter Server Self-Signed Certificate with Custom CA signed Certificate

VMware products use certificates to encrypt session information sent over Secure Socket Layer (SSL) protocol connections between components.

vCenter Server and ESXi hosts come default by Self-Signed certificates. A self-signed SSL certificate is a digital certificate that’s not signed by a publicly trusted Certificate Authority (CA).

Self-signed certificates are considered different from traditional CA-signed certificates because they are created, issued, and signed by the company or developer who is responsible for the website or software associated with the certificate, rather than a CA. These default Self-Signed certificates are not signed by a commercial certificate authority (CA) and may not provide strong security. You can replace default vCenter Server certificates with certificates signed by an Internal Microsoft CA or Commercial CA.

We will take a look at the detailed procedure for the replacement of the vCenter Server Self-signed certificate with Microsoft Custom Certificate Authority includes the below summary of actions:

1. Create vCenter Server CSR request (Certificate Signing Request)

     1a. Generate vCenter CSR request from vSphere Client (UI)

     1b. Generate CSR from the vCenter server “Certificate Manager” command line via SSH.

2. Submit the vCenter Server Certificate request to the Certificate Authority (CA)

      2a. Submit Certificate Request to Root CA

      2b. Submit Certificate Request to Intermediate CA 

3. Prepare the Certificate Chain for vCenter Server Certificate Replacement

4. Upload the certificates to the vCenter Server.

5. Run the vCenter Certificate manager tool to import and replace Self-signed certs with Custom CA certs

1, How to Create vCenter Server CSR Request (Certificate Signing Request)

A certificate signing request (CSR) is one of the first steps towards getting your own SSL/TLS certificate. Generated on the same server you plan to install the certificate on, the CSR contains information (e.g., common name, organization, country) the Certificate Authority (CA) will use to create your certificate. It also contains the public key that will be included in your certificate and is signed with the corresponding private key.

A certificate signing request (also CSR or certification request) is a message sent from an applicant to a certificate authority of the public key infrastructure in order to apply for a digital identity certificate.

The CSR usually contains the public key for which the certificate should be issued, identifying information (such as a domain name) and a proof of authenticity including integrity protection (e.g., a digital signature).

There are two ways you can create CSR from the vCenter Server:

1a. Generate vCenter CSR request from vSphere Client (UI)
1b. Generate CSR from the vCenter server “Certificate Manager” command line via SSH.

1a. Generate vCenter CSR from vSphere Client (UI)

Log in with the vSphere Client to the vCenter Server using administrator@vsphere.locaI.
From the Home menu, select Administration. Under Certificates, click Certificate Management.

For the certificate that you want to replace, under Machine SSL Certificate, click Actions > Generate Certificate Signing Request (CSR).

Enter the below details to generate a CSR. Leave Common name and host as default. The common name and host are the fqdn of vCenter Server.

Specify the other details like organization, organization unit, country, state, locality, email address, and key size. Click Next

Click Copy to save the content of CSR in the file or click Download to download the CSR file of the vCenter Server.

If you download the file. The file will be in “.csr” format.

It looks like the.CSR was created successfully but the private key is not shown and don’t have the option to download the private key in the CSR step when you generate CSR from the vSphere client UI.

The private key is stored inside the VECS certificate store under the __MACHINE_CSR alias. It would have been better if VMware had shown the user a notification in the vSphere Client when a . CSR is generated. But No worries, I will explain how to get the Private key for the CSR request.

How do get a Private Key when generating CSR from vSphere Client?

To obtain the private key, log in to vCenter Server Appliance using SSH and run the below command:

/usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store MACHINE_SSL_CERT --alias __MACHINE_CSR > /path/filename.key

Copy this private key to a notepad file and save it as private.key. Now this file can be used while importing the validated certificate file into the vSphere Client.

1b. Generate vCenter Server CSR from Certificate Manager tool from CLI

To Generate CSR from the certificate manager tool. Login to vCenter Server Appliance via SSH and run the below command:

Choose option “1” – “Replace Machine SSL certificate with Custom Certificate.”

Again, choose option “1” – “Generate certificate signing request(s) and Key(s) for machine SSL Certificate.”

Specify the output directory path: /root/vc-certs. It can be any folder in the VCSA directory.

Provide the below parameters during the vCenter Server CSR generation:

vCenter server CSR File is generated and stored in the specified output location. In my case “/root/vc-certs”.

The default CSR file name is vmca_issue_csr.csr Along with the CSR file, a private key file is also generated and saved in the same location. The private key file name is “vmca_issues_key.key”.

The private key will be automatically generated when you generate CSR with the certificate manager tool in CLI.

Valid the CSR and private key file by browsing towards the specified output location.

2. How to submit a vCenter Certificate request to the Microsoft Certificate Authority (CA)

Digital certificates created by a Public Key Infrastructure (PKI) Certificate Authority (CA) are verified using a chain of trust. The trust anchor for the digital certificate is the Root Certificate Authority (CA), and any Certificate Authority (CA) that comes under Root Certificate Authority (Root CA) is known as a subordinate Certificate Authority (CA) or Intermediate Certificate Authority.

In this blog, we will discuss how to submit vCenter Server Certificate requests to both Microsoft ROOT CA and Microsoft Intermediate CA.

2a. Submit vCenter Certificate request to Microsoft ROOT CA

Download the CSR file (VMCA_Issued_CSR.CSR) with WinSCP and keep it saved in your desktop system to request a CA signed certificate for your vCenter server.

Login to http://CA/certsrv and click Request a Certificate

Click ” Submit an Advanced Certificate Request”

Open the CSR file “vmca_issue_csr.csr” and copy the full contents of the file.

Paste the contents of the .csr file and Select the “vCenter template” from the certificate template drop-down. In my case, I have cloned the web server template and created a new certificate template called the “vCenter template” in my CA. It won’t be present by default. In your case, you can select “Web Server” from the certificate template drop-down.

Click Submit.

Select Base 64 encoded and click Download Certificate.

If you open the downloaded certificate, you can check the Certificate Path/Chain, it shows the full certificate path DC-CA (Microsoft Certificate Authority) -> vc01.md.local (vCenter Server)

It is required to generate the custom CA certificate with a full chain. This is important as VCSA will import the customer root and intermediate CA certificate (If present) from the full chain. You can go back to the page in Microsoft Certificate Service page and select “Download a CA certificate (root certificate).”

I have saved the root-cert as “root-cert” in the local folder.

If you open the root certificate, it will show the certification path.

2b. How to Submit vCenter Certificate Request to Microsoft Intermediate Certificate Authority

In most organizations, Certificates will be issued by the intermediate Certificate Authority (CA) not directly from the ROOT CA. This is for security reasons.

Subordinate CAs – these live between the root and end entity certificates and their main purpose is to define and authorize the types of certificates that can be requested from the root CA.

We will also look at how to submit a CSR file to the Intermediate certification authority (CA) and generate CA signed certificate for the vCenter Server.

Login to your Microsoft Intermediate Certificate authority and run the command:

certreq -submit -attrib "CertificateTemplate:WebServer"

Select the vCenter Server CSR (.csr) file saved in the local folder and click open.

This triggers the Certification Authority window to open. Select the Certification Authority to use (In my case sv01-CA is my sub-ordinate CA server) and click OK.

The certificate Request has been successfully submitted to Intermediate CA and the Request ID is “7”

Open Certificate Authority MMC on your subordinate CA server. You can see the certificate request number “7” under “pending requests.”

Under the pending request, Right-click the certificate request number “7” -> All tasks -> click “Issue”

Once the certificate is issued by CA certificate request ID “7” will appear under “issued Certificates”.

Double-click the certificate in the “Issued Certificates”. It opens up the certificate and click “Copy to file” under details which in turn opens up the certificate export wizard. Click Next.

Specify the certificate file name. In my case “vc01.cert” and click Next.

Select the “Base-64 encoded X.509 (.CER) format” file format in the format list and click Next.

You will receive the popup ” The export was successful” and Click OK.

If you open the exported certificate “vc01.cer”, you can now see the full certificate chain which includes ROOT CA -> Subordinate CA -> vCenter Server.

It is also important that you need to export the certificate of root and subordinate CA using the same procedure as above. to export ROOT CA certificate. Click ROOT CA (DC-CA) and “View certificate”

Click Details. select “Copy to File” and export the certificate using the certificate export wizard.

Save generated VC CA certificate, ROOTCA, and Subordinate CA cert files.

3. Prepare the Certificate Chain for vCenter Server Certificate Replacement

During the import of the new vCenter certificate, you need to import the certificate chain with a single file. Therefore, the below steps are very important steps when you are using multiple CAs like Root CA and Intermediate CA.

Just to summarize, I have put down the table of what each file contains after this certificate chain file creation.

Follow the below steps in order:

• Open the exported subca.cer (intermediate certificate file) with notepad.
• Highlight and Copy everything in the open doc.
• Open the Rootca.cer file with Notepad and paste the information from the Intermediate.cer file to the bottom of the root.cer file.
• Save the Rootca.cer file but don’t close it.  Root.cer File should look like the below example.

-----BEGIN CERTIFICATE-----
ROOT CERTIFICATE
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
INTERMEDIATE CERTIFICATE (IF YOU HAVE ONE)
-----END CERTIFICATE-----

• Select and copy all text in the Root.cer
• Open the generated VC Machine Certificate “vc01.cert” file with Notepad.
• Paste the copied text from Root.cer file to the bottom of the doc
• You will now have the full chain and three certs embedded. VC Machine cert -> ROOT CA -> SUB CA
• Save the MachineCertificate file “vc01.cert“.  vc01.cert file Should be like the below example.

-----BEGIN CERTIFICATE-----
MACHINE CERTIFICATE (VCENTER CERTIFICATE)
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
ROOT CERTIFICATE
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
INTERMEDIATE CERTIFICATE (IF YOU HAVE ONE)
-----END CERTIFICATE-----

4. Upload the certificates to the vCenter Server.

Once all the certification chains and files are updated as mentioned in the above steps. Now copy the below 3 highlighted files to the vCenter server appliance via WinSCP.

• rootca.cer (Contains chain of contents of rootCA and Subordinate CA)
• vc01.cer (contains the full chain of contents of machine certificate, rootCA, and subordinate CA)
• vc01.key (private key generated during CSR request)

5. Run the vCenter Certificate manager tool to import and replace Self-signed certs with Custom CA Certificates

I have copied the above-mentioned 3 files to the directory “/root/finalcerts” in the vCenter server appliance.

To import the new CA signed certificate from the certificate manager tool. Login to vCenter Server Appliance via SSH and run the below command:

Choose option “1” – “Replace Machine SSL certificate with Custom Certificate.”

Then, choose option “2” – “Import Custom Certificate (s) and key(s) to replace existing Machine SSL Certificate.”

Specify the location of the Machine certificate, key file, and signing certificate as below:

Hit enter and Type “Y” to proceed to replace the Machine SSL certificate with the Custom CA certificate

Services will be updated with the new custom certificate, therefore the vCenter server services will be restarted.

This process will restart all the vCenter Services. You can notice that “100% completed [All tasks completed successfully)

After the vCenter Server Self Signed Certificates (SSL) certificates are replaced with Custom CA signed certificates, try to access the vCenter Server using the Web browser. You no longer see the Certificate error in the browser. You can see the Lock symbol which is nothing but a secure site.

Click on the Certificate and check the certification path. you will see a full chain of vCenter server certificates.

You can also validate the same after login to the vCenter server and Certificate Management page.

That’s it. We have gone through the detailed procedure to replace the vCenter Server self-signed certificate with a Custom CA-signed certificate. I hope this is informative for you. Thanks for Reading. be social and share it with social media, if you feel worth sharing it.

The post Master Guide – vCenter Server Certificate Replacement with Custom CA appeared first on VMware Arena.

BDRSuite is the most cost-effective and comprehensive backup & disaster recovery software designed to protect data across virtual (VMware, Hyper-V, KVM), Server (Windows, Linux, FileShare/NAS), Endpoints (Windows, Linux, Mac), Cloud (AWS, Azure), SaaS (Microsoft 365, Google Workspace) and Applications & Databases (Microsoft Exchange Server, SQL Server, SharePoint and MySQL).

Vembu Backup is will be releasing BDRSuite 7.0.0 Release candidate (RC) soon for general availability. BDRSuite 7.0.0 will be soon releasing with great features. We will take a look at what’s included in BDRSuite 7.0.0 Release candidate(RC) in this article.

Key features and components of Vembu BDRSuite v7.0.0:

KVM Backup and Recovery

BDRSuite now offers agentless backup for KVM virtual machines through seamless integration with KVM Hypervisor. It also includes changed block tracking, automated scheduling, flexible recovery options, and wide backup storage target compatibility.

Agentless Backup & Recovery of KVM VMs through seamless KVM Hypervisor Integration. BDRSuite Provides below features:

BDRSuite offers agentless backup for Azure virtual machines using Azure Native APIs. It also includes incremental backups, automated scheduling, flexible recovery options, and wide backup storage target compatibility.

Native Agentless Backup & Recovery for Microsoft Azure Virtual Machines provides below features:

• Agentless backups for Azure virtual machines
• Incremental backups to efficiently backup only changed blocks
• Application-aware backups & Pre/Post Scripts
• Store backups locally or on cloud storage – Azure Blob, S3, Google Cloud, Wasabi, etc
• Customizable backup policies include scheduling, retention & more
• Flexible restore options include entire VM, file recovery, etc
• Cross Subscription Restore
• Automated snapshots & retain them to launch VMs instantly
• Built-in encryption & compression for backups

AWS Backup and Recovery

In the previous version, configuring and scheduling automated snapshots of EC2 instances was supported for backups. This release brings the added capability of configuring backups to be stored locally or in the cloud, alongside support for multiple recovery options.  Most Cost-Effective AWS Backup & Recovery Solution for EC2 Instances provides below features:

• Agentless backups for Amazon EC2 Instances
• Incremental backups to efficiently backup only changed blocks
• Application-aware backups & Pre/Post Scripts
• Store backups locally or on cloud storage – S3, Azure Blob, Google Cloud, Wasabi, etc
• Customizable backup policies include scheduling, retention & more
• Flexible restore options include entire EC2 Instance, Volume recovery, etc
• Schedule & manage automated snapshots
• Built-in encryption & compression for backup data

The post BDRSuite – v7.0.0 Release Candidate – Backup KVM, Azure VM, Amazon EC2 and more appeared first on VMware Arena.