IoT Hub Module Twin Tag value disappears after re-provisioning via DPS

Abby Greentree 126

I am using x509 certificates as Device Authentication Type with Azure Device Update Agent installed on my device. The device Update Agent uses a Module Identity with Symmetric Keys as the authentication type (this is done through Azure Identity Service).

When device certificates are periodically rotated, the device re-provisions itself via DPS to update the certificate thumbprint within IoT Hub. After this happens, it seems the Module Twin complete resets. If I had previously set a device's ADUGroup value in the tags of the Device Update Agent's Module Twin, it disappears after certificate refresh and the device loses it's group.

Any insights as to how I can avoid this issue and persist the ADU group across re-provisioning?

Thank you in advanced for your assistance.

1 answer

QuantumCache 20,031 Reputation points

2023-02-18T02:38:28.82+00:00
Hello Abby Greentree, This is a great discussion, thanks for bringing to this forum.

To persist the ADU group across re-provisioning, you can add the ADUGroup tag to the **device twin instead of the module twin.** The device twin is not reset during re-provisioning, so the tag value will persist.

You can add the tag to the device twin using the Azure portal, Azure CLI, or a sample .NET app.

Manage device groups in Device Update for IoT Hub

Device Update for IoT Hub allows deploying an update to a group of IoT devices. This step is optional when deploying updates to your managed devices. You can deploy updates to your devices using the default group that is created for you. Alternatively, you can assign a user-defined tag to your devices, and they'll be automatically grouped based on the tag and the device compatibility properties.

Understand and use device twins in IoT Hub

Device twins are JSON documents that store device state information including metadata, configurations, and conditions. Azure IoT Hub maintains a device twin for each device that you connect to IoT Hub.

Please comment in the below section if you need further help in this matter.

If this answers your query, do click Accept Answer and Yes for this answer as helpful. And, if you have any further query do let us know.
Please sign in to rate this answer.
Abby Greentree 126 Reputation points

2023-02-20T17:45:00.8333333+00:00

Hi Satish - thanks for your quick response.

I am using the Device Update agent with Azure Identity Service (similar to the setup described here). When doing so - the Device Update agent is added as a module identity by default. Which I believe also aligned with the AIS practice of using a Module Identity for agent code. When ADU Agent is running with a module identity, setting the ADUGroup tag on the device twin level does not seem to have any affect.

Is there a way to use the ADUGroup tag on the device twin level even when the ADU Agent is using module identity?

If not, would you advise using ADU Agent with the device identity instead?

It seems possible to instead set / re-apply the ADUGroup tag in the twin via a backend process (i.e. Azure Function, IoT Hub Job) after a certificate refresh, would that be advisable?

QuantumCache 20,031 Reputation points

2023-02-21T01:56:41.4966667+00:00

Hello Abby Greentree,

Is there a way to use the ADUGroup tag on the device twin level even when the ADU Agent is using module identity?

I think when the ADU agent is running with a module identity, setting the ADUGroup tag on the device twin level will not have any effect. (Need to verify on this...)

If you prefer to use the device identity instead, that is also an option. You can add the Device Update agent as a device identity instead of a module identity, and set the ADUGroup tag on the device twin level, which requires additional setup, such as creating a device identity for the Device Update agent and configuring the appropriate authentication and authorization policies.

After the certificate refresh, you can use a backend process such as an Azure Function or an IoT Hub Job to update the desired properties of the module twin to set/re-apply the ADUGroup tag, and yeah you need to develop the additional backend process for this

Reference links

Abby Greentree 126 Reputation points

2023-02-21T15:36:30.78+00:00

Hi Satish--

I think when the ADU agent is running with a module identity, setting the ADUGroup tag on the device twin level will not have any effect. (Need to verify on this...)

In my testing it does not have any effect, but please let me know if I am missing something.

If you prefer to use the device identity instead, that is also an option... which requires additional setup, such as creating a device identity for the Device Update agent and configuring the appropriate authentication and authorization policies.

I'm a bit confused on this statement, do you mean the ADU Agent would need a separate device registration? I.e. for Device A - I would actually have two devices in IoT Hub, Device A and Device A ADU Agent that each have their own Device Identity?

Abby Greentree 126 Reputation points

2023-02-21T16:05:55.26+00:00

Satish --

I would like to clarify this statement:

The device twin is not reset during re-provisioning, so the tag value will persist.

Is the module twin resetting during re-provisioning intended behavior? I think your statement indicates that it's expected behavior and that's definitely what I've observed in testing. But this behavior intentional or a bug?

Thanks.

QuantumCache 20,031 Reputation points

2023-02-21T16:30:50.1933333+00:00

Hello Abby Greentree,

For one moment i was little worried that I may have overlooked on Device Twin vs Module twin, lol :)

The resetting of the module twin during re-provisioning is expected behavior. The device app must retrieve the full document for desired properties and subscribe for desired properties update notifications after connecting to the IoT Hub.

When a device is provisioned using DPS, the provisioning service creates a module twin for each module running on the device.

When a device is re-provisioned, a new set of module twins are created for the device. This means that the old module twins are no longer valid, and are replaced by the new module twins. As a result, the module twin resetting during re-provisioning is intended behavior.

It is worth noting that the new module twins can be initialized with default properties and values. If you need to preserve the module twin properties and values during re-provisioning, you can implement a mechanism to back up and restore the module twins.

In summary, the module twin resetting during re-provisioning in Azure Device Provisioning Service is intended behavior, and is not a bug.

If you see different behavior, please do let us know or send us an email and we will help you immediately, Any Time!!!
Sign in to comment