Project settings > Settings

Is there a particular reason you can't just use the manual SP approach? I have also had issues in the past using the automatic flow as well, so I usually just add in my SP creds and get on with it rather than hope all my default subscriptions have been exposed for each tenant etc.

Ideally, you would be injecting these via an appsettings.json, Key Vault reference or something and not manually setting these in the Configuration panel itself. In terms of archiving the actual values etc, this is probably most easily accomplished via the https://learn.microsoft.com/en-us/rest/api/appservice/web-apps . There are several CRUD operations that can GET, UPDATE, etc configurations/application settings which should be able to allow you to accomplish what you have asked here.

https://learn.microsoft.com/en-us/archive/blogs/waws/things-you-should-know-web-apps-and-linux#you-can-only-expose-one-port-to-the-outside-worldapplies-to-web-app-for-containers . Azure Web App for Containers detect port 3000 first (3000 Revers proxy in container will resolve your problem. Test outside of container will not work. For test you may be change port 3000 to 8082. Backend /services/* will available, but frontend won't.

A dynamic block does not use the each keyword, but the value of the iterator argument instead. If omitted, it will use the name of the dynamic block instead. Or as https://developer.hashicorp.com/terraform/language/expressions/dynamic-blocks states it: The iterator argument (optional) sets the name of a temporary variable that represents the current element of the complex value. If omitted, the name of the variable defaults to the label of the dynamic block. It's generally fine to omit the iterator argument and just go with the (what should be a) unique name of the block. In your case, replace each.value with virtual_network_rule.value, so you get: dynamic "virtual_network_rule" { for_each = var.virtual_network_subnet_ids content { id = virtual_network_rule.value } } If you do want to use the iterator argument, it would look something like this: dynamic "virtual_network_rule" { for_each = var.virtual_network_subnet_ids iterator = "rule" content { id = rule.value } }

I was able to achieve that Update //|where OSType != "Linux" and UpdateState == "Needed" and Optional == "false" | where Classification in ("Security Updates", "Critical Updates") | where PublishedDate

I added Azure Monitor logs to the Performance counters and now it is showing the Perf data

Create a PowerShell task in Azure DevOps and add this command to it "C:\Program Files (x86)\Google\Update\GoogleUpdate.exe" /c | cmd So we are running the google update exe in the command line which will update the google chrome before you run the other task. We are piping the command to cmd in PowerShell.

This looks like a case for a conditional resource. First, look up the secrets with a https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/data-sources/key_vault_secrets block: data "azurerm_key_vault_secrets" "example" { key_vault_id = data.azurerm_key_vault.keyvault.id } and then a condition on the lookup: data "azure_rm_key_vault_secret" "win_admin_pass" { count = contains(data.azurerm_key_vault_secrets.win_admin_pass.names, var.secret_name) ? 1 : 0 name = var.secret_name key_vault_id = data.azurerm_key_vault.keyvault.id } If the secret doesn't exist, the data will look up zero resources.

I discovered two issues that hindered the pipeline deploying properly. First, it appears that the Azure plugin for Eclipse creates an app.war file in the wwwroot folder of the app. Azure, apparently, prioritizes picking up this war, instead of any that might be in wwwroot/webapps. Previously I had manually deleted app.war, but then the app would just 404. This leads to the second issue. I was attempting to deploy using the default package name "...SNAPSHOT"; however, Tomcat looks for ROOT.war. I added the following lines to my pom.xml. ROOT This delivered the appropriately named file, which the "Azure App Service deploy" task places in wwwroot/webapps (where Tomcat looks for it). I then deleted the app.war file and any leftover ...SNAPSHOT folders in webapps, and restarted the app. It booted up with the war from the pipeline, as intended. I will not be using the Azure plugin for Eclipse any longer, as it appears incompatible with Azure DevOps pipelines.

Assuming you created your sonarqube Service in the defaultnamespace, and using SonarQube default ports, your portal URL would be http://sonarqube.default.svc:9000.

you add the server to balancer then create NAT rule to forward the packet to specific port on your VM. https://argonsys.com/microsoft-cloud/library/manage-port-forwarding-for-backend-pool-with-azure-load-balancer/

You can also configure Azure Functions with NLog: https://github.com/NLog/NLog.Extensions.Logging/wiki/NLog-cloud-logging-with-Azure-function-or-AWS-lambda Here you can find a sample that shows an Azure Function with NLog and GrayLog https://www.gokhan-gokalp.com/en/logging-api-requests-and-responses-to-graylog-over-azure-api-management-using-azure-functions/ nlog.config:

If anyone else has the same issue, please double-check your AKS configuration in Azure and make sure that the Network policy filed in the Networking settings does NOT display None. It should say either Azure or Calico. My cluster was created with terraform and even though I had added network_plugin = "azure", I had missed the network_policy = "azure" field which meant that Network Policies would not be applied. Also, this setting can only be enabled when creating a new cluster. You cannot enabled it on an existing one.

You need to explicitly check out your source code, https://docs.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops : A deployment job doesn't automatically clone the source repo. You can checkout the source repo within your job with checkout: self. Deployment jobs only support one checkout step. strategy: runOnce: deploy: steps: - checkout: self - task: Docker@2 displayName: Build and push an image to container registry inputs: command: buildAndPush repository: $(imageRepository) dockerfile: $(Build.SourcesDirectory)/Dockerfile containerRegistry: $(dockerRegistryServiceConnection) tags: | $(tag)

I think the geolocation of the IP address is generally quite accurate - this is from 15 years of my own anecdotal experience. I can only recall ever having seen an IP address having moved to th "wrong" location once some time in the 2000s. In terms of what region is "nearest" - it seems geography is secondary to geopolitics and how fibre-cables are layed. This github project: https://github.com/turnkeylinux/aws-datacenters maintains a list of fibre cables and AWS locations, I've extended it before to look at the latest AWS regions and so it can be used for other public cloud providers as well. Some (maybe) surprising latency results I found working with people: Norway seems to have better latency to North America than to central Europe (feedback from in-country technical person) Israel better latency to Frankfurt than to Bahrain or Mumbai Also given this story and others as part of fallout from the Snowden releases https://www.dw.com/en/call-me-a-german-satellite-and-internet-company-wants-answers-from-the-nsa/a-17571811 I would assume that for low latency to most of Northern Africa and Western Middle East, you are best to choose a server location in Germany or Italy.

Use the following configuration key: . . "temp_compute_name": "", . . Note: Try to keep name short.

Usually in Azure Vm you should pool disks (P30 or P40) to achieve higher level of troughput. If you need different drives i suggest creating differend storage pools. This way gives you better IO performance that usually is great for databases, but gives you difficulties to enlarge drives. Enlarge drives inside a storage pool is not possible, but you can add more disks to the pool as an alternative.

You can do this with https://www.microsoft.com/en-us/download/details.aspx?id=53595 . Here's a tutorial: https://docs.microsoft.com/en-us/azure/dms/tutorial-sql-server-to-azure-sql

You will need to change the containment option first before you can create a contained user in Azure SQL Managed Instance. It is done by default for the Azure SQL database. Azure SQL Managed Instance behaves like SQL Server on-premises in the context of contained databases. Be sure to change the context of your database from the master database to the user database when creating your contained user. Additionally, there should be no active connections to the user database when setting the containment option. Example code: USE MASTER; GO ALTER DATABASE Test SET RESTRICTED_USER WITH ROLLBACK IMMEDIATE; ALTER DATABASE Test SET containment=partial; ALTER DATABASE Test SET MULTI_USER; USE Test; GO CREATE USER Carlo WITH PASSWORD='Enterpwdhere*' SELECT containment_desc FROM sys.databases WHERE name='Test' Reference: https://docs.microsoft.com/en-us/sql/relational-databases/security/contained-database-users-making-your-database-portable?view=sql-server-ver15