You can now use the Azure CDN to access blobs with custom domains over HTTPS. See the following article for instructions on how to do so: https://docs.microsoft.com/en-us/azure/storage/storage-https-custom-domain-cdn. Having talked to a number of customers, we concluded that this solution addresses many scenarios where the need for HTTPS access to blobs with custom domains exists.
Native Azure Storage support for using SSL to access blobs at custom domains is still on our backlog. We would love to hear about your scenarios where using the Azure CDN is not an acceptable solution, either by posting on this thread or sending us an email at firstname.lastname@example.org.
Thank you for the suggestion. This seems like a reasonable way to make sure that you collect all of the diagnostic data from your virtual machines. I have passed this idea on to the WAD team.
56 votesunder review · 3 comments · Cloud Services (Web and Worker Role) · Flag idea as inappropriate… · Admin →Paul Turner commented
I think I just lost a day trying to get to the exception information I needed to solve a deployment issue. The Worker Role host doesn't deal with unhandled exceptions very gracefully at all. Whilst having the host crash isn't the worst idea, it really pains me to miss the rich .NET exception data.
I would like to see, at a minimum, any unhandled exception being written to a log (the Application log is suitable, especially as it's already exported by WAD), before the host terminates. No exception should just disappear.
Ideally, we should be able to see any exceptions encountered in deploying a role (deployment, startup scripts, role start) through the Azure dashboard. I appreciate that might be a big ask, but it would be very convenient.
Good feedback. We’ll take a look at making PS scripts first-class citizens.Paul Turner shared this idea ·
114 votesunder review · 0 comments · Cloud Services (Web and Worker Role) · Flag idea as inappropriate… · Admin →
Good feedback. No plans in this area, yet.Paul Turner commented
The generated GUID also poses a problem for exposing a static FederationMetadata.xml file, since you don't know the URLs required until after the deployment. It would be nice to just use "staging.myApp.cloudapp.net" as a predictable hostname.