Migrate, modernize .NET applications with Azure
Published Sep 22 2020 09:00 AM 43.8K Views
Microsoft

11/3 update: Some pricing page changes will be delayed this week. All changes should be reflected by 11/9.

 

Digital demand for goods, services and information has never been higher and organizations of all sizes are bringing their web applications to the cloud to save costs and better support remote employees, customers, and partners.

 

As this demand grows, many of our customers have found that their current infrastructure is either limited in capacity or lacks the agility to keep pace with changing user needs. Premera Blue Cross is using App Service to simplify operations for Premera.com and protect patient data. The Academy of Motion Picture Arts and Sciences migrated their apps to Azure to rationalize legacy infrastructure costs and create new experiences for their members. And City National Bank needed modern CI/CD tools to make their development processes more predictable, automated and repeatable.

 

“Nobody understands .NET and SQL Server better than Microsoft, which, through Azure, gave us a robust set of managed services for migrating our legacy applications to the cloud.”

Bev Kite, Chief Information Officer, Academy of Motion Picture Arts and Sciences 

 

As the steward of Windows Server, SQL Server, .NET and Visual Studio for the past two decades, Microsoft has built best in class application development  environments in Azure for ASP.NET web apps and SQL databases. In fact, App Service and Azure SQL were recently benchmarked by GigaOm as the most cost effective and performant environments to run ASP.NET web workloads.

 

Today, we’re announcing several major investments in App Service designed to make it easier and more cost effective to migrate and modernize your .NET web apps with Azure.

 

Our most performant, cost effective offerings ever

 

Starting October 1st, customers will be able to use our updated Premium v3 (Pv3) offering, which leverages the latest Azure Dv4 Virtual Machine (VM) hardware to deliver improved performance and scalability.

 

New 2,4, and 8 vCore options stretch up to 32 GBs of memory. These new, more powerful configurations can handle more apps per instance and better support the large, enterprise applications and content management systems our customers use to run their most critical operations. With more competitive price points for dev/test and production workloads, Premium v3 is our most cost-effective and performant offering ever.

 

IGNITE updated table.png

 

With Premium v3, our support for Windows Containers also becomes Generally Available, making it possible for a variety of .NET applications with legacy configurations - including apps using COM+, GAC and those with custom OS level dependencies, as well as many WCF services - to migrate to Azure App Service.  And for the first time on App Service we are introducing Reservations Pricing to help customers control their TCO and better manage costs.

 

RI.png

 

Starting November 1st, customers can save up to 35 percent with a 1-year commitment and up to 55 percent for a 3-year commitment, compared to pay as you go prices. We are also extending our dev/test pricing discounts to Premium v3 as well as Premium v2, making it more affordable (especially for Visual Studio subscribers) to test workloads that require VNet connectivity before deploying.

 

Cost savings and networking innovation for Isolated workloads

 

For customers in regulated industries, our App Service Environments (ASE) provide an isolated environment to run their most sensitive web workloads. After several years of infrastructure and networking investments, we pleased to share that our App Service Environment v3 (ASEv3) will be available in Public Preview on November 1st.

 

This new single tenant architecture, built on Virtual Machine Scale Sets, places customer application endpoints in the customer's virtual network, while the internal ASE infrastructure is deployed in a separate, Azure controlled network. 

 

IGNITE ASE v2.png

 

This approach eliminates any ASE management traffic in the customer's network and vastly simplifies the deployment experience. This new ASE will be available as part of our Isolated v2 App Service plan, with no per instance stamp fee, offering an 80% reduction in deployment costs compared to Isolated v1.

 

Modernizing with .NET 5

 

Microsoft's commitment to .NET extends to the cloud and beyond. We're continuing to invest in the open source .NET platform to provide experiences for building  across operating systems and devices. Today, the .NET 5 Release Candidate is available with a Go-live license so you are supported in production. This release continues the journey to unify the platform across web, cloud, desktop, mobile, IoT, machine learning & AI.

 

In particular, this release focuses on making .NET the most productive platform for building high-performance microservices and container-based applications with the introduction of single file applications, smaller container images, and smaller memory footprint. It adds support for Windows ARM64, contains significant runtime performance improvements, and includes new C# 9.0 & F# 5.0 language features.

 

The ASP.NET Core web stack also has many additional enhancements for building modern web applications and services, including integrated Azure Active Directory authentication with Microsoft.Identity.Web, Blazor  enhancements like CSS isolation for Blazor components, protected browser storage, and lazy loading in Blazor WebAssembly for improved load times. Blazor is also now supported in Azure App Service Static Web Apps.

 

You can learn more about the release on the .NET Team blog.

 

Get started today with the Azure Migration and Modernization Program

 

Azure is the home for .NET apps. With free and easy to use migration assistants for App Service and Azure SQL and new streamlined resources available through the Azure Migration and Modernization Program, it has never been easier to save costs and begin your modernization journey!

 

**Note: App Service Premium Monthly Cost chart updated 10/12/20 to reflect the correct reservation prices for US East. Premium v3 not available in all regions, check the Azure Pricing Calculator for regional availability and exact pricing. 

51 Comments
Copper Contributor

I may be doing it wrong, but it seems like to achieve the same performance in a Web App as a VM/IIS hosted site you need to spend significantly more. I appreciate the Azure VM’s but always imagined that I’d move to Web Apps to leverage the platform and so far it hasn’t made sense. Hope that changes soon. 

Microsoft

Hey @Jakenuts that's a fair observation, the underlying machines are the same, but we built App Service to do more than simple hosting. It is a fully managed environment for building and managing ASP.NET web apps. We built native integrations with Visual Studio and GitHub for live site debugging and automated CI/CD. We created deployment slots so you can ship code changes with no downtime. We have out of the box monitoring designed specifically for ASP.NET apps and built small details like pre-installing URL Rewrite for devs to define custom rules in web.config. This week we’re updating the hardware so your apps can run on the best machines, and lower rates - soon with commitment discounts - to make it more affordable.

Copper Contributor

Regarding 

With Premium v3, our support for Windows Containers also becomes Generally Available

Would this be next version of Premium Container PC2/PC3/PC4 app service plans? If so, What version of nanoserver container images can be deployed to this environment?

pc2.PNG

 

I had a difficult time deploying windows containers to Azure Container Instances. Specifically, docker images built with nanoserver version 2004, 1909, 1903 fail to deploy on ACI stating UnsupportedWindowsVersion. And the only version supported is nanoserver:1809 which will reach EOL on Nov 10, 2020. Full thread here: https://github.com/dotnet/dotnet-docker/issues/2257#issuecomment-696477226

nanoserver-2004-aci.png

Will Premium V3 environment support deployment of docker images based on nanoserver:2004 ?

Microsoft

HI @prabh62  indeed it does you can deploy containers based on the 20.04 release of Windows Server 2019 and we will also be working upgrade our Windows Container hosts to the latest releases of Windows Server to make it very easy for you to deploy your apps in containers, taking advantages of continued investments in Windows Containers.  You can find out more regarding the base images we cache in App Service and more details on configuration options using this document - https://aka.ms/appsvcwindowscontainersconfiguration

 

Copper Contributor

Great news, was looking forward to this! :) Two questions:
1) I see some mixed details going round on the web about the new plan sku hardware. Can you confirm it's Dv4? (See mentions about Dv3 also)

2) Is this upgrade also coming to Azure Container Instances? ATM we cannot provision more than 4 vCPU / 16GB per ACI group, would be great if those limits will be extended to 8/32 too!

Copper Contributor

This is great news. Will the new isolated / ASEv2 which does away with the stamp fee also offer the new Pv3 VM sizes and also on reserved pricing, dev/test etc? (Being able to run apps securely in Azure App Service shouldn’t be an expensive ‘option’ IMO you should just be able to run normal Pv3 machines in your own vnet like normal VMs / scale sets). Thanks.

Copper Contributor

Hello,

 

I am trying to create an App Service Plan in Azure West US for windows containers and I am still seeing the windows containers preview banner as well as not seeing the Pv3 option to select. Am I missing something? It is Oct 1st so making sure that still is the date.

 

 

JeffBobadilla_0-1601579094169.png

 

Copper Contributor

This should be live since yesterday, but I'm not seeing any P*v3 offers I can switch to, neither in existing AppService Plans, nor when I create a new one.

Was this released yet?

Iron Contributor

Ditto on not seeing V3 offers yet... any additional details on this release @JT Rose?

Microsoft

Hi @Jeff @ThomasChristmann and @Derek Gabriel unfortunately the rollout has been delayed to 10/9/2020. Apologies for any inconvenience caused.

Copper Contributor

This feature is long overdue, I have put my release on hold and counting down to November 1

Microsoft

Further update -  The new Premium V3 SKU and Windows Container GA support is now LIVE and available in the portal, ARM and CLI.  Documentation updates have completed, for example Configure PremiumV3 tier - Azure App Service | Microsoft Docs can answer a number of questions around Premium v3.  cc @Jeff @ThomasChristmann and @Derek Gabriel 

Copper Contributor

Hi,

May I know the available locations for Premium V3 SKU for Windows Container GA support? I couldn't get the locations list.

was it not released yet?. If so when can we expect it?

 

Thanks.

cc @apwestgarth 

 

>az appservice list-locations --sku P1V3
az appservice list-locations: 'P1V3' is not a valid value for '--sku'. See 'az appservice list-locations --help'.

The most similar choice to 'P1V3' is:
        P1V2

 

Copper Contributor

Thanks @apwestgarth 

 

Can I get confirmation that using managed identities to connect to an Azure SQL Database works with Windows Containers now? And it works in an App Services setup?

Microsoft

Hi @pragadeesh the feature is indeed available and released as I posted in the comment prior to yours.  Here is the list of locations, I'm not sure why your CLI session did not return the full list, as you will see from the output below this is from AZ CLI:

❯ az appservice list-locations --sku P1v3
[
  {
    "name": "Central US"
  },
  {
    "name": "North Europe"
  },
  {
    "name": "West Europe"
  },
  {
    "name": "Southeast Asia"
  },
  {
    "name": "East Asia"
  },
  {
    "name": "West US"
  },
  {
    "name": "East US"
  },
  {
    "name": "Japan East"
  },
  {
    "name": "East US 2"
  },
  {
    "name": "South Central US"
  },
  {
    "name": "Brazil South"
  },
  {
    "name": "Australia East"
  },
  {
    "name": "Australia Southeast"
  },
  {
    "name": "Canada Central"
  },
  {
    "name": "West Central US"
  },
  {
    "name": "West US 2"
  },
  {
    "name": "UK West"
  },
  {
    "name": "UK South"
  },
  {
    "name": "Korea Central"
  },
  {
    "name": "France Central"
  }
]
Microsoft

@JeffBobadilla yes, Managed Identities are supported for Windows Containers on App Service, meaning you can indeed use a managed identity with other Azure Services, such Azure SQL DB from your Windows Container app in App Service.

Copper Contributor

Hello @apwestgarth,

 

Thanks for your response.

 

When i tried to create a service plan in WestUS , i bumped into an error (Requested features are not supported in region)

pragadeesh_0-1602005324643.png

{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"BadRequest","message":"{\r\n \"Code\": \"BadRequest\",\r\n \"Message\": \"Requested features are not supported in region. Please try another region.\",\r\n \"Target\": null,\r\n \"Details\": [\r\n {\r\n \"Message\": \"Requested features are not supported in region. Please try another region.\"\r\n },\r\n {\r\n \"Code\": \"BadRequest\"\r\n },\r\n {\r\n \"ErrorEntity\": {\r\n \"ExtendedCode\": \"59911\",\r\n \"MessageTemplate\": \"Requested features are not supported in region. Please try another region.\",\r\n \"Parameters\": [],\r\n \"Code\": \"BadRequest\",\r\n \"Message\": \"Requested features are not supported in region. Please try another region.\"\r\n }\r\n }\r\n ],\r\n \"Innererror\": null\r\n}"}]}
Copper Contributor

Thanks @apwestgarth 

 

But I dont see the managed identities working with windows containers yet as I am still seeing the same errors I have seen in the past where its erroring out trying to connect to the https://database.windows.net/ service point. If I connect with the username and password in the connection string it works as expected. If someone HAS set up managed identities working with windows containers in the App Service please let me know

Microsoft

@pragadeesh can you retry please?  If you hit the same error can you share with me your subscription type and any correlation ID you receive, you should be able to contact me via private message. 

Microsoft

Hi @JeffBobadilla after seeing your response, I went through our documentation (https://docs.microsoft.com/azure/app-service/app-service-web-tutorial-connect-msi) again and setup two new container based instances, both .NET Framework and .NET Core, which connect to Azure SQL Databases using System Assigned Managed Identity, deployed them to two new Pv3 App Service Plans in two regions, and can confirm that both are functioning as expected. I'm sorry you're still experiencing issues with your applications when using Managed Identities. Could you try restarting your application and test once more please? If you are still experiencing an issue, please open a support case and we will be able to look deeper at the issue you are experiencing.

Copper Contributor

Hmm @apwestgarth you can confirm you are using windows containers for this? I still am not able to get this to work. The article in your link is an older article that is focused on an app running in the app service itself not in a container running in the app service. Also I have yet to find an article that doesn’t say that managed identities only works for Linux containers

Microsoft

Hi @JeffBobadilla yes I can confirm I used both a Windows Server Core container (for the .NET Framework) sample, and a Windows Server Nano container for the (.NET Core) sample.  The article is still valid.  I've put my two samples into repos in my GitHub account:

 

.NET Framework - apwestgarth/DotNetFrameworkSqlDbInWindowsContainer: .NET Framework and Azure SQL DB sample where the authentication method is Managed Identity and the app is deployed in a Windows Container (github.com)
.NET Core - apwestgarth/DotNetCoreSqlDbInWindowsContainer: .NET Core and Azure SQL DB sample where the authentication method is Managed Identity and the app is deployed in a Windows Container (github.com)


I used the article mentioned as the basis to build the application and then I added Docker support and published my app in a container to Azure Container Registry then

  • I created a new Resource Group, App Service Plan (P1v3) and Windows Container web app in East US 2, setting the docker container to be the image I had published;
  • Once the site was created I enabled Managed Identity via the portal
  • I added the Managed Identity to my Azure SQL DB using the steps in the tutorial - Tutorial: Access data with managed identity - Azure App Service | Microsoft Docs
  • I browsed the site and confirmed my application was running correctly.

The app itself is currently running at https://apwmsisampleeastus2.azurewebsites.net

 

Managed Identity is supported across App Service - Windows Code, Windows Containers, Linux Code and Linux Container.  We enabled Managed Identities for Windows Containers in App Service in August 2020, so it is possible we may have missed an update to our docs, I am scanning them all to make sure any errors are rectified.

 

As you are currently still experiencing issues with this functionality, please open a support ticket and we can investigate further and help.

Microsoft

@Embers1  The hosts used for Isolated V2 will be the same type used for Premium V3.  

Copper Contributor

Thanks so much for the reply @apwestgarth . I am starting to think that this may be an IIS app pool issue that I am facing. When I deploy our application to a Windows IaaS VM and enable managed identity on the VM to authenticate the app with Azure SQL Database, I have to change the app pools to NetworkService to pickup the MI to authenticate. On an IaaS Windows VM this works successfully. But its not working on windows containers, so I am wondering if the app pool identity needs to be set to something other then NetworkService?

Copper Contributor

Hi @apwestgarth 

 

Will the reserved pricing apply to premium v2 service plan also or it is only for v3 plans?

Microsoft

@rangav185 Reserved instance pricing will only apply to Premium v3 plans.

Copper Contributor

I am having an issue with a .NET Core 3.1 worker service (Microsoft.NET.Sdk.Worker) running in a "windows:1809"-based container (the fat image). Every 21s it outputs the following to the log and the app freezes after 1 min:

 

<time> INFO - Site: <site-name> - [<cont-id>] - Waiting for container to be ready
<time> INFO - Site: <site-name> - [<cont-id>] - Waiting for container to be start. Container Id: <cont-id>

 

Tried re-creating App Service instance - same result. 

I am surprised that the same image works fine on ACI (which still in preview) and fails on App Service (which is now GA).

cc @apwestgarth 

Microsoft

@FeliksM does your container expose a HTTP endpoint?  App Service is a platform for hosting HTTP Workloads and we perform healthchecks on that basis.  If you review this section in our configuration documentation Configure a custom container - Azure App Service | Microsoft Docs you can set the Health Check to report only and then inspect whether or not the container comes up. If you still experience issues please open a support case so we can investigate further.

Microsoft

@JeffBobadilla you do not need to modify IIS Application Pool Identities to have the application run and use Managed Identity.  If you look at the samples I shared, you'll see the Dockerfile includes no additional IIS configuration.  Managed Identity is configured at the app level by the service.

Copper Contributor

Thanks @apwestgarth . Very strange that it works in an Azure IaaS VM perfectly but fails when its in the windows container. And if I add username and password to the connection string it works like a charm in windows containers. Just not working with MI. Error below is what I get

 

 
One or more errors occurred.
at System.Threading.Tasks.Task`1.GetResultCore(Boolean
waitCompletionNotification)
at System.Data.SqlClient.SqlInternalConnectionTds.<>c__
DisplayClass134_1.<GetFedAuthToken>b__1()
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
 
Parameters: Connection String: [No connection string
specified], Resource: https://database.windows.net/,
8D-401F4BA55C88. Exception Message: Tried the following 4
methods to get an access token, but none of them worked.
Parameters: Connection String: [No connection string
specified], Resource: https://database.windows.net/,
8D-401F4BA55C88. Exception Message: Tried to get token
using Managed Service Identity. Unable to connect to the
Managed Service Identity (MSI) endpoint. Please check
that you are running on an Azure resource that has MSI
setup.
Parameters: Connection String: [No connection string
specified], Resource: https://database.windows.net/,
8D-401F4BA55C88. Exception Message: Tried to get token
using Visual Studio. Access token could not be acquired.
Visual Studio Token provider file not found at "C:\Windows
\system32\config\systemprofile\AppData\Local\.IdentityServ
ice\AzureServiceAuth\tokenprovider.json"
Parameters: Connection String: [No connection string
specified], Resource: https://database.windows.net/,
8D-401F4BA55C88. Exception Message: Tried to get token
using Azure CLI. Access token could not be acquired. 'az'
is not recognized as an internal or external command,
operable program or batch file.
 
Parameters: Connection String: [No connection string
specified], Resource: https://database.windows.net/,
8D-401F4BA55C88. Exception Message: Tried to get token
using Active Directory Integrated Authentication. Access
token could not be acquired. Failed to get user name from
the operating system.Inner Exception : No mapping between
account names and security IDs was done
 
 
Request information:
Request URL: http://10.41.0.7/
Request path: /
User host address: 10.41.0.7
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\NETWORK SERVICE
 
Thread information:
Thread ID: 12
Thread account name: NT AUTHORITY\NETWORK SERVICE
Is impersonating: False
Stack trace: at System.Web.HttpApplicationFactory.E
nsureAppStartCalledForIntegratedMode(HttpContext context,
HttpApplication app)
at System.Web.HttpApplication.RegisterEventSubscription
sWithIIS(IntPtr appContext, HttpContext context,
MethodInfo[] handlers)
at System.Web.HttpApplication.InitSpecial(HttpApplicati
onState state, MethodInfo[] handlers, IntPtr appContext,
HttpContext context)
at System.Web.HttpApplicationFactory.GetSpecialApplicat
ionInstance(IntPtr appContext, HttpContext context)
at System.Web.Hosting.PipelineRuntime.InitializeApplica
tion(IntPtr appContext)
Copper Contributor

@apwestgarth My container does not expose an HTTP endpoint. It's a continuously running background job but I would still prefer to run it on App Service rather than ACI because App Service is less expensive and is GA now.

I tried setting CONTAINER_AVAILABILITY_CHECK_MODE to "Off" and restarting the service but that had no effect:

FeliksM_0-1602194758733.png

Untitled.png

Copper Contributor

@apwestgarth Tried replacing the base image with "nanoserver-1809" - no issues in App Service. As soon as I go back to the fat image (windows:1809 or windows:2004) it starts looping through those checks every 21s and eventually dies. Are fat images not supported in App Service?

Copper Contributor

@apwestgarth Got to the bottom of this. Despite having CONTAINER_AVAILABILITY_CHECK_MODE set to "Off" and "autoHealEnabled" set to "false" in the ARM template, App Service is still doing some sort of internal checks via port 80 and restarts the container when it doesn't respond. The workaround is to expose and bind port 80:

 

EXPOSE 80
ENV ASPNETCORE_URLS=http://+:80

 

This should not be required for background services without a public endpoint. At the minimum there should be a setting to disable this default behavior. To reiterate, this is not an issue on ACI.

Microsoft

Hi @FeliksM thanks for the feedback.  Principally App Service is a platform for hosting HTTP applications hence why we have such checks in place but ACI does not.  Your use case is great feedback for us though and is something we will look into in more detail.  Our HTTP Endpoint health check is always running and we report if an endpoint is unreachable.  We make theses events visible to help with troubleshooting. 

 

From your latest comment it would appear you were still seeing your container restart, could you either create a support ticket or send me your site name via private message and we can take a look further at our logs please? 

 

Also for reference the Full Windows Server images are also supported, they are much larger however and take much longer to start up as we do not pre-cache those images locally so there are extra layers for us to retrieve.  I validated this by building an IIS based image on top of mcr.microsoft.com/windows:2004 this afternoon.

Copper Contributor

@apwestgarth 

1. Sorry for for the confusion, once I added port 80 config to windows:2004 image the restarts stopped, so I am using that workaround for now. However, App Service does have "WebJobs" option today but it seems to be disabled for containers. Are there any plans to make it available in the future? That would make it easier to host containerized .NET Core worker services.

2. Regarding pre-caching of Full Windows Server images: does that mean that the image is just not pre-cached with a brand new instance of App Service, or that App Service will always fetch the "windows:2004" layer from registry after every stop/start (like ACI does)?

Microsoft

@FeliksM regarding 1. I have looked at how we can enable WebJobs in Windows Containers but so far that would be specifically for using the WebJobs SDK (How to use the WebJobs SDK - Azure App Service | Microsoft Docs ) this investigation work is ongoing.  My personal background is in .NET however so I will also look deeper into the .NET Core Worker Services;


Regarding 2.  When your site is allocated an instance or a number of instances based on your app service plan, that worker has a number of images pre-cached on the worker before we mark it ready to receive workloads.  The full list is here - Configure a custom container - Azure App Service | Microsoft Docs these images are pre-cached in order to make loading of customer's customer containers as efficient as possible, which particular for Windows Containers, can be quite large. 

 

In the case of the Full Windows Image then each time you deploy or scale to a new instance we need to pull and extract any additional base layers, we don't already have cached which make up that base image, in addition to those which contain your content as they don't already exist locally.  However if you have multiple apps per app service plan that all use the same base image then we don't repull for each new app which starts up as the layers already exist, we just pull and extract the layers that are different (primarily app content). 

 

In the event you stop or start your app we don't need to pull and extract again as the layers already exist on the instance on which you are running.  I hope this explains our behaviour, any further questions on this please let me know and I'll be very happy to answer.

 

Out of interest, do you need to have the overhead of the Full Windows Server image, do you need to use a service/feature/api that is not available in the Nano images?  You should still be able to expose a http endpoint on those images too, then you can also benefit for the massive reduction in container size.

Copper Contributor

@apwestgarth Thanks for the detailed explanation, sharing layers across app services hosted on the same plan is a nice feature. Regarding Full Windows Server images: you tested it with an IIS based image and it worked because that image included port configuration whereas in my case it was a plain windows image (with an application layer on top) that kept restarting. The reason I have to use the fat image is because I need to be able to run Chrome headless browser and have it render websites with custom fonts and export them to PDF, which doesn't work on Core or Nano. The other three options are ACI, AKS and VMs: ACI doesn't cache image layers and takes a long time to start, AKS requires a cluster and VMs are harder to manage.

Copper Contributor

Hi@apwestgarth , Is there any change in the environment that we need to aware of  while using P1V3 for windows container webapp (it works fine on PC2 Plan). and im using node application version 12.18

 

Here is the error im getting

 

16/10/2020 09:12:49.879 ERROR - Site: test - Unable to start container. Error message: Open Compute System failed.
Copper Contributor

@apwestgarth I attempted to scale up an app service plan to P2V3 using PowerShell, and it scaled to P2 (V1) instead.

 

Set-AzAppServicePlan -ResourceGroupName $usedPlan.ResourceGroup -Name $usedPlan.Name -Tier PremiumV3 -WorkerSize Medium

 

I then tried in the portal and got this error:

 

The pricing tier 'PremiumV3' is not allowed in this resource group. Use this link to learn more: http://go.microsoft.com/fwlink/?LinkId=825764

I see some guidance in the documentation about moving to a new plan, but clicking the Clone button in the portal for a few hundred apps is not really feasible. Are there any other options?

 

Thanks!

 

Copper Contributor

I have the same problem as @Thomas Mueller. I am trying to add a V3 app service plan (Windows) to an existing resource group. This RG has P3V2 app services currently running and my intention is to upgrade those to V3 plans.

 

{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"BadRequest","message":"{
 "Code": "BadRequest",
 "Message": "Requested feature is not available in resource group RGNAME. Please try using a different resource group or create a new one.",
 "Target": null,
 "Details": [
 {
 "Message": "Requested feature is not available in resource group RGNAME. Please try using a different resource group or create a new one."
 },
 {
 "Code": "BadRequest"
 },
 {
 "ErrorEntity": {
 "ExtendedCode": "59324",
 "MessageTemplate": "Requested feature is not available in resource group {0}. Please try using a different resource group or create a new one.",
 "Parameters": [
 "RGNAME"
 ],
 "Code": "BadRequest",
 "Message": "Requested feature is not available in resource group RGNAME. Please try using a different resource group or create a new one."
 }
 }
 ],
 "Innererror": null
}"}]}

 

Copper Contributor

Hi,

 

When will reserved instance pricing be going live for App Service? Originally this was advised would be live on 01 Nov. Thanks.

 

"Starting November 1st, customers can save up to 35 percent with a 1-year commitment and up to 55 percent for a 3-year commitment, compared to pay as you go prices. "

 

Copper Contributor

Hi I cannot see V3 windows instances in Reservation, only Linux are available, see image below

 

6DD97886-CE89-4668-9962-A564A4A9C6C0.jpeg

Copper Contributor

@rangav185 - The same, I can't see V3 Windows instances, have tried multiple regions.

Microsoft

@vinod_baliga you need to create a new Resource Group and new App Service Plan to access Premium V3 SKUs.

Microsoft

@rangav185 and @Embers1 we are investigating.  Will post an update here once I have further information

Copper Contributor

@apwestgarth Same problem for me, just showing Linux options, and it's now the 9th, which is the new release date per the update a the top of the article.  

Copper Contributor

ichivers_0-1605009200103.png

Same problem in West Europe!

Copper Contributor

So it's the 11th.  Any updates on this? 

Copper Contributor

Just showed up for me:

Dechutes_1-1605136093581.png

 

Microsoft

Hey folks, we had some backend commerce systems issues with publication. Both Windows and Linux are now available in the Azure Portal: https://ms.portal.azure.com/#blade/Microsoft_Azure_Reservations/CreateBlade/referrer/Browse_AddComma...

 

Pricing page will be updated shortly. Sincere apologies for the delay here @Dechutes @ichivers @rangav185 @Embers1 

Co-Authors
Version history
Last update:
‎Jul 12 2021 11:51 AM
Updated by: