Deployments of XenMobile 10.x may encounter an issue where Enterprise enrolled devices are not correctly associated with the appropriate MAM ID for the device. This results in issues where devices end up in a state of ‘MDM no MAM’ or ‘Cannot install applications, despite seeing them listed in XenMobile Store’ or get a ‘Cannot Access XenMobile Store’ message soon after enrollment, and any applications download subsequently do not launch.
As mentioned, the issues above are due to the MAM ID for the device being ‘null’ or ‘incorrect’ in one or more tables within the XenMobile database. If the MAM ID is incorrect rather than null, then it is likely that it is the MAM ID normally associated with another device. During enrollment of an ‘affected’ device, you can sometimes see the ‘other’ device listed in the console, when searching for the username of the device being enrolled. This search generally stops showing the ‘other’ device soon after the enrollment completes.
Once a device is affected, re-enrollments (with or without firstly deleting the device in the console) do not help. This is due to the device still being matched to references in other ‘tables’ that are not deleted when the device is deleted from the console.
As indicated simply deleting just the affected device and re-enrolling it doesn’t help. Our investigation noted that the device remains intrinsically linked to other devices. If the ‘linked device’ was also deleted then we discovered that a re-enrollment of the original device would then be successful. However the ‘linked device’ would likely still have an issue. In fact we noted that the linked device, might have been working fine, but upon successful re-enrollment of the problematic device, the linked device then stopped working. As such it is therefore likely that ‘all’ devices in a chain need to be deleted at once before allowing re-enrollment.
We developed a set of SQL queries that would allow us to trace the links between devices, effectively following the MAM IDs associated with the one device, that were actually linked to another user. However it was difficult to identify the ‘start’ of a chain, and there were numerous devices where the MAM ID was invalid because it was ‘null’ and this meant following the chain became virtually impossible.
Instead we subsequently identified the following query which lists all the devices that have an invalid MAM-ID in the [device] table when compared to what should be used within the [devices2users] table.
SELECT * FROM device D where CONCAT(D.LAST_USER_ID,':', D.MAM_DEVICE_ID ) not in (select CONCAT(D2U.device_user_id,':',D2U.device_id) from devices2users D2U)
Additionally we’ve recently discovered that there can also be an additional list of devices with an invalid MAM ID, this time due to inconsistencies between the [device] and [devices] table. These devices can be identified with the following query:
select d1.* from device d1 join devices as d2 on d1.MAM_DEVICE_ID=d2.device_id where (d1.DEVICE_TOKEN != d2.device_token) or (d1.DEVICE_TOKEN is null and d1.MAM_DEVICE_ID is not null)
At the time of writing it is not known if the devices identified in the 2nd query are as badly affected as those from the first query. It could be that the devices identified in the 2nd query will self-correct when re-enrolling without the need to delete the devices first.
In addition as we knew we would have at least some devices with a duplicate MAM ID (due to re-enrollment of problem devices post XMS 10.3.6, we also ran the following query to list those devices with duplicate MAM IDs
SELECT * from DEVICE WHERE MAM_DEVICE_ID in (SELECT MAM_DEVICE_ID FROM DEVICE GROUP BY MAM_DEVICE_ID HAVING ( COUNT(MAM_DEVICE_ID) > 1 ))
insert into devices (device_id, device_token, table_id) values('3L/+Wc4ZktlTeqljBJhY8syN3M8CAJeL7VCqHteEmCY=', 'test_token', 99999)
XenMobile 10.3.6 environments must be patched at a minimum with Rolling Patch 1; latest Rolling patch for XMS 10.3.6 is RP3, the patch can be available at:
https://support.citrix.com/article/CTX218255