MatthewSwenson
Hot Shot
Hot Shot

Deleted devices re-adding themselves to the console

Jump to solution

Just letting folks know that we've observed an issue with deleted devices re-adding themselves silently to the console after being deleted. I have navigated this several times with support and haven't really gotten anywhere useful.


Here's what's happening:


We get devices in and process them for application data. During the process, we delete the devices from the console. The device may be on or off during the deletion. Sometimes, the device immediately gets the message to wipe after it is deleted from the console. Other times, it can take several minutes or hours.


If, for whatever reason, you sync the device to the console BEFORE it gets the wipe command, the device gets added back into the console AS A NEW DEVICE. However, this new device, which in my mind seems like a new enrollment, stays enrolled to the same user, and eventually gets applied the same profiles (but seemingly only because they are already installed on the device). ' Eventually'  is important, because until the device is synced several times, the console isn't fully aware of the device SN or really anything beyond the user name. Most importantly, this causes the wipe command to be lost, because the device gets a NEW DEVICE ID in the console, and previous wipe messages are queued for the old device id. You can see this in the event logs, even after a device has been deleted. One would expect that a device which is assigned a new device ID would trigger a user and admin notice of a new enrollment. However, for whatever reason (TOS already accepted on device?), there is no new enrollment email. So you, as an admin, have no clue that the device is back in your console except by running reports or physically inspecting the device. From a DLP standpoint, this has some concerns. Perhaps you think it is not a good thing to immediately delete devices from the console. It has been suggested that devices be unenrolled and then deleted. However, we are looking to keep our enrolled footprint clean so that our metrics are a little more accurate. I suspect the difference in time between unenrolling and deleting is not going to be significant enough to prevent this if a device is powered on after the deletion. So, once we no longer need a device in MDM, we want them gone. Also, devices have to be deleted before you can re-enroll them to a new user in most cases.


Our devices are all enrolled in AE/A4W Work-Managed mode. We've seen this on both Nexus 7 FHD (2013) tablets and Honeywell CT60 devices.


I guess the whole point of this post is not so much to start controversy, but rather to make sure people are aware of this odd quirk and possibly see if anyone else has seen this issue. (OK, so maybe that could start some controversy, but that's not what I'm shooting for.) The ALL-CAPS in the above are more about the surprisingly unexpected behavior than anything else.

Labels (1)
0 Kudos
1 Solution

Accepted Solutions
MatthewSwenson
Hot Shot
Hot Shot

FYI Support eventually discovered the bug and fixed it in console 20.03

View solution in original post

0 Kudos
7 Replies
abdalab
Enthusiast
Enthusiast
Nice post!
Wonder if we just use the ' Prevent re-enrollment'  feature during the device wipe until and official fix if any.
0 Kudos
zlatanp
Enthusiast
Enthusiast

Apparently this is a known bug with their shared SaaS environment, their internal reference number is AAPP-625 for this issue.
We have devices re-appearing weeks after they are deleted,


0 Kudos
MatthewSwenson
Hot Shot
Hot Shot
Abdala,
Thanks!  I haven't posted in a while.  I suspect that ' Prevent re-enrollment'  would not help in this situation, because even though the console assigns a new ID, it doesn't seem to consider this to be a new enrollment from what I can tell.

Zlatan,
HOW in the world did you manage to get a reference number out of this?  I just kept getting told after weeks that, ' You're doing it wrong.  You should device wipe first.'   Also, the fact that I am using the REST API always trips people up.  The support staff often looks through the API documentation and can't find the correct call (admittedly, the challenges of documenting current and deprecated APIs has made the documentation very difficult to weed through).  I am going to re-open my case and see if I can get my issues validated as AAPP-625...
0 Kudos
MatthewSwenson
Hot Shot
Hot Shot
Zlatan,
Could you please check that reference number again?  I want to make sure I have a valid one.  Support came back with a response for a different reference number, and I'm not sure if it's because he misread my request or if it's because the number you gave me is no longer valid.
0 Kudos
zlatanp
Enthusiast
Enthusiast
Matthew,

Its the correct one, below is some text from the incident. 

'This notification is to confirm I have received this case associated with AAPP-6259. I will provide you with a status update of this item as this information is made available to me from our product team.
If you have any questions in the meantime, please reply to this ticket #1441787.' Not sure if the issue might be where in the world you're located, we're in Australia.

I always follow some of their recommendations and when they don't work, I ask them to escalate the matter which seems to get the correct tractions.
If you're dealing with API calls its a bit harder, always try to replicate the issue within the console and then they will take it further.

Hope that helps.
0 Kudos
MatthewSwenson
Hot Shot
Hot Shot
Zlatan,

Thanks - here is the response I got back from support on that item:

' As I understand, you need information related to the bug AAPP-6259.
The bug is for Apple supervised devices only and not affecting other platforms.'

So, I guess the issue you've identified is OS specific...
0 Kudos
MatthewSwenson
Hot Shot
Hot Shot

FYI Support eventually discovered the bug and fixed it in console 20.03

0 Kudos