Hey everyone,
a situation has come up, and I'm asking if you know of a way we can provide access to just these settings for an end-user in Kiosk Mode.
Hey everyone,
a situation has come up, and I'm asking if you know of a way we can provide access to just these settings for an end-user in Kiosk Mode.
As far as I know, there is no MobiControl legacy script nor javascript to set date/time of Android Enterprise devices.
Though there are tricks to go straight to the Date-Time tab of device's Settings while blocking the launching of Settings app as a whole, the date-time tab provides access to extra settings other than just date & time, and the UI of the tab nearly always provides access to other tab/page within Settings on most device brands/models. Hence, this approach likely doesn't fit your use case.
The last approach I can think of is to use latest version of Soti Settings Manager Apps, which includes configurable time-zone tab to allow device end-user to manually set desired time-zone, and the actual time must be synced from SNTP server set by MDM policy, rather than manually configurable to any desired value by device end-user, which by itself is a security threat if allowed.
And how would you solve the problem if you can't authenticate to the network...for example, if authentication is certificate-based only and the device has been offline or completely drained, and when it powers back on, it has a date and time set in the past?
Hi Remy,
If it is a Zebra or Honeywell device, you can accomplish this by using the Soti javascript (run when Lockdown starts) and an XML file based on Zebra MX or Honeywell Enterprise Provisioner - these tools allow you to set a fixed date.
The date can be read from a local XML file. This local XML file can be created dynamically by another Soti script that is scheduled and run only when the device is online. I did this for my customer some time ago and it worked :-)
Hi Radim,
Thanks for the tip. I’ll proceed with the implementation for the Honeywell ecosystem...however, the integration with the Samsung ecosystem remains an open topic.
You can also do this oem config app from honeywell.
The Samsung KSP only provides to change NTP server but maybe request this setting as a feature request throught the Samsung Knox Portal to Samsung..
For devices with a SIM card, you can force the use of the network time by using the following script:writesecuresetting -glo auto_time 1
I've already implemented this script in Lockdown mode for several customers. It helps resolve issues where the device has been without a battery for too long and ends up with an incorrect date and time — for example, January 1st, 2009. This kind of mismatch can cause all internet communications relying on certificates to fail, including connection to the DS.
Hi Remy,
Thank you for posting on SOTI Pulse, and a big thanks to Raymond, Radim, Rafael, and Benjamin for their valuable input—their expertise and willingness to help are greatly appreciated!
Have you had a chance to test the solutions suggested? Were they able to resolve your issue?
If not, or if you have any further questions or concerns, please don’t hesitate to reach out. We're here to support you every step of the way.
Regards,
Hi HD,
To be absolutely honest with you, I would prefer an official response from SOTI regarding this phenomenon. The provided workarounds are only partially valid and depend on factors that, in our case, are not always met. Nevertheless, I would like to thank everyone for their input.
update:
SOTI MobiControl Android Agent now automatically restores the last known system date and time from its internal database when a device is powered on after a complete battery drain. This feature ensures that devices maintain accurate time for certificate-based Wi-Fi reconnections and continued manageability through SOTI MobiControl.
SOTI MobiControl Product Notes
update2:
It is not functioning properly...
update3:
Additional settings/commands are necessary, but once done, it works!
Hi Remy.
Thanks for posting on SOTI Pulse.
We appreciate your honest feedback and understand the importance of receiving an official response. If the shared workarounds are not fully applicable in your environment, we highly encourage you to reach out directly to our support team for a more tailored resolution.
If this post did not fully resolve the issue and you have additional questions, please don’t hesitate to contact SOTI Support at support@soti.net to open a new case. One of our support engineers will be happy to assist you further.