Are you referring to the Device name or the device ID?

When using Ethernet, did you manage to get ALL devices SUCCESSFULLY enrolled onto your MobiControl server (i.e. each with a separate device icon on the web console)?  If so, are the device names different for each such enrolled device?

I am referring to the device id.  In my case, multiple devices are attempting to enroll with a device id of 00904c112233.  The device names are different for each device.

Only the first device will successfully enroll.  All subsequent devices show events in the agent event log like:

• Connecting to xxxxxx
• Device connected to server: xxxxxx
• Duplicate Device ID
• Device disconnected.

When I look in the web UI at the first device that enrolled (i.e. the first one with the same DeviceID), I see many "Device already connected" events.  The time and frequency of these events match what I am seeing in the event logs on the device.

In logcat, I can see messages from Soti that look like:

• 05-30 17:41:36.068 I/soti ( 1133): pool-3-thread-1|I|AP|[DefaultHardwareInfo][calculateDeviceId] - wifiMacAddress = 00904c112233|
• 05-30 17:42:31.750 D/soti ( 1133): pool-3-thread-1|D|AP|ID=00904c112233|
• 05-30 17:42:31.754 D/soti ( 1133): pool-3-thread-1|D|AP|WifiMac=00904c112233|

I suspect that the code in DefaultHardwareInfo.calculateDeviceId() is getting the same Wi-Fi MAC address for all of our devices when they are not connected to Wi-Fi.  Perhaps this is some sort of default address that is returned by the Broadcom modules?

What is the version and build number of your MobiControl server?

There are some changes in latest v13.4 MobiiControl server to handle earlier v13.x device re-enrollment issues, and the related changes might have side effects on device-ID used and caused the problem that you encountered.  

I just have a wild guess.  Maybe you can try toggling the "Enable re-enrollment" option in Servers->Enrollment Settings tab and see if you still get the same problem.  Even if this works, in a longer run, I believe you need to open an official support ticket with Soti to get the problem permanently fixed.

We are running 13.4.0.4339 on the server.  The problem occurs with the 13.5.0.1088 agent but not with the 13.0.0.33835 agent.

Thanks for the tip on the re-enrollment option.  I will need to find a convenient time to test this that will not affect our production processes.

Hi Steve, 

As a result of changes made in Android M we have subsequently made an adjustment across the board for calculating DeviceID's in V 13 and above. 

Are you using the MobiControl Stages or NFC bum to enroll the devices by any chance?   

Also are they Zebra devices?

If you are re-enrolling devices, a factory reset  may be needed (not enterprise reset) as Zebra keeps the old agent database in its /enterprise folder.

Alternately, you can delete /enterprise/usr/mobicontrol folder contents using Remote Control before un-enrolling the devices, although it's tricky and not guaranteed to work.

I have spoken to a another customer in the Discussion Forum who was having a similar issue, I had suggested he create a case and I see that it was resolved although I was not able to confirm  how it was resolved.  I have a few other suggestions but let me know if the above scenerio's are applicable and able to resolve your issue. 

I will continue to look into what resolved this for other customers for you in the meantime. 

> Are you using the MobiControl Stages or NFC bum to enroll the devices by any chance?   

We include the MobiControl agent and mcsetup.ini file in our OS image.  When the device is manufactured, the assembler launches the agent and the device registers automatically to our MDM.

> Also are they Zebra devices?

These are custom-built Android devices.  They are running 6.0.1.

> If you are re-enrolling devices, a factory reset  may be needed (not enterprise reset) as Zebra keeps the old agent database in its /enterprise folder.  Alternately, you can delete /enterprise/usr/mobicontrol folder contents using Remote Control before un-enrolling the devices, although it's tricky and not guaranteed to work.

These are brand new devices so there we can be confident that there isn't an old agent database in the image.

I suspect that this version of Android is somehow returning the same Wi-Fi MAC address for all devices that have never connected to Wi-Fi, and that the DefaultHardwareInfo.calculateDeviceId() method in the 13.5 agent is picking up this value.  The algorithm in the 13.0 agent does something different, as it gives us unique device ids with Android 6.0.1.

Steve...

Hi Steve, 

With these being new devices we should be looking at the device logs a little bit more in depth for a root cause of this.  

Although he have a developers ticket with regards to improving the algorithm it seems that your circumstances are different but are creating a similar situation with the same Device ID.   Please open a case with our Technical Support so that we can review this further and add to the developers ticket if necessary.

You can open a case by emailing us at support@soti.net or by selecting the following link.

Regards,

I have opened case C00205650 for this issue.

Steve...

Hi Steve, 

Looks like your in good hands, your Technician has already reached out to the OEM team and is discussing the new agent you were provided. 

Please update the thread once you have your resolution as your case is unique.

Cheers,