Promise

Author: jlian

articles/iot-hub/iot-hub-ha-dr.md

@@ -55,7 +55,7 @@ Both these failover options offer the following recovery point objectives (RPOs)
 Once the failover operation for the IoT hub completes, all operations from the device and back-end applications are expected to continue working without requiring a manual intervention. This means that your device-to-cloud messages should continue to work, and the entire device registry is intact. Events emitted via Event Grid can be consumed via the same subscription(s) configured earlier as long as those Event Grid subscriptions continue to be available.
 
 > [!CAUTION]
-> - The Event Hub-compatible name and endpoint of the IoT Hub built-in Events endpoint change after failover, and configured consumer groups are removed. When receiving telemetry messages from the built-in endpoint using either the Event Hub client or event processor host, you should [use the IoT hub connection string](iot-hub-devguide-messages-read-builtin.md#read-from-the-built-in-endpoint) to establish the connection. This ensures that your back-end applications continue to work without requiring manual intervention post failover. If you use the Event Hub-compatible name and endpoint in your application directly, you will need to [reconfigure the consumer group that they use and fetch the new Event Hub-compatible endpoint](iot-hub-devguide-messages-read-builtin.md#read-from-the-built-in-endpoint) after failover to continue operations. If you use Azure Functions or Azure Stream Analytics to connect the built-in endpoint, you also need to perform a **Restart**.
+> - The Event Hub-compatible name and endpoint of the IoT Hub built-in Events endpoint change after failover, and configured consumer groups are removed (this is a bug that will be fixed before May 2020). When receiving telemetry messages from the built-in endpoint using either the Event Hub client or event processor host, you should [use the IoT hub connection string](iot-hub-devguide-messages-read-builtin.md#read-from-the-built-in-endpoint) to establish the connection. This ensures that your back-end applications continue to work without requiring manual intervention post failover. If you use the Event Hub-compatible name and endpoint in your application directly, you will need to [reconfigure the consumer group that they use and fetch the new Event Hub-compatible endpoint](iot-hub-devguide-messages-read-builtin.md#read-from-the-built-in-endpoint) after failover to continue operations. If you use Azure Functions or Azure Stream Analytics to connect the built-in endpoint, you might need to perform a **Restart**.
 >
 > - When routing to storage, we recommend listing the blobs or files and then iterating over them, to ensure all blobs or files are read without making any assumptions of partition. The partition range could potentially change during a Microsoft-initiated failover or manual failover. You can use the [List Blobs API](https://docs.microsoft.com/rest/api/storageservices/list-blobs) to enumerate the list of blobs or [List ADLS Gen2 API](https://docs.microsoft.com/rest/api/storageservices/datalakestoragegen2/path/list) for the list of files. 
 
@@ -77,7 +77,7 @@ For step-by-step instructions, see [Tutorial: Perform manual failover for an IoT
 
 Test drills should not be performed on IoT hubs that are being used in your production environments.
 
-### Using manual failover for migrating IoT hub to a different region
+### Don't use manual failover to migrate IoT hub to a different region
 
 Manual failover should *not* be used as a mechanism to permanently migrate your hub between the Azure geo paired regions. Doing so increases latency for the operations being performed against the IoT hub from devices homed in the old primary region.