You can see if the problem goes away if you send the script command   

     foregroundmode  enable

1.  If your device is powered-on and a new test profile is manually assigned to or revoked from such device from the web-console , what is the time delay before the test profile get successfully installed or removed?

2. What are the connection mode settings in the "Advanced Settings" of the problematic devices/device-groups?

3. What are  the update schedule  in the "Advanced Settings" of the problematic devices/device-groups?

4. Are your devices connected to a closed-Corporate network, or to the open public network with internet access?

Hi Raymond,

I have tried foregroundmode enable and it had no effect other than to bring a notification 'Mobicontrol is running'.

1. Do I need to test this with a device that's agent is connected or disconnected? As I cannot interact with a disconnected device, I      have tried a device that's agent is currently connected, a new profile seems to take minutes to install. 

2. All Connection Settings are: Persistent, Retry Interval 30 seconds.

3. Devices are set to Update Schedule every 2 hours.

4. Devices are on the open public network with internet access

Many thanks,

Seb

Your device agent should show the green "connected" status when you do you test for (1). 

What are the brand(s)/model(s) of your devices?

What are the Android versions of their firmware? 

What about your MobiControl server version/build numbers?

Have you tried turning all power-saving modes off from your devices'  "Settings"?   Let's assume you turn off the screensaver timeout and lockscreen.  If you have the test device with you and the device is on-line and the connection status is "connected", will the connection status change to "disconnected" while the device agent is the active foreground app on the device?

We run a mixture of:

Samsung XCover 3

Samsung XCover 4

Acti Tab & Acti Tab 2

As such we currently have a variety of different versions of android - however, no single version seems any more or less affected than any of the others.

We have more XCover 3's than any other device (approx 300) and all of these running 6.0.1

We are currently running Mobicontrol version 14.1.7.1101

I have tested disabling all power saving modes in settings, and yes I get a maintained connection when the device is with me. However, when I hand the devices back out, they eventually start to disconnect. These test devices are all charged, on Wi-Fi and located in the same office as myself. I am unsure what exactly causes them to disconnect, and why they won't natively reconnect.

There is no visible pattern that I can see for devices not connecting, the only consistency I can see is the amount of connected devices?

Many thanks for your help Raymond!

Hi Raymond,

I tried issuing a test profile to get devices online last week. However, it's been three days and it's Pending Install on 56.3% (304 devices)

Do you know why this would be happening?

Best regards,

Seb

Hi- did you ever get a resolution for this? I've got 900 phones and the same 40/60 split of online/offline.

Hi - no, unfortunately, I never did get any further on this one. We even recently reduced our devices by about 100 - and surprisingly the split remains almost a perfect 60/40. 

I tested everything advised here, by our supplier, and SOTI support.

To me, it seems like a server resourcing limit, but I have been ensured that isn't the case.

Out of curiosity, are you also running Samsung devices?

Yep, Samsung, various models. Android+.

As mentioned in Raymonds answer above, it may be worth checking the power/sleep settings. There was an update that killed inactive apps that could be responsible and is worth double checking.

Unfortunately not the case with our deployment, but hoping you might have more luck?

Cheers,

Seb

Hi Seb,

I haven't heard anything similar reported from any of my governmental or corporate customers in Hong Kong.   There shouldn't be any magic number limiting percentage of devices that can get connected to the MobiControl server.  It just doesn't make any sense.

As you mentioned that you could get a maintained connection when the device was with you but the device  started to get disconnected when the devices were handed back out,  I have reasons to suspect if the problem is related to your Wifi infrastructure within your company.   E.g.

- Have you checked if the devices from your MobiControl server are actually online and other apps can access the internet without any problem? 

- Are there any traffic quota set in the Wifi Access Point, firewall, or any network equipment along the path to your MobiConrol server?

- Do your Wifi access points in your office limit the number of devices that can get connected in particular confined area in your office?

-  If you found a disconnected device in some part of your office, have you tried doing on-the-spot (i.e. WITHOUT taking the device back to your own cubicle/room, in which there might be a different Wifi Access Point which has better connection with your MobiControl server) tests to see if the device has any valid IP address assigned from the Wifi Access Point and if the MobiControl device agent has been killed or kept inactive by low-power modes

Also, did you check the cpu, memory and network loading using Microsoft resource monitor on your MS Server hosting MobiControl?

Thanks Raymond,

- Have you checked if the devices from your MobiControl server are actually online and other apps can access the internet without any problem? 

Yes, I have checked this with lots of them (110+), and I am able to initiate a successful remote session with them. Across different days/times.

- Are there any traffic quota set in the Wifi Access Point, firewall, or any network equipment along the path to your MobiConrol server?

Nothing on our end, our MobiControl server is a cloud server hosted by SOTI and I do not have any control over this at present.

- Do your Wifi access points in your office limit the number of devices that can get connected in particular confined area in your office?

No, no settings currently limiting this

-  If you found a disconnected device in some part of your office, have you tried doing on-the-spot (i.e. WITHOUT taking the device back to your own cubicle/room, in which there might be a different Wifi Access Point which has a better connection with your MobiControl server) tests to see if the device has any valid IP address assigned from the Wifi Access Point and if the MobiControl device agent has been killed or kept inactive by low-power modes

I will test this, but we operate nationwide across multiple different regions and offices, and this is an issue affecting our entire stock.

Also, did you check the CPU, memory and network loading using Microsoft resource monitor on your MS Server hosting MobiControl?

SOTI support checked our cloud instance and confirmed that it was handling the current load sufficiently 

As always, thanks very much for your help!

As it is cloud instance hosted in Amazon,  I believe some of the tests I suggested will be difficult to be done with full control to confirm the validity of the test conditions and results.

Please note that many Wifi Access Point hardware have relatively low number of devices that can be connected.  If your devices do not have cellular connection and only rely on Wifi connection in your company premises,  the above limit may be a problem if you have too many devices that can't be served simultaneously by the same Wifi access point.

If you really suspect there is something wrong with the MobiControl server, you can request Soti support team to upgrade your cloud instance to latest v14.2.2.1170 to see if there is any improvement.

Hi everyone,

Not sure if everyone here still got notification from this thread, but i recently face this issue too.

Even more, in my case, device (Samsung A01) user keep the cellular data all day, but when IT admin want to Remote the device, it appear offline in SOTI. Device user sometimes turn off then turn ON again the cellular data.

In my case, is it because Doze Mode that i allowed?

Thanks & regards,

Randy Saputra