As mentioned in my previous post I’m in Redmond (WA) to join the Enterprise Mobility deep dive airlift. During my three-day stay I’ll listen, learn and getting inspired of all cool stuff Enterprise Mobility has to offer. On the first day we covered the hybrid identity part of EMS which means – Azure AD Connect, Azure AD Premium – which provided a lot of new insights and key takeaways.
Last week I came across a scenario where Alternate Login ID feature of Active Directory Federation Services (AD FS) came at its best.
Part of an Enterprise Mobility Suite (EMS) implementation we were facing a challange to overcome. In this scenario the customer has multi-forest (fictive contoso.local & adatum.local) AD structure with a two-way forest trust relationship. The user resources are currently located in te frabrikam.local (blue) where all server resources are part of the contoso.local (grey) domain including AD FS.
As fabrikam.com is the public domain namespace used, we added a UPN suffix for the fabrikam.local domain to make sure the user objects synced from the on-premise Active Directory – by Azure Active Directory Sync – matches the public User Principal Name (UPN) domain namespace.
During a Windows Intune proof of concept (PoC) I was facing some issues configuring federation in order to enable Signle Sign On (SSO).
When configuring federation we couldn’t convert the the default domain to a federated domain type. By using the –Verbose –Debug parameters of convert –MsolDomainToFederated cmdlet the root cause became clear. Proxy Authentication was required and therefore we couldn’t convert the domain. One down two to go!
At the moment there’re several scenario’s to manage and provisioning users to Windows Intune in order to enable Enterprise Mobility Management (EMM) or simply said – managing your mobile devices. As the process of provisioning users to Windows Intune in combination with Configuration Manager 2012 R2 is not always clear I’ll provide you some insights and tips where and how to troubleshoot.
As mentioned I’ll will focus in this post on a hybrid scenario using Configuration Manager 2012 R2, Windows Intune and on-premise Active Directory where Azure Active Directory Sync (aka DirSync) is used to syncronize on-premise users to Windows Intune (Azure Active Directory).
Process Overview Windows Intune User provisioning
John Doe is created in (on-premise) Active Directory
John Doe is synchronized by Azure Active Directory Sync to (off-premise) Azure Active Directory
John Doe is discovered by Configuration Manager 2012 R2
John Doe is add to Windows Intune collection in Configuration Manager 2012 R2
John Doe is synchronized by Windows Intune Connector
John Doe is enabled Windows Intune user
One of the big advantages of using Service Manager as your Configuration Manager Database (CMDB) is the connector framework. By using the connector framework you are able to establish out-of-the box connections to your infrastructure – Active Directory – and System Center components like Configuration Manager-, Operations Manager and Virtual Machine Manager. Hereby you can easily gather and centrally store all relevant information into a single place which forms the basis for your IT Service Management (ITSM) processes.
One of the major challenges of a CMDB is to keep the – information contains – up to date and accurate. Also herein the connector framework have an important role to (automatically) update Configuration Items (CI) from different sources (connector framework).
A while ago Travis Wright (who else…) wrote a blog post regarding the behavior of what happens with CI’s in the CMDB when deleted from Active Directory and what permissions are required by the run-as account that is used for the AD connector.
In this post I’ll walkthrough how to configure and set proper rights for the run-as account used by the AD connector. Continue reading “Keep your Service Manager CMDB in accurate shape!”