This patch addresses an issue introduced in the original Azure DevOps Server release that, under certain conditions, could cause group memberships to become deactivated.

Who should install this patch

This patch applies to customers who installed Azure DevOps Server prior to the March 13, 2026 re‑published release. If you previously applied the mitigation described in earlier guidance, installing Patch 2 completes the remediation. Customers who have not run the mitigation script do not need to do so, installing Patch 2 is sufficient.

Who does not need this patch

Customers performing new installations or upgrades using the re‑published release available as of March 13, 2026.

Azure DevOps Server Patch Download

Verifying Installation

To verify that the patch is installed, run the following command on the Azure DevOps Server machine using the patch installer you downloaded:

<patch-installer>.exe CheckInstall

Replace <patch-installer> with the name of the patch file you downloaded. The command output will indicate whether the patch is installed.

The post March Patches for Azure DevOps Server appeared first on Azure DevOps Blog.

We’re rolling it back temporarily. The restriction will be re-enforced on April 15, 2026.

What you should do

Action is required. The recommended path is a service principal with Advanced Security: Read alerts permissions for your Advanced Security-enabled repositories. Scope it narrowly, and if the service principal isn’t committing code, it won’t consume an Advanced Security committer license.

Status checks in Sprint 272

We’re also shipping status checks soon, which give teams a native way to gate on security posture without API-driven alert mutations from pipeline identities.

This won’t replace every automation scenario, though it enables pull request-time blocking on the presence of high and critical alerts.

Have feedback or hitting gaps moving to a service principal? Let us know.

Action required by April 15: move API automation to a service principal with Advanced Security: Read alerts or watch for status checks in Sprint 272.

The post Temporary rollback: build identities can access Advanced Security: read alerts again appeared first on Azure DevOps Blog.

This update includes a series of visual refinements across the extension, introducing a more consistent design language, smoother transitions when expanding and collapsing sections, improved contrast for better readability, an updated color palette aligned with Azure DevOps, and clearer, more consistent icons throughout the experience.

Side Panel UI Improvements

The side panel has received a complete visual overhaul with a modern, clean design that better integrates with Azure DevOps.

Enhanced Summary View

The Calendar Summary panel has been redesigned with cleaner, more organized cards for Iterations, Days Off, and Events, along with improved spacing that makes the content easier to scan. It now adapts to the available screen space by automatically adjusting how many items are displayed, and when there’s more content, expandable sections let you how more or less as needed.

Organized Event Categories

Events are now organized by category to make navigation easier and more intuitive. Each category can be expanded or collapsed as needed, includes visual color indicators for quick recognition, and displays event counts so you can immediately see how many items are in each group.

Collapsible Sidebar

The side panel can now be collapsed to give you more screen space for viewing your calendar:

Event Color Customization

You can now customize the colors of your event categories to match your preferences or team conventions.

Searchable Teams

Finding and switching between teams is now much easier with the new team search functionality.

Dialog Improvements

Both event and days off dialogs have been updated with better usability. Also a modern date picker.

Summary

This update enhances the overall user experience with a refreshed side panel design, customizable event colors, more intuitive date selection, and improved team navigation. The collapsible sidebar provides greater flexibility when viewing your calendar, and the new team search makes switching between teams in large organizations fast and seamless. All updates are fully compatible with existing functionality.

To use this extension, go download and install the Team Calendar from the Azure DevOps marketplace.

The post Updates to Team Calendar extension appeared first on Azure DevOps Blog.

We are currently in Phase II of this transition. During this phase, you can still replace obsolete policies through Team Explorer. When attempting to check in, you’ll also see a notification indicating that your configuration is out of compliance and still using obsolete policies.

The final phase of this transition is about to be completed. Once it takes effect, any remaining obsolete policies will block all users of the repository from checking in changes. These policies will also no longer be visible or manageable through Visual Studio Team Explorer.

If you are still using obsolete policies at that point, you will need to run a C# code snippet to remove them and restore compliance.

Update Policies with Visual Studio

If you are able to do so, removing the obsolete policies through Team Explorer takes just a few minutes.

1. Open Visual Studio
2. Connect to the project
3. Go to Team Explorer > Settings > Source Control
4. Click on the Check-in Policy tab

5. Add new policies and remove obsolete policies

   

Update policies through C# app

One of the challenges in updating how we store policies is that TFVC is a legacy system. This makes it difficult to deprecate policies without disrupting customers or introducing higher-risk changes to older code paths. This situation highlights the complexities that can arise when updating legacy components. When these policies are deprecated, they are removed from the Team Explorer experience but remain in storage and must still be manually removed.

We strongly recommend replacing any obsolete policies now to avoid disruption. If it is too late and you are blocked, you can create a small C# application and run the provided code to remove the policies and unblock yourself.

Please note that you must be a Project Administrator in order to run the command and remove the obsolete policies.

1. Open Visual Studio

2. Create a new C# Console App using .Net Framework

   

3. Open Solution Explorer. Right click on the project and add select Manage NuGet packages.

   

4. Search for Microsoft.TeamFoundationServer.ExtendedClient and install.

5. Open the Program.cs file and add the following code into the Main method.

   var collectionUri = "https://contoso.visualstudio.com/";
   var currentProjectName = "fabrikam";
   
   using (TfsTeamProjectCollection tpc = new TfsTeamProjectCollection(new Uri(collectionUri)))
   {
       var versionControlServer = tpc.GetService<VersionControlServer>();
       TeamProject teamProject = versionControlServer.GetTeamProject(currentProjectName);
       teamProject.SetCheckinPolicies(null);
   } 
   

6. Update the collectionUri and currentProjectName variables to match your environment.

7. Run the project.

When the code begins to run, you may be prompted to sign in using the same identity you use for Azure DevOps. After signing in, the script will execute and remove the obsolete policies.

Once the process is complete, you can reopen Visual Studio to add policies for your project.

Walk me through it

To learn more about migration and dealing with custom policies, be sure to read our migration guide.

We’ve also put together a short video to guide you through both options for removing obsolete policies.

The post TFVC Remove Existing Obsolete Policies ASAP appeared first on Azure DevOps Blog.

For example, if a work item contains a dozen or more tags and several custom fields, a single card can easily consume a significant portion of your vertical space. In Delivery Plans, we addressed this challenge with the condensed view option, where only the work item Id and title are displayed.

We’re excited to bring the same condensed view capability to both the Kanban and Sprint board pages. With a single click, you can now toggle between the standard card layout and a more compact view that shows only titles.

Before…

After…

As you can see, the condensed view allows you to see significantly more cards on the screen at once, making it easier to scan, triage, and manage large backlogs.

This feature is rolling out as part of the current release and is expected to reach all organizations by early March.

The post Condensed views on Kanban and Sprint boards appeared first on Azure DevOps Blog.

To make it easier to find and apply the latest patches, we are sharing patch details in the table below. Each entry includes the Azure DevOps Server version, a direct download link for the patch, and a link to the corresponding release notes with additional details.

Azure DevOps Server Patch Download

Verifying Installation

To verify that the patch is installed, run the following command on the Azure DevOps Server machine using the patch installer you downloaded:

<patch-installer>.exe CheckInstall

Replace <patch-installer> with the name of the patch file you downloaded. The command output will indicate whether the patch is installed.

The post February Patches for Azure DevOps Server appeared first on Azure DevOps Blog.

One of the top requests from customers using the GitHub Copilot Coding Agent for Azure Boards has been the ability to select and use custom agents defined at the GitHub repository or organization level. In this update, we’re excited to share that support for custom agents is on the way.

What are custom agents?

Custom agents in GitHub Copilot are tailored versions of the Copilot coding agent that you can define once to follow your own workflows, coding conventions, and tool preferences. They act like specialized teammates that consistently apply your team’s standards instead of you repeating the same instructions each time. You configure custom agents using Markdown-based agent profiles that specify prompts, tools, and behaviors.

Example agent

    
---
name: readme-creator
description: Agent specializing in creating and improving README files
---

You are a documentation specialist focused on README files. Your scope is limited to README files or other related documentation files only - do not modify or analyze code files.

Focus on the following instructions:
- Create and update README.md files with clear project descriptions
- Structure README sections logically: overview, installation, usage, contributing
- Write scannable content with proper headings and formatting
- Add appropriate badges, links, and navigation elements
- Use relative links (e.g., `docs/CONTRIBUTING.md`) instead of absolute URLs for files within the repository
- Make links descriptive and add alt text to images

Learn more about Custom Agents

Creating a custom agent

Creating a custom agent involves defining a specialized Copilot coding agent profile that lives in a GitHub repository and includes tailored instructions, tools, and behavior for specific workflows or tasks. You build the custom agent by creating a .agent.md profile file (often in a .github/agents folder) and committing it to a repository. Once merged, that agent appears in the Copilot agents dropdown for use. At the organization level, owners can set up a dedicated .github-private repository to house custom agent profiles that are available across all or selected repositories within the organization. This lets teams standardize custom agents for shared workflows without duplicating agent configurations in each individual repo.

Learn more about creating custom agents and creating custom agents in VS Code

Using the custom agent

Once you have created a custom agent at the repository or organization level, it will automatically be available in Azure DevOps. When you choose to create a pull request from a work item, you’ll see a new agent selection control next to the repository list.

After selecting a custom agent and clicking Create, that agent will be used to generate the code changes and create the pull request in the selected repository.

The post Azure Boards integration with GitHub Copilot includes custom agent support appeared first on Azure DevOps Blog.

Today, filter options are limited, hardcoded, and can vary slightly depending on the page you’re viewing.

With this new feature, you’ll continue to start with the same default filters you’re used to. In addition, you can now open the filter settings and add any field that is already displayed on backlog columns or Kanban cards.

Once you apply your changes, the selected fields immediately become available in the filters control.

Limitations

There are a few limitations you should be aware of.

Fields

• Large text fields are not supported
• Fields that always contain unique values, such as Stack Rank, are not available
• Fields must be added as a backlog column or card field to be available as a filter

Sharing behavior

• If you share a filtered URL and the recipient does not have the same fields configured as filters, those fields will be ignored. To resolve this, add the field as a filter and open the URL again.

Page support

• This feature is currently available only on backlog and board pages
• It is not yet supported on sprint backlogs, sprint boards, query results, or the work items hub

Private preview process

If you’d like early access to this feature, please send me an email with your organization name in the format of dev.azure.com/{organization}. Once enabled, the feature will be available to all users within that organization.

We plan to accept organizations into the private preview until February 6, 2026. After that date, we will close enrollment to focus on collecting feedback, addressing issues, and validating the experience with those preview customers. Our intent is to incorporate what we learn and move quickly toward general availability.

We’re excited to move this feature through private preview and into general availability. It’s been a long time coming!

The post Azure Boards additional field filters (private preview) appeared first on Azure DevOps Blog.

These changes have either already been released or are currently rolling out. Be sure to check the sprint release notes for full details.

Breaking Change: Disabling Obsolete TFVC Check-In Policies

Back in April 2025, we shared changes to how TFVC check-in policies are stored. These updates affect TFVC projects using policies such as Build (require the last build to succeed), Work Item (require an associated work item), Changeset Comments (require users to add a comment to their check-in), and similar rules.

Over the past year, we’ve been guiding customers through migrating existing, obsolete policies to the new storage format and preventing the creation of new ones using the old model. With this release, any remaining check-in policies still using the obsolete format will be disabled. These policies will no longer function, and you’ll need to migrate them to the new format for check-in policies to continue working.

For full details and step-by-step migration guidance, be sure to review our earlier blog post.

Improved Comment Navigation from Pull Request Links

We’ve made improvements to how Azure DevOps handles deep links to pull request comments. When opening a pull request from a direct comment link, focus is now handled more reliably, especially for pull requests with a large number of comments.

This makes it easier to jump directly to the feedback you care about without losing context.

Pull Request Notification Improvements

To help teams better focus on meaningful pull request activity, we’ve updated Azure DevOps email notifications to reduce noise and improve clarity. Several low-value notifications, including draft state changes and auto-complete updates, have been removed entirely.

For the notifications that remain, we’ve simplified the content to highlight what actually changed, such as affected files, while removing redundant details like full reviewer and commit lists. The result is pull request emails that are easier to scan, more actionable, and better aligned with how teams collaborate during code reviews.

Pull Request Templates for Multi-Level Branches

Pull request templates now support nested folder structures that align with multi-level branch names. When you open a pull request targeting a branch like feature/foo/december, Azure DevOps will look for a matching template in the following order:

1. <pull request template path>/branches/feature/foo/december.md
2. <pull request template path>/branches/feature/foo.md
3. <pull request template path>/branches/feature.md

The most specific template available will be applied automatically. This makes it easier to tailor guidance and requirements based on branching conventions without duplicating templates.

Azure DevOps MCP Server

If you haven’t checked it out yet, the local Azure DevOps MCP Server continues to grow with new tools for working with Azure Repos. It enables you to interact with repositories, branches, commits, and pull requests directly from tools like VS Code and GitHub Copilot.

For example, you can fetch repository metadata, list branches, inspect file contents, and explore commit history without navigating the Azure DevOps UI, making it easier to build intelligent tooling and workflows on top of Azure DevOps.

For more information, check out the Azure DevOps MCP Server repo.

Coming Soon

Improved Git Policy Configuration API

We’re working on improvements to the Git policy configuration APIs to make it easier and more efficient to retrieve all policies that apply to a specific repository. This includes policies defined at the repository level as well as those applied to individual branches or refs.

These changes reduce unnecessary API calls and improve performance for services managing policies at scale, while preserving existing policy behavior.

Learn more: Policy Configurations – Get – REST API (Azure DevOps Git) | Microsoft Learn

More Pull Request Improvements Ahead

We have several pull request improvements planned for upcoming sprints, many of which are driven directly by feedback from the Azure DevOps Community. We’re starting with reducing notification noise, as described above, but that’s just the beginning.

We’re also working on improvements such as highlighting pull requests with outstanding comments, allowing authors to reset a pull request back to a “ready for review” state, and adding the ability to filter pull requests by tags.

Together, these changes are focused on making it easier to understand what needs attention and keep reviews moving efficiently.

The post What’s new with Azure Repos? appeared first on Azure DevOps Blog.

And we’re excited to announce that this experience is moving to General Availability (GA) for the Azure DevOps Services throughout January 2026.

Why the New Test Run Hub?

The new hub centralizes test execution for both manual and automated runs, giving teams:

• Real-Time Visibility: Instantly monitor test progress and quality trends to catch regressions before they impact your release.
• Comprehensive Analytics: Dive into historical data with built-in dashboards that break down results by outcome, priority, configuration, and failure type.
• Effortless Management: Use powerful filters such as timeline, run type, pipeline, and more, to find exactly what you need. Customize your view with persistent search and column visibility settings.
• Rich Collaboration: Add screenshots, logs, and artifacts directly to test runs. Link results to work items and collaborate with markdown-enabled comments.
• Programmatic Power: Possible to manage test runs via the Azure DevOps REST API for more advanced automations and integrations.
• Attachment Improvements: Expanded preview capabilities and ability to delete attachments.
• User-Specific Filters: Your filters’ preferences now persist across your sessions.

Your Feedback Matters

Based on your feedback, we’ve made several improvements ahead of General Availability (GA):

• Enhanced search and identification of test runs: You can now search by Test Run ID or Run Title, and look up past runs within any 90-day timeframe.
• More details at a glance: The hub’s landing page now shows additionally Run Title, Last Updated Date, and Owner information for all your runs.
• Inline screenshot preview: Captured test step screenshots are seen directly in each test step.

We’re committed to continuous improvement. Share your ideas and report issues through the Azure DevOps Developer Community.

GA Transition Timeline

Throughout January 2026 all organizations will be automatically transitioned to the new Test Run Hub experience. And after GA, the old (and now legacy) Test Run Hub will be retired and access to it will be discontinued.

Thank You!

A big thank you for your support and collaboration the last months. The new Test Run Hub is here to help you ship faster, reduce risks, and deliver quality with confidence.

The post The New Test Run Hub is Going Generally Available! appeared first on Azure DevOps Blog.