Currently I'm trying to port a web application(ASP.NET MVC) to windows azure and have come across a point, I don't know how to solve.
The application is a multi tenant one. Every customer who registers, can enter a name for his instance and is able to surf the site later on over theenteredname.example.com. Further, the domain is used in an ActionFilter to switch between the databases.
How can I realize this in Windows Azure? I know that I must define a binding with defined hostHeader attribute, but as the subdomains a generated dynamically I would have to change the service definition every time a user registers and a new sub domain appears and redeploy it. But that is really not the way I want it.
Any help would be appreciated!
I think the problem is that IIS does not support subdomain wildcard mapping, see here Wildcard subdomains in IIS7. Is it possible to make them like it is in Apache? for more information.
If you would still like to do this there is a solution here http://www.seoconsultants.com/windows/isapi/subdomains/ , but it requires:
Ability to update DNS records
IIS web server admin access
ISAPI_Rewrite component (for Solution 2)
In Windows Azure, if you simply don't assign any host headers to your web role (which is the default), the site will be configured to accept any host header.
You still need to configure wildcard DNS to point to your Azure instance, just as you would for a non-Azure solution.
Related
This is more of a general question about. I have a website running as an Azure App Service. I configured a custom domain so that you are able to call it by my-site-name.com.
As the request of customers kept growing and each customer has specific demands, I was wondering if it is possible to have a subdomain for each customer. For example, client1.my-site-name.com and client2.my-site-name.com.
Is it possible to do all of this within a single App Service or do I need to set up an Azure App Service for each subdomain?
The reason behind my question is, that it would be quite expensive to have an App Service for each individual customer.
You should also consider just adding a wildcard custom domain entry. This is an older blog post, but it outlines Azure WebApp support for Wildcards:
https://azure.microsoft.com/en-us/blog/azure-websites-and-wildcard-domains/
This would mean that *.my-site-name.com traffic goes to your single Web App. Then it is up to the logic of your webapp to determine which client it is by inspecting the hostname of the request (client1.my-site.name.com) and taking the appropriate action to customize the response to that client.
Using a wildcard eliminates the need to add a specific custom subdomain mapping for each client.
It should be possible. Within your app service, if you go to the settings for that service, there is a Custom domains option, select it.
Within there you can then map your subdomains to this service, and it allows you to do it multiple times. You just need to validate and set it up with the A record or CNAME and own the domain. Additionally, you should be able to add SSL Bindings for each.
Here are some documentation on it, I don't believe this documentation handles your exact use case but it does touch on the custom domain portion and should provide additional support.
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain
https://blogs.msdn.microsoft.com/waws/2014/10/01/mapping-a-custom-subdomain-to-an-azure-website/
Let me know if you need more
This seems more like a domain management issue than an azure specific issue. You have already decided to have different sub domains to each customer. That, by definition, means each sub domain needs individual server space. That in turn would mean, an app service for each customer.
So, the answer is what you already have. Have an app service (essentially web server) for each customer via sub domain.
In your position, I would consider some alternatives.
Rebuild your app to work with some form of login system, so clients login and get themselves a separate view.
Alternatively, go with sub folders instead of custom domains. something like, domain.com/client1, domain.com/client2 and so on.
I'd like to consider this Azure feature:
https://www.youtube.com/watch?v=HxXs9_ggBfg
But it won't be of much use to me if I'm unable to configure a custom domain for it. I'm having no problem with custom domains for standard App Service websites, but this is for containers.
I've tried searching for documentation, but I'm coming up empty.
--EDIT--
The technology I'm interested in is Web Apps for Containers; thanks to #sam-cogan for pointing this out to me.
I believe the video is talking about Azure Web Apps for Containers (I would really recommend not asking people to watch a 30-minute video to understand your question). Assuming that is the case, then adding a custom domain name is the same as setting one up for a normal app service, you can do so through the custom domain name settings in the portal. The process is documented here.
If you're looking to use a different service in Azure for hosting containers then please state which one and I will update. All of these can have custom domain names.
Azure Container Instances usually provide a public IP address, so pointing a domain name to it should not be a problem.
You could map either an A record or a CNAME to your instance.
There is no difference between configuring custom domain for normal web apps and web for container. I have tried below document and it is worked well.
http://www.ayushrathi.com/configuring-a-custom-domain-name-for-web-app-azure-portal/
I wish to connect an active directory controller which is hosted on an Azuer VPS to a domain I have purchased (which uses CloudFlare), how can I go about doing so?
I am aware of the security risks imposed by exposing an AD instance to the public.
I have poked around to try and find details about what ports should be exposed and records that should be created but couldn't find any.
Edit: I found a page containing a list of the required records and managed to configure it correctly - I will now add an answer.
DNS is now properly configured for the AD instance to be exposed to the web.
I followed the records available here and now it's for all to see!
when adding a custom domain to Azure app service, the system always trying to validate your custom domain, but this is very annoying for my case.
i have a CDN service which i have put my www. sub domain on it, and the now i am going to move my website to azure app service
actually i have the website up running already on app service, and the only thing i need to do is point the origin server address to app service in CDN setting
but, i need to set up a custom domain on app service for www. otherwise it won't load.
so the worst thing is, when i try to add the www record as custom domain, it validates if the record is really pointed to app service, which is definitely not possible because if i switch the domain really to app service,
first, i can not guarantee all user will get the dns change in same
time
second, then i need to switch www back to CDN after the
validation, then during this period, my app will work without cdn,
which will be a problem also
so is there anyway to add a custom domain without validation.
this is really stupid, i have to say
maybe i am stupid
found the way in office MS documents
here is the link
https://learn.microsoft.com/en-us/azure/app-service-web/app-service-custom-domain-name-migrate
you can set up a txt verification recond to pass the verification
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.