Thursday, February 26, 2015

Interesting migration issue with Office 365

We’re currently running a migration to Office 365 from an internal Exchange environment.  Rather than use directory synchronisation or go to a Single Sign On environment (SSO), this is a 1 time migration to the new O365 world.
The idea was that instead of “polluting” the new world with rubbish legacy information/setup created over probably 15 years operation since Exchange 2000 days (through 2003, 2007 and 2010); as well as have an impact on the internal setup/migrating by configuring a hybrid setup we would go for a  new setup that we knew would be fresh.

Fortunately (or possibly not, depending on your point of view!) we had an email domain fully registered and configured, but not used in real life (it was just to protect against misuse by someone else). We decided to add that to the O365 world and get a fully working setup, and then we could just add the other "real-life" domains to it to complete the migration.

To set up the O365 trial we did a number of things:
  • Removed the SMTP domain from within Exchange setup (and from the message hygiene service we used)
  • Added it to the O365 trial account
  • Created our mailboxes in O365 and had everything working OK.
  • By now we had removed the aliases in place on the internal exchange system user mailboxes (note: user mailboxes!) for the new domain.  Everything was going swimmingly.
It was at this point 3 further things needed to be tested on O365 before “signing off” that all was good for the 1-time transfer over and migration of data.
  • Mail Enabled Public Folders for List Server subscriptions
  • Use of O365 for automatically mailing of messages from devices and services
  • Use of O365 Shared Mailboxes for accounts such as Admin, Webmaster, Postmaster and so on to cover off public required (or sensible) aliases without using an O365 licence.

The first two were sorted quite quickly using publicly available information (although watch out for mail enabled Public Folders needing anonymous “Create” rights to enable mail to be delivered).

But the last was proving a right PITA.  I had created a Shared Mailbox for the webmaster and whenever I added it to my O365 mailbox my outlook account would constantly prompt for my password to connect.

Eventually (after deleting and recreating profiles, deleting the contents of the Outlook folder (OST and so on) in my home directory, and deleted windows credentials through the control panel); I put in a support call.

Before getting the call and whilst away at a Microsoft IT Camp, I recreated the shared mailbox and found that on my Surface the profile worked fine.  So it was machine specific…

Raj called and we tried a number of things (no caching, new profile, delete the profile from the registry) and so on.  Then we spotted something.  In the depths of the profile registry entries I spotted a reference not (as in the image below) to the ExchangeLabs O365 folders, but to my internal exchange server

Raj agreed this was something to work on, and he came up very quickly with a fix.  The creation of a registry key in AutoDiscover to prevent SCP lookup on the network.  This would prevent the outlook client from searching through our network for a resolution of the webmaster shared mailbox identity and location.

We deleted and recreated the profile, logged in and it all worked.  Hurrah.

As a final test I sent an email from my phone (connected over 3G, not the internal network) and found that my email did not hit the shared mailbox, but when Raj sent a test email, it worked.  Hmm....  This was a further clue as to why SCP lookup was causing the problem.

A quick look at the Exchange Console (I say quick, but given I had Microsoft support on the line it took a bloody age to load!); and I discovered that the webmaster@ alias was still registered on the administrator mailbox.  So, what had been happening is that the SCP lookup in the profile creation when I started outlook was finding the alias in my network, and thereby causing a conflict with the O365 provisioned shared mailbox with the same email alias.

Remediation was then straightforward:
  • delete the now unused smtp alias (and a few others I found) for the domain now on O365 from recipients on the internal network (there were a few admin like accounts that still had them)
  • regenerate the Offline Address Book
  • allow the OAB to distribute
  • remove the ExcludeSCPLookup key from AutoDiscover
  • test again
And all was well.

  1. Don’t assume a completely standalone move, even with unused domains, to O365 will go smoothly :-) - just because it’s completely separate
  2. If you have unused domain names on your exchange infrastructure then do check carefully whether aliases have been created for them
  3. If you have (for legitimate reasons like us, or not) disabled automatic address generation on mailboxes, then you really need to take some care over legacy SMTP aliases on mailboxes  (the PowerShell code listing later on will help you find them - run on an exchange server and look at the output file - the location of which is coded at the end of the PowerShell)
  4. Microsoft O365 tech support are good.  It was nice to prove that before we committed over to the service.

Get-Mailbox -ResultSize Unlimited |Select-Object DisplayName,ServerName,PrimarySmtpAddress, @{Name=“EmailAddresses”;Expression={$_.EmailAddresses |Where-Object {$_.PrefixString -ceq “smtp”} | ForEach-Object {$_.SmtpAddress}}} | Export-CSV c:\smtp.csv -NoTypeInformation

Wednesday, January 28, 2015

update on the #Lumia #Denim failure - it now works :-)

In lumia denim upgrade failure I reported a significant problem with the upgrade in that the handset no longer reported back correctly it was honouring the Exchange ActiveSync policy of handset encryption.

Happy to report that having working with Lumia support staff and even had them connecting their handsets to my infrastructure the problem is fixed.  It turns out there was a corrupt "something" that was cleared by doing what is called a soft reset (but in reality is more of a "clear cache" operation on the handset.  This is done by pressing the power and volume down buttons simultaneously for about 10 seconds until the handset restarts.

Afterwards, the date/time might need to be sorted, but the ActiveSync connection now worked, and the handset remained encrypted.


Thursday, January 22, 2015

Bye Bye #Humax

A long long time ago we moved from tape to disk for Video Recording and (almost randomly) settled on a Humax box after some difficulties with Sony.

Just over 2 years we belatedly made the move to HD TV (the old CRT TV was perfectly OK until then) and, entirely satisfied with our Humax experience moved onto a FOX-T2 unit.

Regrettably, it was clear that Humax had downgraded the software.  Missing was the feature to start watching a program so many minutes into the broadcast.  When you move between devices in different rooms (be it 2 PVR's or iPlayer etc) it can be a damn nuisance to have to fast forward to the point where you want to catch up.

Then just under a couple of years into that unit's life the hard disk failed.  Humax replaced under warranty, and that's when we found out that the the HD recordings we'd faithfully backed up and copied onto the new box would not play.  This was determined to be a hardware fault* on the new box, but there were no replacements available.  At which the ever reliable John Lewis support kicked in.

We got the replacement the 2000T and then found some more calamitous problems: the tuners are of a lower quality and HD broadcasts broke up. A replacement had the same problem.

However, there are other issues with the latest Humax range.
* no front panel for data feedback (not a great loss, but...)
* No slow motion play back - really annoying when trying to see if that try was scored!
* an *incredibly* slow USB port, backing up/restoring takes days, not hours
* a cheaper, tackier feel to the product.

John Lewis played ball, and now we have a shiny new Panasonic unit...

That has it's own issues: only 32 recording slots, it does not permit watching a third channel whilst recording 2  (albeit only on the same transponder as one of the two), a weaker clash of recordings resolution, no folder structure for storing recordings.  But at least we can record and watch HD TV again.
A couple of benefits though - we can watch programs at 125% normal speed and still hear the soundtrack (great for those documentaries that squeeze 10 minute of information into a whole hour), more channels on screen at the same time in the program guide.  And slow mo is back

Muscle memory from many years of Humax is hard to lose, but the products reached the point of being unfit for purpose, and it seemed to me Humax no longer care about quality, performance and user experience.

*actually, it's not - it is by design.  However, if we'd have known that we would have used Foxy to decrypt then when backing up and then been able to watch them on the new one.  But tech support didn't know that... so we took their word it was busted.

#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 -
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.