Cochlear Aqua+ Review

Having a blog and being active on Twitter does occasionally pay off, as I had shown interest in Cochlear’s previous waterproofing solution (do not call it a bag) they contacted me asking if we would like to trial their new Aqua+ accessory for the N5 and N6 range of processors.
We jumped at the chance and after supplying details (coil magnet strength and coil cable length) a massive package turned up:
 


On opening it we got a surprise that there were two kits enclosed (makes sense I suppose as Josef is bilaterally implanted but I thought we would have only got one as a test):
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
It turns out that the reason it is so large is that you get everything you need for a few weeks:

You can see pictured, the guide (multiple languages, only the first 17 pages in English so not as daunting as it first looks!), The Aqua+ (part number Z463273), Nice carry case, Nucleus Aqua+ Coil (part numbers Z463263 – 6 cm length & Z463270 – 8 cm length), Nucleus Safety Line (part number Z467062), Mic Lock-Stirrup (part number Z368868) and a CP900 series magnet (too many part numbers to list!).
 
As a side note: this appears to show that the coil cable and coil are compatible between the N5 and N6 processors.
 
My initial comments on opening the kit are positive:
  • Very nicely packaged (positive impression),
  • In a single kit you get 2x of the Aqua+ sleeve’s and 4x of the Mic Lock- Stirrup’s (extras), 
  • The carry case is very useful for putting all the bits in that you need when going swimming
In the accompanying documentation it says that the sleeve is usable for around 50 sessions so each pack of 2 could do you for up to 100 swims. As a pack of sleeves retails at around £34 (direct from Cochlear) I think this works out very economically. But a note here about the original Aqua Accessory
 

The single use version launched in 2013 and picture above has now been withdrawn from sale and replaced with the new reusable Aqua Accessory; Connevans these new ones on sale at C£39 at the moment for a box of five, each of which can be used up to 20 times.
 
This brings me to the first difference between the Aqua+ and the Aqua Accessory. With the previous version (non-reusable) we had no issues other than the air in the bag would cause the bag to float away if Josef tried to put his head underwater. As the bag was also bulkier and made the processor less movable around the cable it was harder for Josef to put back on himself so what would usually happen was after he had dived under water a few times the “ears” would be off, passed to us parents and he would happily play without sound.
 
With the Aqua+ we have the opposite problem. Josef jumps underwater and or moves quickly with his head under the water and the force of the water against the processor causes it to detach from his head, it then sinks (no air in the sleeve). The first time this happened Josef was a bit worried (he was used to looking for the floating ear, the second time it turned into a game, let the ear sink to the bottom and then try to swim down to it!
 
Thankfully Cochlear have supplied two bits of kit in the pack that can help with this. The first being the Mic Lock-Stirrup:
 
 
This helps to keep the processor attached to the ear – as yet we have not had chance to use it with Josef as he complains that it squashes his ear, it’s very difficult to disagree as that is what its intended to do! I think with an older child you should be able to reason with them to say this will help to keep it on your head but not yet for Josef!
 
The second part included by Cochlear is the Safety Line – this is for making sure that when the processor does come off that it stays attached to clothing. For that reason you need to be wearing something on the top half of your body to attach the line too. Females will be fine with swimming costumes/bikinis tops to clip to in a swimming pool but males will struggle to find somewhere near the neck line to clip it onto - maybe a fashion necklace?
 
I can see that the main reason for the safety line is for when using the Aqua+ in the sea or open water when you would probably be wearing a wetsuit/top of some kind and in that scenario it will certainly save you expensive processor from sinking from sight! My only complaint is that the line is probably 2cm too short for an adult and wearing it and turning your head may pull the processor off unintentionally.
 
There is one bit of preparation that you will need to do prior to using the Aqua+ for the first time and that is to make sure you have some spare earhooks to take with you. This is because you need to remove the earhook from the processor to insert it into the sleeve. In my experience the ear hooks get brittle over time so ensure that you take some spares with you in case removing them causes them to break. The manual again shows you what to do here:
 
 
(Another note on the earhooks – if you have the small tamper resistant ones make sure you take the tool to remove them!)
 
Now a couple of photos of Josef in the swimming pool actually using the Aqua+ (note, this is right at the beginning of the swimming session and he has not put his head under that water at this point. I’m taking photos at the side and getting nagged by both boys to get in and play, hopefully next time I’ll be able to get some better photos of them in-use!) 
 
 
Finally – is it worth it?
 
I would say whole heartedly: Yes. The sleeves are very thin and do not make the processor look any bulkier on the ear. It actually works and pricing is, IMHO, fair: Cochlear sell you the initial pack for either £160+VAT (mono) or £289+VAT (bilateral). This gets you the two sets as shown above. I do think that Cochlear could make a better bilateral kit which only has one of the carry cases and instruction manuals and maybe drop the bilateral price by £20 but understand carrying more product lines increases their costs. That being said each set is made up from the component parts (as you pick the magnet and coil cable length) so this would be an easy change to make.
 

If you would like to find out more please visit the Cochlear website or call (0800 035 6317) or email them.

I'm happy to take questions in the comments or via Twitter.

Thanks to Cochlear for allowing us to trial their new kit.


Exchange 2013 – The things they don’t tell you

(This post is a work in progress, at the moment I’m still migrating things so I have the joy of moving to the new public folder architecture in a few weeks, I’m sure this post will grow after that!!)

So the migration is all but done:
One final server to remove (once we track down all the services using it for SMTP relay) but that has been a mostly painless experience. 

  • Your Content Index will fail and you’ll fix every-so-often by deleting the index and restarting the search services, but there is a proper fix:
  • Don't remove the Self Signed Certificate, it's used by the Back End services. After I had everything running I was getting a bit annoyed that I still had the Self Signed cert sitting there, it is still bound to IIS and SMTP. After a lot of reading I found the following KB article which basically says "leave it alone":
    http://support.microsoft.com/kb/2779694
  • Make sure you receive connectors are scoped so voicemail does not start failing with "Event ID 1446, MSExchange Unified Messaging,
    The Microsoft Exchange Unified Messaging service on the Mailbox server failed to process the message with header file "FILENAME" within "11" minutes. The server will continue to process and deliver the message, but the "MSExchangeUMAvailability: % of Messages Successfully Processed Over the Last Hour" performance counter will be decreased.  http://exchangepro.dk/2014/05/06/voicemail-not-delivered-to-mailbox/
  • Play on phone from the full fat Outlook 2010 client was failing for users still homed on the Exchange 2010 servers but working fine for users homed on Exchange 2013. Play on phone comes up with the following error:



    Strangely playing the same voicemail via OWA works fine
    I've done no further trouble shooting as the users will all be moved to 2010 within the week and we have the above work around in place. If anyone wants to jump in with a suggestion in the next few days I'll be glad to hear it.
  • Running the Public Folder upgrade script (Export-MailPublicFoldersForMigration.ps1) gives warnings about Property errors:

    "WARNING: The object Domain.local/Microsoft Exchange System Objects/Meeting Room 5 (10) has been corrupted, and it's in an inconsistent state. The following validation errors happened:
    WARNING: Property expression "Board Room" isn't valid. Valid values are: Strings formed with characters from A to Z (uppercase or lowercase), digits from 0 to 9, !, #, $, %, &, ', *, +, -, /, =, ?, ^, _, `, {, |, } or ~. One or more periods may be embedded in an alias, but each period should be preceded and followed by at least one of the other characters. Unicode characters from U+00A1 to U+00FF are also valid in an alias, but they will be mapped to a best-fitUS-ASCII string in the e-mail address, which is generated from such an alias."


    For me this was some of the Public Folders not having valid alias entries. It didn't cause a problem (as far as I can see) in all the time we have been running Exchange 2010 but needed to be fixed while moving to 2013 and its new PF architecture.

    I had an additional problem that I couldn't get into the item to edit it in the Public Folder Management Console without applying the following fix (the error was about "no existing publicfolderproxyinformation" sorry, didn't screenprint before fixing!): https://workinghardinit.wordpress.com/2010/11/04/exchange-2010-public-folder-worries-at-customer-no-existing-publicfolderproxyinformation-matches-the-following-identity/ which turns out to be a problem with the homeMDB property of the Microsoft System Attendant!

    Then editing the item to remove the space fixed the issue:

  • While migrating the Public Folders we got to one of the final stages and the process appeared to hang.
    Running Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics gave the response "StalledDueToMailboxLock" and :
    Informational: The request has been temporarily postponed because the mailbox is locked. The Microsoft Exchange Mailbox Replication service will attempt to continue processing the request after 26/01/2015 17:21:07.

    The solution was to restart the Information Store Service on the Legacy Mailbox server and wait 10 minutes for the process to continue.



And as a bonus feature - TLDR: Exchange Unified Messaging Certificates need simply be the server Fully Qualified Domain Name with no additional SAN names.

For my pain simply read on...

I have three new Exchange 2013 servers:
  • FCH-XS13-01.fch.local
  • FCH-XS13-02.fch.local
  • FCH-XS13-03.fch.local
 
(and before someone complains that I’ve given away the names of the Exchange server in my organisation I counter with – “you’d get that simply by receiving an email from anyone in the organisation and looking at the headers” <sigh>)
 
When I created the certificates I used the brilliant Digicert Tool and bashed the FQDN in:
 
fch-xs13-01.fch.local
 
threw in the NetBIOS name for kicks
 
fch-xs13-01
 
sent the response off to my local CA, downloaded the response. Imported it and applied in the ECP (I know, no PowerShell, naughty me).
 

After restarting the two UM services:
 
 
 
No Voicemail – calls just hung up. And not simply for my test mailbox on the Exchange 2013 environment – this was effecting everyone as the Exchange 2013 servers proxy the 2010 traffic
 
Looking in the event log we see Event ID 36884:
 
The certificate received from the remote server does not contain the expected name. It is therefore not possible to determine whether we are connecting to the correct server. The server name we were expecting is fch-xs13-03.fch.local. The SSL connection request has failed. The attached data contains the server certificate.
 
 
Event ID 1649:
 
The Microsoft Exchange Unified Messaging Call Router service failed to exchange the required certificates with an IP gateway to enable Transport Layer Security (TLS). Please check that the gateway is configured to operate in the correct security mode. If the gateway is required to operate in TLS mode, check that the certificates being used are correct. More information: "A TLS failure occurred because the remote server disconnected while TLS negotiation was in progress. The error code = 0x80131500 and the message = Unknown error (0x80131500).". Remote certificate:  (). Remote end point: [::1]:11346. Local end point: [::1]:5061.
 
 
Event ID 1113:
 
The Client Access server failed to exchange the required certificates with an IP gateway to enable Transport Layer Security (TLS). Please check that the gateway is configured to operate in the correct security mode. If the gateway is required to operate in TLS mode, check that the certificates being used are correct. More information: "A TLS failure occurred because the remote server disconnected while TLS negotiation was in progress. The error code = 0x80131500 and the message = Unknown error (0x80131500).". Remote certificate:  (). Remote end point: [::1]:11169. Local end point: [::1]:5063.
 
 
 
On the Lync 2010 servers we see the following:
 
Event ID 14366
 
Multiple invalid incoming certificates. In the past 1 minutes the server received 1 invalid incoming certificates. The last one was from host 172.28.1.63.Cause: This can happen if a remote server presents an invalid certificate due to an incorrect configuration or an attacker.Resolution:No action needed unless the number of failures is large. Contact the administrator of the host sending the invalid certificate and resolve this problem.
 
So, I’m off on a hunt. And it take me hours. Finally after comparing everything I can think of I decide to recreate the certificates (for what feels like the 1 zillionth time) and while I’m doing so this comes to me:
 
The server name we were expecting is fch-xs13-03.fch.local
 
And the certificate I was giving out had two names, the Common Name and the Subject Alternative Name….. so sometimes the service was seeing the NetBIOS SAN name - BINGO. I guess I’ve been spoiled by SAN names on Lync and Exchange so just through “throw it in, what's the worse that’ll happen" - It turns out, a lot!