Skip to main content
commvault.com commvault.com
Solved

SIMCallWrapper issues with NetworkGateway

  • November 27, 2022
  • 2 replies
  • 1069 views
D
Byte
Forum|alt.badge.img+4

Good Day everyone,

we’re operating a remote location with a Windows-Server as a network-Gateway between Clients that have no connectivity to CS and Commserver. (Not the OVA)
All Clients (Windows Servers) are installed decoupled with just the Windows Core Agent.
Remote Customers clicked a powershell on 50 different Servers that were installed like this: 
& C:\temp\CVtemp\Setup.exe /silent /install
and they registered also via the script:
$name = (hostname).tolower()
& 'C:\Program Files\Commvault\ContentStore\Base\SIMCallWrapper.exe' -optype 1000 -cshost CSFQDN -clientname $name -Connectioninfo PROXYFQDN:8403 -user 'clientregister' -password 'PASSWORD' -ClientGroup 'REMOTELOCATION_22'

Then the Fileagent was pushed automatically seconds after register (never seen this before as well) via commcell console...

Out of the blue the whole registration stopped working and I see this in the simmcallwrapper log on the clients behind the gateway:
13244 99c   11/27 12:08:15 ### XML Response :<?xml version="1.0" encoding="UTF-8" standalone="no" ?><CVInstallManager_ClientSetup><SimError ErrorCode="67109051" ErrorString="Backup infrastructure is currently unavailable. Please try later. If problem persists, contact your administrator." errorLevel="2"/></CVInstallManager_ClientSetup>

When executing the above SimcallWrapper.exe, I see in netstat that the registerclient has an established connection to Proxy and also does (after timeout?) a SYN_SENT to Commserver.

However, I’d like to ask first: am I right, that the -connectioninfo is the thing to use, if the client has no connectivity to the commserv itself and it will register itself via the proxy?

Since I have no clue why this stopped out of the blue - does anybody have any suggestions?

Best regards and thanks for help

Best answer by D4T4Pr0T3ction

Good Evening Jos and thanks for the clarification.

turned out there was a wrong set Firewallconfiguration on Commvault Client Group Network Configuration (dont use the toplogies yet). To make it short: We accidently defined nonpersistent ondemand Tunnels... Meaning that the simcallwrapper contacted the proxy which had a connection to the commserve but was not able to route the connection to Commserve (as the commserve is not aware that there is a simmcallwrapper-demand :D ).

However, after reviewing the configuration (as also backups stopped for that environment an hour later) we checked the network summary for the proxy which then had type=passive to (from) Commserver and Clients.
After that the simcallwrapper as described in the text above worked fine (even with -CSName).

Sorry for the mistake here...

Best regards
 

View original
Did this answer your question?

2 replies

Jos Meijer
Commvault Certified Expert
Forum|alt.badge.img+17
  • Jos MeijerCommvault Certified Expert
  • Commvault Certified Expert
  • 638 replies
  • November 28, 2022

Hi @D4T4Pr0T3ction 

As the client also shows a SYN_SENT to the Commserve it seems there is a setting in FwConfig which you don’t want to have.
If this is the case the client will bypass the proxy connection and go straight to the Commserve.

In the Base folder within the commvault folder there should be a few files starting with FwConfig.
Please check these files to see if any of them have a line containing:

cvfwd=<commserve hostname/ip>

If so, please change this to:

cvfwd=<gateway proxy hostname/ip>

Curious if this is your issue and registration progresses after altering the FwConfig files.
You can do this whilst services are running on the client, the firewall daemon will detect the change and reattempt the connection automatically. May need a few minutes to correct the connection.
You can also cycle the commvault services to force the software to establish a new connection.

Regarding the 

[-ConnectionInfo GatewayHostname:Port]

This is the correct way to contact a proxy, but not sure if this needs to be combined with the option:

[-CShost CommServe_hostname]

Looking at how the current installer works a proxy address would be enough to provide connectivity and registration. This option would be fine to refer to the commserve when using the ConnectionInfo option:

[-CSName CommServe_clientname]
Curious if your issue is solved if you change your script to:
'C:\Program Files\Commvault\ContentStore\Base\SIMCallWrapper.exe' -optype 1000 -CSName CSCLIENTNAME -clientname $name -Connectioninfo PROXYFQDN:8403 -user 'clientregister' -password 'PASSWORD' -ClientGroup 'REMOTELOCATION_22'

 

Onno van den Berg
D
2 people like this
  • Onno van den Berg
    Onno van den Berg
  • D
    D4T4Pr0T3ction
D
Byte
Forum|alt.badge.img+4

Good Evening Jos and thanks for the clarification.

turned out there was a wrong set Firewallconfiguration on Commvault Client Group Network Configuration (dont use the toplogies yet). To make it short: We accidently defined nonpersistent ondemand Tunnels... Meaning that the simcallwrapper contacted the proxy which had a connection to the commserve but was not able to route the connection to Commserve (as the commserve is not aware that there is a simmcallwrapper-demand :D ).

However, after reviewing the configuration (as also backups stopped for that environment an hour later) we checked the network summary for the proxy which then had type=passive to (from) Commserver and Clients.
After that the simcallwrapper as described in the text above worked fine (even with -CSName).

Sorry for the mistake here...

Best regards
 

Jos Meijer
1 person likes this
  • Jos Meijer
    Jos Meijer

Reply


Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings