Apply review feedback

Author: kgremban

articles/iot-hub/iot-hub-devguide-messages-read-custom.md

@@ -36,8 +36,6 @@ When you use routing and custom endpoints, messages are only delivered to the bu
 > * Service Bus queues and topics with **Sessions** or **Duplicate Detection** enabled are not supported as custom endpoints.
 > * In the Azure portal, you can create custom routing endpoints only to Azure resources that are in the same subscription as your IoT hub. You can create custom endpoints for resources in other subscriptions by using either the [Azure CLI](./tutorial-routing.md) or Azure Resource Manager.
 
-<!--TODO: Add link to Azure RM routing how-to once it's created -->
-
 For more information about creating custom endpoints in IoT Hub, see [IoT Hub endpoints](iot-hub-devguide-endpoints.md).
 
 For more information about reading from custom endpoints, see:

articles/iot-hub/iot-hub-how-to-clone.md

@@ -37,7 +37,7 @@ There are several things to consider before cloning an IoT hub.
 
 * Many resources require globally unique names, so you must use different names for the cloned versions. You also should use a different name for the resource group to which the cloned hub belongs. 
 
-* Data for the original IoT hub isn't migrated. This data includes telemetry messages, cloud-to-device (C2D) commands, and job-related information such as schedules and history. Metrics and logging results are also not migrated.
+* Data for the original IoT hub isn't migrated. This data includes device messages, cloud-to-device (C2D) commands, and job-related information such as schedules and history. Metrics and logging results are also not migrated.
 
 * For data or messages routed to Azure Storage, you can leave the data in the original storage account, transfer that data to a new storage account in the new region, or leave the old data in place and create a new storage account in the new location for the new data. For more information on moving data in Blob storage, see [Get started with AzCopy](../storage/common/storage-use-azcopy-v10.md).
 
@@ -51,7 +51,7 @@ There are several things to consider before cloning an IoT hub.
 
     * Otherwise, you have to use the Import/Export method to move the devices, and then the devices have to be modified to use the new hub. For example, you can set up your device to consume the IoT Hub host name from the twin desired properties. The device will take that IoT Hub host name, disconnect the device from the old hub, and reconnect it to the new one.
 
-* You need to update any certificates so you can use them with the new resources. Also, you probably have the hub defined in a DNS table somewhere — you need to update that DNS information.
+* You need to update any certificates so you can use them with the new resources. Also, you probably have the hub defined in a DNS table somewhere and need to update that DNS information.
 
 ## Methodology
 
@@ -258,9 +258,9 @@ You have to make some changes before you can use the template to create the new
     ``` json 
     "location": "eastus",
     ```
-#### Update the keys for the routing resources that are not being moved
+#### Update the keys for the routing resources that aren't being moved
 
-When you export the Resource Manager template for a hub that has routing configured, you will see that the keys for those resources are not provided in the exported template. Their placement is denoted by asterisks. You must fill them in by going to those resources in the portal and retrieving the keys **before** you import the new hub's template and create the hub. 
+When you export the Resource Manager template for a hub that has routing configured, you will see that the keys for those resources aren't provided in the exported template. Their placement is denoted by asterisks. You must fill them in by going to those resources in the portal and retrieving the keys **before** you import the new hub's template and create the hub. 
 
 1. Retrieve the keys required for any of the routing resources and put them in the template. You can retrieve the key(s) from the resource in the [Azure portal](https://portal.azure.com). 
 
@@ -274,7 +274,7 @@ When you export the Resource Manager template for a hub that has routing configu
 
 1. After you retrieve the account key for the storage account, put it in the template in the clause `AccountKey=****` in the place of the asterisks. 
 
-1. For service bus queues, get the Shared Access Key matching the SharedAccessKeyName. Here is the key and the `SharedAccessKeyName` in the json:
+1. For service bus queues, get the Shared Access Key matching the SharedAccessKeyName. Here's the key and the `SharedAccessKeyName` in the json:
 
    ```json
    "connectionString": "Endpoint=sb://fabrikamsbnamespace1234.servicebus.windows.net:5671/;
@@ -307,7 +307,7 @@ If you want to move the routing resources, you must manually set up the resource
 
 Now you have a template that will create a new hub that looks almost exactly like the old hub, depending on how you decided to handle the routing.
 
-## Move -- create the new hub in the new region by loading the template
+## Create the new hub in the new region by loading the template
 
 Create the new hub in the new location using the template. If you have routing resources that are going to move, the resources should be set up in the new location and the references in the template updated to match. If you are not moving the routing resources, they should be in the template with the updated keys.
 
@@ -355,9 +355,9 @@ Create the new hub in the new location using the template. If you have routing r
 
 Now that you have your clone up and running, you need to copy all of the devices from the original hub to the clone. 
 
-There are multiple ways to copy the devices. You either originally used [Device Provisioning Service (DPS)](../iot-dps/about-iot-dps.md)to provision the devices, or you didn't. If you did, this process is not difficult. If you did not, this process can be complicated.
+There are multiple ways to copy the devices. You either originally used [Device Provisioning Service (DPS)](../iot-dps/about-iot-dps.md) to provision the devices, or you didn't. If you did, this process isn't difficult. If you didn't, this process can be complicated.
 
-If you did not use DPS to provision your devices, you can skip the next section and start with [Using Import/Export to move the devices to the new hub](#using-import-export-to-move-the-devices-to-the-new-hub).
+If you didn't use DPS to provision your devices, you can skip the next section and start with [Using Import/Export to move the devices to the new hub](#using-import-export-to-move-the-devices-to-the-new-hub).
 
 ## Using DPS to re-provision the devices in the new hub
 
@@ -399,11 +399,11 @@ Here are the five options you specify when you run the application. We'll put th
 
 *   **copyDevices** (argument 3) -- set this to true to copy the devices from one hub to another. 
 
-*   **deleteSourceDevices** (argument 4) -- set this to true to delete all of the devices registered to the source hub. We recommending waiting until you are certain all of the devices have been transferred before you run this. Once you delete the devices, you can't get them back.
+*   **deleteSourceDevices** (argument 4) -- set this to true to delete all of the devices registered to the source hub. We recommend waiting until you are certain all of the devices have been transferred before you run this. Once you delete the devices, you can't get them back.
 
 *   **deleteDestDevices** (argument 5) -- set this to true to delete all of the devices registered to the destination hub (the clone). You might want to do this if you want to copy the devices more than once. 
 
-The basic command is be *dotnet run*, which tells .NET to build the local csproj file and then run it. You add your command-line arguments to the end before you run it. 
+The basic command is *dotnet run*, which tells .NET to build the local csproj file and then run it. You add your command-line arguments to the end before you run it. 
 
 Your command-line will look like these examples:
 
@@ -521,7 +521,7 @@ You can view the devices in the [Azure portal](https://portal.azure.com) and ver
 
 1. Check for import/export errors by going to the Azure storage account in the [Azure portal](https://portal.azure.com) and looking in the `devicefiles` container for the `ImportErrors.log`. If this file is empty (the size is 0), there were no errors. If you try to import the same device more than once, it rejects the device the second time and adds an error message to the log file.
 
-### Committing the changes 
+### Commit the changes
 
 At this point, you have copied your hub to the new location and migrated the devices to the new clone. Now you need to make changes so the devices work with the cloned hub.
 

articles/iot-hub/tutorial-routing.md

@@ -43,7 +43,7 @@ In this tutorial, you perform the following tasks:
 
 # [Azure portal](#tab/portal)
 
-There are no additional prerequisites for the Azure portal.
+There are no other prerequisites for the Azure portal.
 
 # [Azure CLI](#tab/cli)
 
@@ -89,7 +89,7 @@ Register a new device in your IoT hub.
    deviceName=DEVICE_NAME
    ```
 
-1. Run the [az iot hub device-identity create](/cli/azure/iot/hub/device-identity#az-iot-hub-device-identity-create) command in your CLI shell. This creates the device identity.
+1. Run the [az iot hub device-identity create](/cli/azure/iot/hub/device-identity#az-iot-hub-device-identity-create) command in your CLI shell. This command creates the device identity.
 
    ```azurecli-interactive
    az iot hub device-identity create --device-id $deviceName --hub-name $hubName 
@@ -110,7 +110,7 @@ Now that you have a device ID and key, use the sample code to start sending devi
 1. In an editor of your choice, open the `Program.cs` file.
 1. Find the variable definitions at the top of the **Program** class. Update the following variables with your own information:
 
-   * **s_myDeviceId**: The device Id that you assigned when registering the device.
+   * **s_myDeviceId**: The device ID that you assigned when registering the device.
    * **s_iotHubUri**: The hostname of your IoT hub, which takes the format `IOTHUB_NAME.azure-devices.net`.
    * **s_deviceKey**: The device key that you copied from the device identity information.
 
@@ -180,19 +180,19 @@ Now, use that connection string to configure IoT Explorer for your IoT hub.
 
 Watch the incoming messages for a few moments to verify that you see three different types of messages: normal, storage, and critical.
 
-These messages are all arriving at the default built-in endpoint for your IoT hub. In the next sections we're going to create a custom endpoint and route some of these messages to storage based on the message properties. Those messages will stop appearing in IoT Explorer because messages only go to the built-in endpoint when they don't match any other routes in IoT hub.
+These messages are all arriving at the default built-in endpoint for your IoT hub. In the next sections, we're going to create a custom endpoint and route some of these messages to storage based on the message properties. Those messages will stop appearing in IoT Explorer because messages only go to the built-in endpoint when they don't match any other routes in IoT hub.
 
 ## Set up message routing
 
-You are going to route messages to different resources based on properties attached to the message by the simulated device. Messages that are not custom routed are sent to the default endpoint (messages/events).
+You're going to route messages to different resources based on properties attached to the message by the simulated device. Messages that aren't custom routed are sent to the default endpoint (messages/events).
 
 The sample app for this tutorial assigns a **level** property to each message it sends to IoT hub. Each message is randomly assigned a level of **normal**, **storage**, or **critical**.
 
 The first step is to set up the endpoint to which the data will be routed. The second step is to set up the message route that uses that endpoint. After setting up the routing, you can view endpoints and message routes in the portal.
 
 ### Create a storage account
 
-Create an Azure Storage account and a container within that account which will hold the device messages that are routed to it.
+Create an Azure Storage account and a container within that account, which will hold the device messages that are routed to it.
 
 # [Azure portal](#tab/portal)
 
@@ -257,7 +257,7 @@ Create an Azure Storage account and a container within that account which will h
 
 ### Route to a storage account
 
-Now set up the routing for the storage account. In this section you define a new endpoint that points to the storage account you just created. Then, create a route that filters for messages where the **level** property is set to **storage**, and route those to the storage endpoint.
+Now set up the routing for the storage account. In this section you define a new endpoint that points to the storage account you created. Then, create a route that filters for messages where the **level** property is set to **storage**, and route those to the storage endpoint.
 
 [!INCLUDE [iot-hub-include-blob-storage-format](../../includes/iot-hub-include-blob-storage-format.md)]
 
@@ -281,7 +281,7 @@ Now set up the routing for the storage account. In this section you define a new
    | --------- | ----- |
    | **Endpoint name** | Create a name for this endpoint. |
    | **Azure Storage container** | Select **Pick a container**, which takes you to a list of storage accounts. Choose the storage account that you created in the previous section, then choose the container that you created in that account. Select **Select**.|
-   | **Encoding** | Select **JSON**. If this field is greyed out, then your storage account region does not support JSON. In that case, continue with the default **AVRO**. |
+   | **Encoding** | Select **JSON**. If this field is greyed out, then your storage account region doesn't support JSON. In that case, continue with the default **AVRO**. |
 
    ![Pick a container.](./media/tutorial-routing/create-storage-endpoint.png)
 
@@ -349,7 +349,7 @@ Once the route is created in IoT Hub and enabled, it will immediately start rout
 
 ### Monitor the built-in endpoint with IoT Explorer
 
-Return to the IoT Explorer session on your development machine. Recall that the IoT Explorer monitors the built-in endpoing for your IoT hub. That means that now you should be seeing only the messages that are *not* being routed by the custom route we created. Watch the incoming messages for a few moments and you should only see messages where `level` is set to `normal` or `critical`.
+Return to the IoT Explorer session on your development machine. Recall that the IoT Explorer monitors the built-in endpoint for your IoT hub. That means that now you should be seeing only the messages that are *not* being routed by the custom route we created. Watch the incoming messages for a few moments and you should only see messages where `level` is set to `normal` or `critical`.
 
 ### View messages in the storage container
 
@@ -404,7 +404,7 @@ If you want to remove all of the Azure resources you used for this tutorial, del
 
 ## Next steps
 
-In this tutorial you learned how to create a custom endpoint for an Azure resource and then create a route to send device messages to that endpoint. Continue to the next tutorial to learn how to enrich messages with additional data that can be used to simplify downstream processing
+In this tutorial you learned how to create a custom endpoint for an Azure resource and then create a route to send device messages to that endpoint. Continue to the next tutorial to learn how to enrich messages with extra data that can be used to simplify downstream processing
 
 > [!div class="nextstepaction"]
 > [Use Azure IoT Hub message enrichments](tutorial-message-enrichments.md)