Hi ANKMOD

Unfortunately those settings did not work for me either, BUT requesting the device to be deleted by support has now resolved the issue.

Out of interest, the global setting "Permanently delete devices from database when device is deleted from web console" was set to on/active on my instance. Surely the device that SOTISupport just deleted for me, should have already been deleted by this setting ?

Many thanks 

Adam

I don't think there is such a limit. 

If your device firmware, device agent or server has been upgraded since your currently problematic device got successfully enrolled previously, then look carefully into any additions/change(s) in any of the above-mentioned components or server/add-devices-rule option(s) that might hinder your recent re-enrollment attempts.  Also, look in the server or device log for any information about why your re-enrollment attempts fail.

Hi,

I was facing this problem a few weeks ago.

Pretty sure this is not best practice, but in my case I noticed an exception in the DSE logs saying something like "failed to delete device xyz" after trying to enroll this specific device. I stopped all the MC services, searched for the databse entries referring this device and manually deleted all of them.

After restarting the services I was able to enroll the device properly.

Please notice that editing databases manually can get things even more worse. I recommend to create a snapshot before taking these steps!

Hi Both and thank you for the replies.

I now see an exception has been thrown on the DSE, firstly a * Exception: Failed to delete the device 'xxxxxxxxxxxxx'. * No user was found for the given id. and then An unhandled exception on Android RESTful Enrollment.

Unfortunately this is a cloud based MC instance, so from what I have read, I have had to request the device to be deleted by support. Fingers crossed this will resolve this, though no clearer as to what the root cause of this issue is.

Thanks 

Adam

Did you delete the device in mobicontrol console? (look for IMEI or SNR)

If not try this first and tapa on retry then, if yes the only way is then really waiting for support to delete this in the DB first.

Hi Rafael and thanks for the suggestion.

Yes, I also tried to delete the device in Mobicontrol console and retried the enrollment, but it made no difference.

Hello Adam

Greetings for the day!!

Thanks for reqeusting an answer from Soti!!

 Firstly there is no limit for reenrollment and Here is the quick check if you  can do and try to test 

1. You can  check under total logs section  present in global settings to see if the there is checkbox checked in front of permanent delete device once it is deleted from console as shown below.

So if it is checked in , most of the time you willl not face any issue while reenrolling devices.

2. You can also try to test by unchecking strict enrollment present under enrollment settings (in global settings) and see if device enrolls after hard reset( try to make sure  device hardreset from boot)

In last if these things will not work , the best option is to raise a support case(click here ) or call SOTI Support team since It is hosted on cloud as you mentioned to perform deletion from database or check if there are any other issues.

Regards

I just finished a 3 month support case for this same issue. The problem started with version 15.3 and is resolved with version 15.3.3. Finally a different support agent came on my case and said this is a known bug that is fixed in 15.3.3. Despite my previous agent supposedly deleting the device in the DB I still could not enroll, device was not in the console and not in the DB but would still fail enrollment. Specifically, this is in the patch notes listed as:

My best guess is that until the upgrade to 15.3.3 was completed there was still some lag problem in the enrollment process for some devices. This happened to brand new devices to us that had never been set up before.

Hi Robert,

Thanks for the great information, I just looked at our instance and we're still on 15.3.0 but great to know that the bug has been addressed.