Today's post is written by Aaron Robinson, an Engagement Manager at Sonoma Partners.
Microsoft Dynamics CRM has long offered customers the option of choice when it comes to deployment as a differentiation of their product relative to other customer relationship management solution offerings.
But there are some differences in administration and capabilities depending on the deployment option chosen. Let’s take a look at user administrator as it relates specifically to Dynamics CRM 2016 in Office 365.
One benefit of the online or “cloud” offering of Dynamics CRM is how users are created and managed. But before we get into how administration works, we need to understand the ways user accounts are created for Office 365.
If you created an Office 365 tenant and use the Administration portal to create users, you are more than likely creating “cloud accounts”. What does this mean? Office 365 authentication is supported by a version of Microsoft’s authentication engine Active Directory. More specifically, it is Azure Active Directory, meaning it is also a cloud service, just hosted on the Azure platform. So how do I know if they are cloud accounts? Easy!
First login to portal.office.com (I’m going to assume that you are a global (tenant) admin and have permission to the admin tab, otherwise you will not be able to do this). Once logged in, browse to Users>Active Users and look for the Status Column shown below:
The important piece to understand about this method is that the accounts are stored in an instance of Azure Active Directory. You can view this directory by navigating to Admin>Azure AD in the same Admin Portal as shown below.
If you do, it will redirect you to the Windows Azure management website, and ask for you to create an account to manage this Azure tenant. Note this is not a requirement. You can continue to manage users in the Admin portal without ever visiting the Azure AD page. Since this azure portal is a whole other beast, its better left for another time.
Another method is more common in enterprise scenarios, where Active Directory domains have already existed for years and single sign-on (SSO) is preferred for on premises and cloud services in an organization. These accounts must either be sync’d with a cloud Active Directory, or redirected to federation service for authentication. For users this means they will continue to use same email address and password they currently use, and password changes will sync automatically.
DirSync or Azure AD Connect
Directory Sync is one method for enabling single sign-on. One aspect I like about this method is that it is a single page authentication, rather than redirection, meaning less clicks for a user. However, administration of this method can be more demanding, as you need to make sure the service is always running. Microsoft does aide in this process as they will notify the tenant admin if the sync goes down for a predetermined period of time, letting you know that someone should look into it.
The requirement for directory sync is to set up a synchronization service on a server behind the corporate firewall which can connect to the local Active Directory. This was previously done with a tool called DirSync, but has since been replaced by a newer version called Azure AD Connect. There is plenty of information on the deployment of DirSync and Azure AD Connect, so we won’t cover that here.
Active Directory Federation Services
ADFS is another way to go for enabling SSO. Many enterprises will already have this in place for other SSO applications they manage, and as such may be more desirable. The downside of this method in my opinion is the user experience. From the Office 365 sign-in page, a user will enter their email address, and Office 365 will redirect them to the ADFS sign-in page for the organization, where they will have to enter their credentials, possible for a second time (the experience can be a bit inconsistent here depending on the device, operating system and browser).
Once again, there is plenty of good information on the setup here.
Now that we have covered where the user accounts can exist, let’s examine how they become users of Dynamics CRM. This is a two step process that is fairly straight forward. Let’s start with license assignment. Back to our trusty Admin Portal for Office 365 where our users now exist, you will want to expand the Active Users. Select a user, which will give you the user admin panel to the right side as pictured below.
Click Edit on the Assigned license section and add a Dynamics CRM license to this user (this assumes you have purchased the licenses in advance, otherwise you may not have them available). The nice part here is that Microsoft has automated the user creation in Dynamics for you. Once you have assigned the license, an automated routine will run to create the user record in Dynamics. Keep in mind that this automation is not instantaneous, and it may take a few minutes for the user to appear. But in most cases I see it appear in under a minute.
The last step is to sign into Dynamics as a CRM Administrator, and add a security role to the new user account. Unsure how to do that? Refer to this TechNet article.
And one more thing…
Would you like to see a list of all Dynamics CRM Licensed users in the Admin portal? On the Active Users page, there is a view filter dropdown for seeing users by different attributes, such as Active Users, SignIn Allowed or Blocked, Unlicensed Users, etc. A really helpful view is Dynamics CRM Licensed Users, but it doesn’t exist by default. Here’s how you would add one. Click the dropdown for Select a View, and select New View.
Name your view (“Dynamics CRM Licensed Users” works for me), and then under the Assigned License dropdown, select Microsoft Dynamics CRM Online Professional, and then click save.
Now pop into the Active Users, select your new view, and there you go!
Looking for help with your Dynamics CRM deployment? You came to the right place! We can help you better understand Office 365 user account management and so much more.