Merge branch 'main'

Author: Steve Danielson

.openpublishing.redirection.json

@@ -7152,11 +7152,11 @@
     },
     {
       "source_path": "docs/boards/backlogs/office/resolve-excel-data-validation-errors.md",
-      "redirect_url": "/azure/devops/boards/backlogs/office/tfs-office-integration-issues.md#resolve-data-validation-errors-that-occur-when-you-publish-from-Excel"
+      "redirect_url": "/azure/devops/boards/backlogs/office/tfs-office-integration-issues#resolve-data-validation-errors-that-occur-when-you-publish-from-Excel"
     },
     {
       "source_path": "docs/boards/backlogs/office/resolve-excel-data-conflicts-publish-refresh.md",
-      "redirect_url": "/azure/devops/boards/backlogs/office/tfs-office-integration-issues#Resolve-data-conflicts-when-you-publish-or-refresh-Excel-data"
+      "redirect_url": "/azure/devops/boards/backlogs/office/tfs-office-integration-issues#resolve-data-conflicts-when-you-publish-or-refresh-Excel-data"
     },
     {
       "source_path": "docs/extend/extension-report.md",

docs/boards/github/link-to-from-github.md

@@ -8,7 +8,7 @@ ms.author: chcomley
 author: chcomley
 ms.topic: quickstart
 monikerRange: "<=azure-devops"
-ms.date: 10/02/2024
+ms.date: 04/23/2025
 ---
 
 # Link GitHub commits, pull requests, branches, and issues to work items in Azure Boards
@@ -41,13 +41,20 @@ AB#{ID}
 
 For example, `AB#125` links to work item ID 125.
 
-You can also enter a commit or pull request message to transition the work item. The system recognizes `fix`, `fixes`, and `fixed`, and applies it to the #-mention item that follows. Mentioned work items transition to the first **State** associated with the *Resolved* workflow category state. If no **State** is associated with *Resolved*, the work item transitions to the **State** associated with the *Completed* workflow category state. For more information, see [How workflow category states are used in Azure Boards backlogs and boards](../work-items/workflow-and-state-categories.md).
+You can also enter a commit or pull request message to transition the work item. The system recognizes `{state}` or `{state category}`, along with `fix`, `fixes`, `fixed`, and applies it to the #-mention item that follows. 
+
+When a pull request description includes a valid state name, for example, ``Closed AB#1234``, the system updates the referenced work item to that specific state. If the state name isn’t recognized directly, Azure Boards tries to match it to a workflow category like ``Resolved`` or ``Completed``. If a match is found, the work item transitions to the first available state defined under that category.
+
+By default, work items referenced with ``fix``, ``fixes``, or ``fixed`` transitions to the first state associated with the **Resolved** category. If no such state exists in the current process, the system instead transitions the work item to the first state in the **Completed** category.
+
+For more information, see [How workflow category states are used in Azure Boards backlogs and boards](../work-items/workflow-and-state-categories.md).
 
 Review the following table of examples:
 
 | Commit or pull request message              | Action |
 | :------------------------------------------ | :----------------------------------------------- |
 | `Fixed AB#123`                              | Links and transitions the work item to the *Resolved* workflow state category or, if none is defined, then the *Completed* workflow state category. |
+| `Closed AB#123`                             | Links and transitions the work item to the *Closed* workflow state. If none is defined, no transitions are made. 
 | `Adds a new feature, fixes AB#123.`         | Links and transitions the work item to  the *Resolved* workflow state category or, if none is defined, then the *Completed* workflow state category. |
 | `Fixes AB#123, AB#124, and AB#126`          | Links to Azure Boards work items 123, 124, and 126. Transitions only the first item, 123 to the *Resolved* workflow state category or, if none is defined, then the *Completed* workflow state category.|
 | `Fixes AB#123, Fixes AB#124, Fixes AB#125` | Links to Azure Boards work items 123, 124, and 126. Transitions all items to   either the *Resolved* workflow state category or, if none is defined, then the *Completed* workflow state category. |

docs/cli/azure-devops-cli-in-yaml.md

@@ -174,18 +174,18 @@ trigger:
 # Run on multiple Microsoft-hosted agent images
 strategy:
   matrix:
+    linux24:
+      imageName: "ubuntu-24.04"
     linux22:
       imageName: "ubuntu-22.04"
-    linux20:
-      imageName: "ubuntu-20.04"
+    mac15:
+      imageName: "macos-15"
+    mac14:
+      imageName: "macos-14"
     mac13:
       imageName: "macos-13"
-    mac12:
-      imageName: "macos-12"
-    mac11:
-      imageName: "macos-11"
-    windows2019:
-      imageName: "windows-2019"
+    windows2025:
+      imageName: "windows-2025"
     windows2022:
       imageName: "windows-2022"
   maxParallel: 3
@@ -226,18 +226,18 @@ trigger:
 # Run on multiple Microsoft-hosted agent images
 strategy:
   matrix:
+    linux24:
+      imageName: "ubuntu-24.04"
     linux22:
       imageName: "ubuntu-22.04"
-    linux20:
-      imageName: "ubuntu-20.04"
+    mac15:
+      imageName: "macos-15"
+    mac14:
+      imageName: "macos-14"
     mac13:
       imageName: "macos-13"
-    mac12:
-      imageName: "macos-12"
-    mac11:
-      imageName: "macos-11"
-    windows2019:
-      imageName: "windows-2019"
+    windows2025:
+      imageName: "windows-2025"
     windows2022:
       imageName: "windows-2022"
   maxParallel: 3

docs/managed-devops-pools/configure-security.md

@@ -450,12 +450,42 @@ The `permissionProfile` property can be set during pool creation only. Allowed v
 
 ## Key Vault configuration
 
-Managed DevOps Pools offers the ability to fetch certificates from an Azure Key Vault during provisioning, which means the certificates will already exist on the machine by the time it runs your Azure DevOps pipelines. To use this feature, you must configure an [identity on your pool](configure-identity.md), and this identity must have **Key Vault Secrets User** permissions to fetch the secret from your Key Vault. To assign your identity to the **Key Vault Secrets User** role, see [Provide access to Key Vault keys, certificates, and secrets with an Azure role-based access control](/azure/key-vault/general/rbac-guide).
+Managed DevOps Pools offers the ability to fetch certificates from an Azure Key Vault during provisioning, which means the certificates will already exist on the machine by the time it runs your pipelines. 
+
+To use this feature, you must:
+- Configure an [identity on your pool](configure-identity.md), and this identity must have **Key Vault Secrets User** permissions to fetch the secret from your Key Vault. To assign your identity to the **Key Vault Secrets User** role, see [Provide access to Key Vault keys, certificates, and secrets with an Azure role-based access control](/azure/key-vault/general/rbac-guide).
+
+- The principal configuring the Key Vault integration settings (if you are configuring the Key Vault settings, then your account) must have the **Key Vault Certificate User** role assignment on the Key Vault where the certificates are stored.
 
 > [!NOTE]
 > As of `api-version 2025-01-21`, if you use this feature you can only use a single identity on the pool. Support for multiple identities will be added soon.
 > 
 > Only one identity can be used to fetch secrets from the Key Vault.
+>
+> Managed DevOps Pools certificate settings are set at the pool level, and some of the settings are specific for Windows or Linux. If your workflow requires both Linux and Windows images, you may have to divide them into multiple pools if you can't find a common set of certificate settings that work for both Windows and Linux.
+
+The following settings configure the certificates fetched from your Key Vault.
+
+- **Certificates** (`observedCertificates`)
+
+  Specify the certificates to be fetched from your Key Vault and installed on all machines in your pool.
+
+- **Certificate store location** (`certificateStoreLocation`)
+
+  Specify the location to install the certificates on your agent.
+
+  - **Windows agents**: Specify `LocalMachine` or `CurrentUser`.
+  - **Linux agents**: **Certificate store location** is only support on Ubuntu distributions. Specify the disk path to store the certificates, for example `/var/lib/waagent/Microsoft.Azure.KeyVault/app1`.
+     For Ubuntu distributions, if you specify the trusted store location, for example `/usr/local/share/ca-certificates`, the certificate is added to that certificate store as root. For more information, see [Install a root CA certificate in the trust store](https://documentation.ubuntu.com/server/how-to/security/install-a-root-ca-certificate-in-the-trust-store/index.html).
+
+- **Certificate store name** (`certificateStoreName`)
+
+  - **Windows agents**: Specify the name of the certificate store, either `My` (local certificate store - default if no name is specified) or `Root` (trusted root location).
+  - **Linux agents**: This setting isn't used on Linux agents.
+
+- **Exportable private keys** (`keyExportable`)
+
+  Whether the key of the certificates is exportable. The default is `false`.
 
 #### [Azure portal](#tab/azure-portal/)
 
@@ -470,6 +500,9 @@ Key Vault integration is configured in **Settings > Security**.
 
 Azure Key Vault is configured in the `osProfile` section of the `fabricProfile` property. Set the `secretManagementSettings` to be able to access the desired certificate.
 
+> [!NOTE]
+> The `osProfile.certificateStoreName` property is only available in `apiVersion 2025-01-21` and later.
+
 ```json
 {
     "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
@@ -488,6 +521,7 @@ Azure Key Vault is configured in the `osProfile` section of the `fabricProfile`
                 "osProfile": {
                     "secretsManagementSettings": {
                         "certificateStoreLocation": "LocalMachine",
+                        "certificateStoreName": "Root",
                         "observedCertificates": [
                             "https://<keyvault-uri>/secrets/<certificate-name>"
                         ],
@@ -538,18 +572,18 @@ The following example shows the `osProfile` section of the **fabric-profile.json
 
 ### Configuring SecretManagementSettings
 
-Certificates retrieved using the `SecretManagementSettings` on your pool will automatically sync with the most recent versions published within the Key Vault. These secrets will be on the machine by the time it runs any Azure DevOps pipeline, meaning you can save time and remove tasks for fetching certificates.
+Certificates retrieved using the `SecretManagementSettings` on your pool will automatically sync with the most recent versions published within the Key Vault. These secrets will be on the machine by the time it runs its first pipeline, meaning you can save time and remove tasks for fetching certificates.
 
 > [!IMPORTANT]
 > Provisioning of your agent virtual machines will fail if the secret cannot be fetched from the Key Vault due to a permissions or network issue.
 
 #### [Windows](#tab/windows/)
 
-For Windows, the Certificate Store Location is allowed to either be set to `LocalMachine` or `CurrentUser`. This setting will ensure that the secret is installed at that location on the machine. For specific behavior of how secret retrieval works, see [the documentation for the Azure VMSS Key Vault extension for Windows](/azure/virtual-machines/extensions/key-vault-windows).
+For Windows, the Certificate Store Location is allowed to either be set to `LocalMachine` or `CurrentUser`. This setting will ensure that the secret is installed at that location on the machine. For specific behavior of how secret retrieval works, see [Azure Key Vault extension for Windows](/azure/virtual-machines/extensions/key-vault-windows).
 
 #### [Linux](#tab/linux/)
 
-For Linux, the Certificate Store Location can be any directory on the machine, and the certificates will be downloaded and synced to that location. For specifics on default settings and secret behavior, see [the documentation for the Azure VMSS Key Vault extension for Linux](/azure/virtual-machines/extensions/key-vault-linux).
+For Linux, the Certificate Store Location can be any directory on the machine, and the certificates will be downloaded and synced to that location. For specifics on default settings and secret behavior, see [Key Vault virtual machine extension for Linux](/azure/virtual-machines/extensions/key-vault-linux).
 
 * * *
 

docs/managed-devops-pools/features-timeline.md

@@ -1,7 +1,7 @@
 ---
 title: Features timeline and roadmap
 description: Learn about new features in Managed DevOps Pools.
-ms.date: 03/31/2025
+ms.date: 04/25/2025
 ms.topic: overview
 #Customer intent: As a platform engineer, I want to understand the new features in Managed DevOps Pools.
 ---
@@ -12,13 +12,11 @@ ms.topic: overview
 
 The following section describes new features in development for Managed DevOps Pools.
 
-* **Trusted root certificates**: Managed DevOps Pools is adding support so you can configure your pool to add certificates from your Key Vault as a trusted root certificate to your agents, so you don’t have to add a task for it to all the pipelines that use the pool. For more information, see [Key Vault configuration](./configure-security.md#key-vault-configuration). **Planned for April 2025.**
-
 * **Shorter time for agent allocation**: The Managed DevOps Pools team is making updates to shorten the startup time for [standby agents](./configure-scaling.md#standby-agent-mode) (**Fresh agent every time** setting). **Planned for April 2025.**
 
 * **Log analytics**: Managed DevOps Pools is adding support so you can configure your pools to emit logs into Log analytics. The Log Analytics tool in the Azure portal lets you run and edit log queries against data in the Azure Monitor Logs store. Use Log Analytics to analyze and visualize log data using [Kusto Query Language (KQL)](/azure/azure-monitor/logs/get-started-queries) or the point-and-click experience provided in [Log Analytics simple mode](/azure/azure-monitor/logs/log-analytics-simple-mode). **Planned for April 2025.**
 
-* **Pool creation at the Azure DevOps project level using project level permissions**: To create a Managed DevOps Pool, you must currently be an [Organization-level Agent pools administrator or a Project Collection Administrator in Azure DevOps](./prerequisites.md#verify-azure-devops-permissions). We're enabling a new mode of Managed DevOps Pools creation, requiring only Project-level Agent pools administrator. Managed DevOps Pools created using Project-level Agent pools administrator will be created and enabled only for use in the designated Azure DevOps Project. **Planned for April 2025.**
+* **Pool creation at the Azure DevOps project level using project level permissions**: To create a Managed DevOps Pool, you must currently be an [Organization-level Agent pools administrator or a Project Collection Administrator in Azure DevOps](./prerequisites.md#verify-azure-devops-permissions). We're enabling a new mode of Managed DevOps Pools creation, requiring only Project-level Agent pools administrator. Managed DevOps Pools created using Project-level Agent pools administrator will be created and enabled only for use in the designated Azure DevOps project. **Planned for April 2025.**
 
 * **Windows 2025 Azure Pipelines Image**: We're adding the [Windows Server 2025 image](https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md) to [Azure Pipelines images](./configure-images.md#azure-pipelines-images).
 
@@ -34,6 +32,8 @@ The following section describes new features in development for Managed DevOps P
 
 * **Open access for all pipelines to use a Managed DevOps Pool**: By default, each pipeline must be explicitly authorized to use a newly created Managed DevOps Pool. We're adding an option to enable [Open access for all pipelines](../pipelines/agents/pools-queues.md#pipeline-permissions) so that administrators don't need to explicitly authorize each pipeline. For more information, see [Configure open access for pipelines to your pool](./configure-security.md#configure-open-access-for-pipelines-to-your-pool).
 
+* **Trusted root certificates**: Managed DevOps Pools added support so you can configure your pool to add certificates from your Key Vault as a trusted root certificate to your agents, so you don’t have to add a task for it to all the pipelines that use the pool. For more information, see [Key Vault configuration](./configure-security.md#key-vault-configuration).
+
 ## March 2025
 
 The following features were released in Managed DevOps Pools in March 2025.

docs/managed-devops-pools/media/configure-security/configure-keyvault.png

@@ -1,7 +1,7 @@
 ---
 title: Monitor
 description: Learn how to view the health of your Managed DevOps Pools.
-ms.date: 11/13/2024
+ms.date: 04/25/2025
 ---
 
 # Monitor Managed DevOps Pools
@@ -129,6 +129,9 @@ For a list of error codes, see the following [Error codes](#error-codes) section
 | `SkuNotAvailable` | The requested VM size for resource 'Following SKUs failed for Capacity Restrictions:' is currently not available in location. Try another size or deploy to a different location or different zone. See `https://aka.ms/azureskunotavailable` for details. |
 | `TaskCanceled` | The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing. |
 | `VirtualNetworkIsNotFound` | The Virtual Network might be deleted. |
+| `WorkerSetupFailed`, `UnableToDownloadWorkerCheckNetwork`, `UnableToDownloadWorkerCheckNetwork[<endpoint>]`  | [The Network infrastructure is blocking access to one of the prerequisite endpoints.](./configure-networking.md#restricting-outbound-connectivity) |
+| `UnableToDownloadWorkerCheckNetwork_TLSIssue` | [TLS Handshake failed when contacting prerequisite endpoints.](./configure-networking.md#restricting-outbound-connectivity) |
+
 
 ## See also
 

docs/managed-devops-pools/monitor-pool.md

@@ -13,6 +13,9 @@
   - name: Manage extension permissions
     displayName: grant, publish, update, settings, admin
     href: ../marketplace/grant-permissions.md?toc=/azure/devops/marketplace-extensibility/toc.json
+  - name: Manage high privilege extensions
+    displayName: permission, administrator, privilege, extension, scope, Marketplace
+    href: ../marketplace/manage-high-privilege-extensions.md?toc=/azure/devops/marketplace-extensibility/toc.json
 - name: Authenticate
   items:
   - name: Guide to authentication