Sonoma Partners Microsoft CRM and Salesforce Blog

CRM 2011 - Capturing Server SOAP Requests

Today's guest blogger is Bret Scarlavai, a Senior Developer at Sonoma Partners

I was troubleshooting an issue where a CRM 2011 plugin was receiving an error after performing a request on a SOAP endpoint.  The plugin logs were reporting a general “Error” but the details of the error were blank.  I wasn’t sure if the plugin was incorrectly displaying the details or if the SOAP response wasn’t providing them.

I didn’t want to figure out what version of the source to pull down, update with more debug logging, build and deploy to the server if I didn’t have to.  Instead, I decided to install Microsoft Network Monitor on the CRM server running the plugin to see if I could capture the SOAP responses without messing with the code.

After installing Network Monitor, I created a new capture and edited the capture’s settings so that only SOAP messages were monitored.

Create a new capture, then click Capture Settingsclip_image002[6]

Add a new filter to capture only SOAP messagesclip_image004

With the filter applied, I clicked the start button in Network Monitor and reproduced the issue within MSCRM.  Network Monitor proceeded to report the SOAP messages that occurred during the process and gave me the information I needed to determine where to troubleshoot next.

Captured SOAP messages including the response envelopeclip_image002[10]

Being able to capture network traffic of a particular server is very powerful and this is one way Network Monitor can be used to troubleshoot a variety of issues.

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2011

CRM 2011 – What was Imported?

Want a quick way to tell what solutions were imported into your org recently and what customizations they touched?  Thanks to my colleague Matt Dearing, you can use the following query against the importjob view to retrieve the solutions that have touched a specific entity.  This is helpful if you are seeing issues with an entity’s customizations but you aren’t sure what has changed. 

The example query below is checking with solutions have touched the Account entity ordered by the most recent.  Replace ‘account’ below with your entity in question.

select top(50) solutionname, progress, createdbyname, modifiedbyname, completedon, startedon, data, name 
from importjob
where data like '%id="account%'
order by completedon desc


Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2011

Microsoft Dynamics CRM SDK v5.0.16 Released

Last night Microsoft released v5.0.16 of the Microsoft Dynamics CRM 2011 SDK.  For the most part, the SDK contains small updates to the documentation but there were a couple small bug fixes.  Below are some of the notable updates included in this version.

  • First, there is an interesting amendment to a couple articles related to importing solutions.  A new note was added to say "Installing a solution can interfere with normal system operation. We recommend that you schedule solution imports when it’s least disruptive to users.".  This note is about 2 and a half years overdue. 
  • This article was updated with a note to say that showModalDialog and showModelessDialog should not be used on a CRM form.  The recommended method is to use Xrm.Utility.openEntityForm.
  • The very helpful topic What's Changing in the Next Major Release (which we blogged about yesterday) has been added to the SDK.
  • Lastly, a bug was fixed with get for openEntityForm to return a boolean, for whether the operation was successful or not, instead of the window object.  Take note that this fix could cause some issues if you have been expecting the window object to return.

For the full list of updates in this version, head here.

Orion is Coming – Be Prepared

Microsoft published a blog post last night about some new changes that the next major release of CRM is bringing.  An SDK article lists out several features that are being removed which can be found here.  In this post, I wanted to highlight three major changes as far as CRM development is concerned.

The first change is the removal of CRM 4.0 JavaScript Form Scripting support.  This change has been known about for awhile as the support no longer exists with UR 12 due to cross-browser capabilities.  Microsoft has provided a helpful tool to assist in identifying potential issues with JavaScript and HTML web resources.  The tool can be found here and for more information, check out this post we published in December

The second change I wanted to address is that Microsoft will be making major changes to the DOM due to the new enhanced UI.  Any JavaScript that modified the DOM will most likely break due to the new changes that are coming.  A popular scripting customization that could have issues would be modifying the color of fields or labels on the CRM form.  Another DOM manipulation I’ve seen a lot is turning a normal CRM text field into an option set for the sake of being able to make a custom multi-select option set.  These unsupported scripts would need to be upgraded or removed and tested thoroughly before upgrading to Orion.

The third major change is the removal of the 2007 endpoints as well as legacy features such as the ISV folder, 4.0 plug-ins and 4.0 workflow activities.  Luckily, Microsoft has provided a very useful tool to help identify any legacy features being used by your CRM environments.  The tool can be found here and it contains a “readme” file for instructions and more information. 

Note: Run the tool with the /? command-line argument to see the usage instructions.


I have used this tool personally and it is a huge time saver when trying to identify these legacy features.  In addition to the legacy tool, there are a great set of articles to help with upgrading your code -

The rest of the changes coming in Orion are as follows:

If you have any questions or are seeking help in upgrading your code, head to our Contact Us page and also let us know your thoughts about these changes in the comments section below!

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2011 Microsoft Dynamics CRM Online

MSCRM Scalable Security Modeling White Paper Released

Microsoft has just released a white paper on their security modeling features which you can get to from this link.  In this white paper Microsoft goes through in detail the different features within Dynamics CRM that allow users to drive security and different access levels to data with CRM.  It also talks about the implications associated with these features functioning at high volumes, and guidance on modeling Dynamics CRM for scale.

With all of the flexible security features that Microsoft offers, it’s very important to plan out your strategy for your security.  Security is one of the last things we see that is often overlooked in a lot of deployments but is one of the most critical pieces in a successful deployment.  You can build the most amazing custom solution, but if you haven’t thought out who will be accessing your system, how those users will access your system, and what permissions they’re going to need, then your project could be a failure.

Microsoft breaks down user access to Dynamics into two categories:

  • Authentication: Determining who the user is and confirming they are who they say they are
  • Authorization: Determining whether the authenticated user is entitled to access the system and what within the system they are permitted to see or do

The whitepaper goes into details about Authorization, and not Authentication, as Authentication can be handled by a variety of different technologies which have detailed documentation of their own.

The whitepaper discusses a few common business scenarios.  From this discussion, it’s easy to identify the different categories or levels of interacting with CRM data, and the different values of those interactions and what it means for dealing with your customers.  Categorizing your user access needs into these high level buckets is a first start to understanding and developing a security authorization strategy for your deployment.


Dynamics CRM Access Control Objects:

The different Access Control Options made available out of the box are discussed:

  • Sharing with Users / Teams
    • Sharing is a good option for exception cases but when your database size and number of records grow, this becomes an unmanageable solution. 
    • There’s also the concern of a performance impact if you have a lot of shared records in a large database, as each record that is shared, also gets a Sharing Record created increasing the size of your database.
    • Also pay attention to the Cascade settings as sharing a parent record could drastically increase the size of your database if the Sharing is cascaded down to child records.
    • Sharing with Teams reduces the overhead and increase in database size as sharing with one record, ends up sharing with all users in that team.
    • However, there is still a performance concern from the overhead associated with calculating access to each record.
    • The whitepaper discusses in length how Sharing is implemented in CRM and why you should carefully consider if Sharing should be used in your deployment or not.
  • Record Ownership (User / Team / Org / Business Unit)
    • Discusses the different types of ownership types per entity.
    • Team Ownership allows for ease of providing multiple people access to a set of records by adding or removing them from one team, versus sharing with each of the records.
  • Business Unit Privileges
    • Business Units are discussed including how setting up a solid hierarchy of your organization’s groups that will be accessing CRM is a key piece to planning out your security plan.
  • Organization Privileges
    • These are Organization Owned entities that users can either have access to or not. 
    • The granularity of security for User Owned entities do not apply here.
    • Performance benefits for Organization Owned entities exist as individual access checks are not required other than a user or team is allowed access to the record.
  • Field Level Security (Access Control to Fields)
    • If you cannot break out secure information into separate entities that you can lock down, Field Level Security would be required to lock down sensitive pieces of information in a record.

Scalability Characteristics of Dynamics CRM:

The white paper then discusses scalability characteristics of these CRM elements.  Instead of discussing details of each security model, the document goes into the approach used for each so that the scalability can be appreciated.

Dynamics CRM caches a lot of information to optimize the user experience and improve performance.  These include metadata, security roles / business units or a user, security role / business units of teams, and team membership.  This information is cached by each application server separately when the information is first requested.

It’s interesting to note that there are a couple things that could degrade performance and should be something to watch out for when you’re building out your solution:

  • Users are associated with a lot of teams
  • A large amount of users logging in at the same time
  • Frequently changing team membership
  • Frequently updating user details

The whitepaper says that performing the action in the last bullet above regarding updating user details forces the application servers’ caches to flush the user’s information with each update forcing it to be reloaded the next time it’s requested, which is an expensive process.

As discussed previously above, the white paper talks at length about the implementation of Sharing in Dynamics CRM, and the fact that you should carefully consider using it in high volume environments.  The document states that Team Ownership is a great alternative that users should consider instead of using Sharing extensively.  The table below details some of the implications of Team Ownership.


Just like anything else in the system, Business Units also succumb to the “too many could be a bad thing” theory.  Microsoft states that having too many business units (>1000) could have an impact on system performance.

Granular access to records (e.g., sharing) is more expensive in terms of performance compared with organization wide privileges (e.g., making entities Organization Owned).  However, all deployments we’ve worked with require at least some ability to define security at a granular level.  This white paper goes into details about where performance issues can come into play with overusing granular level access to records, and points out that if you can avoid it for some areas of your deployment, you should try to, as this will reduce the probability of running into performance issues down the road as the size of your environment grows.

The table below gives a good overview of the different security features offered by Dynamics CRM and their functionality:



The main takeaways I got from reading this whitepaper are:

  • Use Sharing sparingly and only in exception cases as it can be costly regarding performance – try to use team ownership instead
  • Keep the number of Business Units under 1000
  • Pay attention to the number of teams a user is associated with and keep this to a realistic number
  • Monitor the login pattern of your users as many logging in at the same time could impact overall scalability
  • Do not update user team membership frequently
  • Try not to update user details frequently

If you’re planning on rolling out a Dynamics CRM solution, this whitepaper is a must read.  It goes into great detail how each of the security features in CRM work and the implications of each in regards to scale and performance. 

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2011