networker, problem marking backup-type RCT-based in interface

You might have to state a bit more than that to get an idea what you have and are trying to achieve?

So for example stating the windows version of the hyper-v cluster nodes and the NW and NMM version being used on the clients (hyper-v nodes)? And the NW server version?

I assume you run into the issue when using the NW "Client Backup Configuration" wizard?

Is the hyper-V cluster windows 2016 or up? As only from that version onwards RCT is supported?
From NW19.5 NMM manual:
"NMM supports RCT-based backup, recovery, and granular recovery of Hyper-V virtual machines that run on the Hyper-V role that is installed on Windows Server 2016 and 2019, and on Server Core installations for Windows Server 2016 and 2019."

You are trying to define the client, using the hyper-v cluster name to be able to setup federated backup?

So you are not seeing the options like the NetWorker_Module_for_Microsoft_19.5_Hyper-V_User_Guide shows? So having filled in the remote username and its password? Does it populate the Available Servers list to be able to setup the proxy servers for the (optional) Preferred Server Order List (PSOL)?

Are prereqs fulfilled?

Prerequisites
Before you use the wizard, review the following requirements:
● Ensure that the NetWorker server host is listed in the servers file on the client computer.
● Ensure that the communication between the NMC server, NetWorker client, and NetWorker server uses nsrauth strong authentication.
● Ensure that the user who runs the wizard meets the following requirements:
○ Root (UNIX) or Administrator (Windows) privileges.
○ A member of a User Group on the NetWorker server that has Configure NetWorker privileges.
● Ensure that multiple wizard hosts are not trying to access the same client computer simultaneously.

version networker 19.8  

modulos 19.8 

HYPER-V: 6 nodes

Versão Virtualizador:  10.0.22621.1

Versão do Windows: Windows Server 2022

With "Versão Virtualizador: 10.0.22621.1" you mean the hyper-v version, so is that hyper-v on windows 2022 or what windows version is that?

So on all hyper-v nodes NW19.8 and NW NMM 19.8 are installed and you are using a NW backup server running NW19.8 as well?

Did you even verify if that is even supported for hyper-v backups, even with the latest nw19.8?

As the Dell elab navigator for nw19.8 does not state win 2022 to be supported NetWorker Module For Microsoft Hyper-V? It only states win 2012, 2012R2, 2016, 2019 and Azure stack HCI (21H2)?

https://elabnavigator.dell.com/vault/pdf/NW_All_19_8.pdf?key=1675352105406

Where the prereqs I mentioned earlier also all met?

Hi, Barry. Thanks for your help.

The hyper-v version as well as the Windows servers versions are indeed 2022. 

I saw at e-lab navigator that 2022 is supported for servers, but you are right, it is not lister for hyper-v. As the sales people had already sold the solution, I had to install it anyway, and to be honest, I did not expect that the latest Networker version could not work with Win 2022 hyper-v.

I followed the installation guide, with the pre-requisites. What is happening is that the RCT is not allowed to be chosen during client configuration and the Proxy nodes (physical Hyper-V nodes) are not identified. So, all save sets (VMs) are saved with level FULL every time the workflow runs. I am not being able to identify where I am missing the point here. I think privileges where set locally at the nodes but Networker are not being capable of seing hyper-v cluster configuration correctly. 

If you could help further in any way I would appreciate a lot.

What nw19.8 version are you using? the initial version (Dec 2022) or nw19.8.0.1 released in Feb?

You didn't mention anything, but I assume you intend to backup towards Datadomain using ddboost?

Is there a difference when specifying the user as \user, as the example showed instead of user@domain? Then again, the nw19.8 nmm for hyper-v manual also shows that both RCT as well as VSS option should be selectable, unless it actually verifies the cluster client connected to not be valid for RTC backups as win 2022 is not supported (but the same would also apply to VSS)?

For that you might have to reach out to Dell creating a service request, asking if RTC is even possible - even though maybe unsupported. But as always there is a difference between unsupported and simply not working.

Where do you assume from that also the VSS based hyper-v backups are always running a full?

This as NW is using always will report them to be a full (as it will create a synthetic full backup), just like for BBB (block based backups) of windows or linux clients or for its vmware image level backups. All reported as full backups.

https://www.dell.com/support/kbdoc/en-us/000157590?lang=en

"Deployment KB: NetWorker: How to verify Hyper-V incremental RCT backups in Networker Module for Microsoft.

Summary: Deployment KB: How to verify Hyper-V incremental RCT backups in Networker Module for Microsoft. Networker Management Console and commands always report backup level as full even though the VM backup level is set to incremental RCT or VSS based. This is an expected behavior as it creates a synthetic full however there may be a need to verify that incremental backups are being performed."

The KB article shows some example showing that when you verify ssid's with the mminfo -S option, that it then would show INCR backups being made, which for VVS backups would be something like:

   *BBB LEVEL STR: INCR;
                 *BBB_LEVEL: 1;

Or in the logs:

Example: VSS incremental
158036 1586417070 0 0 0 5220 4364 0 hyperv01.demo.local nsrnmmsv NSR info 55 Enabling Incremental Flag for VMs selected for backup.  0
143920 1586417070 0 0 0 5220 4364 0 hyperv01.demo.local nsrnmmsv NSR info 41 Adding saveset %s to Incremental backup.  1 0 12 Windows 2016
138665 1586417070 0 0 0 5220 4364 0 hyperv01.demo.local nsrnmmsv NSR info 49 Pre-snapshot processing completed for %s manager. 1 0 16 MICROSOFT_HYPERV
158036 1586417070 0 0 0 5220 4364 0 hyperv01.demo.local nsrnmmsv NSR info 55 Enabling Incremental Flag for VMs selected for backup.  0
134349 1586417070 0 0 0 5220 4364 0 hyperv01.demo.local nsrnmmsv NSR info 71 Performing an application incremental backup for the Hyper-V save sets. 0
127164 1586417070 0 0 0 5220 4364 0 hyperv01.demo.local nsrnmmsv NSR info 60 Perform a VSS Incremental backup for %s application manager. 1 0 16 MICROSOFT_HYPERV
114497 1586417070 0 0 0 5220 4364 0 hyperv01.demo.local nsrnmmsv NSR info 35 VSS Backup type set to INCREMENTAL. 0
130360 1586417090 0 0 0 6792 4364 0 hyperv01.demo.local nsrnmmsv NSR info 38 Selected backup device is Data Domain. 0
178090 1586417090 0 0 0 6792 4364 0 hyperv01.demo.local nsrnmmsv NSR info 47 Performing incremental backup using VSS method. 0
130360 1586417090 0 0 0 5312 4364 0 hyperv01.demo.local nsrnmmsv NSR info 38 Selected backup device is Data Domain. 0

Hi, Barry.
Thanks again fo your time and help.
The sub-version used for Networker Server, client, NMM and NMM are all 19.8.01
And you are right, we are saving to DDomain using DDBOOST.
The intention later is install a storage node in another Hyper-V cluster with 2 nodes located in another site. There we intend to save to a local ADVFS device (a CIFS NAS created in a Unity), and clone some of those backups to the DD in the primary site.

You gave me a good tip, we did not test so far replacing user@domain with \user in the "federated backup options" field.
As we are not returning to the customer until next monday, I will ask the customer to make this change to see what happens.

"This as NW is using always will report them to be a full (as it will create a synthetic full backup), just like for BBB (block based backups) of windows or linux clients or for its vmware image level backups. All reported as full backups."
You are correct. I read it some time ago in the docs, but completely forgot this. So maybe the backups are in fact incremental, but are merged to the first real full backup inside Networker/DataDomain...
We also fixed yesterday a issue in DNS, which was directing the DD name to the 1Gb management port instead of the 10Gb port already used for data. This may influence in peerformance too..

Thank you again. We will see if changing federated credentials solves the issue.

nw19.8.0.1 is bleeding edge. We tend to be way more conservative wrg to the NW version we use. There have been way too many grave issues with the latest and greatest.

you can always try a somewhat lower NW and NMM module version on the clients, but as said win 2022 hyper-v  is officially not (yet?) supported, so a lower version is possibly even less likely to work...

I don't know if there is actual build-in validation of the windows version (which shouldn't be too hard to implement) in the NW client wizard, that prevents you from even selecting RCT? Did it not mention anything in one of the previous screens about support when entering the hyper-v cluster node client and connecting to it?

So instead of using the nw client wizard you can also try to configure the client definition manually? As then you'd be setting the option to use RCT yourself, without further possible validation of the involved hyper-v windows version, specifying the required settings in the application information field with NSR_RCT_BACKUP and NSR_FEDERATED_BACKUP set to yes for example.

Maybe that might be able to start even, but might still fail as it might not be able to handle hyper-v win 2022...

https://www.dell.com/support/manuals/en-us/networker-module-for-microsoft/nw_p_nmm_hyperv_guide_19.8/manually-creating-a-client-resource-for-an-rct-based-backup-by-using-the-client-properties-dialog-box?guid=guid-a8259d27-e79c-4d89-947b-b53cab6ab6c8&lang=en-us

Yes this issue has been reported with Windows 2022 and will be fixed . As a workaround just manully update NSR_RCT_BACKUP=yes in the client properties and manually add NSR_FEDERATED_PSOL =nodeA,nodeB...

good morning,.
thanks..
I will put the parameters..
I return
thanks