Merge pull request #250535 from JasonWHowell/fixes7

Bulk fix absolute links

Author: prmerger-automator[bot]

articles/industrial-iot/tutorial-publisher-performance-memory-tuning-opc-publisher.md

@@ -60,7 +60,7 @@ To run OPC Publisher in production, network performance requirements (throughput
 
 ## Latency considerations
 
-What is typically seen as latency is the time difference between the `iothub-enqueuedtime` of the [device to cloud message](https://learn.microsoft.com/azure/iot-hub/iot-hub-devguide-messages-construct) and the `SourceTimestamp` field of an OPC UA telemetry event. There are multiple factors, which contribute to the latency:
+What is typically seen as latency is the time difference between the `iothub-enqueuedtime` of the [device to cloud message](/azure/iot-hub/iot-hub-devguide-messages-construct) and the `SourceTimestamp` field of an OPC UA telemetry event. There are multiple factors, which contribute to the latency:
 * The `SourceTimestamp` of the OPC UA telemetry event is a value [defined by the OPC UA Specification](https://reference.opcfoundation.org/Core/Part4/v104/7.7.3/) as to be as close to the source of the value. The origin of `SourceTimestamp` is highly dependent on the setup between sensor and OPC UA server. Independent from the setup, it's important to ensure that the time source is synchronized precisely otherwise the latency calculation will be not correct.
 * It's important that the systems and interconnection between the sensor and the IoT Edge host system where OPC Publisher runs is stable and doesn't introduce latency.
 * The configuration of the OPC UA nodes to publish and the effect of OPC Publisher command line options on latency will be discussed below.
@@ -116,7 +116,7 @@ OPC Publisher maintains an internal queue for all data change notifications. The
 
 If the queue keeps growing even though the `--si` and `--ms` have been adjusted and the queue capacity will be reached, messages will be discarded. The reason can be that the time it takes to send a message to IoT Hub doesn't provide the required throughput. Since this time is made up of multiple parts to understand if there's a bottleneck several areas should be validated:
 - Validation that the IoT Edge host network connection to the IoT Hub is stable and has low latency.
-- Validation that the modules running in IoT Edge (OPC Publisher, edgeHub, and others) don't hit any limits for CPU and memory consumption. Additionally use of the [IoT Edge metrics collector](https://learn.microsoft.com/azure/iot-edge/how-to-collect-and-transport-metrics?view=iotedge-1.4&tabs=iothub) can give insights on resource usage of the system.
+- Validation that the modules running in IoT Edge (OPC Publisher, edgeHub, and others) don't hit any limits for CPU and memory consumption. Additionally use of the [IoT Edge metrics collector](/azure/iot-edge/how-to-collect-and-transport-metrics?tabs=iothub) can give insights on resource usage of the system.
 - Validation that the time to ingest a message from an IoT Edge module not using any OPC UA data does meet expectations even with active workload.
 
 If the capacity of the internal message queue is used and there are still incoming notifications from the OPC UA server, data change notifications will be discarded. The diagnostics output will show the number of discarded messages.

articles/iot-hub-device-update/delta-updates.md

@@ -25,7 +25,7 @@ Delta updates allow you to generate a small update that represents only the chan
 
 ## Configure a device with Device Update agent and delta processor component
 
-In order for your device to download and install delta updates from the Device Update service, you will need several components present and configured.
+In order for your device to download and install delta updates from the Device Update service, you need several components present and configured.
 
 ### Device Update agent
 
@@ -48,15 +48,15 @@ sudo ldconfig
 
 ## Add a source SWU image file to your device
 
-After a delta update has been downloaded to a device, it must be compared against a valid _source SWU file_ that has been previously cached on the device in order to be re-created into a full image. The simplest way to populate this cached image is to deploy a full image update to the device via the Device Update service (using the existing [import](import-update.md) and [deployment](deploy-update.md) processes). As long as the device has been configured with the Device Update agent (version 1.0 or later) and delta processor, the installed SWU file will be cached automatically by the Device Update agent for later delta update use.
+After a delta update has been downloaded to a device, it must be compared against a valid _source SWU file_ that has been previously cached on the device in order to be re-created into a full image. The simplest way to populate this cached image is to deploy a full image update to the device via the Device Update service (using the existing [import](import-update.md) and [deployment](deploy-update.md) processes). As long as the device has been configured with the Device Update agent (version 1.0 or later) and delta processor, the installed SWU file is cached automatically by the Device Update agent for later delta update use.
 
 If you instead want to directly pre-populate the source image on your device, the path where the image is expected is:
 
 `[BASE_SOURCE_DOWNLOAD_CACHE_PATH]/sha256-[ENCODED HASH]`
 
-By default, `BASE_SOURCE_DOWNLOAD_CACHE_PATH` is the path listed below. The `[provider]` value is the Provider part of the [updateId](import-concepts.md#update-identity) for the source SWU file.
+By default, `BASE_SOURCE_DOWNLOAD_CACHE_PATH` is the path `/var/lib/adu/sdc/[provider]`. The `[provider]` value is the Provider part of the [updateId](import-concepts.md#update-identity) for the source SWU file.
+
 
-`/var/lib/adu/sdc/[provider]`
 
 `ENCODED_HASH` is the base64 hex string of the SHA256 of the binary, but after encoding to base64 hex string, it encodes the characters as follows:
 
@@ -74,7 +74,7 @@ The following table provides a list of the content needed, where to retrieve the
 
 | Binary Name | Where to acquire | How to install |
 |--|--|--|
-| DiffGen | [Azure/iot-hub-device-update-delta](https://github.com/Azure/iot-hub-device-update-delta) GitHub repo | From the root folder, select the _Microsoft.Azure.DeviceUpdate.Diffs.[version].nupkg_ file. [Learn more about NuGet packages](https://learn.microsoft.com/nuget/).|
+| DiffGen | [Azure/iot-hub-device-update-delta](https://github.com/Azure/iot-hub-device-update-delta) GitHub repo | From the root folder, select the _Microsoft.Azure.DeviceUpdate.Diffs.[version].nupkg_ file. [Learn more about NuGet packages](/nuget/).|
 | .NET (Runtime) | Via Terminal / Package Managers | [Instructions for Linux](/dotnet/core/install/linux). Only the Runtime is required. |
 
 ### Dependencies
@@ -95,25 +95,25 @@ The DiffGen tool is run with several arguments. All arguments are required, and
 
 `DiffGenTool [source_archive] [target_archive] [output_path] [log_folder] [working_folder] [recompressed_target_archive]`  
 
-- The script recompress_tool.py will be run to create the file [recompressed_target_archive], which will then be used instead of [target_archive] as the target file for creating the diff.
-- The image files within [recompressed_target_archive] will be compressed with zstd.
+- The script recompress_tool.py runs to create the file [recompressed_target_archive], which then is used instead of [target_archive] as the target file for creating the diff.
+- The image files within [recompressed_target_archive] are compressed with zstd.
 
 If your SWU files are signed (likely), you'll need another argument as well:
 
 `DiffGenTool [source_archive] [target_archive] [output_path] [log_folder] [working_folder] [recompressed_target_archive] "[signing_command]"`
 
-- In addition to using [recompressed_target_archive] as the target file, providing a signing command string parameter will run recompress_and_sign_tool.py to create the file [recompressed_target_archive] and have the sw-description file within the archive signed (meaning a sw-description.sig file will be present). You can use the sample `sign_file.sh` script from the [Azure/iot-hub-device-update-delta](https://github.com/Azure/iot-hub-device-update-delta/tree/main/src/scripts/signing_samples/openssl_wrapper) GitHub repo. Open the script, edit it to add the path to your private key file, then save it. See the examples section below for sample usage.
+- In addition to using [recompressed_target_archive] as the target file, providing a signing command string parameter runs recompress_and_sign_tool.py to create the file [recompressed_target_archive] and have the sw-description file within the archive signed (meaning a sw-description.sig file is present). You can use the sample `sign_file.sh` script from the [Azure/iot-hub-device-update-delta](https://github.com/Azure/iot-hub-device-update-delta/tree/main/src/scripts/signing_samples/openssl_wrapper) GitHub repo. Open the script, edit it to add the path to your private key file, then save it. See the examples section below for sample usage.
 
 The following table describes the arguments in more detail:
 
 | Argument | Description |
 |--|--|
-| [source_archive] | This is the image that the delta will be based against when creating the delta. _Important_: this image must be identical to the image that is already present on the device (for example, cached from a previous update). |
-| [target_archive] | This is the image that the delta will update the device to. |
-| [output_path] | The path (including the desired name of the delta file being generated) on the host machine where the delta file will be placed after creation.  If the path doesn't exist, the directory will be created by the tool. |
-| [log_folder] | The path on the host machine where logs will be created. We recommend defining this location as a sub folder of the output path. If the path doesn't exist, it will be created by the tool. |
-| [working_folder] | The path on the machine where collateral and other working files are placed during the delta generation. We recommend defining this location as a subfolder of the output path. If the path doesn't exist, it will be created by the tool. |
-| [recompressed_target_archive] | The path on the host machine where the recompressed target file will be created. This file will be used instead of <target_archive> as the target file for diff generation. If this path exists before calling DiffGenTool, the path will be overwritten. We recommend defining this path as a file in the subfolder of the output path. |
+| [source_archive] | This is the image that the delta is based against when creating the delta. _Important_: this image must be identical to the image that is already present on the device (for example, cached from a previous update). |
+| [target_archive] | This is the image that the delta updates the device to. |
+| [output_path] | The path (including the desired name of the delta file being generated) on the host machine where the delta file is placed after creation.  If the path doesn't exist, the directory is created by the tool. |
+| [log_folder] | The path on the host machine where logs creates. We recommend defining this location as a sub folder of the output path. If the path doesn't exist, it is created by the tool. |
+| [working_folder] | The path on the machine where collateral and other working files are placed during the delta generation. We recommend defining this location as a subfolder of the output path. If the path doesn't exist, it is created by the tool. |
+| [recompressed_target_archive] | The path on the host machine where the recompressed target file is created. This file is used instead of <target_archive> as the target file for diff generation. If this path exists before calling DiffGenTool, the path is overwritten. We recommend defining this path as a file in the subfolder of the output path. |
 | "[signing_command]" _(optional)_ | A customizable command used for signing the sw-description file within the recompressed archive file. The sw-description file in the recompressed archive is used as an input parameter for the signing command; DiffGenTool expects the signing command to create a new signature file, using the name of the input with `.sig` appended. Surrounding the parameter in double quotes is needed so that the whole command is passed in as a single parameter. Also, avoid putting the '~' character in a key path used for signing, and use the full home path instead (for example, use /home/USER/keys/priv.pem instead of ~/keys/priv.pem). |
 
 ### DiffGen examples
@@ -153,7 +153,7 @@ The basic process of importing an update to the Device Update service is unchang
 
 ### Generate import manifest
 
-The first step to import an update into the Device Update service is always to create an import manifest if you don't already have one. For more information about import manifests, see [Importing updates into Device Update](import-concepts.md#import-manifest). For delta updates, your import manifest will need to reference two files:
+The first step to import an update into the Device Update service is always to create an import manifest if you don't already have one. For more information about import manifests, see [Importing updates into Device Update](import-concepts.md#import-manifest). For delta updates, your import manifest needs to reference two files:
 
 - The _recompressed_ target SWU image created when you ran the DiffGen tool.
 - The delta file created when you ran the DiffGen tool.
@@ -171,9 +171,9 @@ Use the `relatedFiles` object to specify information about the delta update file
 }
 ```
 
-Both of the properties above are specific to your _source SWU image file_ that you used as an input to the DiffGen tool when creating your delta update. The information about the source SWU image is needed in your import manifest even though you will not actually be importing the source image. The delta components on the device use this metadata about the source image to locate the image on the device once the delta has been downloaded.
+Both of the properties above are specific to your _source SWU image file_ that you used as an input to the DiffGen tool when creating your delta update. The information about the source SWU image is needed in your import manifest even though you don't actually import the source image. The delta components on the device use this metadata about the source image to locate the image on the device once the delta has been downloaded.
 
-Use the `downloadHandler` object to specify how the Device Update agent will orchestrate the delta update, using the related files feature. Unless you are customizing your own version of the Device Update agent for delta functionality, you should only use this downloadHandler:
+Use the `downloadHandler` object to specify how the Device Update agent orchestrates the delta update, using the related files feature. Unless you are customizing your own version of the Device Update agent for delta functionality, you should only use this downloadHandler:
 
 ```json
 "downloadHandler": {
@@ -212,14 +212,14 @@ There are three possible outcomes for a delta update deployment:
 
 To determine which of the above outcomes occurred, you can view the install results with error code and extended error code by selecting any device that is in a failed state. You can also [collect logs](device-update-log-collection.md) from multiple failed devices if needed.
 
-If the delta update succeeded, the device will show a "Succeeded" status.
+If the delta update succeeded, the device shows a "Succeeded" status.
 
-If the delta update failed but did a successful fallback to the full image, it will show the following error status:
+If the delta update failed but did a successful fallback to the full image, it shows the following error status:
 
 - resultCode: _[value greater than 0]_
 - extendedResultCode: _[non-zero]_
 
-If the update was unsuccessful, it will show an error status that can be interpreted using the instructions below:
+If the update was unsuccessful, it shows an error status that can be interpreted using the instructions below:
 
 - Start with the Device Update Agent errors in [result.h](https://github.com/Azure/iot-hub-device-update/blob/main/src/inc/aduc/result.h).
 

articles/machine-learning/concept-designer.md

@@ -2,7 +2,6 @@
 title: What is the Azure Machine Learning designer(v2)?
 titleSuffix: Azure Machine Learning
 description: Learn what the Azure Machine Learning designer is and what tasks you can use it for. The drag-and-drop UI enables customer to build machine learning pipeline. 
-services: machine-learning
 ms.service: machine-learning
 ms.subservice: core
 ms.topic: conceptual
@@ -38,7 +37,7 @@ As shown in below GIF, you can build a pipeline visually by dragging and droppin
 
 The building blocks of pipeline are called assets in Azure Machine Learning, which includes:
  - [Data](./concept-data.md)
- - [Model](https://learn.microsoft.com/azure/machine-learning/how-to-manage-models?view=azureml-api-2&tabs=cli%2Cuse-local)
+ - [Model](how-to-manage-models.md?view=azureml-api-2&preserve-view=true&tabs=cli)
  - [Component](./concept-component.md)
 
 Designer has an asset library on the left side, where you can access all the assets you need to create your pipeline. It shows both the assets you created in your workspace, and the assets shared in [registry](./how-to-share-models-pipelines-across-workspaces-with-registries.md) that you have permission to access.

articles/machine-learning/how-to-create-component-pipeline-python.md

@@ -2,7 +2,6 @@
 title: 'Create and run machine learning pipelines using components with the Azure Machine Learning SDK v2'
 titleSuffix: Azure Machine Learning
 description: Build a machine learning pipeline for image classification. Focus on machine learning instead of infrastructure and automation.
-services: machine-learning
 ms.service: machine-learning
 ms.subservice: mlops
 ms.topic: how-to
@@ -256,7 +255,7 @@ Reference for more available credentials if it doesn't work for you: [configure
 
 #### Get a handle to a workspace with compute
 
-Create a `MLClient` object to manage Azure Machine Learning services. If you use [serverless compute (preview)](https://learn.microsoft.com/azure/machine-learning/how-to-use-serverless-compute?view=azureml-api-2&tabs=python) then there is no need to create these computes.
+Create a `MLClient` object to manage Azure Machine Learning services. If you use [serverless compute (preview)](how-to-use-serverless-compute.md?view=azureml-api-2&preserve-view=true&tabs=python) then there is no need to create these computes.
 
 [!notebook-python[] (~/azureml-examples-main/sdk/python/jobs/pipelines/2e_image_classification_keras_minist_convnet/image_classification_keras_minist_convnet.ipynb?name=workspace)]
 

articles/machine-learning/how-to-setup-mlops-azureml.md

@@ -338,7 +338,7 @@ This scenario includes prebuilt workflows for two approaches to deploying a trai
 * [Install and set up Python SDK v2](https://aka.ms/sdk-v2-install)
 * [Install and set up Python CLI v2](how-to-configure-cli.md)
 * [Azure MLOps (v2) solution accelerator](https://github.com/Azure/mlops-v2) on GitHub
-* Training course on [MLOps with Machine Learning](https://learn.microsoft.com/training/paths/introduction-machine-learn-operations/)
+* Training course on [MLOps with Machine Learning](/training/paths/introduction-machine-learn-operations/)
 * Learn more about [Azure Pipelines with Azure Machine Learning](how-to-devops-machine-learning.md)
 * Learn more about [GitHub Actions with Azure Machine Learning](how-to-github-actions-machine-learning.md)
 * Deploy MLOps on Azure in Less Than an Hour - [Community MLOps V2 Accelerator video](https://www.youtube.com/watch?v=5yPDkWCMmtk)

articles/machine-learning/how-to-setup-mlops-github-azure-ml.md

@@ -301,7 +301,7 @@ The sample training and deployment Machine Learning pipelines and GitHub workflo
 * [Install and set up Python SDK v2](https://aka.ms/sdk-v2-install)
 * [Install and set up Python CLI v2](how-to-configure-cli.md)
 * [Azure MLOps (v2) solution accelerator](https://github.com/Azure/mlops-v2) on GitHub
-* Training course on [MLOps with Machine Learning](https://learn.microsoft.com/training/paths/introduction-machine-learn-operations/)
+* Training course on [MLOps with Machine Learning](/training/paths/introduction-machine-learn-operations/)
 * Learn more about [Azure Pipelines with Machine Learning](how-to-devops-machine-learning.md)
 * Learn more about [GitHub Actions with Machine Learning](how-to-github-actions-machine-learning.md)
 * Deploy MLOps on Azure in Less Than an Hour - [Community MLOps V2 Accelerator video](https://www.youtube.com/watch?v=5yPDkWCMmtk)