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
