No Matches Found!
Try with a different search term
Hi,
What other ways are there to set the value of a custom data (for Android Enterprise devices) for a device other than by Group details?
Thanks
Adam
I don't fully understand what your concern is.
Parameters (i.e. INI/XML file and data location, data types, etc.) of a custom data can be DEFINED in the "Custom Data" Advanced Configuration tab of any non-virtual device group of the device group tree. Such definition will be global and can be selectable for re-use by any other device group. I see no other need of finding any alternative way other than "group details" to configure it.
Regarding the actual VALUE of the custom data stored in designated INI/XML file, it is set/written by customer's software running on each targeted device, and is thus not related to anything in the web-console.
If you have other issue(s) specific to your use case, please clarify and provide more details.
Hi Raymond,
We have a number of lockdown profiles depending on usecase. We also have a lockdown for QA purposes.
The ultimate goal is to be able to switch to any of the lockdown profiles from the QA lockdown, possibly by pressing a home item, but I am open to all ideas.
At the moment shared device doesn't seem an option as we wont be having an external identity management on the account.
I see that the device relocation rules can be triggered based on custom data, however if these are set by the device group details then I dont really see the point of this functionality. Please correct me if I have misunderstood something.
I personally don't think using custom data to switch to different kiosk menus is a good approach because
1. the kiosk menu change will not be functional when the device is offline, whether temporarily for a few minutes or for an extended period of time.
2. the kiosk menu change can happen after a considerable amount of time delay even if the device is online because custom data collected may be temporarily buffered on the device rather than being flushed immediately to the MobiControl server for triggering device group relocation with alert rule/policy.
In either cases, the near real-time response (likely 15 seconds or less) expected by any average end-users for entering into a major GUI screen layout cannot be met.
Really great point about the delay Raymond - thank you !
My search continues
Normaly, this information will be gathered on check-in.
The Check-In will be done normaly on regular base (depends on your "folder" configuration).
Take a look into the folder settings where these devices are located:
1. Right click on the relevant folder
2. Group Details
3. Configurations Tab
4. Update Schedule
5. Change the "Device Update Schedule" to a time which would be fine
BUT be aware, if there are many devices in the folder this will cause heavy server load if the time is too short.
Also, if there are subfolders, this setting could be inherited and also effect those other devices.
Another way could be to force the device to do a check-in (via executing a stored script or so) after the data changed. I never did that but i think others like Raymond could help here.
But as Raymond already said for example for offline devices this won't work and even when they are online, there will be a delay.
Custom data buffer is NOT flushed after EACH device check-in, whether scheduled or specially requested via web-console action/script/API. Thus, even when there is very few devices enrolled onto a server and the devices are configured to check in every minute, flushing of custom-data buffer (and thus firing of alert rule based on data collected) will likely be five minutes or more and not responsive enough for average end-users in the required use case.
Hi Raymond,
i agree to you regarding "ot responsive enough for average end-users in the required use case." but when i fill up or change an ini on the device, this data get refreshed everytime i do a check-in. And we work with a big bunch of devices.
Hi Both,
Thank you very much for all of your input.
I eventually moved away from the idea given the trouble setting the custom data without a script and the potential for delay in the system.
I have devised a alternative method using a shared device method.
The QA lockdown being the parent, a shared_device item to launch the log in screen and finally a series of dummy SOTI Identity groups and users to select the final lockdown.
Do you see any huge flaws in this setup?
Thank you
Adam