We have added an app service as an endpoint to Azure Traffic Manager, and everything is working fine. However, when trying to add a second app service it fails with the following error:
Some of the provided Azure Website endpoints are not valid: Traffic manager configuration unexpectedly failed in region 'uksouth' with exception: Microsoft.Web.Hosting.Administration.Client.GeomasterClientException: Call to geomaster failed!, HttpStatusCode=BadRequest, RequestId='cae63ca1-0a3d-4f87-bd8e-9b881186e114', Uri=https://ln1.geomaster.azurewebsites.windows.net:444/subscriptions/fe12301c-5b6f-45f7-a038-ce2d4dbeec94/providers/Microsoft.Web/verifyTrafficManagerConfiguration?api-version=2018-02-01, CorrelationId=06de79f7-a67a-4a0e-ac5f-f6db24d5f908 at Microsoft.Web.Hosting.Administration.Client.InterGeomasterClient.Send[P,R](HttpMethod verb, String path, String queryString, P payload, Boolean throwOnError) at Microsoft.Web.Hosting.Administration.Client.InterGeomasterClient.<>c__DisplayClass22_0`2.<Post>b__0() at Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.RetryPolicy.ExecuteAction[TResult](Func`1 func) at Microsoft.Web.Hosting.Administration.Client.RegionalToRegionalClient.VerifyAndRegisterTrafficManagerConfiguration(String subscriptionName, CsmTrafficManagerConfiguration csmTrafficManagerConfiguration) at Microsoft.Web.Hosting.Administration.GeoScale.Sql.SubscriptionController.ForwardVerifyAndRegisterApiCallToRegionalGeomaster(RESTApiMetricsTracker tracker, String location, String subscriptionName, String trafficManagerDomainName, String[] hostNamesForsitesInRegion, Boolean registerTrafficManagerDomainName, Boolean failIneligibleSites)
We seem to be able to add two different app services without error, even this particular one with a different app service without error. It seems to be this particular combination of app services that fails as if they are somehow incompatible?
Not sure if it's significant but it seems combinations with an old app service (i.e. created a couple of years ago doesn't work with a recently created app service) but adding two app services that have been created recently works OK.
This error could be because of using the free tier of Traffic Management. If you are using the free tier of the old app, then change the tier plan.
Alternatively:
If the two apps are running on standard tier and still the issue occurs, then it must be the location error mentioned in the exception. That is South. Make sure the regions of the apps running are compatible with all the services you want to use. Some of the services may not be enabled in all the availability zones.
Related
I ran into an issue while migrating an Azure app service from .Net Core 5 to 6 while also updating the stack configuration in Azure Portal to use .Net version ".Net 6 (LTS)". The app service only contains continuous webjobs that process service bus messages. Locally, the webjob project runs fine but when deployed to Azure it fails to start. In Kudu tools I'm presented with an error:
[01/03/2023 18:21:32 > 1b0f90: ERR ] Unhandled exception. System.IO.IOException: Failed to bind to address http://127.0.0.1:5000: address already in use.
[01/03/2023 18:21:32 > 1b0f90: ERR ] ---> Microsoft.AspNetCore.Connections.AddressInUseException: Only one usage of each socket address (protocol/network address/port) is normally permitted.
[01/03/2023 18:21:32 > 1b0f90: ERR ] ---> System.Net.Sockets.SocketException (10048): Only one usage of each socket address (protocol/network address/port) is normally permitted.
Eventually I am able to get past the error by applying the app setting ASPNETCORE_URLS=http://localhost:5001 to the app service, and applying the same app setting every .Net Core 6 app service running web jobs in the same app service plan except I have to increment the port to something different. This does not seem to be a problem with non-webjob applications, and only occurs when I configure the app service stack to ".Net 6 (LTS)" in Azure Portal.
My question is: Is there another workaround to this issue? I find adding unique port assignments to every webjob running .Net 6 to be a cumbersome and not ideal, and this issue will exist as a serious gotcha for future development.
Here is the dependencies I am pulling in:
Azure.Messaging.ServiceBus Version=7.11.0
Microsoft.Azure.WebJobs Version=3.0.32
Microsoft.ApplicationInsights.AspNetCore Version=2.21.0
Microsoft.ApplicationInsights.NLogTarget Version=2.21.0
Microsoft.Azure.Services.AppAuthentication Version=1.6.2
Microsoft.Azure.WebJobs.Extensions Version=4.0.1
Microsoft.Azure.WebJobs.Extensions.ServiceBus Version=5.3.0
Microsoft.Azure.WebJobs.Extensions.Storage Version=5.0.1
NLog Version=5.0.4
NLog.Targets.Seq Version=2.1.0
NLog.Web.AspNetCore Version=5.1.4
To reproduce:
Create two or more .Net Core 6 applications that only implement Webjobs. My Webjobs functions process Service Bus topic messages, not sure if this is important to reproduce.
Deploy the Webjob applications to the same App Service Plan
In the configuration blade settings tab for each web app make sure that the runtime stack is set to ".Net 6 (LTS)", keep the rest as default.
Now when you go to view the webjobs in Azure Portal you will see that the job is stuck in a restart cycle.
The problem seems to be around setting the stack settings version to ".Net 6 (LTS)". From this article it seems that this setting makes the app service Run Kestrel with YARP, I'm guessing the feature parity is not 1:1 with the previous stack.
Example project that can reproduce the issue can be found on Github. Follow README found in .\Scripts to deploy example to Azure.
Note: there seems to be an issue with the template setting the stack to .Net 6. This may need to be done manually post deployment to fully reproduce the issue.
I have created 2 .NET Core 6 Applications and deployed to Azure Web Jobs in same Azure App Service.
Make sure to enable Always On option in App Service => Configuration => General Settings to ensure WebJobs are running Continuously.
I have updated the Stack settings run time Version to .NET 6.
Now when you go to view the webjobs in Azure Portal you will see that the job is stuck in a restart cycle.
Yes, even I got stuck with the same issue. The WebJob which I have published 2nd is showing the Pending Restart status.
When I click on the Logs, I can see the below error is Logged.
Make sure that you are setting a connection string named >`AzureWebJobsDashboard` in your Microsoft Azure Website >configuration by using the following format >`DefaultEndpointsProtocol=https;AccountName=**NAME**;Account>Key=**KEY**` pointing to the Microsoft Azure Storage account where >the Microsoft Azure WebJobs Runtime logs are stored.
In the second Console App, I haven't Configured the WebJobs and Storage Account.
Updated the code and published again.
Now I can see both the Jobs are in Running State.
My Program.cs file:
// See https://aka.ms/new-console-template for more information
using System.Threading.Tasks;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
namespace WebJobApp
{
class Program
{
static async Task Main()
{
var builder = new HostBuilder();
builder.UseEnvironment(EnvironmentName.Development);
builder.ConfigureWebJobs(b =>
{
b.AddAzureStorageCoreServices();
b.AddAzureStorageQueues();
});
builder.ConfigureLogging((context, b) =>
{
b.AddConsole();
});
var host = builder.Build();
using (host)
{
await host.RunAsync();
}
}
}
}
Reference taken from MSDoc.
We have a requirement to call a 3rd party API via a source with a fixed set of IPs. The IPs need to be static.
Since we are already using Logicapps(consumption) to do other processing, my initial thought was to continue using logic apps. I have already checked the concurrency and message size and they are all within acceptable range to use Logicapps.
My only question is on the IP of the Logicapp when it makes an API call. We had explored using Logic apps standard with VNET integration and Natgateway but this adds additional cost. The other option was to use APIM to provide a static IP, but the Logic would need to integrate with AAD for oAuth2 authentication and we would face challenges in managing the AAD tokens. We don't want to call AAD for a new token for each and every execution.
From the portal I can see a set of outbound IPs for my Logicapp.
I have already tested that the IP exposed is within this list. But I wanted to know if there is a chance that this can change in the future. I was not able to find any concrete Microsoft documentation around this question.
You should always take in account those IPs can change.
Microsoft exposes a downloadable list of Azure Ip Ranges here
This file contains the IP address ranges for Public Azure as a whole, each Azure region within Public, and ranges for several Azure Services (Service Tags) such as Storage, SQL and AzureTrafficManager in Public. Service Tags are each expressed as one set of cloud-wide ranges and broken out by region within that cloud. This file is updated weekly. New ranges appearing in the file will not be used in Azure for at least one week. Please download the new json file every week and perform the necessary changes at your site to correctly identify services running in Azure.
You can also get this data using the PowerShell Get-AzNetworkServiceTag in case you want to automate things. Example:
$serviceTags = Get-AzNetworkServiceTag -Location westeurope
$logicApps = $serviceTags.Values | Where-Object { $_.Name -eq "LogicApps" }
$logicApps.Properties
Region :
SystemService : LogicApps
ChangeNumber : 11
AddressPrefixes : {4.232.111.16/28, 4.232.111.32/27, 13.64.231.196/32, 13.65.39.247/32...}
I've been trying to get to through this issue for some time now, and unfortunately, I'm hitting a wall.
We have Azure AD configured with Azure Domain Services. VM's are joined to this domain. We also have Azure SQL Database that we're attempting to connect to from the IIS application running on the VM.
I've followed the official MS docs on this (https://learn.microsoft.com/en-us/azure/sql-database/sql-database-aad-authentication-configure) that helped verify Azure AD identities can connect to the Azure SQL DB (I can connect via SSMS to Azure SQL using an Azure AD Admin user. I can then use that ID to generate other contained users, which I have done).
The problem exists when I attempt to authenticate with the database with Active Directory Integration in my connection string. I get two errors, which i'm going to include below.
Now, I have not been able to get past the last one (stating that federation is needed), and in fact, have read numerous things (albeit nothing directly from MS) that says this is simply not supported and that I need to create a federation to get this working, which just seems completely unreasonable given that this is an Azure-only environment.
Connection string included below as well.
I've tried various iterations of that connection string to no avail. If anyone can provide some insight into this, I'd appreciate it greatly!
One last thing, the IIS application pool is running as a user that is both part of the AAD Domain group on Azure AD, and a contained user created on the DB.
Thanks!
I've tried various iterations of the connection string that include removing much of the additional params on the connection string, and the quotes.
I've tried different users on the application pool
End goal is to remove all plain-text PW's from appearing within the connection string to Azure SQL.
First error:
Unable to load adalsql.dll (Authentication=ActiveDirectoryPassword). Error code: 0x2.
Second Error:
[AdalException: Integrated Windows authentication supported only in federation flow.]
ADALNativeWrapper.ADALGetAccessToken(String username, IntPtr password, String stsURL, String servicePrincipalName, ValueType correlationId, String clientId, Boolean* fWindowsIntegrated, Int64& fileTime) +829
System.Data.SqlClient.<>c__DisplayClass2_0.<AcquireTokenAsync>b__0() +132
System.Threading.Tasks.Task`1.InnerInvoke() +121
System.Threading.Tasks.Task.Execute() +47
Connection String:
name="LocalSqlServer" connectionString="Server=tcp:XXXXX;Initial Catalog=XXXXX;Persist Security Info=False;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Authentication='Active Directory Integrated';" />
I'm trying to build a small program to change the autoscale settings for our Azure WebApps, using the Microsoft.WindowsAzure.Management.Monitoring and Microsoft.WindowsAzure.Management.WebSites NuGet packages.
I have been roughly following the guide here.
However, we are interested in scaling WebApps / App Services rather than Cloud Services, so I am trying to use the same code to read the autoscale settings but providing a resource ID for our WebApp. I have already got the credentials required for making a connection (using a browser window popup for Active Directory authentication, but I understand we can use X.509 management certificates for non-interactive programs).
This is the request I'm trying to make. Credentials already established, and an exception is thrown earlier if they're not valid.
AutoscaleClient autoscaleClient = new AutoscaleClient(credentials);
var resourceId = AutoscaleResourceIdBuilder.BuildWebSiteResourceId(webspaceName: WebSpaceNames.NorthEuropeWebSpace, serverFarmName: "Default2");
AutoscaleSettingGetResponse get = autoscaleClient.Settings.Get(resourceId); // exception here
The WebApp (let's call it "MyWebApp") is part of an App Service Plan called "Default2" (Standard: 1 small), in a Resource Group called "WebDevResources", in the North Europe region. I expect that my problem is that I am using the wrong names to build the resourceId in the code - the naming conventions in the library don't map well onto what I can see in the Azure Portal.
I'm assuming that BuildWebSiteResourceId is the correct method to call, see MSDN documentation here.
However the two parameters it takes are webspaceName and serverFarmName, neither of which match anything in the Azure portal (or Google). I found another example which seemed to be using the WebApp's geo region for webSpaceName, so I've used the predefined value for North Europe where our app is hosted.
While trying to find the correct value for serverFarmName in the Azure Portal, I found the Resource ID for the App Service Plan, which looks like this:
/subscriptions/{subscription-guid}/resourceGroups/WebDevResources/providers/Microsoft.Web/serverfarms/Default2
That resource ID isn't valid for the call I'm trying to make, but it does support the idea that a 'serverfarm' is the same as an App Service Plan.
When I run the code, regardless of whether the resourceId parameters seem to be correct or garbage, I get this error response:
<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">
{"Code":"SettingNotFound","Message":"Could not find the autoscale settings."}
</string>
So, how can I construct the correct resource ID for my WebApp or App Service Plan? Or alternatively, is there a different tree I should be barking up to programatially manage WebApp scaling?
Update:
The solution below got the info I wanted. I also found the Azure resource explorer at resources.azure.com extremely useful to browse existing resources and find the correct names. For example, the name for my autoscale settings is actually "Default2-WebDevResources", i.e. "{AppServicePlan}-{ResourceGroup}" which I wouldn't have expected.
There is a preview service https://resources.azure.com/ where you can inspect all your resources easily. If you search for autoscale in the UI you will easily find the settings for your resource. It will also show you how to call the relevant REST Api endpoint to read or update that resorce.
It's a great tool for revealing a lot of details for your deployed resources and it will actually give you an ARM template stub for the resource you are looking at.
And to answer your question, you could programmatically call the REST API from a client with updated settings for autoscale. The REST API is one way of doing this, the SDK another and PowerShell a third.
The guide which you're following is based on the Azure Service Management model, aka Classic mode, which is deprecated and only exists mainly for backward compatibility support.
You should use the latest
Microsoft.Azure.Insights nuget package for getting the autoscale settings.
Sample code using the nuget above is as below:
using Microsoft.Azure.Management.Insights;
using Microsoft.Rest;
//... Get necessary values for the required parameters
var client = new InsightsManagementClient(new TokenCredentials(token));
client.AutoscaleSettings.Get(resourceGroupName, autoScaleSettingName);
Besides, the autoscalesettings is a resource under the "Microsoft.Insights" provider and not under the "Microsoft.Web" provider, which explains why you are not able to find it with your serverfarm resourceId.
See the REST API Reference below for getting the autoscale settings.
GET
https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/microsoft.insights/autoscaleSettings/{autoscale-setting-name}?api-version={api-version}
We have an asp.net web api project deployed to an Azure Cloud Service (classic) that has been running fine using Swashbuckle for almost a year. We configure it like so...
GlobalConfiguration.Configuration
.EnableSwagger(c =>
{
c.SingleApiVersion("v1", "PartnerAPI");
c.UseFullTypeNameInSchemaIds();
}).EnableSwaggerUi(c => { });
Recently we needed to tweak the swagger generated output by plugging in an IOperationFilter. However our Azure Cloud Service (Classic) instance will not start if we create a class that implements the IOperationFilter. We don't even try to configure Swagger to use it. Just the fact that there is a class that implements that interface in our solution causes the deploy to fail stating...
2016-12-29T16:10:26.1066042Z ##[error]BadRequest : Your role instances have recycled a number of times during an update or upgrade operation. This indicates that the new version of your service or the configuration settings you provided when configuring the service prevent the role instances from running. Verify your code does not throw unhandled exceptions and that your configuration settings are correct and then start another update or upgrade operation.
Some Notes:
Everything runs fine on my machine, directly and in the azure emulator
Everything runs fine on teammates machine same as above
The following message appears to be related in the event logs on the azure machine when I rdp into it.
File Server Resource Manager was unable to access the following file or volume: 'E:'. This file or volume might be locked by another application right now, or you might need to give Local System access to it.
Same problem in Swashbuckle versions 5 and 5.5
No new nuget packages or references to the project
Only a "using Swashbuckle.Swagger;' that was added to the SwaggerConfig.cs
The Azure Portal reports the following for the "Instance Status Message"...
[12/29T16:43Z]Failed to load role entrypoint. System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) at System.Reflection.Assembly.GetTypes() at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetRoleEntryPoint(Assembly entryPointAssembly) --- End of inner exception stack trace --- at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetRoleEntryPoint(Assembly entryPointAssembly) at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CreateRoleEntryPoint(RoleType roleTypeEnum) at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.InitializeRoleInternal(RoleType roleTypeEnum)' Last exit time: [2016/12/29, 16:43:59.525]. Last exit code: 0.