Boxer Contacts Sync to Native iOS Contacts App

[antherITguy]

Has anyone had any issues resyncing Boxer contacts to the native iOS contacts app reliably?  We're seeing an issue where if you disable and then re-enable contact syncing from within Boxer [Settings > Export contacts > disable] and then re-enable the option an error is displayed that says ' Warning, Updated Record Does Not Exist' .

Then if I force a resync under Settings > Advanced > Resync Contact Export Data it errors with ' Warning, Updated Record Does Not Exist' , ' Contact Export, Exporting contacts failed to complete' .

[TJMEDLYN]

Just went through this same thing.  There are 2 checkboxes that need to be checked in your restrictions profile if you have one.  The allow managed apps to read contacts from unmanaged contacts accounts and allow unmanaged apps to read contacts from managed contacts account.  Without both these checked I couldn't get it to sync anymore and had your same errors.  With both checked you can resync and they export fine.

[antherITguy]

Do you know enabling these settings affect just the iOS Contacts app or all native iOS apps?

[TJMEDLYN]

It will allow any native app I believe.  Definitely not very secure and something VMWare needs to address and fix and not by creating their own people or contact app.

[antherITguy]

https://support.apple.com/en-us/HT208749

This article states:
In iOS 12, you can use MDM to make the following exceptions to this policy:
Allow unmanaged apps to access managed contacts
Allow managed apps to save contacts to the local Contacts app

Has the behavior changed in iOS12?

[antherITguy]

Interesting thing, we upgraded to 9.7.0.9 and now have both ' Allow unmanaged apps to access managed contacts'  and ' Allow managed apps to save contacts to the local Contacts app'  options in our iOS profile.  With these settings enabled Boxer is still unable to sync back to the contacts app.

[johnmahoneyjohn]

We are currently experiencing this same behaviour on iOS12 devices, even though we have enabled both the new profile restrictions to allow ‘contacts’ to flow between managed and unmanaged apps.
Have been working with tech supt whom at the moment won’t commit whether it is an Apple or AW bug.  It has been assigned JIRA BINXI-9743, but not published yet.
The stand out result from testing, is the unexpected impact of profile setting ' Allow documents from unmanaged sources in managed destinations' .  This has always been disabled in our environment and contact flow to native iPhone worked stable.  Since iOS12 and the introduction of the 2x new specific restrictions for 'contact' flow, there is an unexpected result when combined with the former setting ' Allow documents from unmanaged sources in managed destinations' .
If you enable ' Allow documents from unmanaged sources in managed destinations'  (in addition to enabling the 2x new ‘contact’ flow restrictions) – then contact export works as expected.

[MichaelBenedict]

John - Thank you for providing the JIRA information, as we had not heard there was one made for this.  Our organization is also experiencing the same behavior.  Both of the new contacts settings make no difference.  It is only when ' Allow documents from unmanaged sources in managed destinations'  is enabled that this functionality returns.  Having the 2 new contacts settings has no impact on functionality.  Unfortunately opening up that setting opens a major security hole to our organization, therefore we cannot enable that setting as a workaround.  We continue to work with tech support to obtain a resolution.

[GolanNave]

Just been having the same issue. Thanks for all your work.

[CharlesDrury]

Where are these new contact restrictions found? Presumably we need a specific version of the AW co sole?

[johnmahoneyjohn]

Update from support - the fix for this issue should be in Boxer 5.2, which is currently in beta and expected for release mid December.
There is another JIRA associated to this bug BINXI-9983 – it’s for different (reverse) symptoms, but caused by same underlying bug.
I find it a bit disappointing that VMw have chosen not to publish a KB for what is a significant issue (in my environment at least).

BTW, when the fix is released, there is a chance that you will have to push your restriction profile to your devices.  Support explained that when a new feature is added to the profile (by way of API program update), that new feature is not known to the device until the next time the profile is pushed.  This is something to consider if you don't see immediate expected results with EXISTING enrolled devices (because existing enrolled devices are also affected by this bug, in as much that any contact changes from Boxer do not sync into native iPhone).

[antherITguy]

Thanks for the update John.  I have a case open with VMware about the same issue but have not heard back from them about a fix.  Boxer issues have been piling up recently.  I hate to say it but I miss the Blackberry days...

[anonymousmigrat]

Found this since I'm having the same issue. Commenting to subscribe to this post.

[CharlesDrury]

Boxer 5.2 released and the issue isn’t fixed....

[antherITguy]

Yup, contact issue remains...

[CharlesDrury]

I’ve reopened my case so let’s see what they come up with now.

[raven9810]

I just wanted to post and say we are still experiencing the exact same issue in version 5.2 as well.  Hoping that this thread gains more traction and a true fix from VMware actually appears at some point.

[RyanFrankRyanFr]

We just started using iOS Boxer because the native iOS was causing so many issues that we had no choice.  We also came across this contact issue and the only workaround is to check ' Allow documents from managed sources in unmanaged destinations' , which presents a huge security hole as our users could potentially move sensitive docs over to apps we have no control of.  I see no point in these contact restrictions in the profile.  This has to get resolved.

[johnmahoneyjohn]

The current status of this issue is astonishing, and I am very frustrated with AW developers (not support).  After the absence of the promised bug fix in 5.2 I was again in contact with support.  The dev team basically dropped the ball – they had misunderstood the original problem and started from scratch again.  I worked with support to provide further test info to feedback to dev.

As of yesterday, we are now expected to accept that this is not an AW bug after all, but is in fact an Apple bug.  After AW dev clarified their understanding (new JIRA BINXI-10361), they have apparently contacted Apple, and Apple dev have assigned a RADAR# to this issue.  I have contacted Apple Enterprise Support (and my Solution Engineer at Apple), but they don’t have access to the dev RADAR system and cannot provide any details whatsoever!!

So now we are expected to sit tight and wait for what exactly???
It has taken three months to arrive at this stage!

There are other elements of this situation that I also find hard to accept.:
1. AW support told me that there were only 5 customers validated against the JIRA – why is this so low.  And I guess it means the issue is way down the priority list.
2. The fact that Apple registered a new RADAR for AW (instead of validating them against an existing RADAR) suggests that no other MDM vendor had already reported the issue??
3. AW still have not published any customer facing KB article about this behaviour – despite the fact I have repeatedly asked.

The best thing Apple Enterprise Support could advise is that I (we) give them details about how this issue is affecting our environments.  The more customers they validate against the RADAR, apparently the higher priority it will be given.

[SamuelHowe]

It seems to me that majority of people out there are not using Boxer as their email client. I find it hard to believe that there aren't more rumblings out there. My ticket regarding this issue was closed a couple weeks ago and was told they would add to RADAR.  At this point, we are almost at a hold on the roll out due to this not functioning correctly.

Has anyone heard of any update?