Windows Azure Web Apps let subscription administrators define custom hostnames for a web-app, these have to be manually listed, but you can also specify wildcard hostnames for subdomains, e.g. *.myapp.com.
So if I have a multi-tenant application where each tenant has their own vanity hostname, they could be "billselectrical.myapp.com" and "megabusiness.myapp.com" - and hostname detection in my application code would handle the rest.
However, is it possible to have arbitrary hostnames in Azure Web Apps? What if my (high-profile) customer megabusiness.com wants my hosted-application to appear as "myapp.megabusiness.com"? Obviously I can support this by explicitly and manually adding myapp.megabusiness.com to the Azure domain list (which does require adding verification TXT records, unfortunately - so this requires cooperation from the customer) - but there doesn't seem to be a way to instruct Windows Azure to allow any hostname.
...or is there?
I note that I know this is achievable using a raw VM with a manually configured IIS website - I imagine the same is possible with a Web Role Worker too.
Related
I have a custom domain www.abc.com configured for web app webapp-a, and I'd like to transfer it to webapp-b without downtime.
If I try to add the domain to webapp-b, I am getting
The host name www.abc.com is already assigned to another Azure website: webapp-a
It there a way to let webapp-a continues to serve the requests, until the DNS cache expires?
Edit: The domain has IP based SSL binding, and the DNS is caching the virtual IP.
I faced the same issue, and was able to solve it in a tricky way.
I created new App Service Plan (previously known as Web Hosting Plan), and assigned "new" Web App to it (you can do it via new portal, or you can create Service Plan during Web App creation).
Then, I was able to assign the same host name to Web Apps in different hosting plans.
Thinking about this, I feel it logical: most probably Service Plan is mapped to physical IIS machine, and you cannot have two sites with the same host name in the same IIS for the obvious reason.
After migration from one DNS to another is done, you can remove unused Service Plan (as you basically pay for each separately).
According to a blog post by the Azure App Service Team in June 2017, it would appear that Azure now supports adding the same custom domain to multiple web apps:
There are scenarios where a customer would like to add the same hostname to multiple web apps in the same subscription, having a geo distributed website is one example. Our custom hostname feature allows you to bypass validation for hostnames that have already been validated. You only need to verify domain ownership when you add a hostname for the first time. For all other apps in the same subscription, you can add the same hostname without creating any DNS records.
You can read the entire blog post at https://blogs.msdn.microsoft.com/appserviceteam/2017/06/21/custom-hostnames-with-app-service/. The quote above was taken from the Adding the same custom hostname to multiple web apps section.
This should help in scenarios such as this where you want to transfer a custom domain name from one web app to another. You can simply add the same custom domain name to both web apps, add any required SSL bindings, and then change the DNS to point to the new web app. As the DNS change propagates, traffic should gradually move over to the new web app without any downtime.
I've tested this myself in the North Europe region and had no problems. Both web apps were in different App Service Plans. I have not tested this scenario with both web apps in the same App Service Plan. Bear in mind that if you're using IP addresses/A records in your DNS, you'd need both web apps to have different IP addresses for the DNS to be able to differentiate between your web apps.
Try assigning the domain to Azure Traffic Manager and have the traffic manager forward the request to the second site. Azure Traffic Manager and Web Apps are two different systems so you might be able to assign the same domain name to a web app and a traffic manager.
Once the DNS cache has expired remove the domain from the old Azure web app and add it to the new one, then finally delete the Traffic Manager account.
Option 2
Set the TTL to something very small, say 5 seconds (I believe your hostname provider should let you set that up), wait for the new TTL to propagate through all the caches. Then switch the custom domain from one app to another, and set the TTL back to it's original value.
This will result in just a few seconds of downtime for any customers, but if you do it at a low-traffic time the effect shouldn't be too bad.
I have a multi-site application running on Azure Websites. When a user signs up, they pick a name for their application and they end up with "appname.coolapplication.com". Everything so far is working great within our own domain.
Our application needs to allow users to enter their own custom domain. For example, they want to view their application from "elsewhere.com" rather than "appname.coolapplication.com". How do I go about configuring Azure Websites to allow me to do this?
You don't. Per these instructions you instruct the customer to enter a CNAME record on their domain registrar for the Azure domain, and then it begins to work.
EDIT:
The CNAME only "just works" for Azure Cloud Apps. For Azure Websites, it turns out you must add the domain in the portal as well. I'd thus recommend switching your Azure Websites to Azure Cloud Apps to simplify the issue.
You can use the powershell api to add custom hostnames.
See this question for details: Add many domains to an azure web site
I currently have a VPS with another provider. On that VPS, I have IIS running with multiple app pools and web sites. I would like to get out of the "server management business", so it would seem that Azure Web Sites (Reserved) would be a great fit. I'm able to get the Azure Web Sites set up, including the custom domain piece. The problem that I can't seem to figure out is how to get the same URLs and behavior that I currently have on my VPS.
For example, I have URLs that look like this right now:
www.foo.com/bar
www.foo.com/baz
wildcard.foo.com/bla
I can't find a way to mimic that in Azure.
Things I've thought of/tried:
Go with one Azure Web Site and have separate virtual directories/app pools in Azure, but googling tells me that isn't supported.
Create 3 Azure Web Sites, one for each of the above. The problem there as I see it is I would need to change to use bar.foo.com, baz.foo.com, and bla.foo.com/wildcard (i.e. lose wildcard subdomain mapping and rework things to have a custom route at the end).
Maybe have one Azure Web Site with a rewrite URL? The problem I think I'd run into there is that it all runs in one app pool, so deploying one piece will affect all 3, and obviously a fault in one app would impact the other 2.
Has anyone else gone down this path and solved it? If the answer is spin up a virtual server, I'll probably just stay where I'm at.
Considering www.foo.com/bar, www.foo.com/baz and wildcard.foo.com/bla are 3 independent web applications that share a domain (foo.com):
Create a Windows Azure Website for each web application. You don't necessarily need to assign custom domain names to them.
Create another, separate website and assign to it the *.foo.com domain using an A record. Refer to Configuring a custom domain name for a Windows Azure web site for instructions. As documented, "With an A record, you map a domain (e.g., contoso.com or www.contoso.com) or a wildcard domain (e.g., *.contoso.com) to the single public IP address of a deployment within a Windows Azure web site. The main benefit of this approach over using CNAMEs is that you can map root domains (e.g., contoso.com) and wildcard domains (e.g., *.contoso.com), in addition to subdomains (e.g., www.contoso.com)."
In this "master" website, set up URL redirection (possibly with status code 307 Temporary Redirect) so that requests go to the appropriate applications.
Alternatively, to avoid the delay of the additional request caused by the redirection, set up the "master" website as a reverse proxy that transparently forwards the request to the "inner" web application and sends the response back to the user.
As yet another alternative, use a custom DNS service to do the routing at the DNS layer.
This way, each web application is independent and you solve the issue of routing requests to the appropriate application.
I have a site that I want users from 5 different countries to use. However, I want each country to reach the site on language specific url's like www.deutchname.com and ww.englishname.com. The site will then server the language based on the domain name. Is this possible or do I set up several sites with the same databse? I'm running my site on an Azure web role.
When you create an application in Windows Azure, Azure provides a friendly subdomain on the cloudapp.net domain. However, in most cases you would like to access your website via custom comain, say, www.mysite.com. That ability is supported by both Azure Cloud Services as well as Azure Websites.
Custom domains are invisible to the end user i.e. a visitor of www.yoursite.com will never see the true host (say, yoursite.cloudapp.net).
The approach of having single deployment handling multiple domains or multiple deployments (each supporting single domain) talking to one database depends on architecture of your system architecture. Each solution has its pros and cons. Both solutions can be built in Azure Cloud service.
We are using the first approach i.e. single deployment handling multiple domains (and languages), and it works perfectly fine. There are some challenges but related to the system architecture (e.g. features visible on one domain and hidden on the others etc.) rather than Azure itself.
There is Configuring a custom domain name for a Windows Azure cloud service or storage account article which describes the process of setting up custom domain (via CNAME or Alias record (which is preferred) or via A record) for Azure Cloud service as well as verification process.
I've looked at all related posts in MSDN and stack overflow but still having difficulty finding a solution.
I am looking to map a domain and all sub-domains to my windows azure website. It is a reserved website instance. I am using Amazon Route 53 DNS manager and have mapped a wildcard CNAME to my azure sub domain, and created a redirect on the naked domain to the www. subdomain.
When I navigate to the naked root, the redirect kicks in and I'm brought to www..com, where I receive a 404 error from azure.
I know the wildcard CNAME is working. I've verified using MXToolbox. If I go to "Manage Domains" in the Azure web UI admin system, I can manually add "www..com" or any other subdomain (e.g. "helloworld..com"). Azure verifies it fine and after saving, I can pull up the website fine by navigating to that subdomain and my azure website loads.
Is there any way to add wild card subdomains without having to verify each one manually through the azure ui interface? My application is a SaaS that relies on custom user sub-domains to serve up their branded website and gain access to their account so I need any and all subdomains to map to my application.
Currently, wildcard domains are not supported as far as I know. At least on Windows Azure Web Sites. They are on the roadmap, but currently you'll have to rely on adding every domain manually.
See wildcard comment on "Configuring a custom domain name for a Windows Azure web site".
Another feature not yet available on Azure Web Sites is SSL using a vanity (your own) domain name. If you want full control of your site(s) you can use Azure Cloud Services instead of Web Sites. With Cloud Services you can provision certificates, domain names, and run multiple sites on the same instances using host header routing.
Anything you can do with IIS Management you can do with a cloud service.
You're a little closer to the metal compared to Azure Web Sites (but not as close as with a VM) and you get load balancing, scaling, caching, and other goodness. Visual Studio 2010/2012 has excellent deployment tooling. You will need to study up on Azure deployment projects from VS, bit it's not bad.