(Edit 17th May 2015: This issue has been resolved by Microsoft and Alternate Login IDs are now fully supported with the ConfigMgr/Intune hybrid solution. This involved updates to the Intune service. The WiKi article (referenced below) has been edited to reflect this. Thanks for the information Stefan Schörling and Jörgen Nilsson.)
I hope that this blog post helps other Consultants to avoid the trap that I fell into. "Alternate Login IDs" are a really cool new feature of Windows Server 2012 R2 Update. They are described in detail here
DirSync: Using Alternate Login IDs with Azure Active Directory
The process involves:
- Modifying the DirSync attribute flow for UserPrincipalName for provisioning/sync
- Leveraging the Alternate Login ID feature of AD FS for Single Sign-On authentication
However, it doesn't work with the Unified Device Management solution of ConfigMgr 2012 and Intune. This is because ConfigMgr handles AD user accounts differently. When a user is first discovered all the AD attributes are committed to the ConfigMgr database. This includes the UPN (eg. firstname.lastname@example.org). When I add this user to my "Intune Users" collection this change cannot be synchronised to Intune. The CloudUserSync log tells us that the internal AD UPN is being used to sync to Azure. As the DirSync Direct Mapping is not involved in this process it fails - UserNotFound. Of course it does - email@example.com does not exist in Azure.
The article above has warned me that I might have a problem:
"If you are an InTune Hybrid customers using the SCCM Connector there may be additional configuration required. Please contact your Account representative for more information."
I contacted Microsoft CSS for this "additional configuration". They were aware of this shortcoming. There is no supported solution at this time - and no estimated time for a possible solution. The suggested workaround is to run a script on the ConfigMgr database to change the UPN for the user accounts to use the public routable domain. Clearly this is not supported so I don't think it's a great idea.
A recent customer engagement had several phases. Phase 1 was an Office 365 migration. They were very pleased to implement the new features so that UPNs did not have to be changed. Phase 2 was the ConfigMgr/Intune solution - guess what - UPNs now had to be changed. It's a real shame because Alternate Login IDs are a cracking new feature.