App Service on Azure Stack Hub 2020 Q2 release notes
These release notes describe the improvements and fixes in Azure App Service on Azure Stack Hub 2020 Q2 and any known issues. Known issues are divided into issues directly related to the deployment, update process, and issues with the build (post-installation).
Update Azure Stack Hub to a supported version (or deploy the latest Azure Stack Development Kit) if necessary, before deploying or updating the App Service resource provider (RP). Be sure to read the RP release notes to learn about new functionality, fixes, and any known issues that could affect your deployment.
|Supported Azure Stack Hub version||App Service RP version|
|2005||2020.Q2 (release notes)|
|2002||2020.Q2 (release notes)|
|1910||1.8 (release notes)|
The App Service on Azure Stack Hub 2020 Q2 build number is 22.214.171.124
Refer to the Before You Get Started documentation before beginning deployment.
Before you begin the upgrade of Azure App Service on Azure Stack to 2020 Q2:
Ensure all roles are Ready in the Azure App Service Administration in the Azure Stack Hub Admin Portal
Backup App Service Secrets using the App Service Administration in the Azure Stack Hub Admin Portal
Back up the App Service and Master Databases:
Back up the Tenant App content file share
Cloud operators are responsible for the maintenance and operation of the File Server and SQL Server. The resource provider does not manage these resources. The cloud operator is responsible for backing up the App Service databases and tenant content file share.
Syndicate the Custom Script Extension version 1.9.3 from the Marketplace
Azure App Service on Azure Stack Update Q2 includes the following improvements and fixes:
Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version.
Updates Azure Functions runtime to v1.0.13021.
Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.
Updates to the following application frameworks and tools:
- ASP.NET Framework 4.7.2
- ASP.NET Core 3.1.3
- ASP.NET Core Module v2 13.1.19331.0
- PHP 7.4.2
- Updated Kudu to 86.20224.4450
Updates to underlying operating system of all roles:
Cumulative Updates for Windows Server are now applied to Controller roles as part of deployment and upgrade
Updated default Virtual Machine and Scale set skus for new deployments: To maintain consistency with our public cloud service, new deployments of Azure App Service on Azure Stack Hub will use the following SKUs for the underlying machines and scale sets used to operate the resource provider
Role Minimum SKU Controller Standard_A4_v2 - (4 cores, 8192 MB) Management Standard_D3_v2 - (4 cores, 14336 MB) Publisher Standard_A2_v2 - (2 cores, 4096 MB) FrontEnd Standard_A4_v2 - (4 cores, 8192 MB) Shared Worker Standard_A4_v2 - (4 cores, 8192 MB) Small dedicated worker Standard_A1_v2 - (1 cores, 2048 MB) Medium dedicated worker Standard_A2_v2 - (2 cores, 4096 MB) Large dedicated worker Standard_A4_v2 - (4 cores, 8192 MB)
For ASDK deployments, you can scale the instances down to lower SKUs to reduce the core and memory commit but you will experience a performance degradation.
Issues fixed in this release
- Upgrades will now complete if SQL Always On Cluster has failed over to secondary node
- New deployments of Azure App Service on Azure Stack Hub no longer require databases to be manually converted to contained databases
- Adding additional workers or infrastructure role instances will complete correctly without manual intervention
- Adding custom worker tiers will complete correctly without manual intervention
- Removal of custom worker tiers now completes without portal errors
- Workers are no longer marked as ready if the local disk is out of space
- Time out increased for retrieving the Azure Resource Manager Certificate
- The number of messages retrieved, from server logs and displayed in the Admin Portal, is limited to stay underneath the max Azure Resource Manager Request size
- Time out issue causing usage service startup issues
- Resolved database deployment issue when creating Orchard CMS sites
- Controllers are now updated with Windows Cumulative Updates as part of deployment and upgrade
- App Service no longer locks operations when custom domain verification fails
Review the known issues for update and take any action prescribed.
If you have provided the App Service resource provider with a SQL Always On Instance you MUST add the appservice_hosting and appservice_metering databases to an availability group and synchronize the databases to prevent any loss of service in the event of a database failover.
Known issues (update)
- In situations where a customer has converted the appservice_hosting and appservice_metering databases to contained database, upgrade may fail if logins have not been successfully migrated to contained users
Customers that have converted the appservice_hosting and appservice_metering databases to contained database post deployment, and have not successfully migrated the database logins to contained users, may experience upgrade failures.
Customers must execute the following script against the SQL Server hosting appservice_hosting and appservice_metering before upgrading your Azure App Service on Azure Stack Hub installation to 2020 Q2. This script is non-destructive and will not cause downtime.
This script must be run under the following conditions
- By a user that has the system administrator privilege, for example the SQL SA Account;
- If using SQL Always on, ensure the script is run from the SQL instance that contains all App Service logins in the form:
- All WebWorker logins - which are in the form WebWorker_
USE appservice_hosting IF EXISTS(SELECT * FROM sys.databases WHERE Name=DB_NAME() AND containment = 1) BEGIN DECLARE @username sysname ; DECLARE user_cursor CURSOR FOR SELECT dp.name FROM sys.database_principals AS dp JOIN sys.server_principals AS sp ON dp.sid = sp.sid WHERE dp.authentication_type = 1 AND dp.name NOT IN ('dbo','sys','guest','INFORMATION_SCHEMA'); OPEN user_cursor FETCH NEXT FROM user_cursor INTO @username WHILE @@FETCH_STATUS = 0 BEGIN EXECUTE sp_migrate_user_to_contained @username = @username, @rename = N'copy_login_name', @disablelogin = N'do_not_disable_login'; FETCH NEXT FROM user_cursor INTO @username END CLOSE user_cursor ; DEALLOCATE user_cursor ; END GO USE appservice_metering IF EXISTS(SELECT * FROM sys.databases WHERE Name=DB_NAME() AND containment = 1) BEGIN DECLARE @username sysname ; DECLARE user_cursor CURSOR FOR SELECT dp.name FROM sys.database_principals AS dp JOIN sys.server_principals AS sp ON dp.sid = sp.sid WHERE dp.authentication_type = 1 AND dp.name NOT IN ('dbo','sys','guest','INFORMATION_SCHEMA'); OPEN user_cursor FETCH NEXT FROM user_cursor INTO @username WHILE @@FETCH_STATUS = 0 BEGIN EXECUTE sp_migrate_user_to_contained @username = @username, @rename = N'copy_login_name', @disablelogin = N'do_not_disable_login'; FETCH NEXT FROM user_cursor INTO @username END CLOSE user_cursor ; DEALLOCATE user_cursor ; END GO
Known issues (post-installation)
Workers are unable to reach file server when App Service is deployed in an existing virtual network and the file server is only available on the private network, as called out in the Azure App Service on Azure Stack deployment documentation.
If you chose to deploy into an existing virtual network and an internal IP address to connect to your file server, you must add an outbound security rule, enabling SMB traffic between the worker subnet and the file server. Go to the WorkersNsg in the Admin Portal and add an outbound security rule with the following properties:
- Source: Any
- Source port range: *
- Destination: IP Addresses
- Destination IP address range: Range of IPs for your file server
- Destination port range: 445
- Protocol: TCP
- Action: Allow
- Priority: 700
- Name: Outbound_Allow_SMB445
Known issues for Cloud Admins operating Azure App Service on Azure Stack
- Tenants unable to create App Service Plan using new on App Service Plan view in tenant portal
When creating a new application, tenants can create App Service Plans during the create app workflow, or when changing the App Service Plan for a current app, or via the App Service Plan marketplace item
- Custom domains are not supported in disconnected environments
App Service performs domain ownership verification against public DNS endpoints, as a result custom domains are not supported in disconnected scenarios.
- For an overview of Azure App Service, see Azure App Service on Azure Stack overview.
- For more information about how to prepare to deploy App Service on Azure Stack, see Before you get started with App Service on Azure Stack.