No Matches Found!
Try with a different search term
No Matches Found!
Try with a different search term
There's a new home for Articles. Find Articles on Our Product Support Page.
Hello all, first sorry, we discover Android Entreprise and we are little lost when we enroll devices .. server mobicontrol is on version: 15 5 1 1010 We have some new device Zebra TC58 under android 11. If i take new device OUT OF the box, i follow the step to initialize the device and type afw#mobicontrol and the agent google entreprise is well downloaded and after i enter the code to enroll device to mobicontrol, The result is, device is enroll into management type -> Work Managed device -> PERFECT All seems to work, remote connexion, install profile, rules, and so on ... If i take an other new device OUT of the box, take the same agent from mobicontrol (v 15.4.4.1063), copy paste the agent, install agent, enroll device into mobicontrol. The result device is enroll into management type -> Work managed profile -> BAD Because, we notice there is two " path " on the device (professionnel / personnel), if we starts a remote control (name is remote view), end user need to ACCEPT the permission before the remote , problem with rules, ... We don t want to enroll device as a work profile ..because we notice, this mode can be too much restrictif for us and perhaps lose time when we meet some incident .. My question is, is it possible to enroll device into management type Work Managed device when the device has been initialize ? Because if i copy paste the agent soti 15.4.4.1063 , install it, the device is enroll into work profile .. a command exist perhpas or something else ? thanks for your time
Hello all, first i wish to all people a happy new year ,,A year without no problem with device :) well, we work with mobicontrol server on version 15.5.1.1010. Device is zebra TC75X under android 8 -> enroll entreprise (first device , we discover entreprise just now). Agent is on version 15.3.0.1006 I have a profile with a lockdown and when a apply to the zebra, device information is empty -> no sign of battery / date / network and so on .. If i do the same on my Zebra Android 7 with android + more or less same profile , device information is well present ... Any idea would be appreciate ? How to resolve this ? thanks
Since Zebra appears to be motivated to bridge the functionality gap between DA and AEDO, let's use this thread to list what you want to see them add. If you see another post in the list you identify with and don't need any additional comment, use the upvote to add your weight to that feature. Let's help Zebra help us...
I am wondering if anyone has found a way to not only "ungray" the setting under Settings > Google > Security > Google Play Protect so that it can be toggled, but also actually toggle it OFF. SOTI provided two methods for doing the first item, to re-enable the setting so that it can be manually toggled. The methods are actually the same thing (a feature control) done two different ways: (1) Send script command: writesecureprofstring DeviceFeature DisableVerifyApps 1 apply featurecontrol (2) Create / assign a Feature Control that has "Disable Verify Apps Enforcement" checked. In my experience, these have the effect of re-enabling the toggle on the GPP setting, but leaving the setting toggled ON. It then has to manually be toggled OFF. I have certain apps that are mission-critical and mass-deployed, so touching each device to turn off GPP scanning for first deployment and subsequent app updates is absolutely not a feasible option. So far, SOTI Support has been unable to provide a means to programmatically toggle that option OFF. My other rather large challenge with this is, under AEDO, I've found that a Lockdown Screen profile has the side effect of toggling GPP back on, and graying it back out again so that it once again cannot be toggled off. SOTI says that this is the "expected behavior," to which I respond, WHY? Perhaps I am missing a pertinent concept here, but to my mind it is ridiculous to have a lockdown screen profile that also has the effect of locking GPP scanning on. These corporate users need app installations and app updates -- and those need to happen while the lockdown screen is in place. I've found that if the lockdown profile is already applied, the above two methods will have the effect of "ungraying" the GPP option so that it can manually be turned off. BUT if the lockdown profile ever is re-applied, or refreshes itself due to an editing change (such as perhaps adding an entry for whatever new app(s) are intended to be applied), then GPP is again turned on and the toggle is grayed out. This is very frustrating. I need a way to turn GPP scanning off, and KEEP it off, until I (and only I) tell it that it can turn back on again, Any advice would be appreciated. Thank you, Mark
With Android Enterprise Device Owner enrollment you can end up in a situation where a number of system applications are disabled by default. There are enrollment Extras that you can include in a NFC chip or custom QR code to leave all system apps enabled but if they device has already been enrolled is appears that you have to use the enable_system_app script in order to re-enable the apps individually. Is there an alternative to individually re-enabling system apps such as using a wild card? eg: enable_system_app * enable_system_app com.zebra.*
I have a 14.2.3.1069 instance with Zebra MC93s enrolling with AEDO via StageNow on agent version 13.7.6 Build 1004. The devices are running the latest public Oreo BSP from Zebra (01-21-18.00-OG-U00-STD) for the Helios devices and have the Zebra OEM Plugin (Zebra_Hawkeye_RC_AE_1.6.0.102) installed. On just about 1 out of 3 of the devices I enroll I get a prompt to manually enable the modify system settings permission. The other devices never prompt for this and install all packages and profiles without issue. The devices that prompt for this actually fail to install any packages containing APKs, citing storage/permission issues. After granting the permission manually and then forcing a package reinstallation the installation is successful. Any idea on what might be going on here?
Is there a method for disabling Play Protect beyond these two scripts? I have tried both on an AEDO TC52 and neither seem to disable Play Protect. I am running Agent version 13.7.0 Build 1031. writesecuresetting -glo package_verifier_user_consent -1writeprivateprofstring DeviceFeature DisableVerifyApps 1apply featurecontrol
Hi! I have a case with a custumer that is running Honeywell CT50 (android 6) enrolled as AEDO on MC14.3. they would like to use a PIN kode to unlock the screen witch we have enabled with "resetpassword 12345" as a script we send to the device. That is working fine, the downside and my isse is that this also enables the secure start-up and the user have to enter the PIN/pw to boot the device, witch prevents us from rebboting the device remotly as it wont boot up until the user unlocks it. if you set the password manually on the device you get a question if you want to enable this feature or not, when you set it with script it enables it by default anyone with a suggestion on have we can solve this? the customer have around 200 sites with different PINkodes on each sites so i use a macro from the custum attribute to set the PIN on each site using the same package/script.
I have enrolled an Zebra MC33 Oreo (with latest Lifeguard Update) device with Android Enterprise Device Owner. The Hawkeye Plugin available from Soti Webpage was installed via MobiControl and shows up as "installed". The problem is that there is only "remote view" available, remote control does not work. Does anybody have an idea what the problem could be? MC-Version: 14.3.0.3144 Agent-Version: 13.6.0.1662
Hi all, there seems to be a problem with RC (plugin downloaded from soti.net) and TC20 latest AE agent (13.6.0.1662). When AE agent is updated to the latest version, then a reboot of device the remote control stop working, in details: RC stay in "waiting screen". It does not matter the version of Android (Nougat or Oreo), the problem it's with the AE agent. In a Zebra TC51, same plugin, same agent version, same enrolment type works fine. Has anyone had the same problem? Thank you, Filippo
I have an enterprise B2B application that I distribute to devices via SOTI Package in a Profile. SOTI is properly installing the APK and is also now automatically granting the required permission (just storage) which is a nice feature recently introduced in this agent version. The issue that I'm now facing is that the app itself will no longer launch and I get a permissions related toast message error as soon as I try to launch it. The same version of the application works under the following circumstances: AEDO Managed Zebra MC33 running Android O (8.1.0) with LifeGuard 12 on SOTI server 14.1.3.1587 and the 13.6.0.1567 Android Enterprise Agent.- App runs correctly AEDO managed Zebra VC80x running Android O (8.1.0) with LifeGuard 12 on SOTI server 14.2.2.1170 and the 13.6.0.1622 Android Enterprise Agent - App crashes on launch with permissions error. I'm trying to isolate my variables as much as possible to identify the root cause of this problem but I'm starting to think that it has to do with the automatic permission granting of the new agent version. Is there any way to disable this feature so that I can manually enable the app permissions? The forced upgrade to a newer agent version seems like a pretty frustrating side effect of leveraging Android Enterprise with a Play Store distributed agent. Is there any way to lock in a specific agent version for AEDO enrollment if it does end up being the Agent causing the problem?
I'm fairly certain I already know the answer (no) but is there any way to bind a Managed Enterprise and utilize AEDO management in an On Premise SOTI instance if the SOTI server has no external network access?
Top-tier experts who are delivering outstanding content. Should have more than 7000 points.
Experts who are consistent with great content. Should have more than 1000 points
Highly experienced members with valuable inputs. Should have more than 700 points
Beginners taking the initiative. Should have more than 500 points
