Thursday 31 August 2017

Intune hybrid portal migration to Azure

Our Intune environment is in a hybrid configuration however I wanted to have a look around the layout of the Intune portal in Azure. This was prompted by the various emails I received from Microsoft stating that there are only a few accounts to be migrated, therefore I reviewed the potential migration blockers here

It turns out that hybrid Intune is not yet supported for the Azure portal - this is not clearly documented anywhere as far as I am aware (I have also confirmed this with Microsoft technical support).
Granted there are very few reasons in which you would need to access the portal in this configuration but it would be good to have one less interface to have to log in to...
I have found a user voice there here where this feature can be voted up, looks like work has been started on this as of 14/8/17
So to help with my studies, trial subscription it is for now then.

Tuesday 29 August 2017

Android for Work Play store crashing

Okay, so a few weeks has passed since my last blog post and after returning to the office after a weeks leave, it would appear that the pilot roll out has commenced successfully for our Intune project. I made the guys aware of a known issue internally before going on leave and have now had it confirmed with Microsoft tech support as a bug.
It would appear that there is an issue with the work badged Google Play store where on enrolment it frequently crashes during the installation of enforced applications, hence delaying some application deployments.
Whilst this isn't a major issue it does sometimes make enrolment a long winded process, especially if the store crashed before there was chance for the email profile and app (in our case Gmail) to be deployed to the device.
In order to alleviate the above, the simple workaround I have implemented is to deploy only the email app, calendar app and email profile to the user account so they will be installed pretty much as soon as the device is enrolled. This tends to not crash the store.
All of the other remaining apps are deployed to the device itself, which will take place once it becomes part of a device collection within SCCM.

Wednesday 9 August 2017

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
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=\"\" id=\"EasAfw_0_EasId\" Severity=\"Warning\" NonCompliantWhenSettingIsNotFound=\"true\">
<DisplayName Text=\"Rule: EasId_Name\" ResourceId=\"EasId_Name\" />        
<Description Text=\"The EAS Id to set for this email profile\"ResourceId=\"EasId_Desc\" />       
<SettingReference AuthoringScopeId=\"GLOBAL\" LogicalName=\"EasAfw_Settings\" DataType=\"String\" SettingLogicalName=\"EasAfw_EasId\" SettingSourceType=\"CIM\" Method=\"Value\" Changeable=\"true\" />          
<ConstantValue Value=\"$EASID$\" DataType=\"String\" />        
<RuleExpression RuleId=\"EasAfw_0_EmailClient\" />        
<RuleExpression RuleId=\"EasAfw_0_EmailAddress\" />        
<RuleExpression RuleId=\"EasAfw_0_Host\" />        
<RuleExpression RuleId=\"EasAfw_0_AccountGUID\" />      
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.