Archive
Resolving Unauthorized Error When Deploying an #Azure Function via #ZipDeploy

Deploying an Azure Function to an App Service can sometimes result in an authentication error, preventing successful publishing. One common error developers encounter is:
Error: The attempt to publish the ZIP file through https://<function-name>.scm.azurewebsites.net/api/zipdeploy failed with HTTP status code Unauthorized.
This error typically occurs when the deployment process lacks the necessary authentication permissions to publish to Azure. Below, we outline the steps to resolve this issue by enabling SCM Basic Auth Publishing in the Azure Portal.
Understanding the Issue
The error indicates that Azure is rejecting the deployment request due to authentication failure. This often happens when the SCM (Kudu) deployment service does not have the correct permissions enabled, preventing the publishing process from proceeding.
Solution: Enable SCM Basic Auth Publishing
To resolve this issue, follow these steps:
- Open the Azure Portal and navigate to your Function App.
- In the left-hand menu, select Configuration.
- Under the General settings tab, locate SCM Basic Auth Publishing.
- Toggle the setting to On.
- Click Save and restart the Function App if necessary.
Once this setting is enabled, retry the deployment from Visual Studio or your chosen deployment method. The unauthorized error should now be resolved.
Additional Considerations
- Use Deployment Credentials: If you prefer not to enable SCM Basic Auth, consider setting up deployment credentials under Deployment Center → FTP/Credentials.
- Check Azure Authentication in Visual Studio: Ensure that you are logged into the correct Azure account in Visual Studio under Tools → Options → Azure Service Authentication.
- Use Azure CLI for Deployment: If problems persist, try deploying with the Azure CLI:
az functionapp deployment source config-zip \ --resource-group <resource-group> \ --name <function-app-name> \ --src <zip-file-path>
By enabling SCM Basic Auth Publishing, you ensure that Azure’s deployment service can authenticate and process your function’s updates smoothly. This quick fix saves time and prevents unnecessary troubleshooting steps.
Obtaining an Access Token for Outlook Web Access (#OWA) Using a Consumer Account

If you need programmatic access to Outlook Web Access (OWA) using a Microsoft consumer account (e.g., an Outlook.com, Hotmail, or Live.com email), you can obtain an access token using the Microsoft Authentication Library (MSAL). The following C# code demonstrates how to authenticate a consumer account and retrieve an access token.
Prerequisites
To run this code successfully, ensure you have:
- .NET installed
- The
Microsoft.Identity.ClientNuGet package - A registered application in the Microsoft Entra ID (formerly Azure AD) portal with the necessary API permissions
Code Breakdown
The following code authenticates a user using the device code flow, which is useful for scenarios where interactive login via a browser is required but the application does not have direct access to a web interface.
1. Define Authentication Metadata
var authMetadata = new
{
ClientId = "9199bf20-a13f-4107-85dc-02114787ef48", // Application (client) ID
Tenant = "consumers", // Target consumer accounts (not work/school accounts)
Scope = "service::outlook.office.com::MBI_SSL openid profile offline_access"
};
- ClientId: Identifies the application in Microsoft Entra ID.
- Tenant: Set to
consumersto restrict authentication to personal Microsoft accounts. - Scope: Defines the permissions the application is requesting. In this case:
service::outlook.office.com::MBI_SSLis required to access Outlook services.openid,profile, andoffline_accessallow authentication and token refresh.
2. Configure the Authentication Application
var app = PublicClientApplicationBuilder
.Create(authMetadata.ClientId)
.WithAuthority($"https://login.microsoftonline.com/{authMetadata.Tenant}")
.Build();
- PublicClientApplicationBuilder is used to create a public client application that interacts with Microsoft identity services.
.WithAuthority()specifies that authentication should occur against Microsoft’s login endpoint for consumer accounts.
3. Initiate the Device Code Flow
var scopes = new string[] { authMetadata.Scope };
var result = await app.AcquireTokenWithDeviceCode(scopes, deviceCodeResult =>
{
Console.WriteLine(deviceCodeResult.Message); // Display login instructions
return Task.CompletedTask;
}).ExecuteAsync();
- AcquireTokenWithDeviceCode() initiates authentication using a device code.
- The
deviceCodeResult.Messageprovides instructions to the user on how to authenticate (typically directing them tohttps://microsoft.com/devicelogin). - Once the user completes authentication, the application receives an access token.
4. Retrieve and Display the Access Token
Console.WriteLine($"Access Token: {result.AccessToken}");
- The retrieved token can now be used to make API calls to Outlook Web Access services.
5. Handle Errors
catch (MsalException ex)
{
Console.WriteLine($"Authentication failed: {ex.Message}");
}
- MsalException handles authentication errors, such as incorrect permissions or expired tokens.
Running the Code
- Compile and run the program.
- Follow the login instructions displayed in the console.
- After signing in, the access token will be printed.
- Use the token in HTTP requests to Outlook Web Access APIs.
Conclusion
This code provides a straightforward way to obtain an access token for Outlook Web Access using a consumer account. The device code flow is particularly useful for command-line applications or scenarios where interactive authentication via a browser is required.
Find #Azure Functions still using the in-process model in #Azure

If you got the following email from Microsoft Azure:
Migrate your .NET apps in Azure Functions to the isolated worker model by 10 November 2026
You’re receiving this email because you use the in-process model with .NET applications in Azure Functions.
Beginning 10 November 2026, the in-process model for .NET apps in Azure Functions will no longer be supported. To ensure that your apps that use this model continue being supported, you’ll need to transition to the isolated worker model by that date.
You may still use your .NET apps with the in-process model beyond 10 November 2026, but they will no longer receive security and feature updates from Microsoft.
The isolated worker model offers all the same functionality as the in-process model, plus improvements such as:
Full control of the dependency chain.
Isolation from platform lifecycle activities.
The ability to target Standard Term Support (STS) versions of .NET.
Required action
To ensure your .NET apps in Azure Functions continue to receive support, migrate to the isolated worker model by 10 November 2026.
Here is a script in both Powershell and Dos (Batch), to check which functions are using the in-process model; (Using the azure CLI for Windows)
This script logs into Azure, sets the subscription, lists the function apps, and checks the settings to identify which apps are using the in-process model for .NET:
powershellCopy code# Log in to Azure
az login
# Set your subscription (replace with your subscription ID)
$subscriptionId = "<your-subscription-id>"
az account set --subscription $subscriptionId
# List all function apps in the subscription
$functionApps = az functionapp list --query "[].{name:name, resourceGroup:resourceGroup}" --output tsv
Write-Output "Function Apps using in-process model for .NET:"
Write-Output "--------------------------------------------"
# Loop through each function app
$functionApps | ForEach-Object {
$name, $resourceGroup = $_ -split "`t"
# Get the app settings for the function app
$appSettings = az functionapp config appsettings list --name $name --resource-group $resourceGroup --query "[?name=='FUNCTIONS_WORKER_RUNTIME' || name=='FUNCTIONS_EXTENSION_VERSION']" | ConvertFrom-Json
# Check if the function app is using the in-process model
$isInProcess = $appSettings | Where-Object { $_.name -eq 'FUNCTIONS_WORKER_RUNTIME' -and $_.value -eq 'dotnet' }
if ($isInProcess) {
Write-Output "Function App Name: $name, Resource Group: $resourceGroup"
}
}
To run this script:
- Open PowerShell on your Windows machine.
- Copy and paste the script into the PowerShell window (or save it as a
.ps1file and run it). - Replace
<your-subscription-id>with your actual Azure subscription ID.
This script will list all function apps that are using the in-process model for .NET, helping you identify which ones need to be migrated to the isolated worker model.
If you prefer a DOS batch script, it’s a bit more complex due to the limitations of batch scripting, but here’s an attempt to do something similar using basic batch commands and PowerShell for processing:
batchCopy code@echo off
REM Log in to Azure (this will open a browser for authentication)
az login
REM Set your subscription (replace with your subscription ID)
set SUBSCRIPTION_ID=<your-subscription-id>
az account set --subscription %SUBSCRIPTION_ID%
REM List all function apps in the subscription and save to a temporary file
az functionapp list --query "[].{name:name, resourceGroup:resourceGroup}" --output tsv > functionapps.txt
echo Function Apps using in-process model for .NET:
echo --------------------------------------------
REM Loop through each function app
for /F "tokens=1,2" %%A in (functionapps.txt) do (
set NAME=%%A
set RESOURCE_GROUP=%%B
REM Get the app settings for the function app and save to a temporary file
az functionapp config appsettings list --name %NAME% --resource-group %RESOURCE_GROUP% --query "[?name=='FUNCTIONS_WORKER_RUNTIME' || name=='FUNCTIONS_EXTENSION_VERSION']" --output json > appsettings.json
REM Use PowerShell to check if the function app is using the in-process model
powershell -Command "
$appSettings = Get-Content 'appsettings.json' | ConvertFrom-Json;
$isInProcess = $appSettings | Where-Object { $_.name -eq 'FUNCTIONS_WORKER_RUNTIME' -and $_.value -eq 'dotnet' };
if ($isInProcess) { Write-Output 'Function App Name: %NAME%, Resource Group: %RESOURCE_GROUP%' }
"
)
REM Clean up temporary files
del functionapps.txt
del appsettings.json
To run this batch script:
- Open a text editor and copy the script into it.
- Save the file with a
.batextension, for example,checkFunctionApps.bat. - Run the batch file from the command prompt.
This script uses az commands to log in, set the subscription, and list the function apps. It then checks each app’s settings using PowerShell to determine if it is using the in-process model for .NET.