We can either point the device at a URL to download and install the Legacy Profile (what we are doing now), or wrap it in a Declarative asset and reference that (newer offered path).
Is there a recommended approach, and what drives it — reliability if the URL is unreachable at install time, how refreshes are handled, payload size?
One of the pain points we have been working through with the Legacy Profile migration/default use (using the workflow point the device at a URL to download and install the Legacy Profile) is that durring the deployment of net new Declarations at ADE, and UIE on new enroll devices the profile install fails after ~15-30 profiles, and results in deadlock (FB22832791, FB22828244, and FB22827718) until devices reboot. Not ideal for a net new enroll with a end user.
Would moving all net new deployments to the asset fix this? Is that going to be required? Thanks!
The choice between ProfileURL and ProfileAssetReference ultimately boils down to how you want to authenticate the requests. With ProfileURL there is no choice - the URL is expected to be on the MDM server and the device provides the device identity cert (with in TLS handshake or MDM-Signature). With ProfileAssetReference you get the choice of using "MDM" or "None" for the asset authentication type. The former is effectively what ProfileURL does. The latter allows you to host the profile data on any server and use your own mechanism for protecting access. In addition, the asset includes some integrity checks such as verifying the hash of the downloaded content. In terms of preference, the asset provides more flexibility and security and should be preferred.
We are aware of the feedback items you highlighted and are working to resolve the issues.
