A year ago today we launched the public preview of the Azure IoT Hub Device Provisioning Service, and today we announce the public preview of the latest major wave of functionality to automate device provisioning! We've taken your feedback, made changes, built features, and are happy to make the following features available to you today via public preview:
- Increased limit on the number of CA certificates stored (GA).
- Increased limit on the number of enrollments (GA).
- Symmetric key attestation support (preview).
- Re-provisioning support (preview).
- Enrollment-level allocation rules (preview).
- Custom allocation logic (preview).
All these features have support in the C device SDK and the Node service SDK, with full support to follow in general availability. Let's dive deeper into each bullet.
Increased limits
As of today, all Device Provisioning Service instances have new max limits on the number of CA certificates stored and number of devices enrollments:
- 25 CA certificates which is up from 10.
- 500,000 enrollments, with more available if you contact support. This number is up from 10,000.
These limit increases are generally available.
Symmetric key attestation
Symmetric keys are one of the easiest ways to start off using the provisioning service and provide an easy “Hello world” experience for those of you who are new to device provisioning. Furthermore, symmetric key enrollment groups provide a great way for legacy devices with limited existing security functionality to bootstrap to the cloud via Azure IoT. Check the docs to learn more about how to connect legacy devices.
Symmetric key support is available in two ways:
- Individual enrollments, in which devices connect to the Device Provisioning Service just like they do in IoT Hub.
- Enrollment groups, in which devices connect to the Device Provisioning Service using a symmetric key derived from a group key.
Check out the documentation to learn more about using this new way to verify a device's identity.
Automated re-provisioning support
Based on customer feedback we added first-class support for device re-provisioning, allowing devices to be reassigned to a different IoT solution. Customers wanted their devices to be reassigned to a different IoT solution if something changed. The Device Provisioning Service now supports re-provisioning IoT devices from one solution to the other. Re-provisioning support is available in two flavors:
- Factory reset, in which the device twin data for the new IoT hub is populated from the enrollment list instead of the old IoT hub. This is common for factory reset scenarios as well as leased device scenarios.
- Migration, in which device twin data is moved from the old IoT hub to the new IoT hub. This is common for scenarios in which a device is moving between geographies.
We’ve also taken steps to preserve backwards compatibility for those who need it. Check the documentation to learn the details. If you have strong feelings about re-provisioning defaults, please let me know in the comments!
Check out the documentation to learn more about how to use re-provisioning.
Enrollment-level allocation rules
Customers need fine-grain control over how their devices are assigned to the proper IoT hub. For example, Contoso is a solution provider with two large multinational companies as customers. Each of Contoso’s customers is using Contoso devices across the globe in a geo-sharded setup. Contoso needs the ability to tell the provisioning service that customer A’s devices need to go to one set of hubs distributed geographically and that customer B’s devices need to go to another set of hubs distributed geographically. Enrollment-level allocation rules allow Contoso to do just that.
Per-enrollment allocation policies allow customers to have the level of control they need with the following functionality:
- Specifying allocation policy per enrollment gives finer-grain control.
- Linked hub scoping allows the allocation policy to run over a subset of hubs.
This is available for both individual and group enrollments. We're also going to be deprecating the iotHubHostName field in the enrollments in favor of a new way of specifying the desired IoT hub that's consistent with the rest of the allocation features in the Device Provisioning Service.
Custom allocation logic
Sometimes customers need to get data from external systems to avoid keeping duplicate copies of information, such as configuration information or even sales data. With custom allocation logic, the Device Provisioning Service will trigger an Azure Function to determine where a device ought to go and what configuration should be applied. Custom allocation logic can only be set at the enrollment level. You can set custom allocation logic via the service SDK or service REST APIs for now, and Azure Portal support will come in the following weeks.
Watch the video to see how it works:
Try out these features today and read up on them in the documentation! General availability will follow after we confirm we got it right. Leave feedback on this blog post, on the docs, or on the Azure IoT UserVoice forum.
To sum things up with a limerick:
Thank you for all the feedback!
It made planning our features a snap.
Please try them all out
And give us a shout
To tell us if we are on track.