Changing IPs and FQDN in a DataProtector environment

A few month ago I wrote an article on how to upgrade from 32bit DP cell manager to 64bit cell manager. This article required keeping FQDN and IP address of the CM.

Sometime, perhaps because of an update to your network/DNS infrastructure, you'll have to change IP address or even FQDN on the CM and all your clients. Since DP is really dependent on DNS resolution this can be a bit tricky to handle. I found several articles on the net that describe most scenarios but nothing like this.
To help you migrate without problems, this article will be your step-by-step guide.

So, assume your current config looks like this:

CM DNS name is cm-old.demo.lab. It doesn't matter if the host is a member of an Active Directory or not, you only have to take care that the host can resolve itself, all imported clients and vice versa via their FQDN names.

In our demo environemnt we have a single cell manager (that is installation server at the same time) and a single client imported to the cell. The CM is Windows-based but it could also be *nix based. You then have to translate the commands below to their *nix pendants.

Installation of DP is v6.2 (you can also use other versions, in the DP world there are nearly no changes in config behavior since 5.x) and all files are located under c:\Programme\Omniback. It's a german OS but you can also get the install directory at c:\Program Files\Omniback (it's just a symbolic link). I also use to put all DP files in the same directory and do not split data files and config files to separate directories. If you do so (and this is the default setting during DP installation), you will find the config directory at c:\ProgramData\Omniback\Config.

We have a single client (dpclient.demo.lab) and a simple file library (B2D) with a single virtual tape drive called B2D_Writer0.


We have two backup jobs for the dpclient system, one simple file backup, one VSS enabled job. Both are configured to use the B2D device and have a schedule to run once per week on different days.

backup jobs

That's what our demo environment looks like. Testing the backup jobs once before we change anything is mandatory to see if everything works as expected. You should always do so in production environments.

Let's go to define what we exactly want to do. Assuming you have to redesign your network for all servers/clients and also want to move to a new AD infrastructure. This will cause a name and IP change of your CM and all your client server systems. Obviously, this will tear down your backup infrastructure. Only changing your IP address space wouldn't be problematic. Simply update your DNS and make sure to open all neccessary ports on firewalls and your DP backup environment will keep on working. But what to do if you also change the FQDN? Even if you allow to resolve to the old FQDNs after updating, this will probably work for backups but restores don't like these kind of cheating.

So you have to clean up your DP installation after the changes. And here is what you have to do:

Get a full backup of all your systems BEFORE you change anything. Test restores to make sure you can use the backups for recovery.

Disable all schedules for all backup jobs. You can do this by moving all files from the C:\Program Files\Omniback\Config\Server\*schedules* folders to a different location

Make a consistency check of your database by running "omnidbcheck -extended"

Stop all DP services and copy the whole C:\Program Files\Omniback folder to a backup location. If you have split binaries and config files then also copy C:\ProgramData\Omniback to the backup folder.

Start with changing IP and FQDN on the CM. In our case I change the name to cm-new.demo2.lab and IP to Restart the server.

Logon to the rebooted server and change to folder C:\Program Files\Omniback\Config\Server\Cell

Open file "cell_info" in notepad and change the line containing your cell server to the new values.

cell info old

cell info new

Leave all client systems untouched for the moment. Save and close the file.

Make the same changes in the file "installation_servers" in the same folder, assumed this CM is installation server at the same time. (This is default setting if you install DP on a Windows host)

Move to folder C:\Program Files\Omniback\Config\Server\users and edit file "userlist". Change the name for the CM as shown below

userlist old

userlist new

This will allow your local administrator user to get access to the DP GUI. Later, you can allow/change other users via the GUI. This is easier, so for the moment only change entries for the local administrator account.

Save and close the file.

Open registry editor and move to key [HKLM\SOFTWARE\Hewlett-Packard\OpenView\OmniBackII\Site and change CellServer entry to reflect new FQDN

reg old

reg new

Change ownership of the CM database to the new server. This is done by opening a command shell, change to folder C:\Program Files\Omniback\bin and run the command "omnidbutil -change_cell_name". Press y to confirm.

change cell

Check to see if the name change was done correctly with the command "omnidbutil -show_cell_name". It should print out the new name of the CM.

new cell name

Open DP GUI and check if you can log on. Then change to "Clients" and check if CM and IS are shown correctly. If you get any error like "no permission", "database belongs to other cell" or the names are not shown correctly, repeat the steps above. You probably missed something.

If everything is correct, your DP GUI should now look like this:

new cell gui

You can see, the new name for the CM and the IS is now reflected in the GUI but still the old FQDN for the client exists. And if you go to the Devices&Media section, you will see, that the file library still belongs to cell "cm-old.demo.lab".

old devices

You cannot change the client system of a device in the GUI. The "omnidbutil -change_cell_name" command pretends to change the owner of the devices and pools too but it doesn't work for the client system. You have to manually change the client system on the command line. That's what we do next.

Open a command shell, goto C:\Program Files\Omniback\bin and enter "omnidownload -library NameOfLibrary -file c:\temp\library.txt". In our case the name of the library is "B2D". Fire up the command and goto the c:\temp folder. Open the newly created file library.txt. Change the line starting with "HOST cm-old.demo.lab" to "HOST cm-new.demo2.lab" or whatever your new FQDN is and save the file.

Now we have extracted and changed the settings for the library, but we also have drives inside the library that still belong to the old CM. So let's extract the info of the drives with the command "omnidownload -device NameOfDevice -file c:\temp\deviceX.txt". In our case we only have a single device called B2D_Writer0 but you can also have many other drives that you need to configure. Do the last step for every single device/drive you have in use. Save the config in different text files.

Now open each of them and edit the "HOST" line to your needs. Save the files, we will now import them back into the CM database.

Use the command "omniupload -modify_library NameOfLibrary -file c:\temp\library.txt" to upload library information and the "omniupload -modify_device NameOfDevice -file c:\temp\deviceX.txt" commadn for every single device.

Restart your DP GUI and check if your updates are successfully imported into the database. It should now look like:

new devices

This was the last step for the CM, let's switch over to the client systems.....

Goto the Clients section.

The first step is to move the clients to the new IP range and the new domain. Make sure you have flawless DNS resolution, forward and reverse for the new FQDNs.

Then we have to remove the clients from the internal database but without deleting the DP software on the systems. To do that, mark the clients and choose "Delete" from the context menu. You will be asked if you want to delete the client software too. Deny this, simple remove the client from the cell. Accept all error messages, this is normal. Your clients are now removed from the cell. All backup definitions are still there, there is no automatism that deletes them if you dlete the client. That's good, it will spare us to recreate the backup jobs later.

For each client you want to re-add to the cell do the following:

goto your system via RDP or console or SSH if you have *nix systems. Logon as adminstrator/root.

For Windows: open regedit, goto [HKLM\SOFTWARE\Hewlett-Packard\OpenView\OmniBackII\Site and change CellServer entry to the new FQDN of the CM. Restart the "DataProtector Inet" service.

For *nix: edit file /etc/opt/omni/server/cell/cell_server and change hostname to match new CM. You don't have to restart any service.

Goto CM -> DP GUI -> Clients, right-click "Clients" in the left navbar and choose "Import client". Add every client you want to re-add with its new FQDN to the list and click "Finish". All your clients should now be imported to the new cell.

The last step is to change the backup specifications and schedules so you don't have to recreate them manually.

Therefore, open Windows explorer on the CM, goto C:\Program Files\Omniback\Config\Server\. In the folder "Barlists" and it's subfolders you will find all specifications for non-filesystem backup jobs. In the folder "Datalists" you will find all filesystems specs.

Rename the textfiles (if they reflect the client name) one after the other, change the first line (starts with "DATALIST") to match the new name of the spec and change all entries containing the old FQDN of the system to match the new FQDN. Here is an example from the demo lab.

old filelist


new filelist

Repeat this for every backup spec you want to re-use in your new CM.

Well, okay, a lot of work to do but believe me, the more specs you had the more time this procedure will save you in comparision with rebuild them from scratch.

Last but not least, we have to do -nearly- the same for the schedules. DP manages the schedules in separate files. The backup spec and the schedule are combined by their name so if you changed the name of the backup spec in the last step, you have to do the same for the schedule files.

You can find them in C:\Program Files\Omniback\Config\Server\Barschedules and subfolders for the non-filesystem jobs and in C:\Program Files\Omniback\Config\Server\Schedules for filesystem jobs. Name them exactly the same as you did for the backup specs and you're done.

Steps you should do after these changes:

  • check your environment really carefull
  • since your IP address of the CM has changed, your former licenses for DP are invalid. They are bound to the old IP address of the CM. To resolve this problem you have two options. First option is easy: goto HP license portal, "rehost" your licenses to the new CM's IP and add them as new licenses. After that, you should delete the old licenses from the file C:\Program Files\Omniback\Config\Server\cell\lic.dat. It's a simple text file that you can edit any delete the lines containing the old license keys.
    Sometimes you don't have time to do so or even lost your corresponding HP passport account, then there is option 2. You can add the CM's old IP as additional IP address to the new CM. It doesn't matter if you use the IP for anything or just as a dummy address but the license will be valid again. I would never recommend option 2 as this is probably against the HP license agreement but I also know the slow responsiveness from HP if you have to wait for them for granting you access to your license portal.
  • make test backups and restores for all your jobs
  • check the transferred specs and schedules carefully in the DP GUI
  • if you also use Copy&Consolidation jobs, since the name of the backup specs probably changed, reconfigure these jobs to use the new backup specs.

That's all. I hope, I can give you some help at hand if you ever need to move a DP installation to new IPs and/or DNS.



Add comment

Security code