We recently moved Commvault/Commcell to a new server (same domain) because the old one did not have enough place on it for the disks backups.
We had it installed on a server named SPGEOFS01
We moved it (the technician) on new server called SVGEOCVCS
Now, the name on the new client still is SPGEOFS01
I want to add the old Commvault server that still exists and was wiped to host data (SPGEOFS01)
But I get conflicts since the name has not changed to SVGEOCVCS everywhere and it tells me that the client already exists.
Did our technician do something wrong during the switch ? How can I fix this ? He says it can be days before he finds a solution.
Thank you for your help,
Felix
Best answer by Jos Meijer
Hi Felix,
I have performed a CSrecovery in the lab and encountered the same name difference:
Tried changing it via the GUI, no luck.
I found a possible solution in the SQL database, but I strongly advice to contact support and ask if this change is allowed/supported and that this change can be made without impacting production. During this short time frame I only identified the value and have not tested the complete functionality chain which might be related to this value. So again please contact support to validate. If not, this is on your own risk as you will be manipulating the database without developments assistance.
Side note: Change the client names and ID’s I used for your own client names and ID’s, do not plain copy paste as your environment is different from mine.
Database: CommServ
Table: dbo.APP_Client
Identify the Client ID:
SELECT [id]
,[name]
,[csHostName]
,[displayName]
FROM [CommServ].[dbo].[APP_Client]
WHERE [name]='COMMSERVE'
Result:
Update the client name for client id 2:
UPDATE [CommServ].[dbo].[APP_Client]
SET [name]='WIN2022CS'WHERE [id]='2'
Result:
Result in GUI after refresh client list:
Tested on 11.28.15
Hope this helps 🙂
P.s. before the name change in the DB I tried to create a client with the same name and this did not result in an error. The client was created without issues. Looking at why, the client name is automatically provided with a follow up nr when the entered name is already in use. So in this case I had client name COMMSERVE, the newly created client had client name COMMSERVE_1.
This functionality is also in place in 11.24.43 so the issue you are describing normally shouldn’t be an issue… you should be able to install a new client with the old commserve name.
Looking at unique identifiers for clients, this by default is the client hostname only. So the hostname should be the only error generating value if a duplicate is encountered, unless you use the additional setting nAllowDuplicateHostName then this limitation is ignored.
@Mike Struening , thank you for taking the time to read my question !
What I was told from the tech is that when we received our new server, he installed the OS (windows server 2022) and then the Commvault application. He then told me he moved everything from one to the other as to keep the policies in places, indexes etc.
Sorry if I lack some information, I will make sure to contact him today to ask more details. I tried to look in the automaticInstall logs and found this :
I think you are talking about a name conflict with the commserve client.
In the control panel you can go to name management and select the option to change the commserve display name, enter the new name SVGEOCVCS. When finished restart the Java GUI
@Jos Meijer Hi Jos, Yes this action was done ! As you can see in my first post, the image shows that the display name is SVGEOCVCS, but the name is still SPGEOFS01.
I have performed a CSrecovery in the lab and encountered the same name difference:
Tried changing it via the GUI, no luck.
I found a possible solution in the SQL database, but I strongly advice to contact support and ask if this change is allowed/supported and that this change can be made without impacting production. During this short time frame I only identified the value and have not tested the complete functionality chain which might be related to this value. So again please contact support to validate. If not, this is on your own risk as you will be manipulating the database without developments assistance.
Side note: Change the client names and ID’s I used for your own client names and ID’s, do not plain copy paste as your environment is different from mine.
Database: CommServ
Table: dbo.APP_Client
Identify the Client ID:
SELECT [id]
,[name]
,[csHostName]
,[displayName]
FROM [CommServ].[dbo].[APP_Client]
WHERE [name]='COMMSERVE'
Result:
Update the client name for client id 2:
UPDATE [CommServ].[dbo].[APP_Client]
SET [name]='WIN2022CS'WHERE [id]='2'
Result:
Result in GUI after refresh client list:
Tested on 11.28.15
Hope this helps 🙂
P.s. before the name change in the DB I tried to create a client with the same name and this did not result in an error. The client was created without issues. Looking at why, the client name is automatically provided with a follow up nr when the entered name is already in use. So in this case I had client name COMMSERVE, the newly created client had client name COMMSERVE_1.
This functionality is also in place in 11.24.43 so the issue you are describing normally shouldn’t be an issue… you should be able to install a new client with the old commserve name.
Looking at unique identifiers for clients, this by default is the client hostname only. So the hostname should be the only error generating value if a duplicate is encountered, unless you use the additional setting nAllowDuplicateHostName then this limitation is ignored.
Sorry for the late comeback, I wanted to answer you sooner. Thank you very much for the time you poured into this problem, you definetly went overboard to help me.
I had a lengthy discussion with our tech yesterday, I showed him your answers and he knows he is out of depth in this matter. He has a meeting scheduled with a Commvault expert next Tuesday and we should be able to fix this with all the information you gathered and the help of a Commvault Technician.
I will make sure to update the post if we find other helpful things,
Have a good one and thanks again for your help and your lab tests, real savior !
The following registry entries need to be altered as well to facilitate normal functioning of the Commserve communication service, when not changed it will crash.
Keep in mind, use your own client name values as your environment is different from mine.
Mandatory changes:
Location:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\CommServe
Key:
sCSCLIENTNAME
Value:
Change from old value COMMSERVE to newvalue WIN2022CS
Location:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\Database
String Value:
sDOMAIN
Value:
Change from old value COMMSERVE to newvalue WIN2022CS
Location:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\Machines
Deletekeywith new name WIN2022CS (this only refers to the existing sGUID)
Rename keywith old name COMMSERVE to new name WIN2022CS
Optional change:
This depends of the webserver package is installed on the commserve, if not ignore this change.
Location:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\WebServer
String Value:
sWebServerClient
Value:
Change from old value COMMSERVE to newvalue WIN2022CS
Tested some functionality in during this investigation.
After the changes I found that there were no apparent errors needing investigation at this point. Job management, media agent management, webserver, alerting, all seem to work as expected.
From discussions with people within Commvault, some issues came forward.
One for example is if you have existing network topologies, the reference in the fwconfig.txt also uses this Commserve client name. So if changed only on the Commserve, this could introduce connection failures.
This name correction needs a lot more attention before it can be considered to be a valid and complete solution. To be continued..
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
