InTune Android for Work Exchange Conditional Access bug

Android for Work is a great feature which we are implementing within our organisation to secure Corporate data on Android devices. But as with any relatively newly released feature it has taken a good degree of testing, troubleshooting and collaborating with Intune support, which may I add has improved infinitely within the last 6 months.
I stumbled across an issue where devices were being blocked by Exchange when subject to conditional access and after working on this with tech support for a few weeks I was recommended to log a case on connect by Enterprise Mobility MVP Paul Winstanley, the case can be found here https://connect.microsoft.com/ConfigurationManagervnext/feedback/details/3138364
I was sure this was a bug due to some strange behaviour I was observing where after enrolling the device I could see that an entry was created for the Intune managed device itself, and once the email profile was authenticated, an addition Exchange Active Sync object. This to me didn't seem to be expected behaviour;

There ultimately didn't seem to be any way of registering the EAS ID in Azure AD hence the device being prompted for conditional access, even though it was already enrolled and eventually being blocked.

Microsoft contacted me directly and it turns out that the Android for Work email profile is failing to generate some settings required for the EAS ID, therefore under their instruction I carried out the following as a workaround;
- Exported the Android for Work profile. You can do this by highlighting the profile and selecting the "View Xml Defnition" option. This will open the file which can then be saved.

- I emailed this back to Microsoft who in turn sent back to me a .MOF file generated from the XML with the missing settings within it. Not sure exactly how they would have generated it but what I can point out is that it had the addition of the below code to it;


<Rule xmlns=\"http://schemas.microsoft.com/SystemsCenterConfigurationManager/2009/06/14/Rules\" id=\"EasAfw_0_EasId\" Severity=\"Warning\" NonCompliantWhenSettingIsNotFound=\"true\">
<Annotation>        
<DisplayName Text=\"Rule: EasId_Name\" ResourceId=\"EasId_Name\" />        
<Description Text=\"The EAS Id to set for this email profile\"ResourceId=\"EasId_Desc\" />       
</Annotation>       
<Expression>        
<Operator>Equals</Operator>        
<Operands>          
<SettingReference AuthoringScopeId=\"GLOBAL\" LogicalName=\"EasAfw_Settings\" DataType=\"String\" SettingLogicalName=\"EasAfw_EasId\" SettingSourceType=\"CIM\" Method=\"Value\" Changeable=\"true\" />          
<ConstantValue Value=\"$EASID$\" DataType=\"String\" />        
</Operands>       
</Expression>       
<KeyPropertiesRules>        
<RuleExpression RuleId=\"EasAfw_0_EmailClient\" />        
<RuleExpression RuleId=\"EasAfw_0_EmailAddress\" />        
<RuleExpression RuleId=\"EasAfw_0_Host\" />        
<RuleExpression RuleId=\"EasAfw_0_AccountGUID\" />      
</KeyPropertiesRules>     
</Rule>
Along with a configuration policy version number increment by 1;
<ConfigurationPolicy AuthoringScopeId=\"ScopeId_1AAA8919-CE7D-43A2-8BAF-D95647C0D2B9\" LogicalName=\"ConfigurationPolicy_4008a5b9-9ff1-4d41-b46e-8ed8ef4bb47c\" Version=\"3\">


- Saved the .MOF file to the SCCM server and then ran the command "mofcomp moffilename.mof" in an admin command prompt


- After this I enrolled a device and this time even after I authenticated the Android for Work email profile could only see the Intune managed device within SCCM;

Devices are no longer being blocked and it would appear at this stage this has resolved the issue. I am led to believe that a patch will be released by Microsoft but have no timescales yet.


I hope this helps anyone who has been having issues with this, and any comments on points I have made that do not make sense, or believe you can fill in any gaps, please feel free to add.