Changes to CDN Origin Configuration for Static Website not working for my existing sites

Question

My company has been using static website storage on Azure since it was in beta. We host web forms that need to be updated annually and replaced at the same URL.

We take the following steps setting up a site (mostly in the Azure portal):

1. Create a storage account configured as a static website and upload the static html, js and css files to it.
2. Create a CDN endpoint with an Origin Type of Storage Static Website and a hostname of the static website URL created in step 1
3. Once the endpoint is created and deployed, copy endpoint URL
4. Go to our DNS Zone and add a record set (each of these sites is set up as a subdomain) of type CNAME, using the cdn endpoint URL as the Alias and a TTL of 1 hour. Alias Record Set is set to "no"
5. Go back to the CDN profile I created and add a custom domain, using the subdomain I just created as the custom hostname. Enable CDN managed for that hostname.

After step 5, it takes a few hours for the new URL to be publicly available with https.

This all still works correctly. Where we have been having issues starting just in the past month is in the process for annually updating the sites. Our process requires that we create an entirely new static website and seamlessly cut over to the new files at the same URL. The most recent process we had that worked was this:

1. Go to the CDN endpoint created in step 2 above and select Origin in the Settings menu
2. Select the current origin (we always only have one)
3. In the dialog that comes up, select the new storage account as the origin hostname (in the portal we are shown a drop-down list of our active static site storage accounts in this field).
4. The "Origin Host Header" field automatically populates with the same URL that was selected as the Origin Hostname.
5. If we haven't done so already (this is a new requirement as of a year or so ago), I set the priority to 1 and the weight to 1000, because we only have one origin for the endpoint.
6. Save changes and return to the endpoint overview.
7. Click the "Purge" button and select "Purge All."

Until a few weeks ago, this functioned perfectly. We would continue to see the old files at the URL until the purge had completed (usually about an hour), at which point we would see the new files. There was no down time.

A few weeks ago, we started to see an error in step 6 (saving changes). When we tried to complete the steps as listed, we see an error message stating that Origin Host Headers can't be used in this configuration. The only way we have found to save the changes is to delete the pre-populated information in the Origin Host Headers field, save changes, and then purge. This so far has worked eventually, but we are experiencing 1-5 hours of downtime on our live site while this change is made. When we attempt to load the site we see a "URI Invalid" message which eventually is replaced by the new files. Since we are doing this for live sites, we need to be able to cut over without downtime. Is there some part of this process that we should be doing differently? The portal documentation is not up to date on the changes that have been made to the process. Thank you for any help.

Answer 1

Thank you, Gita. I did end up signing up for a support plan specifically for this issue. The response I received is that what we are doing should be the correct process. Backend logs confirmed that there is a bug in the portal. Since there isn't an ETA to fix it at the moment, we are advised to use the command line to do the same thing for now. Adding this comment so that anyone else encountering the same issue will see it.

Answer 2

Hello @LM ,

Apologies for the delay in response.

This issue you are facing would require a deeper investigation with remote support & collection of backend logs, so if you have a support plan, I request you file a support ticket, else please do let us know, we will try and help you get a one-time free technical support.

Thanks,
Gita