How to Set Microsoft Exchange Online Service Account Permissions for use with Server Side Sync or Email Router

If you're using Microsoft Exchange Online and you're setting up a server side sync or email router, you may be using the method of using one service account in your Exchange environment to use in the configuration of the email router or server side sync. This one service account would then be used for access to all other user mailboxes. In today's blog, however, we'll show you how to set permissions for an Exchange online service account for use with server side sync or email router. So let's dive in!

This steps outlined below are accomplishing this using PowerShell. Most of these steps can also be done via the web user interface of Office 365, but it's easier to automate the permissions on a large number of mailboxes with PowerShell.

1. First, connect to your Office 365 tenant via PowerShell.

2. Next, run PowerShell using the following commands to connect to your Office 365. When prompted, log in with an account that's a global administrator in your Office 365 tenant:

Import-Module MSOnline
$O365Cred = Get-Credential
$O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $O365Cred -Authentication Basic -AllowRedirection
Import-PSSession $O365Session
Connect-MsolService –Credential $O365Cred

3. Grant your service account the application impersonation role by running the following commands:

Note: This permission may sometimes take up to about an hour to take effect.

4. The service account will need "send as" permissions for any users that will be sending out emails from CRM through this setup as well as "full access" permissions for any users that will have incoming mail monitored by the email router or SSS (server side sync).

To grant "send as" permission for all existing mailboxes follow these steps:

Alternatively, if you wanted to apply permissions only to some users, simply create a text file of all the email addresses, one email address per line, and apply permissions with the commands below. First, create your text file with one email address per line and nothing else. Be sure that the email addresses are primary email address.

In this example, our file is called "emailaddresses.txt" and is saved in c:filelocation.

5. Run this command to import contents into a new variable we are calling $emails:

6. Next, to set "send as" permissions for the service account on all the mailboxes in the list follow these steps:

7. One optional step you may want is to have the password never expire for this service account (be sure to set a very strong password). This will prevent email processing from stopping when the service account's password expires. Through PowerShell, you can do this using the following command:

8. One final item to be aware of is that the "send as" and/or "full access" permissions were granted for existing mailboxes, but as new users get created in the future, the service account will need to have permissions added if the new users require incoming and/or outgoing email through CRM.

To grant these permissions for one user follow these steps:

That's all for the blog today. Want to learn more about Microsoft's wide array of services and products? Check out our information about Microsoft Office 365 and learn how you can bundle all of your cloud licenses and services by participating in our Microsoft Cloud by PowerObjects program!

Happy CRM'ing!

CRM 2015 Update 0.2 Troubleshooting: Help! I can’t import solutions that contain business rules!

Did you install the CRM 2015 Update 0.2? Do any of the entities in your solution contain a business rule? After installing the update, did you find yourself saying "Help! My solution failed to import and says there is a process that is missing, but I know there isn't!" If this is you, then today's blog has all the answers you need!

This error with business rules is a known bug for the 0.2 CRM update. The bug impacts any solution that contains business rules. When you try to import a solution containing business rules, the solution import will fail due to those business rules. Yikes. No one likes that.

Here is an example of the error message when importing a solution:

"The required record was not found or you do not have sufficient permissions to view it."


A possible, but risky, workaround is to delete the business rule(s) in the target CRM you are importing the solution to. After the import, recreate those business rule(s) in the target CRM. Did we mention you might want to back-up your CRM database before doing this? Sounds a little dicey, right?

Microsoft says this issue will be fixed in the 0.3 update so keep your fingers crossed!

Don't want to wait until the 0.3 update with the fix for this issue? Good news! Microsoft has a hotfix for this. Whoop whoop. You can contact Microsoft for assistance in getting the hotfix.

Curious about taking the plunge and upgrading to Dynamics CRM 2016? Check out some of the new features that come with the latest version of Dynamics CRM by watching this segment of The CRM Minute, our weekly video blog series!

Happy CRM'ing!

Duplicate Detection and Security Roles in Dynamics CRM

The duplicate detection functionality in Microsoft Dynamics CRM was developed to help you maintain integrity of your data. You can configure duplicate detection rules for any entity in CRM. The duplicate detection can be used during the creation of a record, updating a record, during imports or as a scheduled job.

One thing to note is that the duplicate detection setting only allows you to check against records that you have access to in CRM.

Let's say, for example, that a salesperson attends a conference and receives a handful of business cards. He would like to create them as leads in CRM to validate that they actually want to do business. Currently, this user has full access to leads, but his access to the accounts and contacts are only for records that are in his business unit. The system administrator created a few duplicate detention rules to help prevent duplicate data in the system:

1. The first rule was set up to check against existing leads.

duplicate detection with security roles

2. The second one was to check the first name, last name and email address of the lead against existing contacts.

3. The last one was to check the company name against the account name in the account entity.

With these three duplicate detection rules setup in CRM, the system administrator believed they could catch all records that may have been duplicates. What the administrator didn't realize is that when the duplicate detection functionality is run by the user, it only checks against records that the user has access to.

Below is the current organizational structure. There is a business unit based on each territory. Security is set up so that users can only see and access data in their specific business unit, except for leads.

Let's say that a user in the Eastern BU creates a lead, but a contact already exists in the Midwest BU. Since the user doesn't have access to check against the records in the Midwest BU, this would allow the user to create the lead record. If the contact existed in the Eastern BU, the duplicate detection would have caught this duplicate record.

There are a few different ways to handle this situation:

  1. Allow users read rights to all leads, accounts and contacts. This might not be the best option as this is the reason you set up your CRM hierarchy.
  2. Create a new security role that has permission to the whole organization and grant one person this role. This user would then be required to create any new records that you want the duplicate detection turned on for.
  3. Create a duplicate detection job that is run by an administrator user that has organizational rights to the lead, account and contact entities. Any duplicate records would have to be merged by a user who has rights at the organization level.

The option you go with will depend on how your organization handles the way data is shared among its users.

If you need help developing best practices for your particular organization regarding security roles and duplicate detection, PowerObjects can help. Contact us for more information.

Happy CRM'ing!

A recent error message and a quick fix


We recently came across an error issue where a relatively new Microsoft Dynamics CRM 2011 environment could not import any solution.  The ambiguous error message was ‘You do not have the necessary permissions to change the domain logon name for this user’.  Even when logged on as an admin user in the server and CRM we kept getting the same error.

As we dug into it, we found the cause was that the crm application pool account needs read/write access to this folder on the CRM server.

C:Program FilesMicrosoft Dynamics CRMCustomizationImport

The application pool account is typically the network service account in a default out of the box installation.  This is a folder were all imported customizations are first copied to.

If you’ve run into this as well, we’d love to hear your story. Leave a comment.

Happy CRM’ing!

Image courtesy of Flickr user dno1967b.

Can role-based forms be used to determine write access of the user?

This was a question we were recently asked by one of our clients, and the answer is - Yes, role-based forms can be used to determine write access based upon the security role of the user. In Microsoft Dynamics CRM 2011 the read-only property of an attribute can be changed per form. Therefore, a number of forms may be created with similar fields but with different access privileges to those fields based on the user's security role. Each of these forms can be assigned to a single or multiple security roles, thus restricting the form/field access to only the users with assigned security roles.

This is an alternative to setting up field-level security on a number of fields on the form. In the following example the "Vice President of Sales"
does not have write access to the "Winning Carrier," "Winning Carrier Rate," "Estimated Members," and "Estimated Contracts" fields; while "Vice President of Marketing" does have the write access. To make this happen create two forms, each having the fields mentioned above. In the form for "Vice President of Sales" mark these fields as read-only and assign the security role to the form as "Vice President of Sales." Whereas in the form for "Vice President of Marketing" leave these fields as writable and assign the security role to the form as "Vice President of Marketing."

Follow the screenshots for "How to make an attribute read-only on the form?" and "How to assign security roles?"

How to make an attribute read-only on the form?

Repeat this process for all the attributes required to be read-only.

How to assign security roles?

Repeat this process for each form for different security role/roles.

Related PowerObjects blogs:

Microsoft Dynamics CRM 2011 – Role Based Forms


Field-Level Security Out-of-box in Microsoft Dynamics CRM 2011


MSCRM 2011 just keeps getting better – if there is anything the MSCRM Experts and PowerObjects can do please reach out.

Happy CRM'ing

Microsoft Dynamics CRM 2011 - Role Based Forms

Another exciting new feature in CRM 2011, is the ability to have different forms for different security roles. For Example: You may want the Account form show different fields, for different security roles to maximize the important information that is displayed for each role.

Each Entity has two forms created by default: A "Main" Form and a "Mobile" Form. (Mobile Express)

By Default, the "Main" form is set so that all security rolls use this form whenever they access the Entity. However, with a few minor changes, additional Forms can be created to Rearrange/Add or Remove Information to maximize productivity for different users in CRM.

Let's take a look at the Account Form:

Let's say we would like to move some of the billing information to the top of the form for our Customer Service Reps and add a grid that shows all of the invoices related to the account record.

The first thing we want to do is make a "Copy" of the original form so that we don't have to start from scratch.

Double click the "Main" form, when it opens click "Save As", choose a Name and click Save.

Notice that our new Form is listed in the Form list

Customize the new Form:

  1. Drag and drop the Administration portion of the form to the top

  1. Click Insert and select Sub-Grid

  1. Choose what you want to display in your sub-grid

  1. Hit "OK", then save and close the form. Last but not least, we need to assign the security Role(s) to the form.

Highlight your new form, and click "Assign Security Roles"

Choose the "Customer Service Representative" and "CSR Manager" Roles and click OK.

All we have left is to publish the Account Entity! Our new Form is Live!

**NOTE: If a security role has not been specifically assigned to a Form, the default form for the entity will display for that user.

As always we are here and willing to help with all your Microsoft Dynamics CRM needs!

Happy CRM'ing!