Sonoma Partners Microsoft CRM and Blog

Understanding Office 365 User Account Management for Dynamics CRM Online

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.

Account Types

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.

Cloud Accounts

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 (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.

Local Accounts

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.

User Management

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. 



Topics: Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

FetchXML: Left Outer Joins with Multiple On Clauses

Having worked on CRM for ten years, I thought I understood everything that was possible with FetchXML. After all it seems pretty straight forward and each clause has almost a one to one equivalent with SQL. However, while I was recently doing some work on a project that required me to find records missing certain child records, I was surprised to find my understanding of left outer joins was incomplete.

The Requirement

In the project I was working on, we were using the native Connection entity to track relationships between contacts and users. Some of the Connections were manually created, but others needed to be automatically created based on business logic. In some cases we needed to detect all contacts that a user did not have a connection of a specified role with.  This seemed like a good case for using a left outer join and I sat down and wrote the following FetchXML:

The Concern

As I reviewed the FetchXML, I became concerned that I wouldn’t get the proper results with this query. I was assuming that CRM only used the to and from attributes on the link-entity element to build the on clause for the left join in SQL.  I knew that if the additional conditions inside the link-entity were added to the SQL where clause, that I would get no rows back.  In short, I was worried the generated SQL would look something like this:

It was enough of a concern that I decided to fire up SQL Profiler on my local dev org and see what exactly CRM generates in this case.  Much to my surprise I found the following (slightly cleaned up to help legibility):

In Summary

So in the end, CRM came through and put the link-entity’s conditions in the on clause for the left join.  This subtle change makes a huge difference in the results returned and makes left joins much more useful in CRM than one might assume based on the FetchXML structure.  This left me with an efficient query to solve the business requirement and a new found respect for FetchXML.

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2013 Microsoft Dynamics CRM 2015 Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

CRM DevTools - Easily Update Hidden or Read-Only Fields for Testing

When testing functionality in CRM, most likely you will need to update some data in order to complete the test.  But what happens if the field doesn’t exist on the record form or is read-only?  One option would be to edit the form temporarily to display the field on the form, update the field value and then remove the field from the form after your test.  A better option, to save the hassle of all that publishing, would be to create an on demand workflow that updates your field directly and then manually run that workflow against your record.  However, CRM DevTools provides an even better option through the Test tab by allowing a System Administrator to update the field value through the record form even if the field doesn’t exist on the form or it is read-only.

First, you need to head over to the Chrome web store and add the CRM DevTools extension to your Chrome browser.  Also make sure you are System Administrator of your environment, otherwise the Test tab will not display.

Next, head to the record you want to update and press F12 which will pop open Chrome’s DevTools pane.  There should be a CRM DevTools tab at the top of the pane.


Click CRM DevTools and once it loads, click on the TEST tab.  You can now select up to three fields at a time.  Once you select a field, it will display the existing value in the Value column and then you can change that value.  If the field is a Lookup then you will need to enter the schema name for that Lookup in the Entity Schema Name column.  Then click Update and your field will be set to the new value.


Now you can easily update hidden or read-only fields in just a few easy steps without messing with the form or creating unnecessary workflows! 

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2013 Microsoft Dynamics CRM 2015 Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

Dynamics CRM - Entity Change Tracking

With the release of Dynamics CRM 2015 Online Update 1, Microsoft has provided developers many different ways to optimize performance when integrating with other systems.  We already covered Alternate Keys in a previous post which help increase performance by reducing the need to make retrieve API calls in order to find the primary key of a record.  In this post I will cover Entity Change Tracking, another feature of 2015 Online Update 1 which increases performance when needing to send data to an external system by retrieving only a subset of data that has changed since the last retrieval. 

So how does it work?

First you need to enable Change Tracking for the specific entity you want to use it on.  You can do this through the Entity customizations as shown below.


Then the RetrieveEntityChanges request can be used in code to get a list of entity records that have changed since the last retrieval.  If it is the first request then you’ll want to pass in an empty string or null to the DataVersion property but subsequent requests should use a token (which is returned from RetrieveEntityChangesRespone) in order to retrieve a list of records that have been changed since the last request.

string token = "";

var records = new List<Entity>(); 
var request = new RetrieveEntityChangesRequest(); 
request.EntityName = "account"; 
request.Columns = new ColumnSet("name"); 
request.PageInfo = new PagingInfo() { Count = 5000, PageNumber = 1, ReturnTotalRecordCount = false }; 
request.DataVersion = token;    
while (true) 

     var response = (RetrieveEntityChangesResponse)orgService.Execute(request); 
     records.AddRange(response.EntityChanges.Changes.Select(x => (x as NewOrUpdatedItem).NewOrUpdatedEntity).ToArray()); 
     records.ForEach(x => Console.WriteLine(x.Id)); 
     if (!response.EntityChanges.MoreRecords) 
         token = response.EntityChanges.DataToken; 
     request.PageInfo.PagingCookie = response.EntityChanges.PagingCookie; 

Running this code using LinqPad in a brand new Online trial org with no token provided a list of 10 records that have been changed:


And then the DataToken:

568840!02/10/2016 21:11:27

Running the same code above but passing in the token of “568840!02/10/2016 21:11:27” will now yield no results as expected as Account records haven’t been changed since we made our RetrieveEntityChanges request.

As you can see, this new request will be very handy when there is a need to synchronize data to external systems.  Now you can easily optimize performance by only synchronizing records that have been changed since the last sync.

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2015 Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

Deploy Dynamics CRM with PowerShell Part 3: Auditing

Today's post is written by Ian Moore, a developer at Sonoma Partners.

Making sure that auditing is enabled and configured correctly is usually a critical step when setting up a new Dynamics CRM organization, especially a production instance. Everything related to auditing can easily be added to a deployment or setup script with a couple extra lines of PowerShell code.

The first step in configuring auditing for your organization is to make sure it is enabled at the system level. If it is not enabled here, no auditing will ever occur. Here is a simple code snippet to test if your CRM organization has auditing enabled, and to enable it if it does not:

From there, you will need to ensure that auditing is enabled at the entity level for all data where you want to track changes. If you’re not sure which entities have been configured to audit, you can actually use PowerShell to generate a simple report of your current entity audit settings:


Once you know which entities still need to have auditing enabled, you can use metadata updates to configure each entity. The following snippet would enable auditing for accounts:

As with any metadata changes, you will need to make sure to publish changes for the entity. The easiest way from your PowerShell script would be to use the Publish-CrmAllCustomization function. If you are only updating a handful of entities, you could also create a PublishXmlRequest similar to the UpdateEntityRequest above rather than publishing all changes.

Hopefully these snippets help eliminate necessary manual steps when configuring auditing in your CRM environment.

Make sure to download the Microsoft.Xrm.Data.PowerShell module from GitHub at and follow for updates to the module!

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM Online

Deploy Dynamics CRM with PowerShell Part 2: Importing SLAs

Today's post is written by Ian Moore, a Developer at Sonoma Partners.

If your Dynamics CRM deployment includes Service Level Agreements, you have probably encountered the following error in the import log when importing solutions from a dev environment to a testing environment:

“You can't edit an active SLA. Deactivate the SLA, and then try editing it.”


This error occurs because your solution contains an SLA that is active in the current environment. Having an SLA in your solution can complicate imports if you forget to deactivate the SLA before starting, as the error will come at the end of the import process and you will have to start over. Thankfully we can use PowerShell to automatically deactivate any active SLAs and re-activate after importing an updated solution.

For this example we will use a simple solution that contains one SLA component, and try importing it into an organization that already has an active previous version of the SLA.


After getting a connection with Get-CrmConnection, we can query for active SLA’s with Get-CrmRecords in the org we will be importing to:

$crmOrg = Get-CrmConnection –InteractiveMode

# get any active SLAs in the org
$SLAresults = Get-CrmRecords -conn $crmOrg -Entitylogicalname sla -Fields slaid, statecode, isdefault -FilterAttribute statecode -FilterOperator -eq -FilterValue Active

From here we can deactivate the SLAs with Set-CrmRecordState and import the solution:

# deactivate the active SLAs
$SLAresults['CrmRecords'] | % { Set-CrmRecordState -conn $crmOrg -CrmRecord $_ -StateCode Draft -StatusCode Draft }

# import solution
Import-CrmSolution -conn $crmOrg -SolutionFilePath C:\Path\To\Solutions\ -ActivatePlugins -PublishChanges

With the SLAs in draft status, the solution should import successfully. Once it is completed, we can re-activate the SLAs. One catch to this process is that any SLA that was not marked as Default will not be restored when it is reactivated – so after reactivation we can use Set-CrmRecord to update the “Is Default” property as necessary.

# re-activate SLAs
$SLAresults['CrmRecords'] | % { Set-CrmRecordState -conn $crmOrg -CrmRecord $_ -StateCode Active -StatusCode Active }

# update any default SLAs to be default again
$SLAresults['CrmRecords'] |
? { $_.isdefault -eq 'Yes' } |
% { Set-CrmRecord -conn $crmOrg -EntityLogicalName sla -Id $_.slaid -Fields @{'isdefault'=$true} }

Now any SLAs should be restored to their original state, and the solution with SLA updates is imported and applied. Here is a sample script that shows the whole process:

Make sure to download the Microsoft.Xrm.Data.PowerShell module from GitHub at and follow for updates to the module!

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM Online

Dynamics CRM 2016 – Turn Any Text Field into an Auto-Complete

Before the holidays I wrote about the new keypress events that exist in Dynamics CRM 2016 and how they can be used to provide more rich data validation but also with the release of Dynamics CRM 2016, the keypress events can be utilized to provide even more functionality by way of auto-complete controls.  Auto-completion methods were added to the Xrm client-side library which can be used in conjunction with the keypress events to turn any text field into an auto-complete control.  This can come in handy if you want to pull data from a third-party source and display it as if it were a native lookup control in CRM. 

A great example of this would be turning the native State and Country address fields into an auto-complete using live data from another source.  Without further ado, lets jump into some code on how this can be accomplished using the native Country field.

In this example I will be using the geognos free web service to retrieve a list of countries as well as their respective flags.

Note:  The free web service is http only so if you are using it in an https-enabled CRM environment then you will have to manually allow access through a browser prompt.

First setup a standard onload event in your JavaScript and register it on your form.

Then make an ajax call to the geognos web service which will retrieve all countries and add them to a list along with a URL to an image of the country flag.

     url: '',
     dataType: "jsonp",
     jsonpCallback: 'callback',
    success: function(data) {
          for (var country in data.Results) {
                   id: country,
                   name: data.Results[country].Name,
                   icon: "" + country + ".png",
                   fields: [data.Results[country].Name] 

Next we will write a function using the keypress event for the native address1_country field which will utilize the new auto-completion methods to hide and show a list of countries.  The kepress event needs to handle the logic to filter the list of countries based on what the user types so we will compare what the user typed to the name of the country in the list to filter it down and pass the results to the showAutoComplete method.  If the data passed into showAutoComplete has an icon property set (a url to an image) then it will display an icon next to the list item which we will utilize to display the country’s flag.

var keyPressFcn = function (ext) {
     try {
          var resultSet = { results: [] };
          var userInput = Xrm.Page.getControl("address1_country").getValue();
          var userInputLowerCase = userInput.toLowerCase();
          for (i = 0; i < countries.length; i++) {
               if (userInputLowerCase === countries[i].name.substring(0, 
                  userInputLowerCase.length).toLowerCase()) {
                          id: i,
                          fields: [countries[i].name],
                          icon: countries[i].icon
               if (resultSet.results.length >= 10) break;
          if (resultSet.results.length > 0) {
         else {
     } catch (e) {

Lastly, we need to register the keypress function we wrote above to the address1_country keypress event


Once we add the script to CRM and register the onload function we can now check it out in action!

Note:  The user can still type free-form text into the control and by default CRM won’t validate that the user selected something from the list but JavaScript validation could be added to make sure an item from the list was used if necessary for your business.

Here is the complete script for this example:

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

Deploy Dynamics CRM with PowerShell Part 1: Duplicate Detection Rules

Today's post is written by Ian Moore, a Developer at Sonoma Partners.

The Dynamics CRM PFE team recently released Microsoft.Xrm.Data.PowerShell, which is a PowerShell module with cmdlets for interacting with data in a CRM Organization. It includes cmdlets that allow automation of solution exports and imports, changing system settings, and administration tasks. In this series of blogs, we will look at how these cmdlets can be used to automate common tasks that are encountered in deploying solutions for Dynamics CRM. The first part will be how to enable duplicate detection rules from PowerShell.

When importing a solution that contains an entity, it is not uncommon for CRM to unpublish any duplicate detection rules for the entity.


This requires any affected rules to be published manually after the solution is imported. We can automate this process in a few lines of PowerShell.

First, create the following function:

This function takes in the CrmServiceClient created by the Get-CrmConnection cmdlet, and an array of guids for duplicate rules. Each guid is piped to the small “Create-PublishRuleRequest” function to create an SDK request, and the piped to the code block that executes the request and returns the response as a PublishDuplicateRuleResponse.

Now for the script, we need to make sure the module is imported and can create a connection to Dynamics CRM with Get-CrmConnection.

if (-Not (Get-Module -Name Microsoft.Xrm.Data.Powershell)) {
     Import-Module Microsoft.Xrm.Data.Powershell

$crmOrg = Get-CrmConnection –InteractiveMode

Before importing the solution, we can query for the duplicate rules that are currently published with Get-CrmRecords. By filtering for only active rules, we can make sure we don’t unintentionally publish a rule that wasn’t active prior to importing the solution.

$duplicaterules = Get-CrmRecords -conn $crmOrg 'duplicaterule' -FilterAttribute statecode -FilterOperator -eq -FilterValue Active

$duplicateruleIds = $duplicaterules['CrmRecords'] | select -ExpandProperty duplicateruleid

Now we have the guids we need for publishing, so we can import our solution to the organization with Import-CrmSolution, and call our publish function.

Import-CrmSolution -conn $crmOrg -SolutionFilePath C:\Path\To\Solutions\ -PublishChanges

Publish-CrmDuplicateRules -conn $crmOrg -RuleIds $duplicateruleIds

Here is a sample script that shows the whole process.

Make sure to download the Microsoft.Xrm.Data.PowerShell module from GitHub at and follow for updates to the module!

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM Online

Dynamics CRM 2016 – New Keypress Events

Just a few weeks ago Microsoft announced the official release of Dynamics CRM 2016 for both Online and on-premise.  With this release comes exciting new features for developers.  The new feature that I will cover in this post is the ability to add keypress events to number or text controls.  The new keypress event allows developers to trigger a function when the user presses keys in a number or text control.  This will allow developers to provide more rich data validation in a supported manner which is especially useful if auto-save is used in your organization. 

For example, if you want to ensure the user enters valid data into the native phone number field, we can register on the keypress event and automatically remove invalid characters as the user presses them.

First we will setup a function on the new addOnKeyPress event for the main telephone field.

Xrm.Page.getControl('telephone1').addOnKeyPress(function() { });

Then we will retrieve the value from the main telephone field to get the keys that the user inputted.

var userInput = Xrm.Page.getControl('telephone1').getValue();

Then we will build a regex to replace any of the inputted keys that are not “(“, “)”, “-“, or a number.

userInput = userInput.replace(/[^\d-()]+/g, '');

Lastly, we will replace the main telephone value with the new clean version of the user’s input


It’s just that easy!  Now if a user presses an invalid character in the main telephone field, it will automatically delete the character so the field will not be saved with invalid data.

Below is the full snippet of code:

Head here for the full SDK documentation on the new keypress methods.

Topics: Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

Introducing Dynabacus – Microsoft CRM Record Count Tool

Today’s guest blogger is Mike Dearing, a Principal Developer at Sonoma Partners.

Ever wanted to get an accurate record count of all of your organization’s companies, contacts, <enter additional entity names here…>?  Well, you aren’t alone.  Your current options to accomplish this are limited. They include doing excel exports, writing reports, or performing SQL count queries (if your deployment is on-premise). We decided to develop a user-friendly, managed solution that you can easily drop into any Dynamics 2015 on-premise or online environment to perform these counts for you.  Dynabacus (the Dynamics-abacus) gives CRM administrators the ability to get the record count of any number of entities (native or custom) simultaneously.  Administrators can also refine these counts further by applying personal and system views if they choose to do so.  Then with the simple click of a button, Dynabacus crunches the numbers for you using supported API calls and returns the results.


And the best part is, it’s available now for free! Download it today and let us know what you think!

Topics: Microsoft Dynamics CRM 2015 Microsoft Dynamics CRM Online