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
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
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