CRM 2011 TO CRM 2013 Upgrade Process

CRM 2013Software and OS Components Support Changes

What software and operating systems will Microsoft Dynamics CRM 2013 support?

  • Microsoft Exchange Server 2013
  • Microsoft Outlook 2013
  • Active Directory Federation Services (AD FS) 2.2 (ships with Windows Server 2012 R2)

What software and operating systems will Microsoft Dynamics CRM 2013 no longer support?

  • The Microsoft Dynamics CRM for Outlook or the web application on Windows XP
  • Microsoft Office 2003
  • E-mail router will no longer support:
    • Microsoft Exchange Server 2003
    • Microsoft Exchange Server 2007 WebDAV protocol for email routing and tracking (Microsoft Exchange Server 2007 Exchange Web Services (EWS) will still be supported)

Preparing the CRM Organization for the Upgrade

CRM 2011 to CRM 2013 On-Premise Upgrade Preparation Tasks:

  • Determine if the current implementation of CRM 2011 is using any legacy features
  • Use the CRM 2013 Custom Code Validation Tool to examine web resources and determine where there could be potential upgrade issues.  If the custom validation tool does find any concerns, they will either be using deprecated CRM 4.0 objects and functions or an unsupported coding process.  For more information about the validation tool go to the following links:
  • Use the legacy feature check tool to detect any server extensions that use the 2007 endpoint or Microsoft Dynamics CRM 4.0 features.  For more information on legacy tool, go to the following link:
  • Determine the appropriate upgrade path
  • Take into the consideration the following when determining which upgrade path to follow:
    • Upgrading to CRM 2013 is a one way process
    • One cannot upgrade directly to CRM 2013 from CRM 4.0
    • One cannot rollback the server installation to CRM 2011 once the upgrade to CRM 2013 is complete
    • In order to upgrade to CRM 2013, the CRM 2011 Server must either be on Update Rollup 6 or Update Rollup 14 or a later rollup before an upgrade can be considered

CRM 2013 Organization DB Changes

The structure of the organization database is optimized to take advantage of the built-in capabilities of SQL Server. In order to achieve this optimization, restructuring of the CRM organization database is required.  This restructuring should be factored into the upgrade planning as it can take time to complete.  This restructuring process is known as a database or base extension “table merge”.

In Microsoft’s internal testing, after the table merge process was completed, the performance of CRM increased under a variety of workloads.  There was also a reduction in the number of SQL errors due to conflicts in accessing system data. Important aspects to note about the CRM organization database schema changes:

  • Data access through the filtered views is supported
  • Data access through direct SQL calls against the database tables is unsupported and therefore may not work after the upgrade
  • If data is inserted or updated into CRM through direct SQL against the tables, this method is unsupported and the code will need to be updated

So when should the table merge process be run?  Should it be run as part of the upgrade or after the upgrade process is completed?  The size of the CRM 2011 organization database is a determining factor on which approach to take. The following factors need to be considered with regards to the size of the CRM 2011 organization database and the table merge process:

  1. If the organization database has very large tables than one can choose to defer the restructuring of the database until after the upgrade. For example, if the organization database is 70-GB then the database table merge process could take several hours. By deferring the merge process the upgrade process could finish in approximately two hours and the system can be returned to a usable state. Potentially during nightly maintenance windows, one can merge the organization, one entity or more at a time until the all the base and extension tables are merged.
  2. During the upgrade process when a full merge is done the process will require approximately two times the size of the current database for the lifecycle of the merge. So if one chooses to do the table merge process as part of the upgrade and if the organization DB size is 20-GB, then approximately 40-GB will be needed for the upgrade.

In order to determine the right approach is, it is highly recommended to upgrade a copy of the CRM 2011 organization on a test environment prior to performing the upgrade on the production environment.  As part of the upgrade process, there is a report and information in the log for the table marge process to help make the decision.

Upgrade Paths

The following tasks pertains to both the migration and in-place upgrade methods:

  1. Verify that the CRM Server and organizations are patched up all the way to Update Rollup 14 (if part update rollup 6 already) and that all the functionality in the application is working correctly. Note: Upgrading from CRM 2011 to CRM 2013 is supported from either update rollup 6 or update rollup 14. Microsoft recommends that all deployments of CRM 2011 be upgraded to Update Rollup 14 before upgrading to CRM 2013.  The option of upgrading from Update Rollup 6  is meant to support a step-through upgrade from CRM 4.0.
  2. The CRM 2013 product key must be obtained before the upgrade process begins as the key is required to run the upgrade process.

Regardless of which upgrade part is chosen, the following are the stages of the upgrade process:

  1. Database Base and Extension Table Merge (this stage can either be run at the time of upgrade or later using a merge tool on a per entity basis).
  2. The server and organization update.
  3. Solutions update
    • Solutions will be converted to a new format
    • Solution will be upgraded to CRM 2013 forms and data engine
    • Unmanaged and managed solution will be supported
  4. The forms will be updated to the new CRM 2013 format.

Migration Method

(this is the option recommended by Microsoft):

  • Provides the ability to fallback to an existing CRM 2011 deployment as this method requires additional hardware for the CRM 2013 upgrade
  • This method allows upgrading to CRM 2013 without affecting the existing CRM 2011 deployment

Migration Method Steps:

  1. Server infrastructure for the CRM 2013 deployment needs to be setup. You can obtain further information regarding the minimum requirements of a deployment in the “Microsoft Dynamics CRM 2013 system requirements and required technologies” section of the Microsoft Dynamics CRM 2013 Implementation Guide.  This guide can be obtained from the following site:
  2. Regarding Microsoft SQL Server, ensure that the new CRM 2013 environment is at or above the version and patch level of the existing CRM 2011 SQL Server deployment. Doing this will allow for restoring a backup to the new CRM 2013 environment.
  3. Perform the CRM 2013 installation. The new CRM 2013 deployment will be setup and the base organizations will be configured.
  4. Confirm that the CRM server is working correctly with the newly created CRM 2013 organization.
  5. Open the deployment manager in the source deployment (CRM 2011 Deployment), and validate that the organizations are updated to UR14. Important: CRM 2013 will import organizations that are only on Update Rollup 6, Update Rollup 14 or an update rollup later than UR14 for CRM 2011 release. The CRM 2011 organization must be patched with a valid update rollup before doing the migration upgrade:
  6. Organizations that have Update Rollup 6 will have this version number: 05.00.9690.1992
  7. Organizations that have Update Rollup 14 will have this version number: 05.00.9690.3557
  8. Using SQL Server backup in the source CRM 2011 deployment, backup the organizations that need to be migrated to CRM 2013. Back up the organization database, which will have a name like <YOURORGNAME>_MSCRM. Ensure a full back up of the organization database is taken.
  9. Restore the backups from the CRM 2011 environment to the CRM 2013 environment (SQL Server).

Important: If the decision has been made to defer the database table merge process, registry keys need to be added to the deployment server. This must be done prior to running the upgrade process.

  1. Open the deployment manager and choose Import organization in the new environment. The import organization process will start, which will import and then upgrade the CRM 2011 organization to CRM 2013.
  2. Confirm that things are working as expected after the import is complete, by going to the organization in a web browser.

In-Place Method:

  • This method is utilized when upgrading the existing CRM server is a requirement
  • While this method provide the easiest and simplest path to upgrade. The following should be considered:
    • Falling back to CRM 2011 is not an option without reinstalling the CRM 2011 server
    • If the upgrade fails, the CRM server or organization will not be accessible until the error is cleared or the server is restored from a backup

In-Place Method Steps:

  1. First, backup the deployment database and organization databases.
  2. Determine that the environment meets the minimum requirements for CRM 2013. Review the “Microsoft Dynamics CRM 2013 system requirements and required technologies” section of the Microsoft Dynamics CRM 2013 Implementation Guide.
  3. Uninstall the Microsoft Dynamics CRM Connector for Microsoft SQL Server Reporting Services. This is necessary as the upgrade process cannot upgrade the CRM Connector for SQL Server Reporting Services.
  4. Proceed with the CRM 2013 Server setup process.
  5. If the CRM deployment has more than one organization, then use the deployment manager, to upgrade any remaining organizations. During upgrade, you can upgrade one or none of the organizations in CRM.

CRM 2013 Business Process Flows

With the release of the RTM version of CRM 2013 on the near horizon, there are many exciting new features to look forward to:

  • A new command bar to replace the ribbon in CRM 2011
  • A flat user interface to replace the pop-up windows in CRM 2011
  • Auto-save functionality that saves a record that the user is working on every 30 seconds
  • Quick create forms which allow a user to complete a subset of fields required to create a record

To learn more about these new features, click on the following link: http://blog.dynamicscrm2013.com/.

While there are many new features to be released with CRM 2013, the one in particular I would like to elaborate on in this article is called Business Process Flow.

The business processes functionality was first released in the Polaris release of CRM 2011 (December 2012 Update of Microsoft Dynamics CRM Online).  However, at that time the business process functionality was limited to the lead, opportunity, and case entities. In CRM 2013, this limitation does not exist. Therefore:

  • Processes can be created for any entity
  • Processes can be created across entities including custom entities. For example, turning an opportunity into a quote, order or invoice. In addition, multiple processes can be created for the same record type and made available to users through security roles
  • Multiple processes can be created per entity and one can switch between each process in a record

So what are the basic steps to create a business process flow?

  • The first step is to enable the business process flow functionality for an entity, if it is a custom entity.  If it is an out of the box entity, the business process flow functionality will be automatically enabled:

post 2 image 1

  • When the business process flow functionality is enabled on a custom entity, the following two fields will automatically be created.  The ‘ProcessId’ signifies the ID of the process associated with a particular record whereas ‘StageId’ signifies the ID of the current stage of a particular record in the process.

post 2 image 2

  • To create a business process flow, proceed to Settings>Processes and click on ‘New’ to create a business process flow. Two new categories are available for selection in CRM 2013:post 2 image 3
  • In this case, select ‘Business Process flow’ and then select the entity, the process needs to be created for

post 2 image 4

  • Next, add stages and steps to the process flow:

post 2 image 5

  • Multiple stages can be added in the process flow and multiple steps can be added in each stage.  The required flag can be used to tollgate a stage to ensure that one cannot move to next stage without completing the required step.  A business process flow can include multiple entities by clicking on the Options buttonpost 2 image 6

The following are examples of out of the box business flow processes:

post 2 image 7

post 2 image 8post 2 image 9

Additional features of Business Process Flows

Switching: Multiple business flow processes can be created per entity and as such one can switch from one process to another in a particular record using the post 2 image 10 option available under the ellipsis in the record menu command bar. Selecting the ‘Switch Process’ option opens up a ‘Select Business Process Flow’ dialog like the example below.  Select the process you would like to switch to and the record will be refreshed with the new selected process.

post 2 image 11

Process Editing: The process that is currently selected in the record can be edited directly from the record using the post 2 image 12 option available under the ellipsis in the record menu command bar.  However, please note that in order to edit the business flow process, one must have the appropriate privileges in his/her security role(s).

Role-Based: Business Process Flows are role-based, which means different processes can be designed for different job designations. Roles can be assigned to processes through the ‘Enable Security Roles Option’:

post 2 image 13

Now that the end user can design business process flow, Microsoft Dynamics CRM 2013 will really provide a process driven user interface.

Daily Matching and Merging of Guest Data to Make the Guest Unique

In the hospitality industry, storing information about guests and their stays is critical to tailoring offers to each guest. Information regarding the guest and the stay is stored in a system called the property management system at the hotel franchise’s corporate headquarters.  The property management system stores information for each guest such as: (This is a sample list of attributes, not a complete list):

  • Prefix (Mr., Mrs., Miss, Dr., etc.)
  • Full name • Company name
  • Physical address
  • One or more e-mail addresses
  • One or more telephone numbers
  • Gender

The property management system stores information such as the following for each reservation that a guest makes (this is a sample list of attributes, not a complete list):

  • Booked date
  • Arrival date
  • Departure date
  • Folio status (booked, checked-in, checked-out, cancelled, no show, etc.)
  • Property where the guest will stay
  • How the reservation was made
  • Promotion response code (this is the code that is captured if the reservation was made after receiving promotional e-mail such as providing a discount if a reservation is booked in the next 5 days)
  • Room type booked
  • Length of stay
  • Method of payment
  • Was the reservation an advance purchase

Property management systems can be setup with centralized or decentralized data storage architecture. Let’s discuss what each of these means to storing guest profile and stay data.

Centralized PMS Data Repository:

With this type of storage architecture, all of the guest profile and guest stay data is stored in one location. Therefore, the franchise properties for a particular franchise will access all of the guest profile and stay data from a single location. What does this mean? It means that this system:

  • Reduces the amount of duplicate data entered as searching for a guest can be done against a single source
  • Records all guest stay data to a single guest profile record
  • Eliminates the need to cleanse the data by a data processing company

Decentralized PMS Data Repository:

With this type of storage architecture, the guest profile and guest stay data is stored in multiple locations. Each franchise property has its own storage and the data from each of these sources of rolls up to a single storage located at the franchise headquarters. This type of operating environment makes it very difficult to provide for the daily matching and merging of guest data to make guest data unique. Therefore, there is a definite need to cleanse the data and remove the duplicates by a data processing company. This can be done on a daily, weekly, or monthly basis.  However, frequent cleansing may not be very cost effective. So, what are potential causes for the duplicated data?:

  • There is no central database of guest profile data
  • There is no visibility into guest stays at other properties
  • Lack of a single unique identifier for the guest

While there are three main causes for duplicate data, there are also guest data anomalies/concerns that can contribute to the duplicate and inaccurate data. Here are some of the anomalies/concerns:

  • Guest data inconsistently entered across properties
  • Guest data from external sources (Hotwire, Priceline, etc.)
    • Not providing guest personal data (i.e. generic address, generic email)
  • Administrators at a company may be making the reservations for a group of people with different names and email addresses
    • Front desk staff are not updating the correct guest profile information
  • Data quality issues:
    • Guest name example: first name was blank and last name was Hotel Beds (Wholesale reservation channel)
    • Incorrect guest address, which impacts guest match rate
    • Email address of hotel property entered instead of that of the guest, with insufficient guest profile information
  • Operational Data Collection Issues:
    • The field ‘Email’ is not required to be completed
    •  Mobile phone numbers are not in PMS with proper masking and numeric fields
  • Guest data cleanup initiative is required

As one can see, a decentralized PMS architecture tends to have challenges around the uniqueness of guest profile data. The rest of this blog will focus on processes surrounding how to make a guest unique in an operating environment that has a decentralized PMS system.

The following section depicts an example solution created with Microsoft Dynamics CRM 2011 on making a guest unique in a decentralized PMS environment.  This solution includes the following components and processes:

  • PMS Database Tables: these are the tables in the PMS System that store the guest profile information such as name, address, e-mail, etc. and the reservations made by each guest
  • Guest Profile:
    • Definition: this is the record in CRM that stores basic information about the user and is a cumulative rollup of certain guest stay information
    • The basic information stored is:
      • First name
      • Last name
      • Physical address
      • Zip code
      • Telephone number(s)
      • E-mail address(s)
      • Opt-in
      • Gender
    • The cumulative rollup information stored is the following:
      • What was the method used to book the last reservation?
      • What is the frequent method of booking reservations?
      • What is the total room nights stayed across all reservations?
      • What is the total sum of revenue spent?
      • What is the total number of stays?
      • What was the last date stayed?
      • Is the guest in-house or does he/she have a pending reservation?
      • What was the average daily rate paid by the guest?
      • What is the average length of stay?
  • Guest Stay:
    • Definition: this is the record in CRM that stores information about each guest stay. A guest stay record is created anytime a guest books a reservation at a particular franchise property.  Therefore multiple guest stays can be associated to a single guest profile record
    • The information captured on the guest stay form is:
      • The date the reservation was booked
      • The date the guest plans on arriving
      • The date the guest plans on departing
      • The franchise property where the guest will be staying
      • The folio status (booked, checked-in, checked-out, cancelled, no show, etc.)
      • The type of room booked
      • The average daily rate for each particular stay
      • The length of stay for each particular stay
      • The method of payment used to book the reservation
      • Was the reservation an advance purchase?
  • Now that we know what the components are, lets discuss how these components are used in the following three processes:
    • Daily loading
    • Cleansing
    • Reconciliation

Figure 1: Guest Data LifeCycle

guest data 5-20-13

 Daily Loading Process:

The first process we will discuss is the daily loading of the reservations. For each reservation loaded into Dynamics CRM, a guest profile record is created and a corresponding guest stay record is created which is associated to the guest profile record.  For example, if John Smith makes two reservations (regardless of the reservation channel) for two rooms, he will have two guest profile records and two guest stay records in the PMS. Each guest stay record will be associated to one guest profile record.  Since the data is stored in this manner in the PMS, it is loaded from the PMS into Dynamics CRM in the same way. This means that every time a guest makes a reservation, there will be a guest profile record and an associated guest stay record created for each reservation, even if the guest stays multiple times in a short period such as a month at a franchise property. This is referred to as un-cleansed data.

Cleansing Process:

On a regularly scheduled basis, such as a weekly or monthly period, the guest profile data from the PMS is compiled into a file and sent to a data processing company. The data processing company reviews for duplicates based on the following criteria:

  • First name
  • Last name
  • E-mail address
  • Physical address:
    • Street 1
    • Street 2
    • City
    • State
    • Zip code

Reconciliation process:

(this can be weekly or monthly basis. For this discussion the reconciliation process will be monthly at the end of each month)

  • Step 1: Once the duplicate records are removed, and the cleansed file is returned, the new guest profile data is loaded into a staging database and in this database all the cleansed guest profile records are associated to their guest stay records. For example, a file containing un-cleansed guest profile records for the entire month of January was sent to the data processing company.  If there were two John Smith’s in the un-cleansed file, and then based on the above criteria, the two matching records will be compared and the one that has the most completed information would be kept.  With the returned cleansed file containing only the one John Smith guest profile, the next step is to associate all the guest stays that John Smith had for the month of January to his cleansed guest profile record.  For example, if John Smith stayed five times in the month of January, then all five stay records would now be associated with his cleansed guest profile record.
    In a nutshell when the un-cleansed file is sent to the data processing company at the end of each month it, the data being cleansed is for the month that just ended. Once the cleansed file is returned with unique guests for the month, then the guest stays for the each of those guests for that particular month is associated to each unique guest profile record.
  • Step 2: Once step 1 is completed, then the identified unique guest profiles with their associated guest stays for the previous month are loaded into Dynamics CRM 2011.  This is performed in two separate steps:
    • First the unique guest profiles are loaded
    • Then the guests’ stays are loaded and associated to the guest profile records
  • Step 3: Once step 2 is completed, then the un-cleansed guest profile and guest stay data loaded in the previous month is purged. This process will only delete all the un-cleansed guest profile and guest stay data. The cleansed guest profile and guest stay data will remain in Dynamics CRM permanently.

As one can see, when a PMS has a decentralized storage architecture, there are some processes that need to be put in place to make a guest unique.

Trigger Based Marketing with Dynamics CRM 2011

INTRODUCTION

Creating and maintaining profitable customers is the main aim of business. Therefore, customer satisfaction leading to profit is the central goal of hospitality marketing. In the hospitality industry, the marketing department tends to be responsible for both Business-to-Consumer (B2C) and Business-to-Business (B2B) marketing.  The marketing team needs detailed data on prior leisure and business guests to successfully target marketing campaigns to the appropriate audiences.

The main purpose of this article is to discuss B2C marketing and in particular a process called Trigger based Marketing in Microsoft Dynamics 2011.

What is trigger based marketing?  For the purposes of this article, trigger based marketing is defined as consumer profile or stay data meeting the criteria of a marketing list for an active campaign. This active campaign then processes an e-mail blast to the recipients of the marketing list on a scheduled and automated basis.

BUSINESS PROCESS REQUIREMENTS

Assume the requirement is to create a process that allows for the automation of trigger based campaigns which, in this case, means guest satisfying particular marketing criteria.  This requirement of automating trigger based campaigns is dependent on daily matching and merging of guest data to make the guest unique (the process of ensuring a guest is unique will be discussed in a separate blog). The following are potential trigger based campaigns:

  • Driven by check-ins – “Welcome”
  • Driven by check-outs – “Thanks for Staying”
  • Reactivation
    • “We miss you!”
    • Requires guest stay history
  • In-house guest campaigns
    • Loyalty related
    • Requires guest stay history

So, the next question becomes, “Once the triggered campaign requirement is satisfied how does the e-mail blast execute on a scheduled basis?” To satisfy this requirement a third party marketing integration product such as ExactTarget, CoreMotives, or ClickDimensions can be used.  These are just some third party marketing integration products for CRM 2011, there are additional products out there.  Most of these third party marketing add-ons tend to have Application Programming Interfaces (APIs) available that can be programmed. In this particular instance, ExactTarget and the ExactTarget API were used to achieve the requirement of executing the e-mail blast on a determined schedule.

PROCESSES DEVELOPED TO ACHIEVE REQUIREMENTS

The processes developed contain a combination of manual and automated processes to complete the triggered e-mail process.

Manual Processes

  • STEP 1: Marketer contacts advertising company to create art design
  • STEP 2: Approved art design is converted to HTML format
  • STEP 3: Receives completed HTML
  • STEP 4: Prepare website for marketing campaign with website design company
  • STEP 5: Create an e-mail for each triggered e-mail process in ExactTarget
  • STEP 6: Create a dynamic marketing list for each triggered e-mail scenario
  • STEP 7: Create a campaign for each triggered e-mail scenario
  • STEP 8: Create an ExactTarget automated send record for each triggered e-mail scenario
  • STEP 9: Create an application configuration record for each triggered campaign

Automated Processes

  • STEP 10: Custom application runs at a schedule time on a nightly basis and performs a lookup against active campaign configuration records.  Deactivated campaign configuration records will not be executed against.  While this application will run on a nightly basis by default, it will use the configuration record for each active triggered campaign to determine the appropriate schedule (daily, weekly, monthly) it needs to run at for the automated campaigns. For daily processing, the custom application will run every night at a given time.  For weekly processing, the custom application will check the day of each week of the current day and compare it to the list of days of the week selected in the configuration record. If the current day of the week matches any of the selected days of the week in the configuration record, it will run.  For monthly processing, the custom application will run on the date selected on the configuration record. Therefore, the custom application will run on the exact same day each month. The custom application is setup and scheduled using the windows task scheduler.
  • STEP 11a: Create a copy of the dynamic marketing list as a static list
  • STEP 11b: Compare the new static list created in the step above to the static control group list and removes the contacts matching in both lists from the static marketing list, which is then used as the list to process the e-mail blast
  • STEP 11c: Create a recipient record for each daily email blast and then the recipient record will be associated to the marketing list attached to the campaign
  • STEP 11d: Associate the recipient records to the appropriate send record designated for each campaign
  • STEP 12: Results from the email blasts will be processed as ExactTarget response activity type records directly into CRM against the guest profile record

metesh email process graphicCONCLUSION

In conclusion, while this is only one solution of meeting a requirement to process triggered campaigns using Dynamics CRM 2011 and ExactTarget,  other solutions can be created using Dynamics CRM 2011 and other third party marketing integration products.

How to Optimize Microsoft Dynamics CRM 2011 Applications (Part 3)

In Part 1, I highlighted changes to improve performance for the Microsoft Dynamics CRM Web Application. Part 2 focused on performance improvements for CRM customizations. In this blog, I will highlight changes to improve performance for the following:

  • Microsoft Dynamics CRM SDK Applications and
  • Microsoft Dynamics Reporting Services.

Microsoft Dynamics CRM SDK Applications

It is imperative to ensure the optimal performance of any custom applications, plug-ins, or add-ins developed using the Microsoft Dynamics CRM 2011 SDK.

A precise recommendation for any custom application is to limit any columns and rows retrieved to those required to achieve the application’s business goals. This technique is particularly significant when CRM users access the data from a Wide Area Network (WAN) with higher network latencies. The data returned by custom applications can be limited:

  • when using ‘Condition’ attributes to restrict the data that the ‘FetchXML’ and ‘ConditionExpressions’ queries return,  and
  • When using paging to restrict the number of rows returned by a custom application.

NOTE: For Microsoft Dynamics CRM deployments that are integrated with other systems, test custom applications in an environment similar to the complexity and integration present in the production environment. Another thing to keep in mind is that performance results may vary if the database on the test system is not of similar size and structure to that in the production environment.

Microsoft Dynamics CRM Reporting Services

There are a variety of factors that can affect report server performance:

  • hardware,
  • number of concurrent users accessing reports,
  • the amount of data in a report, and
  • output format.

Organizations that have smaller data sets and a smaller amount of users can deploy on a single server or on two servers, with one computer running Microsoft Dynamics CRM Server 2011 and the other computer running Microsoft SQL Server and SQL Server Reporting Services.  Performance will be affected with larger datasets, more users, or heavier loads.  Optimizing reporting services would be required, if it is noted that the usage for reports has increased.

Consider these guidelines when optimizing Microsoft Dynamics CRM 2011 Reporting Services:

  • Ensure that the computer hosting the report server includes ample memory as report processing and rendering are memory intensive operations.
  • Host the report server and the report server database on separate computers instead of hosting both on a single high-end computer.
  • When there are signs of all reports processing slowly, contemplate a scaled-out deployment with multiple report server instances. For best results consider using load balancing software and hardware to allocate requests evenly across multiple report servers in the deployment.
  • If only one report is processing slowly, tune the query if the report must run on demand.  Consider caching the report or running it as a snapshot as well.
  • Consider the following if all reports process slowly in a specific format (for example, while rendering to PDF):
    • File share delivery;
    • Adding more memory;
    • Using another format (Excel, CSV, etc)

How to Optimize Microsoft Dynamics CRM 2011 Applications (Part 2)

In this blog, I will highlight changes to improve performance for Microsoft Dynamics CRM Customizations. Additional blogs will follow highlighting performance improvements to custom Microsoft Dynamics CRM SDK applications and Microsoft Dynamics CRM Reporting Services.

Microsoft Dynamics CRM Customizations Optimization

The following are guidelines to keep in mind when optimizing the performance of Microsoft Dynamics CRM customizations:

  • Carefully consider the possible effects on your organization’s business before removing or changing the order of records returned by a saved query. There may be important business reasons associated with the order of display in query results. If there are business reasons for changing, consider adding an index based on the new ordering to improve the performance of the query.
  • Use an iterative process to define which index best optimizes query performance. Test each index using a variety of selection criteria that may be common for the specific query. While one set of criteria may provide the projected performance increase from an index, different criteria may have no effect.

Consider these potential optimization techniques:

Disabling Auto-Complete on Lookups:

The Auto-Complete on Lookups functionality is enabled by default and while it can help to increase user efficiency, it can also affect overall performance and resource usage in a deployment of Microsoft Dynamics CRM 2011.  For optimal performance, consider disabling this functionality:

  • STEP 1: Log into Microsoft Dynamics CRM 2011 with a user that has a security role allowed to customize entities.
  • STEP 2: Proceed to Settings > Customize the System > Components > Entities > Entity >Forms.  In this case entity signifies the name of the entity to be modified and forms presents selecting the form that includes the field that needs to be modified.
  • STEP 3: Once in ‘Form Design’ view, find the field for which Auto-Complete is configured and then select ‘Change Properties’.
  • STEP 4: Once the ‘Field Properties’ window has appeared, proceed to the ‘Display’ tab and under ‘Field Behavior’ mark the check box to ‘Turn off Automatic Resolutions’ and select ‘OK’.
  • STEP 5: Repeat this process on each Entity/Field combination where the auto-complete feature needs to be disabled.

Querying on Custom Entities:

When adding custom attributes to the Microsoft Dynamics CRM system or custom entities, the columns for those attributes are included in an extension table in the SQL Server database instead of the entity’s base table.

When considering performance optimization of queries on custom entities, confirm that all columns on the ‘Order By’ clause derive from a single table, and create an index that satisfies the ‘Order By’ requirements and as much of the queries ‘WHERE’ clause selection criteria as possible. The process of creating the appropriate index will be iterative, however the performance benefits can be significant if implemented correctly.

To learn more about Edgewater’s CRM practice, click here.

Image courtesy of xkcd.com

How to Optimize Microsoft Dynamics CRM 2011 Applications (Part 1)

When considering optimal performance for Microsoft Dynamics CRM 2011, the following areas require attention:

  1. Microsoft Dynamics CRM Web Application
  2. Microsoft Dynamics CRM Customizations
  3. Custom Microsoft Dynamics CRM SDK Applications
  4. Microsoft Dynamics Reporting Services

In this blog, I will highlight changes to improve performance for the Microsoft Dynamics CRM Web Application.  Additional blogs will follow highlighting areas two, three and four.

Microsoft Dynamics CRM Web Application Optimization

The following are some simple changes to the out of the box configuration of Microsoft Dynamics CRM:

Setting the Default Views:

When starting Microsoft Dynamics CRM, viewing all records for an entity can be resource intensive, particularly as the size of the database increases. In order to improve system performance, the default views should be customized to limit the records that are displayed. For example, to see the default view for Contacts (assuming changes are made to the default solution):

  • STEP 1: On the Microsoft Dynamics CRM home page,
    • Select ‘Settings’;
    • Then under ‘Customization’, click ‘Customizations’;
    • Select ‘Customize the System’;
  • STEP 2: In the Solution window, under Components,
    • Select ‘Entities’;
    • Then select ‘Contact’;
    • Finally select Views;

NOTE: In the list of available views, the entry for the current default view is marked with a star. It displays as Default Public View.

  • STEP 3: Select the different view you that you want to set as default, then on the action toolbar,
    • Select ‘More Actions’;
    • Then select ‘Set Default’;
  • STEP 4: To save and publish the configuration changes, select ‘Publish All Customizations’ or under the Contact entity select ‘Publish’.

Quick Find Views (Limiting Search Columns):

The quantity of fields that are searched to display quick find results can directly affect performance.  For optimal performance, the quick find feature per entity should only be configured to search the fields that address specified business requirements. The following steps explain how to customize the ‘Quick Find’ feature (assuming changes are made to the default solution):

  • STEP 1: On the Microsoft Dynamics CRM home page,
    • Select ‘Settings’;
    • Then under ‘Customization’, click ‘Customizations’;
    • Select ‘Customize the System’;
  • STEP 2: In the Solution window, under Components,
    • Select ‘Entities’;
    • Then select the entity for the ‘Quick Find’ view needs to be customized;
    • Finally select Views;
  • STEP 3: In the list of views
    • Select the ‘Quick Find’ view;
    • Then on the action toolbar select ‘More Actions’;
    • Then select ‘Edit’;
  • STEP 4: In the ‘Quick Find’ view
    • Select ‘Add Find Columns’ located under ‘Common Tasks;
  • STEP 5: Select the fields that will be searched to provide Quick results and then select ‘Ok’.
  • STEP 6: Select ‘Save and Close’ in the ‘Quick Find’ window and then to save and publish the configuration changes, select ‘Publish All Customizations’ or under the selected entity select ‘Publish’.

If quick find results are slow to return with the simple changes described above, then database optimization techniques and tools should be leveraged with consideration to the following aspects:

  • The more columns included in a search, the longer the search will take.
  • Fields included in a search should be leading columns in indexes, even if this means creating one for each field. Also consider including in those indexes the Owner, BU, and the State fields, which are typically included in the query.
  • The use of filtered indexes can result in better query performance.

Best Practices:

The following are best practices to contemplate when considering optimal performance of CRM 2011:

  • Team Functionality: Teams can own records (objects) and records can be shared to teams thereby allowing members of that team access to the shared records.  Leveraging the enhanced team’s functionality should be considered as opposed to a complex business hierarchy because teams will provide better performance with a lesser drawback for security checks.
  • Field Level Security (FLS) Functionality: Field Level Security provides more granular control over the data that specified users can or cannot create, update or view. While FLS is a great feature to use the more comprehensively it is used in an implementation, the greater the impact on performance.

To learn more about Edgewater’s Microsoft Dynamics expertise visit www.fullscope.com

What happens when tracked records are removed between Outlook and Dynamics CRM?

Here is a small summary describing what occurs when records tracked between Outlook and Dynamics CRM are removed regardless of whether it is removed from Outlook or Dynamics CRM.

Deletions through Microsoft Dynamics CRM:

Type of Record

Dynamics CRM

Microsoft Outlook

Emails

Deleted*

Email Stays

Active(Open) Appointments

Deleted*

When the appointment is deleted in CRM, it is deleted in outlook for all users if the appointment start time is in the future.

Canceled/Completed Appointments

Deleted*

Appointment Stays

Active (Open) Tasks

Deleted*

Deleted as well

Cancelled/Completed Tasks

Deleted*

Task Stays

Contacts

Deleted*

The contact is deleted for all users except the record owner

Deletions through Outlook:

Type of Record

Microsoft Outlook

Dynamics CRM

Emails

Deleted

Email Stays

Active(Open) Appointments

Deleted

Will be Deleted* when done by Organizer. However the appointment will still remain in Dynamics CRM if deleted from one of the Attendees Outlook

Canceled/Completed Appointments

Deleted

Appointment Stays

Active (Open) Tasks

Deleted

Deleted* as well

Cancelled/Completed Tasks

Deleted

Task Stays

Contacts

Deleted

Contact Stays and will synchronize back to record owner’s Outlook when modified in the future.

Deleted* means the ‘Delete’ permission has been granted in one of the user’s security roles and this allows for the removal of CRM records.

Optimizing and Maintaining the Microsoft Dynamics CRM 2011 Outlook Client

Access to Microsoft Dynamics CRM is available in one of three ways:

  1. The Microsoft Dynamics CRM web client leverages Internet Explorer versions 7 through 9 as a browser to provide access to Microsoft Dynamics CRM functionality without requiring the install of any type of client software on the user’s computer.  In the very near future CRM will be supporting multiple browsers.
  2. The Microsoft Dynamics CRM 2011 for Microsoft Office Outlook client provides a familiar experience to the user since it is highly integrated with Outlook. This version of the client also provides offline access as a second configuration option, allowing users to go offline with synchronized Microsoft Dynamics CRM data.
  3. Users can also connect to an implementation of Microsoft Dynamics CRM from an Internet-enabled mobile device, such as a cell phone, tablet, by using the Mobile Express client, which provides access via a lightweight version of the Microsoft Dynamics CRM web client.  In the very near future CRM will be supporting a variety of mobile devices.

This article will focus on optimizing and maintaining the performance of the Microsoft Dynamics CRM 2011 Outlook client.

The major factors that can affect Microsoft Dynamics CRM 2011 client Outlook performance:

  1. Processes and applications running on the client computer
  2. Type of hardware on the client computer
  3. Version of software on the client computer
  4. Network characteristics
  5. Complexity of customizations
  6. Microsoft Dynamics CRM Outlook client configurations

1. BUSINESS Processes and Applications

Some Antivirus applications can cause performance issues with web based applications such as Microsoft Dynamics CRM, particularly those that scan webpages for malicious JavaScript. In cases like this, adding the URL of the Microsoft Dynamics CRM organization to the list of excluded web sites can improve performance. Also removing the CRM file directory from being scanned can improve performance.  Prior to removing web sites and files from being scanned considerate decisions need to be made on what needs to be included and excluded so that there are no undesirable consequences.

Where ever possible turn off non-critical business processes, music/video streaming, gaming software and third party add-ins for Outlook that are not needed to accelerate performance.

2. Hardware Requirements

Component *Minimum *Recommended
Processor (32-bit) 750-MHz CPU, or comparable Multi-core 1.8-GHz CPU or higher
Processor (64-bit) x64 architecture or compatible 1.5 GHz processor Multi-core x64 architecture 2 GHz CPU or higher such as AMD Opteron or Intel Xeon systems
Memory 2 GB RAM 4 GB RAM or more
Hard disk 1.5 GB of available hard disk space 2 GB of available hard disk space
Display Super VGA with a resolution of 1024×768 Super VGA with a resolution higher than 1024×768

* Actual requirements and product functionality may vary based on your system configuration and operating system.

3. Software Requirements

Microsoft Dynamics CRM for Outlook software component prerequisites

The following components must be installed and running on the computer before you run Microsoft Dynamics CRM for Outlook setup:

  • The following versions of Internet Explorer
    • Internet Explorer 7
    • Internet Explorer 8
    • Internet Explorer 9
  • The following versions of Microsoft Office
    • Microsoft Office 2003 with SP3 or later version
    • Microsoft Office 2007
    • Microsoft Office 2010
    • Indexing Service (must be installed and running)

If the following components are missing, they will be installed by Microsoft Dynamics CRM for Outlook setup:

  • Microsoft SQL Server 2008 Express Edition (Microsoft Dynamics CRM for Outlook with Offline Access only)
  • Microsoft .NET Framework 4
  • Microsoft Windows Installer (MSI) 4.5
  • MSXML 4.0
  • Microsoft Visual C++ Redistributable
  • Microsoft Report Viewer 2010
  • Microsoft Application Error Reporting
  • Windows Identity Framework (WIF)

Other prerequisites:

  • Microsoft Internet Explorer 6 or earlier versions are not supported
  • Microsoft Office XP and Microsoft Outlook 2000 versions are not supported for installing and running Microsoft Dynamics CRM for Outlook
  • For the 64-bit version of Microsoft Dynamics CRM for Outlook, a 64-bit version of Office 2010 is required
  • Before you run the Configuration Wizard to configure Microsoft Dynamics CRM for Outlook, a Microsoft Outlook profile must exist for the user
  • Microsoft Outlook must be run at least once to create the user’s Microsoft Outlook profile
  • Cross browser support is coming in the near future in the Microsoft Dynamics CRM Q2 2012 Update

4. Network Characteristics

One of the main causes of poor performance of the Microsoft Dynamics CRM Outlook Client is the latency of the network over which the clients connect to the Microsoft Dynamics CRM Server. Lower latencies normally provide better levels of performance. Latency is the time required for a signal to travel from one point on a network to another. While latency of a network connection can be low, bandwidth (capacity of a specific communications channel) can be a factor if there a lot of resources sharing the network connection, e.g. file downloads and high e-mail traffic.  It is highly recommended to test Microsoft Dynamics CRM Outlook Client performance in a Wide Area Network (WAN) configuration to determine possible bandwidth or latency issues as this testing can vary greatly from performance in a Local Area Network (LAN) configuration.

5. Level of Customization Complexity

When considering performance optimization of Microsoft Dynamics CRM outlook clients, the following should be kept in mind:

  • Number of —
    • Columns in views
    • Columns and grids in use
    • Rows returned per page
    • Sub-grids used on a page
    • Controls on a form (form design)
    • Controls on the ribbon
    • Pinned views
  • Complexity and number of visualizations used in dashboards
  • Use of Jscript and Plugins. Advanced Jscript can add a significant amount of time to, open, save, close and other events especially if calls are made to Microsoft Dynamics CRM or other system. Also plug-ins can affect performance when saving.

In environments with high latency and/or low bandwidth, it is recommended to limit use of these features and functionalities as much as possible without compromising business requirements.

6. Microsoft Dynamics CRM Outlook Client Configurations

For Microsoft Dynamics CRM for Outlook performance optimization, configure the Outlook synchronization filters to affect the fewest record types as well as to occur as infrequently as possible without compromising business requirements and avoid the creation of duplicate records if key fields match.

Note: Over very high latency connections, often a Terminal Services/Citrix connection will improve performance. Note that Terminal Services/Citrix connections are only accessible via Microsoft Dynamics CRM for Outlook; Terminal Services does not support Microsoft Dynamics CRM for Outlook with Offline Access.

In order to optimize Address Book performance, the Address Book should be configured to match only against the contacts that are synchronized to Microsoft Dynamics CRM and to retrieve updates as infrequently as possible without compromising business requirements. For Example, the address book synchronization can be done every 8 hours.

With Microsoft Dynamics CRM for Outlook, users can open tabs to display multiple views of an entity. Users can also “pin” views so they always display when a user logs in to Outlook. Pinned views, which are stored in cache, respond more quickly than do standard views, so be sure that users “pin” the views with which they most commonly interact.

Important: Each pinned view consumes system resources (memory), so balance the use of pinned views against the need for system resources. To optimize the offline synchronization process on computers running Microsoft Dynamics CRM for Outlook with Offline Access, consider the following:

  • Assign all users roles with the minimum access levels and permissions required to perform a job function to help ensure optimized data synchronization to the offline client.
  • Whenever possible, avoid using:
    • “Parent downloaded=true” clauses. Use of this clause often results in the synchronization of unnecessary data, which can degrade the performance of the synchronization process.

Create local data filters for each offline client to ensure that users only have offline access to the data required to perform their job functions. One the local data filters are setup, be sure to remain online and synchronize the data manually. The first synchronization will be slower than subsequent synchronizations because Microsoft Dynamics CRM must remove records.