search

ms-iot / azure-client-tools

Azure Client Tools
Other
43 stars 37 forks source link

Is Azure Provisioning Service required? #9

Closed FunctionallyLiterate closed 5 years ago

FunctionallyLiterate commented 5 years ago

I just finished building an entire solution based around the iot-core-azure-dm-client project. Our UWP application is set up to use a completely custom provisioning endpoint we built into our api. Our solution does not use the Azure Provisioning Service. Instead, we have out own process that the device goes through and in the end receives it's api key to our Azure Iot Hub.

If we migrate from the dm-client to this new approach will we still be able to do this? From reading the documentation so far in this project it seems like it's tied into the Azure Provisioning Service. Is it possible for our UWP app to handle provisioning with this new Azure Client?

To clarify a little more, basically my UWP application has similar code to this in it which manages the communication with SystemConfigurator.exe:

https://github.com/ms-iot/iot-core-azure-dm-client/blob/master/samples/IoTDMBackground/DMClientBackgroundApplication.cs

My version implements GetConnectionStringAsync() in the above example differently since we have our own provisioning system which provides the Iot Hub credentials that are used for the device to build it's connection string.

Will it be possible to handle the provisioning process without using Azure Provisioning service with this library as I am doing with dm-client?

Thanks

gmileka commented 5 years ago

Hi ds62987, This is doable with some code changes to the AzureDeviceManagementClient.exe.

Today, AzureDeviceManagementClient.exe attempts to retrieve the connection string from the TPM, if it succeeds, it proceeds without invoking DPS. If it doesn't, it invoked DPS.

The main thing we would have to solve is the timing.

The model implemented today in AzureDeviceManagementClient.exe, assumes that the device agent will do the provisioning, and retrieve the device connection string - and from there and based on the configuration, it can further create module twins, and store all the connection strings into the designated TPM slots. Once this is done, the other applications on the device can pick-up their connection strings from their designated slots... Those apps would basically keep checking the TPM until the connection strings appear...

If the provisioning is done by another application, something similar will need to be implemented... The provisioning application will need to know how to store connection strings and create modules... And the device agent (AzureDeviceManagementClient.exe) will need to wait for it to be done before proceeding to establish the connection to IoT Hub...

Does this make sense?

gmileka commented 5 years ago

We can also work explore together possible solutions - let us know...

amisaify commented 5 years ago

@ds62987 Could you please also share the reason you are not using Azure DPS?

FunctionallyLiterate commented 5 years ago

Thank you for the response. For our scenario the customer has strict requirements on how to assign the device's identity in our custom application and it made more sense for us to just build the provisioning system into our application rather than pay for the Azure DPS service.

Really all we would need would be the ability to assign the connection to the Iot hub through our UWP app and I think our existing system could work with this new Azure Client Tools code. That would be great if it was possible. Would that be difficult to change?

Unfortunately due to timelines of the project and some advice I got from Azure support a few months ago we decided to build everything on the DM Client codebase. It appears that wasn't a good idea... If this can't be done it looks like our application will be stuck using SystemConfigurator.exe for the foreseeable future. We don't have time at this point to scrap this portion of the project and rebuild it with DPS.

gmileka commented 5 years ago

We can definitely work with you to understand more on what will need to change, and we can see if a plan is doable in the short term. We can continue our conversation using my email gmileka at microsoft com. Please, feel free to drop me an email...

gmileka commented 5 years ago

Hi ds62987, I'm closing this thread. Please, feel free to re-open if needed. Let us know if you need changes in the device agent to accommodate your needs.