194 posts tagged with "Azure"

Do you ever want to add external Microsoft Entra ID or other users to specific boards in a project, but not want to give them access to the entire Azure DevOps Project?

Using the steps below, we can restrict users to a specific board.

1. Invite external users to DevOps org with Stakeholder access.
2. In the project, create a new Team and do not add it to the existing security group to inherit permissions.
3. Add external users to created Team.
4. Set permission for created Team properly. In this case, it’s to set View project-level information to Allow.
5. Create a new area path and set the permission for the created Team in Security
6. Assign the area path to the newly created Team.

Issue Description​

Intermittent issues with Azure WebApp constantly stop functioning, a Stop/Start operation brings it back online.

Root Cause​

Further investigation using Azure Application Insights, reveals the Azure WebApp was experiencing a few FailedRequestCount, with HTTP 500 Errors. An exception was thrown by a TaskScheduler. Exception of type 'System.OutOfMemoryException' was thrown.

Resolution​

In my case, the service that was running on the Azure WebApp was using .NET Core 2.0, the fix was to upgrade to the latest version.

.NET Core 2.0 is an unsupported version and we highly recommend upgrading to the latest version (3.1). Please take a look at this information of the .NET Core official support policy: https://dotnet.microsoft.com/platform/support/policy/dotnet-core

For .NET Core applications I suggest enabling the stdout logs, as those will capture some important errors: https://learn.microsoft.com/en-us/aspnet/core/test/troubleshoot-azure-iis?view=aspnetcore-2.2#aspnet-core-module-stdout-log-azure-app-service-1

If those OutOfMemory exceptions come with a 5xx status code, I would suggest as well using the AutoHeal feature as it will allow setting rules based on that status code to capture a Memory Dump, you can check more information here: https://azure.github.io/AppService/2018/09/10/Announcing-the-New-Auto-Healing-Experience-in-App-Service-Diagnostics.html

It is best practice to lock down Azure resources to be accessible by location and services that is only to what's required and, the Azure Key vault is no exception.

When using Microsoft Hosted Agents in Azure DevOps, you need to make sure that the AzureCloud IPs for the Azure DevOps regions are opened on the Firewall.

In my case, I was in the: AustraliaEast region and needed to identify and add the following 'AzureCloud' Address Ranges to the KeyVault firewall:

• "name": "AzureCloud.australiaeast",
• "id": "AzureCloud.australiaeast",
• "properties": {
• "changeNumber": 13,
• "region": "australiaeast",
• "regionId": 3,
• "platform": "Azure",
• "systemService": "",
• "addressPrefixes": [
• "13.70.64.0/18",
• "13.72.224.0/19",
• "13.73.192.0/20",
• "13.75.128.0/17",
• "13.104.211.128/26",
• "13.105.16.192/26",
• "13.105.20.128/26",
• "13.105.52.192/26",
• "13.105.53.128/26",
• "20.37.192.0/19",
• "20.38.112.0/23",
• "20.40.64.0/20",
• "20.40.80.0/21",
• "20.40.120.0/21",
• "20.40.176.0/20",
• "20.42.192.0/19",
• "20.43.96.0/20",
• "20.47.37.0/24",
• "20.47.122.0/23",
• "20.53.32.0/28",
• "20.53.40.0/21",
• "20.53.64.0/18",
• "20.53.128.0/17",
• "20.58.128.0/18",
• "20.60.72.0/22",
• "20.60.182.0/23",
• "20.70.128.0/17",
• "20.135.120.0/21",
• "20.150.66.0/24",
• "20.150.92.0/24",
• "20.150.117.0/24",
• "20.157.44.0/24",
• "20.188.128.0/17",
• "20.190.142.0/25",
• "20.190.167.0/24",
• "20.191.192.0/18",
• "20.193.0.0/18",
• "20.193.64.0/19",
• "23.101.208.0/20",
• "40.79.160.0/20",
• "40.79.211.0/24",
• "40.82.32.0/22",
• "40.82.192.0/19",
• "40.87.208.0/22",
• "40.90.18.0/28",
• "40.90.30.0/25",
• "40.90.130.80/28",
• "40.90.130.208/28",
• "40.90.140.32/27",
• "40.90.142.160/27",
• "40.90.147.64/27",
• "40.90.150.0/27",
• "40.112.37.128/26",
• "40.126.14.0/25",
• "40.126.39.0/24",
• "40.126.224.0/19",
• "52.108.40.0/23",
• "52.108.83.0/24",
• "52.109.112.0/22",
• "52.111.224.0/24",
• "52.113.88.0/22",
• "52.113.103.0/24",
• "52.114.16.0/22",
• "52.114.58.0/23",
• "52.114.192.0/23",
• "52.115.98.0/24",
• "52.120.158.0/23",
• "52.121.108.0/22",
• "52.143.199.0/24",
• "52.143.200.0/23",
• "52.147.0.0/19",
• "52.156.160.0/19",
• "52.187.192.0/18",
• "52.232.136.0/21",
• "52.232.154.0/24",
• "52.237.192.0/18",
• "52.239.130.0/23",
• "52.239.226.0/24",
• "52.245.16.0/22",
• "104.44.90.64/26",
• "104.44.93.96/27",
• "104.44.95.48/28",
• "104.46.29.0/24",
• "104.46.30.0/23",
• "104.209.80.0/20",
• "104.210.64.0/18",
• "191.238.66.0/23",
• "191.239.64.0/19",
• "2603:1010::/46",
• "2603:1010:5::/48",
• "2603:1010:6::/48",
• "2603:1016:1400:60::/59",
• "2603:1016:2402::/48",
• "2603:1016:2500:c::/64",
• "2603:1017:0:60::/59"

You only need to add the IP ranges of the Region that your Azure DevOps instance sits in.

You can find the region that your Azure DevOps instance sits in by following the article below:

• Microsoft-hosted agents for Azure Pipelines - Azure Pipelines

You can retrieve the list of Azure IP Ranges and Service Tags from the following Microsoft JSON file:

• Download Azure IP Ranges and Service Tags – Public Cloud from Official Microsoft Download Center

Note: These IP ranges can change and update, depending on Microsoft removing and adding new datacenter capability, it is always worth rechecking the list if you find you start having problems with intermittent connectivity to check whether new ranges have been added that haven't been whitelisted.

Issue Description​

Failed to delete the private endpoint. Error: Call to Microsoft.Storage/storageAccounts failed

Root Cause​

Azure Backup locks the storage account when you configure protection for any file share in the corresponding account. This provides protection against accidental deletion of a storage account with backed-up file shares.

Resolution​

In my case, the Storage account I was attempting to remove the Private Endpoint from was an Azure File Sync storage account, that had Azure File Shares that were getting Backuped Up.

• Found and removed the lock on the storage account
• Then successfully delete the private endpoint

More info​

Generally, it is recommended that keep the lock taken on the storage account by Azure Backup. If you delete the lock, your storage account will be prone to accidental deletion and if it's deleted, you'll lose your snapshots or backups.

https://learn.microsoft.com/en-us/azure/backup/backup-afs#best-practices

https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources

Issue Description​

Unable to start Windows Azure Guest Agent (it's in a disabled state). When trying and set the service to auto the following error occurs 'The specified service has been marked for deletion.'

VM Agent is unable to communicate with the Azure Backup service.

Root Cause​

This may occur if Windows Communication Framework (WCF) profiling is enabled. WCF profiling should only be enabled while debugging a WCF issue. It should not be left enabled while running a production workload.

Resolution #1​

1. Restart your workload, I would recommend to Stop (deallocate first) to make sure that the workload starts correctly on a new hypervisor, the Azure Backup agent starts and checks for agent updates during the boot process.

Resolution #2​

Disable WCF profiling:

1. Launch an elevated CMD prompt. 2. Run the following commands to back up the existing: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config file:

   cd C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config

   copy machine.config machine.config.bak

3. Run notepad machine.config to edit the file in Notepad.

Remove this text, being careful not to also remove any additional text that may be on the same line:

<add name="Microsoft.VisualStudio.Diagnostics.ServiceModelSink.Behavior" type="Microsoft.VisualStudio.Diagnostics.ServiceModelSink.Behavior, Microsoft.VisualStudio.Diagnostics.ServiceModelSink, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

Also remove this text, being careful not to also remove any additional text that may be on the same line:

<commonBehaviors><endpointBehaviors><Microsoft.VisualStudio.Diagnostics.ServiceModelSink.Behavior/></endpointBehaviors><serviceBehaviors><Microsoft.VisualStudio.Diagnostics.ServiceModelSink.Behavior/></serviceBehaviors></commonBehaviors>

4. Save and close the file. 5. Restart the guest agent services:

net stop Rdagent

net stop WindowsAzureGuestAgent

net stop WindowsAzureTelemetryService

net start Rdagent

6. In some cases the VM may need to be restarted for the WCF disablement to take effect.

Resolution #3​

From time to time the Azure backup agent may fail. Sometimes this will self-resolve but on the odd occasion, additional steps may be needed.

1. Uninstall the agent via the Control Panel. 2. Open CMD as Admin. 3. Stop the following services:

net stop rdagent

net stop WindowsAzureGuestAgent

net stop WindowsAzureTelemetryService 

4. Delete all the services of the agent:

sc delete rdagent

sc delete WindowsAzureGuestAgent

sc delete WindowsAzureTelemetryService 

5. Create a folder called OLD in "C:\ WindowsAzure" and move the old version of the agent to it and the folders that say Packages. 6. Install the service again using the link: https://go.microsoft.com/fwlink/?LinkID=394789&clcid=0x409 or the latest agent available.
7. Restart the server.

Resolution #4​

1. Migrate the Pagefile to a new disk 2. Set a limit on the pagefile