Networker issues after change to another domain

Let me guess - you most likely also changed the IP address.

It seems as if you have a license issue. Delete the /nsr/logs/damon.raw file and restart the services manually. The new file will tell you exactly where the problem is.

is the NW server renamed as well? From NW9 onwards changing the NW server name is no longer supported (I assume as the NW server name is now mentioned in way more config files and things like the authc service).

So if the NW server has a different FQDN, it now might no longer match its earlier configuration, as still might be even set in its own NSRLA configuration as it would contain the hostname of the NW server at the time NW started for the very first time after being started. In the deamon.log it might mention maybe not being able to resolve this name and as a result will not be able to start the NW services.

The thing is you might wanna have the old NW server name references removed, but that might not even be possible, as a NW server rename is not supported (some have done this regardless by manually modifying files here and there, but you might run into issue further on and it is not supported, hence you might be on your own).

Something similar can happen on a NW client, whenever the hostname changes, while the old name is no longer resolvable. Then the NW services will no longer start. On a client however this can be solved by deleting the files underneath nsrla directory (after first having shut down the NW client services). After a NW restart it would then recreate the nsrlad contents and fill it with the hostname of the client and create a new nsr peer certificate (which then would have to be deleted on the NW server, so that when client and server talk, the new nsr peer info will be used and saved on the nw server).

However that cannot be simply be done on a NW server as well...

So if indeed NW services do not start as there is still a nsrla reference to the old name, you might wanna play with this with a fake IP address in its host file.

I however don't like such approach, so more neat would be having a new backup server. However that will come at a lot of reconfiguration.

And yes, that is stupid and something Dell (EMC at the time) should have noticed when introducing NW9 at the time, but they simply ignored that option being able to rename a backup server. So when it is needed to rename a nw server, then you'd have to see and think what you would be changing or even removing, so that it still might work after the rename. Adding aliases is often no problem, however removing things might, especially in case of the hostname if uses a FQDN for that (which we prefer and not to have/use the shortname). As also the license is linked to hostname and IP address nowadays, certain changes might invalidate the license, which would require Dell to create a new one. However for an IP address, that isn't to complex as that is at least supported, it would only invalidate the current license. However if the NW server name changes, then that is not supported at all.

How a NW server name is actually determined, is something you can control. NW first gets its shortname. It then tries to see what this shortname resolves to. We always control this in the hosts file, by setting the FQDN we want the NW server to be running as, by putting that FQDN name in front of the shortname in the hosts file.

1.1.1.1 nwserver.backupdomain nwserver

2.2.2.2 nwserver-mgt

3.3.3.3 nwserver.frontend.com

In above example the NW server will be called nwserver.backupdomain, using IP 1.1.1.1.

1.1.1.1 nwserver.backupdomain

2.2.2.2 nwserver-mgt

3.3.3.3 nwserver.frontend.com nwserver

In above it will be called nwserver.frontend.com with IP 3.3.3.3

1.1.1.1 nwserver.backupdomain

2.2.2.2 nwserver nwserver-mgt

3.3.3.3 nwserver.frontend.com

Now it will be called nwserver as it is the first entry, so will get IP 2.2.2.2.

We recently performed a migration to a new domain. We had to install a new NW server/nmc onto the target domain and migrate the DataDomains and StorageNodes and read in all the DataDomain savesets info to the new server. This had to be performed by Dell professional services at a charge.

Changing FQDN of a NetWorker server is not supported as that information is in the NetWorker server database.

You chose to have it done by Dell professional services and therefor had to pay them. It is not required to have it done by them however, as they also would "simply" use scanner to scan in the savesets on the ddboost devices.

Anything else they did for you along the way?

The new Networker volume move tool (introduced with nw19.3 or so) is not specifically meant for that as in your case one would want to make all data available, as it does not support the move of NW backup server nor storage node backup data (if I recall correctly). Hence scanning in all ddboost volumes would need to be done, repopulating the NW media DB and also to restore all client indices.

Also all client backup definitions need to be setup again (devices/pools/policies/workflows/backup+clone actions), which would be rather cumbersome to do, depending on how large your environment is, even when using some own scripting to do so... still there is no simple approach yet, to have the whole backup configurations migrated to another NW backup server.

I don't know of any intention yet from Dell to make a NW server rename possible, nor to be able to easier migrate backup configurations from one nw server to the other. I'll reach out to Dell, when we have another of their roadmap presentations about this.