Share via

How to re-provision an IoT Edge Device?

Amparo Pittier 21 Reputation points
Jul 28, 2020, 9:31 PM

Hello,

I've been experimenting with the DPS and individual enrollment using symmetric key attestation for an IoT Edge Device.

After following the steps detailed in "Device Provisioning Service defined with an individual enrollment defined using symmetric key attestation", when the corresponding IoT Edge Device starts up, it gets properly assigned to the target Iot Hub.

Now, I want to assign the same IoT Edge Device to a different Iot Hub. For this, I modify the individual enrollment definition by:

  • specifying a different Iot Hub (while keeping the 'static configuration' option) and
  • defining a DeviceID (originally it was blank).
    (The re-provision policy is set to "Re-provision and reset to initial config").

Then, I deployed an IoT Edge Module on the Edge Device, with a Direct Method to trigger the re-provisioning, which calls the RegisterAsync() method from Microsoft.Azure.Devices.Provisioning.Client.ProvisioningDeviceClient.

But even though a new Device ID (Iot Edge Device) gets created in the (new) target Iot Hub, the Device is not actually connected to this Iot Hub (is not reachable from the Iot Hub).

  • Should it be possible to re-provision the Device following this approach?
  • Or is it mandatory to restart the iotedge daemon for changes to take effect?
  • If so, is it possible to restart the iotedge daemon remotely?
  • I mean, is it possible to re-provision the Iot Edge Device remotely?

I'd appreciate any guidance on this.

Many thanks.

Best regards,
Amparo

Azure IoT Edge
Azure IoT Edge
An Azure service that is used to deploy cloud workloads to run on internet of things (IoT) edge devices via standard containers.
581 questions
Azure IoT Hub
Azure IoT Hub
An Azure service that enables bidirectional communication between internet of things (IoT) devices and applications.
1,221 questions
{count} votes

Accepted answer
  1. Sander van de Velde | MVP 33,951 Reputation points MVP
    Jul 30, 2020, 10:37 PM

    More information about this topic is seen in this closed issue: https://github.com/MicrosoftDocs/azure-docs/issues/53757 . There, rebooting the IoT Edge device is suggested.

    The functionality executed by an IoT Edge device is separated from the IoT Hub connectivity which is a good thing.

    Having to reboot an IoT Edge device just to have it reprovisioned to another IoThub (if applicable) is disruptive for the workload of an IoT Edge device.

    The IoT Edge runtime should be capable to be forced to reprovision via the cloud or should be able to reprovision on its own without stopping the work done by the individual modules and the routes.

    Please upvote this suggestion: https://feedback.azure.com/forums/907045-azure-iot-edge/suggestions/40393507-force-reprovisioning-of-the-iot-edge-daemon

    2 people found this answer helpful.

2 additional answers

Sort by: Most helpful
  1. QuantumCache 20,346 Reputation points
    Jul 28, 2020, 11:11 PM

    Hello @Amparo Pittier , Thanks for reaching out to us!

    Quote: Send a provisioning request from the device

    In order for devices to be reprovisioned based on the configuration changes made in the preceding sections, these devices must request reprovisioning.

    How often a device submits a provisioning request depends on the scenario. However, it is advised to program your devices to send a provisioning request to a provisioning service instance on reboot, and support a method to manually trigger provisioning on demand. Provisioning could also be triggered by setting the desired property.

    The reprovisioning policy on an enrollment entry determines how the device provisioning service instance handles these provisioning requests, and if device state data should be migrated during reprovisioning. The same policies are available for individual enrollments and enrollment groups:

    For example code of sending provisioning requests from a device during a boot sequence, see Auto-provisioning a simulated device.

    To learn more Reprovisioning, see IoT Hub Device reprovisioning concepts

    Or is it mandatory to restart the IoT edge daemon for changes to take effect?
    If so, is it possible to restart the iotedge daemon remotely?

    Please see this documentation on a better understanding.

    14134-image.png

    The IoT Edge security daemon is a native component that needs to be updated using the package manager on the IoT Edge device.

    0 comments No comments

  2. Amparo Pittier 21 Reputation points
    Jul 29, 2020, 8:01 PM

    Hi @QuantumCache ,
    I guess my question was not clear enough.

    • Goal: use DPS -with individual enrollment- to get Iot Edge Devices (i.e., devices with the Iot Edge Runtime), initially assigned to a default Iot Hub, and then later, re-assigned to a different Iot Hub with a specific Device ID set.*

    The first part works fine, by setting the proper " DPS symmetric key provisioning configuration" in the config.yaml file, the Iot Edge Device gets properly assigned to the default Iot Hub (using the Registration ID as Device ID, cause I'm not defining any Device ID at this point).

    Then, when I trigger the re-provision from the device (by calling a direct method exposed by an Iot Edge module running on the Iot Edge Device, a Device ID is created in the new Iot Hub. BUT, when accessing this new device from the azure portal, it displays: "IoT Edge Runtime Response: NA":

    14346-iotedgeruntimeresponse-na.png

    In order to get the new Device reachable from the Azure Iot Hub I need to Restart the IoT Edge security manager by running: sudo systemctl restart iotedge

    So that's my question, is this a mandatory step to get everything properly connected? Do I need to manually restart the IoT Edge security manager? (i.e., that means that I need remote access to the unit, that's not a remote command that I can run from the Azure portal).

    Please find below some additional resources similar to my question:

    Best regards,
    Amparo


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.