Hi, I am trying to configure a basic traffic manager on my azure account. But I always got 404 not found when I using the traffic manager URL.
I have two app service for the TM endpoints:
1. xxxus.azurewebsites.net
2. xxxeu.azurewebsites.net
TM Url is:
xxxtm.trafficmanage.net
I was able to use www.whatsmydns.net to check what the tm is heading to.
But when I use the TM url, I got this:
Did anyone has the same issue? Looking forward to your help
Thank you
I ran into the exact same thing and just found the solution - the app service plan needs to be at least a standard SKU. I was using a free tier, and that was causing my 404.
From Microsoft's Traffic Manager documentation:
Only Web Apps at the 'Standard' SKU or above are eligible for use with Traffic Manager. Attempts to add a Web App of a lower SKU fail. Downgrading the SKU of an existing Web App results in Traffic Manager no longer sending traffic to that Web App.
Currently, you could not add web apps from different subscriptions to the same traffic manager configuration since It is not possible to use Web Apps from multiple subscriptions with the same domain name. Refer to this. You can check this on your side. If so, you can remove one website from your endpoint, then add the website to the same subscriptions.
Moreover, the 404 error always happen due to the domain name could not be resolved by its IP address. It may be one of the following reasons:
The custom domain configured is missing an A record and/or a CNAME record.
The browser client has cached the old IP address of your domain. Clear the cache and test DNS resolution again. On a Windows machine, you clear the cache with ipconfig /flushdns.
You can follow the quickstart to create a Traffic Manager profile, then follow this to verify your traffic manager settings.
I encountered similar issue. My problem is one of my app service is a free tier, so I scaled it up to standard one. And delete my traffic manager and reinstalled and add the service endpoint again, the issue gone.
It's strange. Nslookup will take you to the right web app but the browser will show 404. Changing the app service plan to 'Standard' SKU fixed it for me.
Related
I have an Azure App Gateway connected to 3 different App Service apps all running as part of the same App Service Plan (3 different back-end pools). In the Backend Health section of the AG, one of the app/pool is constantly flipping between Healthy and Unknown states. I have checked the entire network configuration according to this article and everything seems to be configured properly.
I have configured ip restrictions on the app services according to this article specifying the subnet the AG resides in as allowed. I have also temporarily allowed my ip address and every time the health for the 1 app goes to "unknown", I am still able to access the app service using its native .azurewebsites.net url locally on my machine.
Any ideas how I can troubleshoot this?
Please check if below points help to work around the issue.
As a workaround initially,try to restart the application gateway after the backend is deployed .
Also check this discussion on github issue
Sometimes Appgateway will cache the response indefinitely and the fix
maybe "Dynamic DNS" which ensures that the "no existing domain" is not
cached on the Appgw.Also check for the fix using v16.
Also check this > similar issue which says to use custom domain names as the request looks for some domain.
I'm migrating a complete infrastructure over to Azure; it's been slow going as there's so much to learn and for every two steps forward, there seems to be one step back.
After what seems like an eternity, I think I've got it all sorted with one exception.
The architecture is as follows:
Azure Traffic Manager ==> 2 Azure Application Gateways (geo separated) ==> Azure App Service
A custom domain is used for the traffic manager and the gateways are listening for the same domain and, when the route matches, passing on the requests down to the app service.
The actual app itself is a ASP.NET MVC application and it uses forms authentication; and this is where the challenge happens.
When navigating to the public address: client.domain.com and hitting the website, it determines that the user is not authenticated and sends the browser to the login page... so far so good but, rather than using client.domain.com/login it uses the web-server dns name, so client.azurewebsites.com/login
How do I go about changing the behaviour so that it uses the external DNS name rather than the website name?
I can't setup custom domains on the app service as the only route into the site is via the gateway as this is also the firewall.
Is there some Web Config setting I can make? I'm looking at the outbound rewrite rules but these seem to only work on tags rather than 302 redirects.
Any thoughts would be most welcome.
You need to setup custom dns names on your webapp (you can use TXT record to verify dns name, so i dont see a reason why you can add it to the webapp). or you can alter the code.
In order to solve this problem, I had to make a code change to the web app itself. Not ideal but it worked.
What I had to do was to extend the code that redirects an unauthenticated request to the login page by sniffing for the X-Original-Host HTTP Header that the App Gateway forwards on. This contains the public facing DNS name. If the header is present and it is on a pre-approved white-list (so as to prevent any hijacking), then redirect the user to the login page for this domain, rather than the one the server is listening on directly (so use client.domain.com rather than client.azurewebsites.com)
I was doing some experiments with the Traffic Manager (new azure portal). I configured a new Azure Traffic Manager and added two Azure WebApp endpoints.
But when trying to browse Traffic Manager endpoint I am getting
This site can’t be reached, niktm.trafficmanager.net’s server DNS address could not be found.
The Status' of the TM endpoint are "Enabled" and both the Web apps are up and running. Also, the Azure Traffic Manager Monitoring status is Online.
I did this few times and still getting the same result. Am I missing something?
Another reason why Azure Traffic Manager could not working with Azure App Service (Web App) is because you are using Basic service-tier, which doesn't support Traffic Manager feature. As a result, a Traffic Manger Profile has the Inactive status and Stopped for Endpoint monitor status.
This site can’t be reached, niktm.trafficmanager.net’s server DNS address could not be found.
If I do not add any endpoints in my traffic manager, Monitor status is Inactive.
To verify DNS propagation using http://digwebinterface.com/, I could find similar result as yours niktm.trafficmanager.net.
And if I browse to {my traffic manager name}.trafficmanager.net, I could see same error message in browser.
If I add available endpoints for traffic manager, I will see Dig result like below, and I could browse to {my traffic manager name}.trafficmanager.net.
I suspect that your endpoints do not really add to traffic manager even though Azure portal shows they are enabled and online. You could try to create a new traffic manager and add endpoints to check if it will work fine, if Azure traffic manager still/always not work fine in your subscription, you may need to create a support ticket to fix this issue.
I thought I had all my mappings perfectly done:
I'm able to add the www.mydomain.me to azure but not mydomain.me. Is there something I'm missing?
Edit: When I attempt to point to mydomain.me in my broswer, I get the following error message:
Error 404 - Web app not found.
The web app you have attempted to reach is not available in this Microsoft Azure App Service region. This could be due to one of several reasons:
1. The web app owner has registered a custom domain to point to the Microsoft Azure App Service, but has not yet configured Azure to recognize it. Click here to read more.
2. The web app owner has moved the web app to a different region, but the DNS cache is still directing to the old IP Address that was used in the previous region. Click here to read more.
Thanks
It's hard to tell what's wrong since you've hidden the settings. Here's what should work:
A Record points to the IP address found on the Azure portal
CName awverify points to awverify.yourservice.azurewebsites.net
CName www points to yourservice.azurewebsites.net
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.