Making CRM 2011 and IE11 work together

CRM 2011 and Internet Explorer 11 (IE11)

With Internet Explorer 11 being pushed out as part of the Windows Updates, consideration needs to be provided on the compatibility of the CRM 2011 with IE11.

When logging into CRM in IE11 using the URL: http://crmorg.domain.com, you will be re-directed to the Microsoft Dynamics CRM ‘Mobile Express’ site. That site looks something like this:

CRM 2011 and IE11

So what are the potential workarounds to avoid this?  There are three options available:

Option 1

OR

Option 2

  • Use the IE Developer Tools to set the browser mode to IE10.
    • Browse to your CRM UR
    • Hit F12 ke
    • Select the “Emulation” setting
    • Set the “User agent string” to “Internet Explorer 10
    • Browse back to the CRM URL

Option 3

Use Chrome or Firefox.  This options require the CRM 2011 environment be upgraded to UR12 or above. Upgrading to UR12 or above requires validating that custom functionality works correctly in Internet Explorer, Google Chrome, or Mozilla Firefox.

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.

Creating an Editable Grid in CRM 2011 Using Knockout JS

Dave Berry wrote an excellent customization for CRM 4.0 which provided the ability to mass update child records, directly from the related parent’s form. Unfortunately, the CRM 2011 architecture prevents this customization from being adopted. By now, there exist quite a few commercial solutions for grid editing.

http://www.sparklexrm.com/s/features.html
http://pinpoint.microsoft.com/en-US/applications/add-edit-grid-for-crm-2011-and-crm-online-12884923430 http://pinpoint.microsoft.com/en-US/applications/editable-grid-add-on-for-crm-2011-and-crm-online-12884921672 http://www.c360.com/RecordEditor.aspx http://www.axonom.com/crm_solutions/powertrak/articles/editablegrids.html

I’ve been looking for a way to build a solution instead of buy.  I came across this fantastic blog post, which suggests using knockout JS as the data-binding tool. There is a great tutorial and lots of examples to get started.

The following is an example of an implementation of an editable grid for CRM 2011. I show two examples of editing opportunity products from within the parent opportunity which are:

  • How all changes to opportunity product are saved in a single operation
  • How only one opportunity product is saved back to the server

I demonstrate the following features which allow:

  • Editing existing data, including lookup data
  • Adding a new record
  • Deleting an existing record

Demo

post 3 image 1

The first editable grid illustrated above, implements the ‘multi-save’ design. In this case, all data is editable all the time. The second editable grid demonstrates using a single-record approach to editing records.

post 3 image 2

Referring to the single-edit approach, clicking on the ‘Edit’ link enables that record for edit. In this approach, the user must click ‘Apply’ in order to successful save the data. The record remains in edit mode until the user clicks ‘Apply’ or ‘Cancel.

post 3 image 3

Click ‘Apply’ results in a pop-up confirmation of the success. Naturally, the pop-up can be removed.

post 3 image 4

In the multi-save demonstration, note that both quantities have been updated. Click ‘Save’ to send the updates back to the server.

post 3 image 5

A confirmation pop-up reports the success of both records.

post 3 image 6

Click ‘Add Opportunity Product’ to add a new record.

post 3 image 7

Adding a record requires that certain required fields, namely the product, are selected. Therefore, the standard product lookup is presented.

post 3 image 8

Upon selecting a product, and clicking ‘Ok’, the record is successfully created. Notice that quantity and UOM are defaulted.

post 3 image 9

Removing a record is accomplished by clicking ‘Delete’ link next to the record.

post 3 image 10

Notice the record has been removed.

In the next blog post, I will walk through the code and how to integrate this code in CRM.

Some features I plan on demonstrating in a future blog are:

  • Editing ‘OptionSet’ fields
  • Sorting
  • Paging through the grid

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.

CRM Resolutions for 2013

Organizing your personal preferences in CRM is a great way to start your day, review your upcoming events, and utilize the features of Microsoft Dynamics CRM® 2011. Below are a few easy ways to stay organized in 2013!

1. Setting up your personal preferences:

In your CRM options menu, update the below fields on the “General” tab.

    • What page in CRM do you use most often? What page would you like to set as your home page/landing page? If you review your dashboards frequently or like the visual reminder of your activities, you can set it as your default pane and default tab. (A)
    • Do you use the “Get Started” pane? If not, disable it. It will add more real estate to your CRM form. (B)
    • Set your records per page. By default, CRM list 50 records per page. We recommend changing it to 250. (C)
    • Check that your time zone and current are correctly set. (D)

Ashley Blog 1

2. Stay Organized with Dashboards

One of the best ways to put everything you need in one spot in CRM is on a personal dashboard that you can set on your home screen and see all your major needs. As described in this blog, you can set a home screen that CRM will start on every time you open it and you can set a default page for every entity. But what if you want to see more than one CRM aspect right away?

Setting up a personal dashboard will allow you to choose up to 6 different views on one screen. Not only will you be able to put in the views such as your daily activities for the day, you can also put charts within the dashboard to measure any kind of progress to suit your needs!

Here are just a few of the countless examples of dashboards:

  • This dashboard put personal “Activitiy” views all in one dashboard so you don’t have to toggle between different views

Ashley Blog 2

  • This dashboard captures a few measurement charts as well as an opportunity and activity view

Ashley Blog 3

3. The “What’s New” Feature

“What’s New” is an exciting new feature of Dynamics CRM 2011 which allows users to follow their fellow colleagues, certain accounts, etc. for up-to-the-minute activity. It is similar to an internal social media page. Below is an example of the items users can follow.

The “Activity Feeds” comes in a solution which is free to download, just make sure you have rollup five installed for it to function.

Ashley Blog 5

As you can see, there are plenty of ways to keep organized in CRM. All it takes if a few clicks and turns and you can determine what works best for you!

To learn more about the Edgewater CRM practice, click here.