Mobile Device Factory Wipe on a single failed password
We have had a situation reported where a device has performed a factory wipe on a single failed password or not at all. This has been reported on two different devices HTC Touch Pro2 and an HTC Diamond 2 running 6.1.4 (latest production release). Normally I would say the user was mistaken however I have just watched exactly the same this happen in front of me on an HTC Mega Mobile 6.5.
The group policy appplied for passwords is Simple Password, 4 characters, 10 attempts prior to wipe, "SCMDM 2007" prompt on attempt 7.
What has just happened is the HTC Mega was on my table and not connecting to the 3G network due to a SIM issue - ie no phone, no wifi, no 3g. The device was attempting to connect regularly then all of the sudden the screen becomes active and the you have one more attempt to logon prior to a wipe appears. To be clear there have been no logon attempts and no failed logons at all since enrollment on this device.
I then entered the password incorrectly and the factory wipe proceeded.
So this thing has wiped on a single incorrect password even though the group policy was for 10 attempts. The word prompt did not occur. The user was simply presented with the 1 logon left message without attempting to logon...
This is a disaster. Has anyone else seen this? I'm going to try and replicate on 6.1 , 6.5 devices but would be interested if anyone has seen this occur.
The only common thing I see at the moment is that the devices may not have had network coverage and be retrying prior to this occuring.
This is a real pain to debug as a factory wipe is performed so any local logs are toast as encryption is on so even cards are unless due to encryption. I'll have to try without encryption on. Any suggestions as to how to debug this one?
Cheers
Matthew
All Replies
- Hi Matthew, Negative I have not seen this occur before..
Sounds like you have this confirmed on at least 3 different devices. What can you tell us on your SCMDM 2008 SP1 environment? Do you have other devices working fine? Are these 3 devices in question with this issue receving other policies or packages? I assume they might have rebooted after receiving other policies while they still were connected?
Just want to make sure the policies are working in general..
|\\arco.. - Gudday Marco,
No one else that I have spoken to has seen this either. Luckily someone else witnessed the fault occur on the Mega otherwise I might just be going mad.
All of the devices that this has occured on have been enrolled and had all policies applied for at least 1 week. We only have about 60 devices at present primarily HTC TYTNII, Touch Pro 2 (Prototypes and Production release), Diamond 2 (Protypes and Production release), and some odd ones out including Sony Xperia, Palm Treo Pro, HTC Mega and an Eten Glofiish M610. The only reason we don't have more is a handset supply issue.
Given the nature of the environment we very rarely push out packages or group policy updates as the device configurations are set in stone and require several litres of blood to change. The policies themselves heavily limit the functionality of the devices. We do not allow OTA enrollment instead we tether to nominated terminals on the internal network to enrol and then as soon as policies are applied after enrollment activesync connectivity is disabled and practically everything is encrypted. Password reset/recovery is not enabled. This configuration has been unchanged for about 6 months.
The faults were originally reported by the CEO (ie. not the most technical of users) and we did some investigation putting it down to entering incorrect passwords however the second time it happened on a different device I became a little concerned. After some questioning it appears that network connectivity was lost in both instances prior to the event occuring - 1 while roaming , 1 local.
Since the last report I have been hammering a Touch Pro 2 confirming all aspects of the group policies and try to fail the password retry mechanism. Dropping out the battery, multiple resets, removing the SIM etc. nothing stopping the password mechanism from working correctly ie on the 7th failed password prompt with a word response "SCMDM 2007" in this case, and then wipe on attempt 10. This could not be faulted and this is where I'm kind of stuck. There are a large number of attempts plus the word entry required prior to a wipe occuring. The policies have been applied to the devices and tested to the point of the word prompt. Then sometime muhc later after much use they fail in a condition where the device wipes without the workd prompt or the expected 10 attempts. Even if the policy was reset or change (it wasn't) then the default condition is still 5 password attempts?
To date only one user has reported the problem - however this is the one user that is most likely to make a mistake entering the PIN and does so regularly. The first fault was reported 6 weeks ago, the second 1 week ago with moderate activesync traffic on the device.
There are three significant differences between the reported problem and what I observed:
1 Different device - HTC Mega ptotype vs production versions of Touch Pro 2 and Diamond 2.
2 OS - Mobile 6.5
3 No Network coverage
I'm setting up a series of tests using multiple handsets and varying SIMs that will generate local, roaming, incorrect apn, and no connectivity to try and recreate what happened.
If you or anyone else has any suggestions for any particular logging that could be useful I would greatly appreciate it.
Cheers
Matthew - Are you running ActiveSync on these devices? And if so - are you syncing to an Exchange 2003 or Exchange 2007 server? I have seen issues with Exchange 2007 SP1 causing some strange things. Not this specific issue, but I've seen devices enforcing encryption even though the policy didn't require this, so maybe there are other possibilities too.
- Yes, ActiveSync to Exchange 2007 SP1....
Hmm... With SP1 you're always pushing down a policy from Exchange regardless of the settings contained in it. So check that you haven't got any conflicting settings in GPO and Exchange.
Have you configured "AllowExternalDeviceManagement"? (http://technet.microsoft.com/en-us/library/dd261868.aspx)- Proposed As Answer byWayne Phillips.MVP, ModeratorSunday, November 01, 2009 10:14 PM
Have you checked the MDM console for that specific device. Does the device show up under "Blocked Devices" or "Recent Wipes" ? If MDM wiped the device, you should see the device under "Recent Wipes". Did the user receive a Device Wipe email ? If the device is not listed under "Recent Wipes", check the Device History (sort by date) for an indication of what policies were applied to the device prior to the hard reset.
If the incorrect password group policy is set to 10 attempts, and the MDM console is not reporting it has been wiped, then I doubt MDM is responsible.
I've had device hard reset for no apparent reason, so this could be a hardware issue.
I'm tending to agree with Andreas, it could be a policy conflict... but ActiveSync and MDM usually play well together. What other third party applications are installed on the device ?
Cheers Wayne
Airloom- Proposed As Answer byWayne Phillips.MVP, ModeratorSunday, November 01, 2009 10:14 PM
- Thanks Wayne,
There is no record of a remote wipe nor are the devices blocked or any record under recent wipes.
There is one piece of 3rd party software related to subject line classification of email on the devices - one I can get the reproduction understood I'll remove it and try again. The devices are basically for corporate e-mail only with a forced VPN and no split tunnelling. Cameras, bluetooth, infrared, desktop connectivity and anything else usefull are all disabled.
I'm trying to prove that it is not related to MDM/ActiveSync conflicts and it hardware specific at the moment...
Cheers
Matthew - Were you able to reproduce the issue ?
Cheers Wayne
Airloom
