DEV Community

Cover image for Troubleshooting Bicep Updates on Windows Self-Hosted Agents
Ihechi Okere
Ihechi Okere

Posted on

Troubleshooting Bicep Updates on Windows Self-Hosted Agents

#bicep #devops #cicd #azure

🛠️ Resolving Bicep Update Issues in Self-Hosted CI/CD Agents

This post is a follow-up to my previous article on updating Bicep to leverage Microsoft's latest features. In our organization, we use Windows-based self-hosted agents for CI/CD pipelines. While updating Bicep might seem as simple as running a command and moving on, I recently encountered a subtle issue that proved otherwise.

⚠️ The Problem

After running the update command for Bicep, I expected the pipeline to use the latest version. However, it continued to execute using an older version. This was puzzling, especially since the update process had completed without errors.

Initial Troubleshooting Approach

Initially, I suspected a path conflict. Months ago, I had manually placed the Bicep executable in Program Files to avoid copying it over with each update. To streamline future upgrades, I configured a system environment variable pointing to the auto-updated version located in:

C:\Users\<username>\.azure\bin\bicep.exe
Enter fullscreen mode Exit fullscreen mode

Despite confirming that the system path was correctly set, the pipeline still defaulted to the outdated executable.

🔍 Root Cause Discovery

To investigate further, I added a whoami command to the PowerShell script running in the pipeline:

whoami
Enter fullscreen mode Exit fullscreen mode

Surprisingly, the job was being executed by:

NT AUTHORITY\NETWORK SERVICE
Enter fullscreen mode Exit fullscreen mode

This was not the account I had assumed.

✅ The Solution

This discovery led me to check the file permissions on the Bicep executable. Since the machine was domain-joined but the service account was local, I had to explicitly grant NETWORK SERVICE the necessary permissions to read and execute the file.

Here's what I did:

  1. Right-clicked the bicep.exe file
  2. Opened Properties > Security
  3. Added NETWORK SERVICE to the list of users
  4. Granted Read & Execute permissions

Once I updated the file's security settings, the pipeline successfully picked up the correct version of Bicep.

💡 Key Takeaways

If you're using Windows self-hosted agents and encounter issues with updating Bicep—or any other tool—it's worth checking:

  • Service Account Context: Always verify which account is actually executing your pipeline processes
  • Permission Management: System-level path configurations are insufficient if the executing service account lacks proper file permissions
  • Local vs. Domain Accounts: Consider the account type when troubleshooting permission-related issues

This solution applies broadly to similar scenarios involving executable updates for any programs within Windows self-hosted agents, not just Bicep.

Hopefully, this helps someone avoid the same rabbit hole I went down! If you've run into similar issues or have other tips for managing self-hosted agents, feel free to share in the comments.

Thanks for reading! 👋

Top comments (0)