Post

Replies

Boosts

Views

Activity

WatchOS MDM Enrollment
We have a few development servers that implement MDM and I am trying to incorporate WatchOS Enrollment. I am having trouble connecting to our enrollment URL that is defined in the watch enrollment payload. The error I get indicates that the server certificate is invalid. I can see this error if I attempt to pair to an iPhone that has the WatchOS enrollment declaration on it and I also see if I send an iMessage with our server url and attempt to open the url using the messages app on the watch itself. The certificate is valid, but the SAN does not define my particular domain but rather it uses a wildcard (i.e. DNS Name: *.domain.com and DNS name: domain.com). The url opens fine on any other Apple device (iPhone, iPad, Mac, etc) as well as windows. My question is, is there some problem with using an SSL server certificate that has a wildcard in place of a specific domain when attempting to connect using WatchOS?
2
0
757
Feb ’24
Declarative Management Lacking
I have found that Declarative management, although intriguing and could be useful in the future, is quite lacking. At this point in development, I don't see an advantage over using MDM commands. In order for a device to apply policies, the device must first post to a server to receive the manifest set, then for each item in the set, the device must post to the server to get the policy. How is that better than posting via MDM to obtain a policy (configuration profile, app, etc.)? It seems there is no benefit in terms of time complexity. In both scenarios the device would need to make O(n) posts. This doesn't solve the scalability issue with regards to the MDM channel. The limitation with regards to available native declarations vs configuration profiles means declarative management is not yet ready for prime time. Although the first attempt at solving this through LegacyProfiles allows for installing ConfigurationProfiles, this method adds another POST, so at this point it's 1 post to get the manifest, then 2 mores posts to get the policy, which is even worse that MDM. Regarding the status channel, the status report is missing quite a bit of device information. Currently, in order to obtain a more complete view of device state using MDM, the MDM server must send a set of commands to get information, installed profiles, apps, certificate, etc. The Status channel includes some of this stuff, but not all of it, which means a device must augment the status channel with some (or all) of these commands.
0
0
471
Feb ’24