Merge pull request #125101 from ArieHein/Spelling-Wave-27

v-dirichards · web-flow · commit 2d69e55f06c6 · 2024-12-11T10:48:49.000-06:00
Spelling Fixes
diff --git a/articles/iot-central/core/concepts-device-implementation.md b/articles/iot-central/core/concepts-device-implementation.md
@@ -173,7 +173,7 @@ To learn more about the CLI command, see [az iot central device manual-failover]
 You can now check that telemetry from the device still reaches your IoT Central application.
 
 > [!TIP]
-> To see sample device code that handles failovers in various programing languages, see [IoT Central high availability clients](/samples/azure-samples/iot-central-high-availability-clients/iotc-high-availability-clients/).
+> To see sample device code that handles failovers in various programming languages, see [IoT Central high availability clients](/samples/azure-samples/iot-central-high-availability-clients/iotc-high-availability-clients/).
 
 ## Next steps
 
diff --git a/articles/iot-central/core/howto-integrate-with-devops.md b/articles/iot-central/core/howto-integrate-with-devops.md
@@ -50,7 +50,7 @@ You need the following prerequisites to complete the steps in this guide:
 
 ## Download the sample code
 
-To get started, fork the IoT Central CI/CD GitHub repository and then clne your fork to your local machine:o
+To get started, fork the IoT Central CI/CD GitHub repository and then clone your fork to your local machine:
 
 1. To fork the GitHub repository, open the [IoT Central CI/CD GitHub repository](https://github.com/Azure/iot-central-CICD-sample) and select **Fork**.
 
diff --git a/articles/iot-central/core/howto-manage-deployment-manifests-with-rest-api.md b/articles/iot-central/core/howto-manage-deployment-manifests-with-rest-api.md
@@ -286,7 +286,7 @@ The response to this request looks like the following example:
 PATCH https://{your app subdomain}/api/deploymentManifests/{deploymentManifestId}?api-version=2022-10-31-preview
 ```
 
-The following sample request body updates the `SendInterval` desired property setting for the `SimuatedTemperatureSetting` module:
+The following sample request body updates the `SendInterval` desired property setting for the `SimulatedTemperatureSetting` module:
 
 ```json
 {
diff --git a/articles/iot-central/core/howto-manage-organizations-with-rest-api.md b/articles/iot-central/core/howto-manage-organizations-with-rest-api.md
@@ -1,6 +1,6 @@
 ---
 title: Manage organizations with the REST API in Azure IoT Central
-description: How to use the IoT Central REST API to manage organizations in an application. Oganizations let you manage access to application resources.
+description: How to use the IoT Central REST API to manage organizations in an application. Organizations let you manage access to application resources.
 author: dominicbetts
 ms.author: dobett
 ms.date: 10/22/2024
diff --git a/articles/iot-central/core/howto-transform-data.md b/articles/iot-central/core/howto-transform-data.md
@@ -417,7 +417,7 @@ To verify the scenario is running, navigate to your **IoT Edge gateway device**
     The telemetry data in the **Measurements** column looks like:
 
     ```json
-    {"temperature":85.21208,"pressure":59.97321,"humidity":77.718124,"scale":"farenheit"}
+    {"temperature":85.21208,"pressure":59.97321,"humidity":77.718124,"scale":"fahrenheit"}
     ```
 
 The temperature is sent in Fahrenheit. Because the IoT Edge device is transforming the data from the downstream device, the telemetry is associated with the gateway device in IoT Central. To visualize the transformed telemetry, create a view in the **IoT Edge gateway device** template and republish it.
@@ -467,7 +467,7 @@ The device bridge then sends the transformed data to IoT Central in the followin
   "temp": <temperature in degrees F>,
   "humidity": <humidity>,
   "lat": <latitude>,
-  "lon": <logitude>,
+  "lon": <longitude>,
   "weather": {
     "weather_temp": <temperature at lat/lon>,
     "weather_humidity": <humidity at lat/lon>,
diff --git a/articles/iot-dps/concepts-device-oem-security-practices.md b/articles/iot-dps/concepts-device-oem-security-practices.md
@@ -26,7 +26,7 @@ Three widely used authentication types are X.509 certificates, Trusted Platform
 
 ### X.509 certificate
 X.509 certificates are a type of digital identity you can use for authentication. The X.509 certificate standard is documented in [IETF RFC 5280](https://tools.ietf.org/html/rfc5280). In Azure IoT, there are two ways to authenticate certificates:
-- Thumbprint. A thumbprint algorithm is run on a certificate to generate a hexadecimal string. The generated string is a unique identifer for the certificate. 
+- Thumbprint. A thumbprint algorithm is run on a certificate to generate a hexadecimal string. The generated string is a unique identifier for the certificate. 
 - CA authentication based on a full chain. A certificate chain is a hierarchical list of all certificates needed to authenticate an end-entity (EE) certificate. To authenticate an EE certificate, it's necessary to authenticate each certificate in the chain including a trusted root CA. 
 
 Pros for X.509:
diff --git a/articles/iot-edge/how-to-monitor-module-twins.md b/articles/iot-edge/how-to-monitor-module-twins.md
@@ -166,7 +166,7 @@ The information about the connectivity of your custom modules is maintained in t
 
 You can use your preferred programming language with the [Azure IoT Hub Device SDKs](../iot-hub/iot-hub-devguide-sdks.md#azure-iot-hub-device-sdks) to update reported property values in the module twin, based on your module's application code. The following procedure uses the Azure SDK for .NET to do this, using code from the [SimulatedTemperatureSensor](https://github.com/Azure/iotedge/blob/main/edge-modules/SimulatedTemperatureSensor/src/Program.cs) module:
 
-1. Create an instance of the [ModuleClient](/dotnet/api/microsoft.azure.devices.client.moduleclient) with the [CreateFromEnvironmentAysnc](/dotnet/api/microsoft.azure.devices.client.moduleclient.createfromenvironmentasync) method.
+1. Create an instance of the [ModuleClient](/dotnet/api/microsoft.azure.devices.client.moduleclient) with the [CreateFromEnvironmentAsync](/dotnet/api/microsoft.azure.devices.client.moduleclient.createfromenvironmentasync) method.
 
 1. Get a collection of the module twin's properties with the [GetTwinAsync](/dotnet/api/microsoft.azure.devices.client.moduleclient.gettwinasync) method.
 
diff --git a/articles/iot-edge/how-to-provision-devices-at-scale-linux-tpm.md b/articles/iot-edge/how-to-provision-devices-at-scale-linux-tpm.md
@@ -145,7 +145,7 @@ After the installation is finished and you've signed back in to your VM, you're
 ## Retrieve provisioning information for your TPM
 
 > [!NOTE]
-> This article previously used the `tpm_device_provision` tool from the IoT C SDK to generate provisioning info. If you relied on that tool previously, then be aware the steps below generate a different registration ID for the same public endorsement key. If you need to recreate the registration ID as before then refer to how the C SDK's [tpm_device_provision tool](https://github.com/Azure/azure-iot-sdk-c/tree/main/provisioning_client/tools/tpm_device_provision) generates it. Be sure the registration ID for the individual enrollment in DPS matches the regisration ID the IoT Edge device is configured to use.
+> This article previously used the `tpm_device_provision` tool from the IoT C SDK to generate provisioning info. If you relied on that tool previously, then be aware the steps below generate a different registration ID for the same public endorsement key. If you need to recreate the registration ID as before then refer to how the C SDK's [tpm_device_provision tool](https://github.com/Azure/azure-iot-sdk-c/tree/main/provisioning_client/tools/tpm_device_provision) generates it. Be sure the registration ID for the individual enrollment in DPS matches the registration ID the IoT Edge device is configured to use.
 
 In this section, you use the TPM2 software tools to retrieve the endorsement key for your TPM and then generate a unique registration ID. This section corresponds with [Step 3: Device has firmware and software installed](../iot-dps/concepts-device-oem-security-practices.md#step-3-device-has-firmware-and-software-installed) in the process for [integrating a TPM into the manufacturing process](../iot-dps/concepts-device-oem-security-practices.md#integrating-a-tpm-into-the-manufacturing-process).
 
diff --git a/articles/iot-edge/iot-edge-for-linux-on-windows-networking.md b/articles/iot-edge/iot-edge-for-linux-on-windows-networking.md
@@ -66,7 +66,7 @@ Depending on the type of virtual switch used, EFLOW VM supports different IP all
     ```
 
     >[!WARNING]
-    > When using static IP, the **three parameters** (`ip4Address`, `ip4GatewayAddres`, `ip4PrefixLength`) must be used. Also, if the IP address is invalid, being used by another device on thee netowrk, or the gateway address is incorrect, EFLOW installation could fail as the EFLOW VM can't get an IP address.
+    > When using static IP, the **three parameters** (`ip4Address`, `ip4GatewayAddress`, `ip4PrefixLength`) must be used. Also, if the IP address is invalid, being used by another device on thee network, or the gateway address is incorrect, EFLOW installation could fail as the EFLOW VM can't get an IP address.
 
 - **DHCP** -  Contrary to static IP, when using DHCP, the EFLOW virtual machine is assigned with a dynamic IP address; which is an address that may change. The network must have a DHCP server configured and operating to assign dynamic IP addresses. The DHCP server assigns a vacant IP address to the EFLOW VM and others connected to the network. Therefore, when deploying EFLOW using DHCP, no IP address, gateway address, or prefix length is needed, as the DHCP server provides all the information. 
     
diff --git a/articles/iot-edge/nested-virtualization.md b/articles/iot-edge/nested-virtualization.md
@@ -39,7 +39,7 @@ To set up an Azure IoT Edge for Linux on Windows on a VMware ESXi Windows virtua
 1. Install Hyper-V hypervisor. If you're using Windows client, make sure you [Install Hyper-V on Windows 10](/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v). If you're using Windows Server, make sure you [install the Hyper-V role](/windows-server/virtualization/hyper-v/get-started/install-the-hyper-v-role-on-windows-server). 
 
 > [!NOTE]
-> For VMware Windows virtual machines, if you plan to use an **external virtual switch** for the EFLOW virtual machine networking, make sure you enable _Promiscious mode_. For more information, see [Configuring promiscuous mode on a virtual switch or portgroup](https://kb.vmware.com/s/article/1004099). Failing to do so will result in EFLOW installation errors.
+> For VMware Windows virtual machines, if you plan to use an **external virtual switch** for the EFLOW virtual machine networking, make sure you enable _Promiscuous mode_. For more information, see [Configuring promiscuous mode on a virtual switch or portgroup](https://kb.vmware.com/s/article/1004099). Failing to do so will result in EFLOW installation errors.
 
 ## Deployment on Azure VMs
 
diff --git a/articles/iot-edge/reference-iot-edge-for-linux-on-windows-functions.md b/articles/iot-edge/reference-iot-edge-for-linux-on-windows-functions.md
@@ -79,7 +79,7 @@ The **Add-EflowVmEndpoint** command adds a new network endpoint to the EFLOW vir
 | --------- | --------------- | -------- |
 | vswitchName | Name of the virtual switch |  Name of the virtual switch assigned to the EFLOW VM. |
 | vendpointName | Name of the virtual endpoint | Name of the virtual endpoint assigned to the EFLOW VM. |
-| ip4Address | IPv4 Address in the range of the DCHP Server Scope | Static Ipv4 address of the EFLOW VM. |
+| ip4Address | IPv4 Address in the range of the DHCP Server Scope | Static Ipv4 address of the EFLOW VM. |
 | ip4PrefixLength | IPv4 Prefix Length of the subnet | Ipv4 subnet prefix length, only valid when static Ipv4 address is specified. |
 | ip4GatewayAddress | IPv4 Address of the subnet gateway | Gateway Ipv4 address, only valid when static Ipv4 address is specified. |
 
@@ -159,7 +159,7 @@ The **Deploy-Eflow** command is the main deployment method. The deployment comma
 | vmLogSize | **Small** or **Large** | Specify the log partition size. Small = 1GB, Large = 6GB.<br><br>**Default value**: Small.  |
 | vswitchName | Name of the virtual switch |  Name of the virtual switch assigned to the EFLOW VM. |
 | vswitchType | **Internal** or **External** | Type of the virtual switch assigned to the EFLOW VM. |
-| ip4Address | IPv4 Address in the range of the DCHP Server Scope | Static Ipv4 address of the EFLOW VM. |
+| ip4Address | IPv4 Address in the range of the DHCP Server Scope | Static Ipv4 address of the EFLOW VM. |
 | ip4PrefixLength | IPv4 Prefix Length of the subnet | Ipv4 subnet prefix length, only valid when static Ipv4 address is specified. |
 | ip4GatewayAddress | IPv4 Address of the subnet gateway | Gateway Ipv4 address, only valid when static Ipv4 address is specified. |
 | gpuName | GPU Device name |  Name of GPU device to be used for passthrough. |
diff --git a/articles/iot-edge/tutorial-configure-est-server.md b/articles/iot-edge/tutorial-configure-est-server.md
@@ -137,7 +137,7 @@ Each device requires the Certificate Authority (CA) certificate that is associat
 1. On the IoT Edge device, create the `/var/aziot/certs` directory if it doesn't exist then change directory to it.
 
     ```bash
-   # If the certificate directory doen't exist, create, set ownership, and set permissions
+   # If the certificate directory doesn't exist, create, set ownership, and set permissions
    sudo mkdir -p /var/aziot/certs
    sudo chown aziotcs:aziotcs /var/aziot/certs
    sudo chmod 755 /var/aziot/certs
@@ -264,7 +264,7 @@ On the IoT Edge device, update the IoT Edge configuration file to use device cer
     ```
 
     > [!NOTE]
-    > In this example, IoT Edge uses username and password to authenticate to the EST server *everytime* it needs to obtain a certificate. This method isn't recommended in production because 1) it requires storing a secret in plaintext and 2) IoT Edge should use an identity certificate to authenticate to the EST server too. To modify for production: 
+    > In this example, IoT Edge uses username and password to authenticate to the EST server *every time* it needs to obtain a certificate. This method isn't recommended in production because 1) it requires storing a secret in plaintext and 2) IoT Edge should use an identity certificate to authenticate to the EST server too. To modify for production: 
     > 
     > 1. Consider using long-lived *bootstrap certificates* that can be stored onto the device during manufacturing [similar to the recommended approach for DPS](../iot-hub/iot-hub-x509ca-concept.md). To see how to configure bootstrap certificate for EST server, see [Authenticate a Device Using Certificates Issued Dynamically via EST](https://github.com/Azure/iotedge/blob/main/edgelet/doc/est.md). 
     > 1. Configure `[cert_issuance.est.identity_auto_renew]` using the [same syntax](https://github.com/Azure/iotedge/blob/main/edgelet/contrib/config/linux/template.toml#L257) as the provisioning certificate auto-renew configuration above. 
diff --git a/articles/iot-edge/tutorial-develop-for-linux.md b/articles/iot-edge/tutorial-develop-for-linux.md
@@ -627,7 +627,7 @@ The sample C# code that comes with the project template uses the [ModuleClient C
         if (json_object_dotget_value(root_object, "machine.temperature") != NULL && (temperature = json_object_dotget_number(root_object, "machine.temperature")) > temperatureThreshold)
         {
             printf("Machine temperature %f exceeds threshold %f\r\n", temperature, temperatureThreshold);
-            // This message should be sent to next stop in the pipeline, namely "output1".  What happens at "outpu1" is determined
+            // This message should be sent to next stop in the pipeline, namely "output1".  What happens at "output1" is determined
             // by the configuration of the Edge routing table setup.
             MESSAGE_INSTANCE *messageInstance = CreateMessageInstance(message);
             if (NULL == messageInstance)
@@ -804,7 +804,7 @@ The sample C# code that comes with the project template uses the [ModuleClient C
                         long threshold = Math.round((double) property.getValue());
                         App.tempThreshold.set(threshold);
                     } catch (Exception e) {
-                        System.out.println("Faile to set TemperatureThread with exception");
+                        System.out.println("Failed to set TemperatureThread with exception");
                         e.printStackTrace();
                     }
                 }
diff --git a/articles/iot-edge/tutorial-nested-iot-edge-for-linux-on-windows.md b/articles/iot-edge/tutorial-nested-iot-edge-for-linux-on-windows.md
@@ -59,7 +59,7 @@ To create a hierarchy of IoT Edge devices, you need:
 > [!TIP]
 > It is possible to use **internal** or **default** virtual switch if a port forwarding is configured on the Windows host OS. However, for the simplicity of this tutorial, both devices should use an **external** virtual switch and be connected to the same external network. 
 >
-> For more information about netowrking, see [Azure IoT Edge for Linux on Windows networking](./iot-edge-for-linux-on-windows-networking.md) and [Networking configuration for Azure IoT Edge for Linux on Windows](./how-to-configure-iot-edge-for-linux-on-windows-networking.md).
+> For more information about networking, see [Azure IoT Edge for Linux on Windows networking](./iot-edge-for-linux-on-windows-networking.md) and [Networking configuration for Azure IoT Edge for Linux on Windows](./how-to-configure-iot-edge-for-linux-on-windows-networking.md).
 >
 > If you need to set up the EFLOW devices on a DMZ, see [How to configure Azure IoT Edge for Linux on Windows Industrial IoT & DMZ configuration](how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz.md).
 * An Azure account with a valid subscription. If you don't have an [Azure subscription](../guides/developer/azure-developer-guide.md#understanding-accounts-subscriptions-and-billing), create a [free account](https://azure.microsoft.com/free/) before you begin.
diff --git a/articles/iot-edge/tutorial-store-data-sql-server.md b/articles/iot-edge/tutorial-store-data-sql-server.md
@@ -161,7 +161,7 @@ You need to select which architecture you're targeting with each solution, becau
 
                    if (messageBody != null && messageBody.machine.temperature > temperatureThreshold)
                    {
-                       // Send the message to the output as the temperature value is greater than the threashold.
+                       // Send the message to the output as the temperature value is greater than the threshold.
                        using (var filteredMessage = new Message(messageBytes))
                        {
                             // Copy the properties of the original message into the new Message object.
diff --git a/articles/iot/howto-connect-on-premises-sap-to-azure.md b/articles/iot/howto-connect-on-premises-sap-to-azure.md
@@ -7,7 +7,7 @@ ms.service: azure-iot
 ms.topic: how-to #Don't change.
 ms.date: 4/14/2024
 
-#customer intent: As an ower of on-prem SAP systems, I want connect them to Azure so that I can add data from these SAP systems to my cloud analytics.
+#customer intent: As an owner of on-prem SAP systems, I want connect them to Azure so that I can add data from these SAP systems to my cloud analytics.
 
 ---
 
diff --git a/articles/iot/tutorial-iot-industrial-solution-architecture.md b/articles/iot/tutorial-iot-industrial-solution-architecture.md
@@ -232,7 +232,7 @@ You can also visit the [Azure Data Explorer documentation](/azure/synapse-analyt
 
 ## Render the built-in Unified NameSpace (UNS) and ISA-95 model graph in Kusto Explorer
 
-This reference solution implements a Unified NameSapce (UNS), based on the OPC UA metadata sent to the time-series database in the cloud (Azure Data Explorer). This OPC UA metadata also includes the ISA-95 asset hierarchy. The resulting graph can be easily visualized in the Kusto Explorer tool available for download [here](/azure/data-explorer/kusto/tools/kusto-explorer).
+This reference solution implements a Unified NameSpace (UNS), based on the OPC UA metadata sent to the time-series database in the cloud (Azure Data Explorer). This OPC UA metadata also includes the ISA-95 asset hierarchy. The resulting graph can be easily visualized in the Kusto Explorer tool available for download [here](/azure/data-explorer/kusto/tools/kusto-explorer).
 
 Add a new connection to your Azure Data Explorer instance deployed in this reference solution and then run the following query in Kusto Explorer:
 
@@ -394,7 +394,7 @@ This integration showcases the following scenarios:
 - Uploading assets from the Manufacturing Ontologies reference solution to Dynamics 365 Field Service.
 - Create alerts in Dynamics 365 Field Service when a certain threshold on Manufacturing Ontologies reference solution telemetry data is reached.
 
-The integration uses Azure Logics Apps. With Logic Apps bussiness-critcal apps and services can be connected via no-code workflows. We fetch information from Azure Data Explorer and trigger actions in Dynamics 365 Field Service.
+The integration uses Azure Logics Apps. With Logic Apps business-critical apps and services can be connected via no-code workflows. We fetch information from Azure Data Explorer and trigger actions in Dynamics 365 Field Service.
 
 First, if you're not already a Dynamics 365 Field Service customer, activate a 30 day trial [here](https://dynamics.microsoft.com/field-service/field-service-management-software/free-trial). Remember to use the same Microsoft Entra ID (formerly Azure Active Directory) used while deploying the Manufacturing Ontologies reference solution. Otherwise, you would need to configure cross tenant authentication that isn't part of these instructions.
 

Original file line number	Diff line number	Diff line change
`@@ -286,7 +286,7 @@ The response to this request looks like the following example:`
`286`	`286`	`PATCH https://{your app subdomain}/api/deploymentManifests/{deploymentManifestId}?api-version=2022-10-31-preview`
`287`	`287`	```
`288`	`288`
`289`		-The following sample request body updates the `SendInterval` desired property setting for the `SimuatedTemperatureSetting` module:
	`289`	+The following sample request body updates the `SendInterval` desired property setting for the `SimulatedTemperatureSetting` module:
`290`	`290`
`291`	`291`	```json
`292`	`292`	`{`