Forum Widgets
Latest Discussions
Cloud-Native vs. Hybrid for the 2026 Workplace
When to choose Cloud-Native vs. Hybrid for the 2026 Workplace? Hi everyone, I am starting a discussion on the foundational phase of one project. As a Computer Engineer, I believe the most critical decision we face in 2026 is determining exactly when to step to a Full Cloud model versus maintaining a Hybrid Infrastructure. In my view, the decision is not about cost, it is about resiliency, high availability and more avalability. I would like to exchange views with other engineers on these area: latency, edge requirements, integration and aglility. In your experience, what are the Tipps that makes you choose one over the other for a 2026 environment? I'm looking for technical architectural insights, not sales approaches.
Patterns for low-code Azure config state snapshot + recovery solution for resource groups
I’m looking for patterns that capture resource configuration changes over time and support best-effort recovery (redeployment) of resource config state. I understand that authoritative IaC (Bicep) would be the most mature option, however, I am wondering if anyone has ever implemented a solution similar to what I have described above. Ideally this would be a low-code, Azure native solution.
Using Github Copilot from Azure Subscription
Hello, I have a question on how GitHub Copilot can be accessed and managed through an Azure subscription. If I am getting a Github Copilot license, how is my azure subscription getting linked to the billing and licensing? Specifically, I would like clarification on how the Azure subscription is linked to GitHub Copilot billing and licensing.
Azure Artifact Signing: SignTool "Access is denied" with active Public Trust profile
I’m blocked on Azure Artifact Signing for Windows EXE signing. What is already confirmed: - Account endpoint: https://wus2.codesigning.azure.net/ - Code signing account: notarios - Certificate profile: notarios-public-trust (Public Trust, Active) - Identity validation: Completed - User object id: 9aa27294-c04d-4aab-a7b2-3a8b10be96f9 - RBAC includes: - Artifact Signing Identity Verifier - Artifact Signing Certificate Profile Signer (also assigned at certificate profile scope) Signing command (signtool 10.0.26100.0 x64 + dlib): ... sign /v /debug /fd SHA256 /tr http://timestamp.acs.microsoft.com /td SHA256 /dlib "<...>\\Azure.CodeSigning.Dlib.dll" /dmdf "C:\temp\metadata-corr.json" "C:\temp\notarial-app-test.exe" Error every time: - SignTool Error: Access is denied. - Number of files successfully Signed: 0 I also tested Azure CLI auth and explicit AccessToken in metadata; same result. CorrelationId for troubleshooting: - notarios-20260425-1859 If anyone from Microsoft can check backend logs for that CorrelationId, I’d appreciate the exact reason and remediation.Azure RBAC Custom Role Best Practices or Common Build Patterns
As a platform admin, I want to grant application admins Contributor access while removing their ability to write or delete most Microsoft.Network resource types, with a few exceptions such as Private Endpoints, Network Interfaces, and Application Gateways. Based on the effective control plane permissions logic, we designed two custom roles. The first role is a duplicate of the Contributor role, but with Microsoft.Network//Write and Microsoft.Network//Delete added to notActions. The second role adds back specific Microsoft.Network operations using wildcarded resource types, such as Microsoft.Network/networkInterfaces/*. Application Admin Effective Permissions = Role 1 (Contributor - Microsoft.Network) + Role 2 (for example, Microsoft.Network/networkInterfaces/, Microsoft.Network/networkSecurityGroups/, Microsoft.Network/applicationGateways/write, etc.) I understand that Microsoft RBAC best practices recommend avoiding wildcard (*) operations. However, my team has found that building roles with individual operations is extremely tedious and time-consuming, especially when trying to understand the impact of each operation. Does anyone have suggestions for a simpler or more maintainable pattern for implementing this type of custom RBAC design?Legacy SSRS reports after upgrading Azure DevOps Server 2020 to 2022 or 25H2
We are currently planning an upgrade from Azure DevOps Server 2020 to Azure DevOps Server 2022 or 25H2, and one of our biggest concerns is reporting. We understand that Microsoft’s recommended direction is to move to Power BI based on Analytics / OData. However, for on-prem environments with a large number of existing SSRS reports, rebuilding everything from scratch would require significant time and effort. Since Warehouse and Analysis Services are no longer available in newer versions, we would like to understand how other on-prem teams are handling legacy SSRS reporting during and after the upgrade. Have you rebuilt your reports in Power BI, moved to another reporting approach, or found a practical way to keep existing SSRS reports available during the transition? Any real-world experience, lessons learned, or recommended approaches would be greatly appreciated.
Running Commands Across VM Scale Set Instances Without RDP/SSH Using Azure CLI Run Command
If you’ve ever managed an Azure Virtual Machine Scale Set (VMSS), you’ve likely run into this situation: You need to validate something across all nodes, such as: Checking a configuration value Retrieving logs Applying a registry change Confirming runtime settings Running a quick diagnostic command And then you realize: You’re not dealing with two or three machines you’re dealing with 40… 80… or even hundreds of instances. The Traditional Approach (and Its Limitations) Historically, administrators would: Open RDP connections to Windows nodes SSH into Linux nodes Execute commands manually on each instance While this may work for a small number of machines, in real‑world environments such as: Azure Batch (user‑managed pools) Azure Service Fabric (classic clusters) VMSS‑based application tiers This approach quickly becomes: Operationally inefficient Time‑consuming Sometimes impossible Especially when: RDP or SSH ports are blocked Network Security Groups restrict inbound connectivity Administrative credentials are unavailable Network configuration issues prevent guest access Azure Run Command To address this, Azure provides a built‑in capability to execute commands inside virtual machines through the Azure control plane, without requiring direct guest OS connectivity. This feature is called Run Command. You can review the official documentation here: Run scripts in a Linux VM in Azure using action Run Commands - Azure Virtual Machines | Microsoft Learn Run scripts in a Windows VM in Azure using action Run Commands - Azure Virtual Machines | Microsoft Learn Run Command uses the Azure VM Agent installed on the virtual machine to execute PowerShell or shell scripts directly inside the guest OS. Because execution happens via the Azure control plane, you can run commands even when: RDP or SSH ports are blocked NSGs restrict inbound access Administrative user configuration is broken In fact, Run Command is specifically designed to troubleshoot and remediate virtual machines that cannot be accessed through standard remote access methods. Prerequisites & Restrictions. Before using Run Command, ensure the following: VM Agent installed and in Ready state Outbound connectivity from the VM to Azure public IPs over TCP 443 to return execution results. If outbound connectivity is blocked, scripts may run successfully but no output will be returned to the caller. Additional limitations include: Output limited to the last 4,096 bytes One script execution at a time per VM Interactive scripts are not supported Maximum execution time of 90 minutes Full list of restrictions and limitations are available here: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command?tabs=portal%2Cpowershellremove#restrictions Required Permissions (RBAC) Executing Run Command requires appropriate Azure RBAC permissions. Action Permission List available Run Commands Microsoft.Compute/locations/runCommands/read Execute Run Command Microsoft.Compute/virtualMachines/runCommand/action The execution permission is included in: Virtual Machine Contributor role (or higher) Users without this permission will be unable to execute remote scripts through Run Command. Azure CLI: az vm vs az vmss When using Azure CLI, you’ll encounter two similar‑looking commands that behave very differently. az vm run-command invoke Used for standalone VMs Also used for Flexible VM Scale Sets Targets VMs by name az vmss run-command invoke Used only for Uniform VM Scale Sets Targets instances by numeric instanceId (0, 1, 2, …) Example: az vmss run-command invoke --instance-id <id> Unlike standalone VM execution, VMSS instances must be referenced using the parameter "--instance-id" to identify which scale set instance will run the script. Important: Uniform vs Flexible VM Scale Sets This distinction is critical when automating Run Command execution. Uniform VM Scale Sets Instances are managed as identical replicas Each instance has a numeric instanceId Supported by az vmss run-command invoke Flexible VM Scale Sets Each instance is a first‑class Azure VM resource Instance identifiers are VM names, not numbers az vmss run-command invoke is not supported Must use az vm run-command invoke per VM To determine which orchestration mode your VMSS uses: az vmss show -g "${RG}" -n "${VMSS}" --query "orchestrationMode" -o tsv Windows vs Linux Targets Choose the appropriate command ID based on the guest OS: Windows VMs → RunPowerShellScript Linux VMs → RunShellScript Example Scenario - Retrieve Hostname From All VMSS Instances The following examples demonstrate how to retrieve the hostname from all VMSS instances using Azure CLI and Bash. Flexible VMSS, Bash (Azure CLI) RG="<ResourceGroup>" VMSS="<VMSSName>" SUBSCRIPTION_ID="<SubscriptionID>" az account set --subscription "${SUBSCRIPTION_ID}" VM_NAMES=$(az vmss list-instances \ -g "${RG}" \ -n "${VMSS}" \ --query "[].name" \ -o tsv) for VM in $VM_NAMES; do echo "Running on VM: $VM" az vm run-command invoke \ -g "${RG}" \ -n "$VM" \ --command-id RunShellScript \ --scripts "hostname" \ --query "value[0].message" \ -o tsv done Uniform VMSS, Bash (Azure CLI) RG="<ResourceGroup>" VMSS="<VMSSName>" SUBSCRIPTION_ID="<SubscriptionID>" az account set --subscription "${SUBSCRIPTION_ID}" INSTANCE_IDS=$(az vmss list-instances -g "${RG}" -n "${VMSS}" --query "[].instanceId" -o tsv) for ID in $INSTANCE_IDS; do echo "Running on instanceId: $ID" az vmss run-command invoke \ -g "${RG}" \ -n "${VMSS}" \ --instance-id "$ID" \ --command-id RunShellScript \ --scripts "hostname" \ --query "value[0].message" \ -o tsv done Summary Azure Run Command provides a scalable method to: Execute diagnostics Apply configuration changes Collect logs Validate runtime settings …across VMSS instances without requiring RDP or SSH connectivity. This significantly simplifies operational workflows in large‑scale compute environments such as: Azure Batch (user‑managed pools) Azure Service Fabric classic clusters VMSS‑based application tiers
Excited to share my latest open-source project: KubeCost Guardian
After seeing how many DevOps teams struggle with Kubernetes cost visibility on Azure, I built a full-stack cost optimization platform from scratch. 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗱𝗼𝗲𝘀: ✅ Real-time AKS cluster monitoring via Azure SDK ✅ Cost breakdown per namespace, node, and pod ✅ AI-powered recommendations generated from actual cluster state ✅ One-click optimization actions ✅ JWT-secured dashboard with full REST API 𝗧𝗲𝗰𝗵 𝗦𝘁𝗮𝗰𝗸: - React 18 + TypeScript + Vite - Tailwind CSS + shadcn/ui + Recharts - Node.js + Express + TypeScript - Azure SDK (@azure/arm-containerservice) - JWT Authentication + Azure Service Principal 𝗪𝗵𝗮𝘁 𝗺𝗮𝗸𝗲𝘀 𝗶𝘁 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁: Most cost tools show you generic estimates. KubeCost Guardian reads your actual VM size, node count, and cluster configuration to generate recommendations that are specific to your infrastructure not averages. For example, if your cluster has only 2 nodes with no autoscaler enabled, it immediately flags the HA risk and calculates exactly how much you'd save by switching to Spot instances based on your actual VM size. This project is fully open-source and built for the DevOps community. ⭐ GitHub: https://github.com/HlaliMedAmine/kubecost-guardian This project represents hours of hard work, and passion. I decided to make it open-source so everyone can benefit from it 🤝 ,If you find it useful, I’d really appreciate your support . Your support motivates me to keep building and sharing more powerful projects 👌. More exciting ideas are coming soon… stay tuned! 🔥.Pipeline Intelligence is live and open-source real-time Azure DevOps monitoring powered by AI .
Every DevOps team I've worked with had the same problem: Slow pipelines. Zero visibility. No idea where to start. So I stopped complaining and built the solution. So I built something about it. ⚡ Pipeline Intelligence is a full-stack Azure DevOps monitoring dashboard that: ✅ Connects to your real Azure DevOps organization via REST API ✅ Detects bottlenecks across all your pipelines automatically ✅ Calculates exactly how much time your team is wasting per month ✅ Uses Gemini AI to generate prioritized fixes with ready-to-paste YAML solutions ✅ JWT-secured, Docker-ready, and fully open-source Tech Stack: → React 18 + Vite + Tailwind CSS → Node.js + Express + Azure DevOps API v7 → Google Gemini 1.5 Flash → JWT Authentication + Docker 𝗪𝗵𝗮𝘁 𝗺𝗮𝗸𝗲𝘀 𝗶𝘁 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁? Most tools show you generic estimates. Pipeline Intelligence reads your actual cluster config, node count, and pipeline structure and gives you recommendations specific to your infrastructure. 🎯 This year, I set myself a personal challenge: Build and open-source a series of production-grade tools exclusively focused on Azure services tools that solve real problems for real DevOps teams. This project represents weeks of research, architecture decisions, and late-night debugging sessions. I'm sharing it with the community because I believe great tooling should be accessible to everyone not locked behind enterprise paywalls. If this resonates with you, I have one simple ask: 👉 A like, a comment, or a share takes 3 seconds but it helps this reach the DevOps engineers who need it most. Your support is what keeps me building. ❤️ GitHub: https://github.com/HlaliMedAmine/pipeline-intelligence
Building a Production-Ready Azure Lighthouse Deployment Pipeline with EPAC
Recently I worked on an interesting project for an end-to-end Azure Lighthouse implementation. What really stood out to me was the combination of Azure Lighthouse, EPAC, DevOps, and workload identity federation. The deployment model was so compelling that I decided to build and validate the full solution hands-on in my own personal Azure tenants. The result is a detailed article that documents the entire journey, including pipeline design, implementation steps, and the scripts I prepared along the way. You can read the full article here
