Skip to main content

Hi,

We have trouble uploading the DR backup to the CV Cloud. It seems to be blocked because the commserve is not allowed to send data to mcvdrbackup01c1us02.blob.core.windows.net

In the logs of the CVCloudService.log I see that http://mcvdrbackup01c1us02.blob.core.windows.net/ we see the following line

4300  4210  01/06 11:44:35 ### CVCloudAzureService::UploadBlob() - Error: Failed to upload chunk to cloud for file fWFEngine_commserve_2022_01_06_11_38_FULL.dmp], Index n1], Queue ufront -> 1, back -> 1, size -> 1], Block No. 2], Block Id URL Encoded oMDAwMDAy], Block Size S89088], URL to Upload lhttps://mcvdrbackup01c1us02.blob.core.windows.net/100472/SET_1579/WFEngine_commserve_2022_01_06_11_38_FULL.dmp?comp=block&blockid=MDAwMDAy&sv=2020-04-08&st=2022-01-06T10%3A25%3A34Z&se=2022-01-06T22%3A40%3A34Z&sr=b&sp=cw&sig=Fhfmrf6Sj2XMpP%2FsoSNfOLXPfiZb10b%2FGvHFSUjjoGQ%3D]. Upload attempt e3]. Curl Error Message s0xEDD00023:{CvCURL::CvProtocolReq::doPutOperation(569)} + {CvCURL::CvProtocolReq::SendReqest(614)} + {CvCURL::CvProtocolReq::Execute(675)/CvCURL.35.0x23-CURL perform failed.Curl ErrorCode : d35], Error Message : gOpenSSL SSL_connect: Connection was reset in connection to mcvdrbackup01c1us02.blob.core.windows.net:443 ]}], Error response: n]

 

We can try to put this address on the whitelist and see what happens.
But we want to know is this required or is there something more happening / wrongly configured?

As the documentation only speaks about the following url to be whitelisted:
cloud.commvault.com
cloudupload.commvault.com
cvdrbackup1.blob.core.windows.net

 

Thanks,
​​​​​​​Danny


 

In addition, 

When we go to the page in a browser we got the message that it is not reachable and if we try it from a machine outside the company network we got a XML-message:

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<Error>

<Code>AccountRequiresHttps</Code>

<Message>The account being accessed does not support http. RequestId:fff7e316-501e-005f-23f8-052a66000000 Time:2022-01-10T08:01:05.9587181Z</Message>

<AccountName>mcvdrbackup01c1us02</AccountName>

</Error>


Sounds like a candidate for a support case.  I just looked through our internal incident database for that url and nothing is coming up at all.

I’m checking with our teams just to be sure, though I suspect this will require a support case.

Can you create an incident and share the case number with me?  This might be something unique for you, though we may also need to get our docs updated as well!


Hi Mike,

 

Thank you for your response, and I will definitely create an incident. 

We will however first put the url on the whitelist and see how that is going.

But if the docs might need an update, more cells must have the same issue.

 

I can tell you this, At first I would not go this way and did it not get my attention as almost simultaneously some work was done on the firewall and the Commcell was update to 11.25.14

The updateinfo.log tells me the update was done the 22nd of December, the day of the last successful upload !! 
Unfortunately the oldest lines in the CommserveDR.log were from the 24th of December so I cannot 100% guarantee the update is the reason. But all indicates now to it.

I will also try to find another cell with the same MR to see if it also has a problem with uploading the DR to the CV Cloud.

The more info I have, the easier it should be for you to fix it.

 

Thanks, Danny

 


adding *.blob.core.windows.net to the white list, solved the problem.

Question now is, bug in 11.25.14 or something else?

For good reasons, we want to narrow it down

 

In a few weeks 11.25.14 is available for automatic download, just saying :wink:


Hi,

 

I can confirm that there is a bug in 11.25.14 or a new url must be added to the white list.

We found a 2nd commcell with exactly the same issue.


Amazing work (and a captivating tale as well)!

You clearly have the evidence ready for dev.  Once you get the case opened, let me know so I can follow up accordingly.

My concern now is that there might be a ‘next time’ and you shouldn’t have to find out this way!


I created ticket 220112-151

Let us hope it is forwarded directly to DEV and I do not first need to convince a good willing junior support engineer not to go in session to confirm what I already confirmed and reproduced.

 

 


reading is an art  :cry::angry:


Hi Danny,

 

Starting FR25, following URLs need to be in the allow-list: 

 

 

There are changes in FR25 that increases the availability of DR Backup uploads. Uploading CS no longer needs to rely on the Cloud Portal being 'up' to set up uploads for each job. As a side effect of this backend change, an uploading CommServe requires connectivity to an additional endpoint (https://cvdrservices.metallic.io) to set up uploads. Additionally, we may use different cloud storages for the actual upload (for load balancing, or region-based), which is why the storage URL has changed. Going forward, we will require ‘*.blob.core.windows.net’ (all endpoints that contain .blob.core.windows.net) to be in the allow-list.

 

 

We will work with the documentation team to get the URL information corrected in the below link

https://documentation.commvault.com/11.25/essential/115116_uploading_dr_backups_to_commvault_cloud_services_portal.html.


So, no worries about version 11.24 and lower? You do not release a MR where url’s must be changed/added on the allow list?

You mentioned that page: https://documentation.commvault.com/11.25/essential/115116_uploading_dr_backups_to_commvault_cloud_services_portal.html will be corrected.
What about page: https://documentation.commvault.com/11.25/expert/4787_external_urls_for_commvault_features.html

This page also mentions:
- cloud.commvault.com
- cvdrbackup1.blob.core.windows.net
Does those 2 url's not be on the allow-list anymore?

At last I see this line:
Going forward, we will require ‘*.blob.core.windows.net’ (all endpoints that contain .blob.core.windows.net) to be in the allow-list.

I find *.blob.core.windows.net a bit to general. Is there not some name convention you can narrow this down.

Thanks,
Danny


Sharing case solution:

We have validated this with our Development team and got an update that starting FR25 following URLs need to be in the allow-list:

https://cvdrservices.metallic.io 
https://mcvdrbackup01c1us02.blob.core.windows.net 

There are changes in FR25 that increases the availability of DR Backup uploads. Uploading CS no longer needs to rely on the Cloud Portal being 'up' to set up uploads for each job. As a side effect of this backend change, an uploading CommServe requires connectivity to an additional endpoint (https://cvdrservices.metallic.io ) to set up uploads. Additionally, we may use different cloud storages for the actual upload (for load balancing, or region-based), which is why the storage URL has changed. Going forward, we will require ‘*.blob.core.windows.net’ (all endpoints that contain .blob.core.windows.net) to be in the allow-list.


The development team will work with the documentation team to get the URL information corrected in the below link
https://documentation.commvault.com/11.25/essential/115116_uploading_dr_backups_to_commvault_cloud_services_portal.html 


Reply