Re-IPing Networker servers

Re-IPing the NW server also is likely to invalidate your current NW server license, depending on what and you have setup the NW server. As the name and IP as shown for example in nsrwatch, is what is used for the license. If that IP does not change, then the license remains valid. In our case we always made sure that the interface that is facing towards the clients is the one that is used for the license and NW server name. So if that changes, then you need a new NW license.

Beware that re-IPing by itself might not be a biggy, depending on you having DNS for example and not host file based resolving? Changing the hostname of a NW server however is no longer supported from NW9 onwards. Very likely due to the name being used all over the place in various config files and settings and auth service for example. So don't touch the NW server name as stated in nsrwatch or as stated in the NSR resource when querying with nsradmin looking at the "name" attribute of the NW server.

Vproxy and NW storage node re-IPing we've had to be performed regularly already. That might not to be a problem either, assuming you still would have access for example through vmware or remote console, just in case...

We have taken the approach to have not one but two vproxies deployed per esxi cluster, so to have some leeway to perform activities like upgrades (or rather redeployment as a vproxy cannot be updated) or when having issues, that you still have another vproxy, with the intention that that might make life easier along the road... For the vproxy bases backups we then use "auto proxy selection" so that NW will use anyone of the two vproxies and based on the load and amount of simultaneous running sessions both at the same time.

For a vproxy to change the network config, you can use the cli instead of needing to fiddle around with config files. See KB https://www.dell.com/support/kbdoc/en-us/000157759/nvp-vproxy-how-to-manually-change-the-vproxy-appliance-network-interface-settings.

1) Open a SSH session to the vProxy appliance and authenticate with the admin account.
Note:
If vProxy cannot be reached over SSH, launch a web console connection the vProxy from the vSphere web client.
2) Switch users to root

sudo su -

3) Run the config_network.sh script to update the interface settings replacing the parameters with your host/network info:
/opt/emc/vproxy/bin/config_network.sh

Additionally we are on Networker 19.7.0.1 with vproxies 4.3.0-34 and there is a newer version although it says networker 19.7.0.3 vproxy 4.3.0-39. Is there any benefit to simply upgrading these?

vproxy ova's are always released with a specific nw version, however not limited to it. luckily there is a wide range of nw19.x versions all supporting the 4.3.0-x vproxy versions, so you can then always use the latest and greatest if Dell releases yet another DSA (security advisory) if you are running a supported nw19.x version.

That is what the Dell elab navigator is for. For NW that is https://elabnavigator.dell.com/eln/modernHomeAutomatedTiles?page=NetWorker and the latest "NETWORKER 19.7 ALL MODULES & FEATURES Simple Support Matrix April 17, 2023" for nw19.7 https://elabnavigator.dell.com/vault/pdf/NW_All_19_7.pdf stating supported nw vproxies in table "NetWorker NVP (Proxy) Compatibility Matrix" only stating vproxy 4.3.0-x to be supported.

higher vproxy versions are mainly CVE bugfixes more often than actual functional improvements. I can only recall one recent improvement where one can state the syslog server to centrally collect vproxy logs from a certain vproxy version onwards. Almost all other new releases were for security bugfixes.

Also there is no vproxy upgrade method. NW offers kinda redeploy, which powers down and renames the old vproxy in the VC registry and then deploys using the new OVA that is put on the NW server pushing it over port 443 towards the same esxi hosts that the original vproxy was currently deployed on. Newer nw versions also offer the OVA to be put within the VC infrastructure to be deployed from there instead of from the NW server end.

So if you have two on each esxi cluster, than you could "upgrade" one, using CLI or NWUI, see if it works and then do the other one(s) at a later time.

Thank you I successfully re-ip the vProxy. I learned that one does not simply re-ip a vProxy, you have to first disable and delete it from Networker and then re-register after it has the new IP.  I think they should have included that to the KB article.

Anyway, on to re-IP'ing the storage nodes please let me know if anyone has any insight into those. Thank you!!

How was the vproxy added to NW initially? With its fqdn I assume, not by IP? I can't recall that disabling, deletion and the re-addition of a vproxy would have been required to change the vproxy IP?

Then again not running yet ourselves with 19.7.0.1 with vproxies 4.3.0-34 or up, so there might be slight differences their wrg to their workings?

Via nsradmin CLI one also has the option to (un)register a vproxy: https://www.dell.com/support/kbdoc/en-us/000156072 "NVP vProxy: How To Unregister/Re-Register a vProxy Appliance?". That is an option one can use for example when needing to redeploy a vproxy as it would then have a wrong certificate within NW. We also ran into that when trying a new vproxy version, while also having the old deployed as well for back-out. So to be bale to switch to the new vproxy, one would have to unregister the old one and then register the new one. So that would not even require deleting the vproxy entry (which in effect would also lead to the same thing, getting the appropriate certificate from the vproxy in question).