Hello @Adel BOUKHATEM 

The port number would be whatever port your Network Team has opened to allow communication between the CommServe <> Proxy <> Cloud Service Host. Commvault is not able to tell you which port to use as it must be configured by your Network Team.

Thank you,
Collin

Hi @Collin Harper ,

Thank you for your reply.

For testing purpose, our network team allowed all ports on firewalls and switches and disabled firewalls on servers.

The thing is that, we don’t know on which port the CommServe Server can communicate with the proxy Server. I mean, when we try to reach a port on a server, it should be a service behind, otherwise there would be no communication and the connection would be refused/dropped.

That’s why I would like to know what Commvault advise on this. We tried many ports number like: 8400,8403,443,80, 8080.. and many other random numbers, and still not working.

Since the communication is between Commvault Services (I guess), what port is used? Otherwhise, if we can use a random one, what should be done further?

Thanks

@Adel BOUKHATEM you should use the port that is used by the proxy server to receive incoming requests. For squid this is normally (by default) TCP port 3128 and some others listen on 8080. 

Commvault can use any port but you will have to reach out to the team who manages the HTTP proxy. 

Hi @Onno van den Berg ,

Thanks for your reply.

The thing is that a tried so many ports, and it's still not working.

We added new inbound rules on the proxy server to allow connections to that port, but still not working.

Since it is a Commvault Proxy Server, it should have a specific port I guess. Maybe I am missing something.

Regards

It's not a Commvault Proxy Server!!!

You are configuring Commvault to utilize an external proxy for the communication towards the defined cloud library/ Do note that it will communicate from the MediaAgent that is attached to the cloud library configuration. You are referring to the CommServe which could of course also act as the MediaAgent, but in most cases customers use dedicated machines that act as MediaAgents.

So what you can do to test it out is perform a telnet command towards the proxy + port from the server that will act as MediaAgent to see if you are able to make a connection. 

Hi @Onno van den Berg ,

Actually, we’re using the Media Agent as a proxy, because the Cloud storage is only visible to that Media Agent for security purpose. Since the CommServe doesn’t have direct/Any access to the cloud library, we taugh about using the Media Agent as a proxy in order to allow the CommServe to upload  the backumetadataat (DR DBs Backup) to that cloud library.

Any idea on how to achieve that?

Regards

Hi @Adel BOUKHATEM.  following up on some old threads.

Were you able to run the test @Onno van den Berg suggested?

So what you can do to test it out is perform a telnet command towards the proxy + port from the server that will act as MediaAgent to see if you are able to make a connection. 

@Adel BOUKHATEM It's the MediaAgent role or storage accelerator (in case of a client with that component enabled and properly configured) that communicates with a cloud library for backup and recovery purposes. This also includes the standard DR storage policy that has to be configured 

Now there is one specific option under DR Backup → Export settings which is the option named "Upload backup metadata to cloud library” which upload the DR set in native format towards the designated cloud library. This by default requires the CommServe to be able to communicate directly towards the configured cloud library endpoint, however in case you configure a HTTP proxy under Internet Options than it should use the configured proxy. 

@Adel BOUKHATEM were you able to get an answer for this one?

Might be worth a support case to get this wrapped up.

Hi @Mike Struening ,

Yes, we opened a case with Commvault, and they suggested checking with the storage vendor.

The object storage team, fixed the issue from their side. We are able to upload all files now.

Best Regards

Glad to hear it, @Adel BOUKHATEM !  Can you share what the object storage team did to fix it?

Thanks!

Hi @Mike Struening ,

Sorry, the storage team didn’t share the way they fixed it.

All I know is that they had to access to each node to make the configuration rather than the web console. I know it doesn’t help at all.

No worries, at the least we know this was hardware/storage related which helps!

Thanks again for sharing here 🤓