[2015-05-04 12:15:10.459] Process:OUTLOOK |Organization:xxxxxxxx-4c42-435c-9cf4-xxxxxxxxxxxx |Thread: 30 |Category: Application.Outlook |User: 00000000-0000-0000-0000-000000000000 |Level: Error |ReqId: | ThreadsSupport.ExecuteThreadProc ilOffset = 0x2 at ThreadsSupport.ExecuteThreadProc(ThreadProc threadProc, IntPtr parameter) ilOffset = 0x2 > TraceException: Unhandled Exception: System.Runtime.InteropServices.COMException: Principal user (Id=xxxxxxxx-36fe-e311-803d-xxxxxxxxxxxx, type=8) is missing prvReadConvertRule privilege (Id=a51aa4b3-b0c3-4b81-a290-9ed4b0db8fb1) at Microsoft.Crm.Application.SMWrappers.CrmServiceForOutlook.Execute(OrganizationRequest request, Boolean wrapException) at Microsoft.Crm.Application.SMWrappers.EmailForOutlook.Microsoft.Crm.Application.SMWrappers.IEmailForOutlook.DeliverPromote(String messageId, String subject, String from, String to, String cc, String bcc, Double receivedon, String submittedBy, String importance, String body, IDynamicEntityCollectionForOutlook attachments, Int32 attachmentCount, IDynamicEntityForOutlook extraProperties, String entityXml, String regardingId, Int64 regardingObjectType, String crmId, Int32& notification)First clue is that it isn’t Read, Create, etc. on XXXXX entity. Have you heard of the prvReadConvertRule privilege? I hadn’t. At a minimum, I have something I can throw into my search engine of choice. Turns out this is a new feature with 2013 SP1 that didn’t cause any issues in CRM 2013 SP1 client, but does now with 2015. Worst case is that I have a trace and an error to send to Microsoft support. At this point, you should know that the user has a custom security role. First troubleshooting step for me will be to give an OOTB security role to that user and see if the issue persists, like Salesperson. This has all the “normal” albeit low-end rights. You can compare the OOTB role to your custom role and see where the differences are. Another more extreme example was a recent client upgrade from 4.0 all the way to CRM 2015. You see, CRM 4.0 didn’t have Server Side Sync, nor did CRM 2011, so when those custom roles are upgraded, they will miss out on some of the very basic permissions surrounding Server Side Sync. We encountered this with a client where through our Test and Enable of mailboxes in the system, we came across some interesting errors ONLY on the synchronization of Contacts, Appointments and Tasks testing, Incoming and Outgoing email tested just fine. Here are the errors (names changed to protect the innocent): So the one at 4:52 made us realize that we might need some additional rights and that a custom security role was in play. So we went looking to the Salesperson role and under Business Management section there is a Mailbox entity with User rights on Read, Write, and append. As the second test 2 minutes later showed, we were still not home. The problem is that error wasn’t nearly as helpful in its wording, so after doing a bit more review with Dustin Mathern, we found the Email Server Profile rights in the same section. Once we added those rights to the custom role, the errors ceased and we got a successful test. In summary, with all upgrades, we should be vigilant to review custom security roles and dare I say, we should create them again. Best practices always suggest that a copy of an existing OOTB security role be used. Take the time to discuss what the original intent of the custom role was, as it is possible that the need no longer exists. Using an OOTB role as a template will typically get you around the “hidden” permissions that existed in earlier versions of CRM. When dealing with custom security roles and strange errors, for testing purposes I always immediately suggest giving the Salesperson role as this is basic and has all the normal, albeit low-end, rights. If the error persists and you are in control of the testing situation, a higher bump in security role could also be done to further test.