Thursday, January 22, 2015

#Lumia #Denim upgrade failure.


I tweeted last night about a Lumia 620 that seemed bricked by the Denim upgrade.  The jury is now in!
The handset is an unlocked “any network” device; it has taken all the upgrades to date and been used by Mrs B for about 2 years without any issues.  It’s entirely a business device – email, internet, phone and text – no games and only about 4gb in use of the 7.2gb free space.
Yesterday the phone presented a critical upgrade, (the language used did not describe it as either Windows 8.1 update 1 or denim, just critical).  So the upgrade was performed.  All went smoothly (no error messages, the standard reboot) and all seemed well.
However after a few hours, it was clear email was not coming down to the phone and when a sync was forced, an error was presented.  At this point the device became my problem (correctly so, I’m the local IT admin!).
Quick investigation demonstrated that the phone was no longer able to comply with security policies of the exchange server to which it was attached (albeit an Exchange 2010 box, not 2013); but, to be fair, MDM in 2013 and 2010 isn’t much different and the options there are the same. 
A quick trip to the exchange server EAS policies (Exchange Console, Organisation, Client Access) and I inspected the policy, a perfectly normal policy here:
So, some investigation – I found a few references to 86000C2A error code I was getting and discovered this post from a couple of years ago - http://blogs.technet.com/b/kristinw/archive/2013/03/15/windows-8-devices-fail-to-sync-with-microsoft-exchange-with-86000c2a-error-or-similar.aspx
It was good advice, and on checking I found that -WSSAccessEnabled  -UNCAccessEnabled were indeed $true instead of $false.  So, correcting that with a quick bit of PowerShell (as guided in that article) I was a tad surprised to find that the policy still failed.
Rather than muck around any further with a policy managing a number of devices  I created a new policy (through the EMC) to mirror the policy in use and more by instinct than anything else set the require encryption on device option to disabled.  Email started to flow.  Whether those two AccessEnabled polices were set to true or false; hmmm.
However, this was not the end of the problems.  The handset was largely unresponsive and spontaneously rebooted a couple of times.
Looking around there was plenty of free space, but a couple of issues:
  1. when I investigate the maps on the phone it reported that the UK maps (which were previously on it) required 1% more to complete downloading at about 340MB. I resumed the download, and it was very slow.
  2. Whenever I tried to use the internet, IE, Search tool, Microsoft Store - the phone would not connect (either on Wi-Fi or 3G data).
I noticed that when using search/IE a “checking location” message appeared at the top of the screen, disappeared and then nothing would happen.  The phone has location settings off for privacy reasons.
So, without any solid reason I deleted the maps (this took several attempts, included a deletion of the HERE Maps app) and although I eventually got them fully off the device, the problem remained.  Nor was I able to get to the store to reinstall the HERE Maps app.  But, via System, Applications, Maps I was able to get the UK maps downloading in full – but (interestingly, and perhaps critically) the download was about 540MB, not the 340MB it was previously reporting.
Upon completion of the download and a reboot, the phone’s IE, Search and Store functions all fired up again and things were back to normal.
I don’t pretend to understand what was going on, but I notice that even now search/ie check for location very briefly during their start up.  However I do wonder if somehow with the corruption in the mapping part of the system the location checks were somehow failing and the system was refusing to play ball with internet connections because it no longer was certain where it was.  I really doubt it’s that, or as simple as that, but…
Oh, for the record, I also connected the phone to an Office 365 Enterprise email account and tried the same policy issues there – and got the same result.

1 comment:

P Bryant said...

as you can now see in http://corylus.blogspot.co.uk/2015/01/update-on-lumia-denim-failure-it-now.html it's now fixed!