Tag Archives: crm

PrincipalObjectAccess and double mailboxes

PrincipalObjectAccess table – The stuff that nightmares are made of ūüôā

Ok So first of all if you don’t know what PrincipalObjectAccess is (POA from now on), Go ahead and write it down in your favorite search engine, do some reading in the endless blog posts and articles available out there – and then get back here, as I’m going to assume that you already know what it is and how it works.

Think of the following scenario – You have 10 users in your Organization but want to use only 1 mailbox, and you want all the users to use the same email address and see the same emails in the system. Yes you should definitely use a Queue for this, but maybe you don’t feel like using a queue or just don’t know exactly how it works and how to set it up – and hey, the system does not prevent you from setting the same email address for multiple users, right‚Ķ?

So can you do it this way? Probably yes
Will it actually work? Likely it will
Is it a good idea? Nope

Here’s what will happen
** Obviously this is for demonstration only DO NOT DO THIS IN YOUR ENVIRONMENT **

Step 1: Assign 10 users the same email address. (I used a yahoo.com email for testing – feel free to spam my email address :))

Step 2: Create your server-side-sync profile and assign to the users, then activate, approve, test & enable all the mailboxes – Basically do all the steps you need to do for a mailbox to start working.

Step 3: Change all the user’s settings to automatically track all emails in the mailbox (the scenario would also work for emails in reply to CRM emails).

Step 4: Send an email to the newly crated mailbox and wait a few minutes.

Step 5: Check your POA table by running a query on your DB:

SELECT TOP 100 * FROM PrincipalObjectAccess
ORDER BY ChangedOn DESC

Results:
The email that entered the system receives a POA share record for every user that owns the email address. Not so great!

This is a small example of what will happen. I found it at a customer with more then 400 users that were assigned the same mailbox and something in between a few hundreds to thousand email threads – every day!
Needless to say that in this scenario their POA table grew at a rate of about 500,000 records per day.

This could definitely be causing additional side effects but I didn’t bother to check any further ūüôā

The fact that the system allows you to do things in a certain way does not always mean it’s a good practice, and if there is a mechanism built in the system to address a specific scenario – you should probably use it as there is a reason behind it.

If this post prevents from even one person setting up a system in this way – I’ve done my job ūüôā

Happy POA’ing

Michael

Step-By-Step Dynamics CRM 2015 Installation Guide

Hey everyone!

So I finally decided to create my very first video tutorial – it’s a basic & simple installation guide for Dynamics CRM 2015 ¬†on 2 servers and you can watch it on my YouTube channel

I hope you find this helpful & useful!

More stuff coming soon!

CRM 2013 Fetch XML reports not working

Here’s a¬†scenario:

You install a fresh deployment of Dynamics CRM 2013 on one server using a domain account as the CRMApppool in IIS and Microsoft SQL with SSRS on a second server РInstallation goes smoothly and everything works just fine including out-of-the-box reports Рexcept that when you try to create and run Fetch XML reports you get the following error:

“the report cannot be displayed. (rsprocessingaborted)”

Image


Here is what you need to do (The changes that we’ll make might cause CRM to be unavailable for short periods of time):

1. Check the identity of the CRMAppPool. To do this simply click Start -> Run -> type inetmgr -> Press Enter. Expand the server name and under application pools check the CRMAppPool identity.

Image


2. You need to register an SPN for this identity – Let’s assume that the identity is domain\crmservice and the CRM server name is just¬†crmserver.

Open CMD¬†with “run as administrator” and type the following commands one by one:

setspn -A HTTP/crmserver domain\crmservice

setspn -A HTTP/crmserver.domain.com domain\crmservice

Important notes:

  • In the second line you need to use your domain’s FQDN – domain.com is just an example.
  • I’m assuming that you installed CRM on port 80, if not or if you are using host headers you will need to create the proper SPN’s along with the port number – for example: ¬†setspn -A HTTP/crmserver:5555 domain\crmservice

You should get a confirmation that the SPN’s were registered successfully.


3. Browse to your SSRS URL (Probably: http://sqlserver/reports) and click ‘Details View’ on the right, then browse to:

YourOrganization_MSCRM > CustomReports > MSCRM_FetchDataSource – Inside make sure that the data type is set to ‘Microsoft Dynamics CRM Fetch’,¬†the connection string has your Organization Name and connect using is set to ‘Credentials supplied by the user running the report’

Image

Save & Close.


4. Do an IIS reset (should work without but just in case…) Open CRM and check your FetchXML reports – they should be working now – It’s very important to check everything locally on the CRM¬†server & remotely from clients or other server.


VERY IMPORTANT:

As we did changes in SPN’s that may mess up Kerberos authentication – you should check that CRM is available locally and from remote clients – If you are able to browse CRM locally (or using I.P) but you are getting 401 authentication error (after being asked for credentials 3-4 times) when trying to access from a different server or client using the CRM URL – do the following to resolve this:

  • On the CRM server open IIS and go to the¬†Microsoft Dynamics CRM website -> Open the Configuration Editor

Image

  • Under Section browse to the following location – system.webServer -> Security -> Authentication -> Windows Authentication

Image

  • Inside make sure that UseAppPoolCredentials is set to True:

Image

  • Do an IIS reset on the CRM server.¬†This procedure should resolve the 401 authentication issue and your CRM should be accessible from all clients along with the working FetchXML reports.

If from some reason your CRM started behaving “weird” or this process caused other issues you can revert all the changes we did by simply deleting the SPN’s and changing back UseAppPoolCredentials to False.

To delete the SPN’s use -D instead of -A:

setspn -D HTTP/crmserver domain\crmservice

setspn -D HTTP/crmserver.domain.com domain\crmservice

Remember that it’s best to do all those changes after¬†working hours, as some of them might cause CRM to be unavailable. Also if you have a testing environment – it’s always better to test¬†those things there before we do them on the production servers.

Good Luck!