Azure Networking: Request for Granular Control of “Allow Azure Services and Resources”
I would like to get the Azure community’s thoughts on a networking/security improvement that I believe could help organizations implement a stronger least-privilege model. Several Azure resources provide an option similar to: “Allow Azure services and resources to access this resource.” This is useful when an Azure service needs to access another Azure resource, but the current option can be quite broad. Example: Power BI → Azure SQL For example, suppose Power BI Service needs to access an Azure SQL Server. The actual requirement might be: Power BI → Specific Azure SQL Server = Allow However, the available option may require enabling: “Allow Azure services and resources to access this server” This effectively creates a much broader trusted-service exception than the actual requirement. Ideally, I would like to see something like: Azure SQL Server │ ├── Power BI Service → Allow ├── Azure Data Factory → Deny ├── Azure Functions → Deny ├── Azure App Service → Deny └── Other Azure Services → Deny Proposed improvement Could Microsoft provide an additional option such as: “Allow selected Azure services and resources” where customers can explicitly select which Azure service/resource is allowed to bypass the network restriction? Depending on the Azure service, the selection could potentially be based on: Specific Azure service Specific Azure resource Resource ID Subscription Resource group Tenant Managed identity / Entra identity Specific service instance For example: Trusted Azure Services / Resources Power BI → Production Analytics → Allow All other Azure services → Deny Why I think this would be useful This would give customers a middle ground between: Disabling public access and implementing Private Endpoint/private connectivity, or Allowing all Azure services/resources through the broad trusted-service exception. A granular trusted-service model would allow: Only the Azure service/resource that actually requires access is trusted. This would better support least privilege, Zero Trust, security, and compliance requirements. Broader Azure applicability My suggestion is not specifically for Azure SQL. The Power BI → Azure SQL scenario is just an example. I think this could be a common Azure networking capability for all Azure resources that currently support a trusted Azure services / “Allow Azure services and resources” type of bypass. I would be interested to hear from the Azure community and Microsoft: Is there already a way to achieve this level of granularity? Are there architectural/security reasons why this cannot currently be implemented? Is Microsoft considering a more granular trusted-service model? Would a feature like “Allow selected Azure services/resources” be technically feasible? I would appreciate any feedback or guidance from the Azure networking/service teams.
Three Cloud Myths I Believed Before Studying Azure Fundamentals
While preparing for AZ-900, I realized that several assumptions I had about cloud computing were incomplete. ☁️ Myth 1: The cloud is always cheaper Cloud services can reduce upfront costs, but unused resources, incorrect sizing, and poor planning can quickly increase the bill. 🖥️ Myth 2: The cloud means there are no servers The physical infrastructure still exists. What changes is how much of it is managed by the cloud provider. ⚙️ Myth 3: More control is always better Additional control also means additional responsibility for patching, monitoring, configuration, security, and maintenance. My biggest takeaway was that cloud computing is not automatically cheaper, simpler, or better. It is about finding the right balance between cost, control, responsibility, and speed. For beginners interested in exploring these concepts, Microsoft Learn provides an official learning path: https://learn.microsoft.com/en-us/training/courses/az-900t00?wt.mc_id=studentamb_615882 Which cloud misconception did you believe when you first started learning?Find out a server with Azure AD Connect
Hi All, Normally, if someone need to find on which server Azure AD Connect is installed it can be done in Azure portal under Microsoft Entra Connect - Microsoft Entra Connect Health - Sync Services. Is there any way to find out on which server Azure AD Connect is installed if Microsoft Entra Connect Health is not installed or its service stopped? I know in this case no server will be displayed under Microsoft Entra Connect Servers. The reason why I'm asking, someone deployed Azure AD Connect and ran syncing but for unknown reason stopped Azure AD Connect Health service. Because of that I couldn't find on which server Azure AD Connect tool was installed until that person advised. If he didn't tell me I most likely would need to sign in to each production server to check. However, just wondering if it can be done with some PowerShell command. Thanks.
Cost increases when selecting Amortised cost in cost analysis
Hi, this seems like a bug. When i select Amortized cost in Cost analysis, our monthly cost jumps from $25,664.54 to $76,315.83. The resource that causes the jump is a Reservation for a D4asv5 virtual machine. It jumps to $3,120.09 per day. Can someone please try it their side.
Docker Engine v29 on Linux: Why data-root No Longer Prevents OS Disk Growth (and How to Fix It)
Scope Applies to Linux hosts only Does not apply to Windows or Docker Desktop Problem Summary After upgrading to Docker Engine v29 or reimaging Linux nodes with this version, you may observe unexpected growth on the OS disk, even when Docker is configured with a custom data-root pointing to a mounted data disk. This commonly affects cloud environments (VMSS, Azure Batch, self‑managed Linux VMs) where the OS disk is intentionally kept small and container data is expected to reside on a separate data disk. What Changed in Docker Engine v29 (Linux) Starting with Docker Engine 29.0, containerd’s image store becomes the default storage backend on fresh installations. Docker explicitly documents this behavior: “The containerd image store is the default storage backend for Docker Engine 29.0 and later on fresh installations.” Docker containerd image store documentation Key points on Linux: Docker now delegates image and snapshot storage to containerd containerd uses its own content store and snapshotters Docker’s traditional data-root setting no longer controls all container storage Docker Engine v29 was released on 11 November 2025, and this behavior is by design, not a regression. Where Disk Usage Goes on Linux Docker’s daemon documentation clarifies the split: Legacy storage (pre‑v29 or upgraded installs): All data under /var/lib/docker Docker Engine v29 (containerd image store enabled): Images & snapshots → /var/lib/containerd Other Docker data (volumes, configs, metadata) → /var/lib/docker Crucially: “The data-root option does not affect image and container data stored in /var/lib/containerd when using the containerd image store.” Docker daemon data directory documentation This explains why OS disk usage continues to grow even when data-root is set to a data disk. Why the Old Configuration Worked Before On earlier Docker versions, Docker fully managed image and snapshot storage. Configuring: { "data-root": "/mnt/docker-data" } Was sufficient to redirect all container storage off the OS disk. With Docker Engine v29: containerd owns image and snapshot storage data-root only affects Docker‑managed data OS disk growth after upgrades or reimages is expected behavior This aligns fully with Docker’s documented design changes. Linux Workaround: Redirect containerd Storage To restore the intended behavior on Linux, keeping both Docker and containerd storage on the mounted data disk, containerd’s storage path must also be redirected. A practical workaround is to relocate /var/lib/containerd using a symbolic link. Example (Linux) sudo systemctl stop docker.socket docker containerd || true; sudo mkdir -p /mnt/docker-data /mnt/containerd; sudo rm -rf /var/lib/containerd; sudo ln -s /mnt/containerd /var/lib/containerd; echo "{\"data-root\": \"/mnt/docker-data\"}" | sudo tee /etc/docker/daemon.json; sudo systemctl daemon-reload; sudo systemctl start containerd docker' What This Does Stops Docker and containerd Creates container storage directories on the mounted data disk Redirects /var/lib/containerd → /mnt/containerd Keeps Docker’s data-root at /mnt/docker-data Restarts services with a unified storage layout This workaround is effective because it explicitly accounts for containerd‑managed paths introduced in Docker Engine v29, restoring the behavior that existed prior to the change. Key Takeaways Docker Engine v29 introduces a fundamental storage architecture change on Linux data-root alone is no longer sufficient OS disk growth after upgrades or reimages is expected containerd storage must also be redirected The workaround aligns with Docker’s official documentation and design References Docker daemon data directory https://docs.docker.com/engine/daemon/ containerd image store (Docker Engine v29) https://docs.docker.com/engine/storage/containerd/ Docker Engine v29 release notes https://docs.docker.com/engine/release-notes/29/Azure VM resize: PowerShell lists Dv5 sizes, but Azure Portal only offers Dv4
Hello, We recently migrated two production Azure virtual machines away from the retiring Bv1 family. Initially, the VMs were running as: Standard_B2ms Standard_B4ms Our goal was to move them to a newer supported VM family. Environment Region: France Central Managed OS disks (one Standard SSD, one Standard HDD/Standard LRS) SCSI disk controller Windows Server virtual machines What we observed After stopping and deallocating the VM, we queried the available resize targets using PowerShell: Get-AzVMSize ` -ResourceGroupName "<ResourceGroup>" ` -VMName "<VMName>" For one VM, PowerShell returned, among others: Standard_D2ads_v5 Standard_D2ds_v5 Standard_D2d_v5 Standard_D2as_v4 Standard_D2ds_v4 For the other VM, it returned: Standard_D4ads_v5 Standard_D4ds_v5 Standard_D4d_v5 Standard_D4as_v4 However, when opening VM → Size in the Azure Portal, the v5 sizes were not available. Only the following sizes appeared: Standard_D2as_v4 Standard_D4as_v4 As a precaution, we resized both VMs using the sizes proposed by the Azure Portal: Standard_B2ms → Standard_D2as_v4 Standard_B4ms → Standard_D4as_v4 The migration completed successfully and both VMs are running correctly. Question Can someone explain why there is a difference between: the sizes returned by Get-AzVMSize, and the sizes displayed by the Azure Portal? More specifically: Does Get-AzVMSize return VM sizes that are not actually valid resize targets? Does the Azure Portal apply additional compatibility or capacity checks that PowerShell does not? Is this related to: regional capacity, VM generation, disk controller, managed disk type, host cluster, or another compatibility requirement? Would you recommend staying on Das_v4, or should we plan another migration to Dads_v5 if possible? I am trying to understand the reason behind the different behavior rather than forcing the resize through PowerShell. Thank you in advance for your insights.
Building Production-Ready Pipelines in Azure DevOps: Beyond the Documentation Examples
Hi everyone, When moving from basic Azure DevOps tutorials to enterprise production environments, we all quickly realize that documentation examples don't always cover real-world complexities. Handling multi-stage dependencies, keeping Terraform state secure, and managing secrets across environments requires a highly strategic approach. To help DevOps engineers bridge this gap, I recently put together a deep-dive architecture breakdown detailing how to build a resilient, multi-stage YAML pipeline from scratch. Here is a quick look at the core enterprise architecture I focus on: - Multi-Stage Lifecycle: Safe progression flows through Build, Dev, QA, UAT, and Production stages. - Infrastructure Automation: Clean integration with Terraform, including state and secrets management using Azure Key Vault. - Security Gates: Implementation of SAST scanning, Workload Identity, and automated approval policies. - Team Alignment: Connecting Azure DevOps with project tools like Asana to streamline cross-platform tracking. I wanted to share this pattern here to get some community feedback on the YAML structure. Before I post the full configuration snippets, I would love to hear how your teams handle environment gates and approvals. What are the biggest bottlenecks you run into with multi-stage YAML pipelines? Let's discuss in the comments below! Best regards, Abdullah Shahid
Azure support team not responding to support request
I am posting here because I have not received a response to my support request despite my plan stating that I should hear back within 8 hours. It has now gone a day beyond that limit, and I am still waiting for assistance with this urgent matter. This issue is critical for my operations, and the delay is unacceptable. The ticket/reference number for my original support request was 2410100040000309. And I have created a brand new service request with ID 2412160040010160. I need this addressed immediately.
DevOps REST API - identity picker (query on list of users)
I'm using DevOps REST API via OAuth 2.0 to populate the fields of work item types. For "identity" fields, such as "System.AssignedTo", I'm having a hard time trying to figure out the best API that allows to retrieve a searchable list of users that mirrors what users see on DevOps website. From the browser inspector I saw the website calls this API, which is not documented: [POST] https://dev.azure.com/MY_ORGANIZATION/_apis/IdentityPicker/Identities as also noted on another discussion. But when I call this API (with the very same request body) from my local server I get a 401 response status code, and HTML content instead of the anticipated JSON. In Microsoft Entra Admin Center, I made sure to include "vso.identity" API permission for my app registration. What am I missing here? If I cannot use this API, what's the best alternative? I saw the https://learn.microsoft.com/en-us/rest/api/azure/devops/ims/identities/read-identities?view=azure-devops-rest-7.0&tabs=HTTP, but when I try to load it on the browser I always get zero results. E.g. https://vssps.dev.azure.com/MY_ORGANIZATION/_apis/identities?api-version=7.0&searchFilter=DisplayName&filterValue=SEARCH_TERM { "count": 0, "value": [] } Also, all the REST APIs I used so far are on https://dev.azure.com. How is https://vssps.dev.azure.com any different? Can I call APIs on a different host with the same OAuth access token?Building Production-Ready Pipelines in Azure DevOps: Beyond the Documentation Examples
Hi everyone, When moving from basic Azure DevOps tutorials to enterprise production environments, we all quickly realize that documentation examples don't always cover real-world complexities. Handling multi-stage dependencies, keeping Terraform state secure, and managing secrets across environments requires a highly strategic approach. To help DevOps engineers bridge this gap, I recently put together a deep-dive architecture breakdown detailing how to build a resilient, multi-stage YAML pipeline from scratch. Here is a quick look at the core enterprise architecture I focus on: - Multi-Stage Lifecycle: Safe progression flows through Build, Dev, QA, UAT, and Production stages. - Infrastructure Automation: Clean integration with Terraform, including state and secrets management using Azure Key Vault. - Security Gates: Implementation of SAST scanning, Workload Identity, and automated approval policies. - Team Alignment: Connecting Azure DevOps with project tools like Asana to streamline cross-platform tracking. I wanted to share this pattern here to get some community feedback on the YAML structure. Before I post the full configuration snippets, I would love to hear how your teams handle environment gates and approvals. What are the biggest bottlenecks you run into with multi-stage YAML pipelines? Let's discuss in the comments below! Best regards, Abdullah Shahid
