Merge pull request #207267 from ValOlson/patch-12

Update device-update-multi-step-updates.md

Author: PRMerger10

articles/iot-hub-device-update/device-update-multi-step-updates.md

@@ -195,6 +195,9 @@ Example Update Manifest with one Reference Step:
 }
 ```
 
+> [!NOTE]
+> In the [update manifest]( https://docs.microsoft.com/azure/iot-hub-device-update/update-manifest), each step should have different “installedCriteria” string if that string is being used to determine whether the step should be performed or not. 
+
 ## Parent Update vs. Child Update
 
 For Public Preview Refresh, we will refer to the top-level Update Manifest as `Parent Update` and refer to an Update Manifest specified in a Reference Step as `Child Update`.  
@@ -208,6 +211,11 @@ Inline step(s) specified in `Parent Update` will be applied to the Host Device.
 > [!NOTE]
 > See [Steps Content Handler](https://github.com/Azure/iot-hub-device-update/tree/main/src/content_handlers/steps_handler/README.md) and [Implementing a custom component-Aware Content Handler](https://github.com/Azure/iot-hub-device-update/tree/main/docs/agent-reference/how-to-implement-custom-update-handler.md) for more details.
 
+> [!NOTE]
+> Steps Content Handler: 
+> IsInstalled validation logic: The Device Update agent’s [step handler]( https://github.com/Azure/iot-hub-device-update/blob/main/src/content_handlers/steps_handler/README.md) checks to see if particular update is already installed (i.e.,  IsInstalled() resulted in a result code “900” i.e., is installed is ‘true’). To avoid installing an update that is already on the device the DU agent will skip future steps because we use it to determine whether to perform the step or not.
+> Reporting an update result: The result of a step handler execution must be written to ADUC_Result struct in a desired result file as specified in --result-file option [learn more]( https://github.com/Azure/iot-hub-device-update/blob/main/src/content_handlers/steps_handler/README.md#steps-content-handler). Then based on results of the execution, for success return 0, for any fatal errors return -1 or 0xFF.
+
 ### Reference Step In Parent Update
 
 Reference step(s) specified in `Parent Update` will be applied to the component on or components connected to the Host Device. A **Reference Step** is a step that contains update identifier of another Update, called as a `Child Update`.  When processing a Reference Step, the Steps Handler will download a Detached Update Manifest file specified in the Reference Step data, then validate the file integrity.