A slightly shorter blog post this week, as I have spent the majority of the weekend upgrading our CRM Online instance to 2016 🙂 Due to the size of our current deployment and, because some of the new features such as Word Templates and Solution Patches will help make a real difference for our end-users/CRM Administrators, we decided to take the plunge early on. As with any upgrade, these can be potentially fraught with many risks for larger deployments, so I very quickly caveat that you should ensure that your business & CRM team are ready to make the jump and that you have put a solid plan in place in order to ensure the upgrade proceeds smoothly.

Microsoft have already published detailed articles that go through the upgrade process in detail, so today’s post is going to provide a more practical description of what to expect, both during and after the deployment.

E-mail Notifications

As the TechNet article above states:

You’ll receive reminders 90, 30, 15, and 7 days before the update begins

These will be sent to all CRM Administrators for your instance from the e-mail address crmonl@microsoft.com, so make sure you check your spam filter settings. The e-mail will look something like this:

CRMEmail

What happens when the upgrade starts

You’ll get no e-mail notification at the exact moment when the upgrade starts, so you will need to ensure that your users have logged off your CRM instance at least 10-15 minutes before the upgrade states, just to be on the safe side. One observation on this point is that there is no (easy) way for CRM Online Administrators to ensure that all of their logged in users have left the application. I am really hoping that they make Administration Mode available to Production instances in the near future, as this will help greatly for scenarios like this or if you are, for example, planning on doing a Solution update during a specific time period.

If you attempt to login into your CRM instance, you’ll be greeted with a screen similar to the below:

CRMUpgrade

Whilst the upgrade was being carried out, I noticed that the Status moved from “Disabled” to “Pending” during the upgrade process. You can therefore refresh the page in order to gain a brief indicator of how the upgrade is going.

How Long the Upgrade Takes

In our case, it took a little over an hour for the upgrade to complete, which was great! In this instance, we were upgrading from CRM 2015 Update 1, so I assume this had a factor in ensuring the upgrade completed so quickly. I would assume that, if the update process is similar to how you would upgrade On-Premise CRM 2013 to CRM 2016, (as an example) then each version update is applied in sequential order (CRM 2013 -> CRM 2015 -> CRM 2016), therefore adding to the amount of time it takes to finish the upgrade

As soon as the upgrade is finished, all CRM Administrators will get the following e-mail:

CRMEmail_2

What to Expect after the upgrade

Again, this section is going to be more specific to scenarios where you are upgrading from CRM 2015 Update 1, though I would be interesting in finding out if these behaviours differ in any other upgrade scenario:

  • This is perhaps more applicable before the upgrade even begins, but if you are making the jump from a much earlier version of CRM, then you may encounter serious problems with any form level JScript. CRM has made some quite fundamental changes in recent versions in regards to the supported methods that should be used. Your CRM Administrators/Developers should have read and fully understood the What’s New for developers guide and, as part of any upgrade plan, some kind of test upgrade in a Sandbox/Trial CRM instance needs to be completed. This should be pretty obvious, but doing this ensures that you can identify and fix these kind of issues long before the upgrade begins.
  • This is a strange one, but the upgrade reverted back our CRM Theme to the system default one. Fixing this is literally just a case of re-publishing your desired Theme from Customizations, but it is rather curious that this even happens in the first place.
  • All Personal/System Settings remain as they were before the upgrade
  • Any Waiting or in progress workflows will remain processing in the background
  • If your organization is using the CRM for Client to Outlook, then you may be pleased to hear that the 2015 Client is compatible and works successfully with CRM 2016. Following the upgrade, when your users first open Outlook again, they will be greeted with the following screen:

CRMForOutlook_Message

Once this has completed, CRM for Outlook will then operate as normal.

In our upgrade however, we did encounter a few cases where this did not always work. For example, the pop-up box above did not appear at all and whenever we tried to navigate to an Entity list in Outlook, Outlook would hang like so:

CRMForOutlook_Hanging

I suspect though that the problems in our case were down to something to do with our organisations infrastructure, as opposed to solely the CRM Upgrade itself. We managed to resolve the above by simply re-creating the connection to the CRM Organization. After that, everything worked perfectly 🙂 I would recommend that you look at upgrading to the Client eventually though (like we are), as it is my understanding that it includes a number of performance tweaks.

Final Thoughts

I am really looking forward to working with CRM 2016 more closely in the weeks and months ahead. The release feels very familiar, but also comes packed with a number of small, but significant, improvements or new features. These are specifically designed to give end users more flexibility in how they use CRM, and in helping make CRM Administrators/Developers lives easier.

Is anyone else planning on or have already upgraded to CRM 2016? Let me know in the comments below.

When working with CRM extensively across multiple environments, you do start to get into a fairly regular rhythm when it comes to completing key tasks again…and again…and again. One of these tasks is the process of rolling out a Solution update. To briefly summarise, this is where you export an updated version of your solution from your development environment and then import the solution file on top of a previous version in a different instance. CRM will then go through the solution import file, detect and then apply any changes which have been made. The original solution will be overwritten as part of this and you will be informed at the end of the import on any warnings or errors that were encountered during import. Warnings will generally not cause the solution import to fail, whereas errors will stop the import completely.

Like with anything, Solution updates can sometimes fall-over for a whole host of different reasons. They can fail altogether, or sometimes just hang and become unresponsive. If you are running On-Premise CRM, then you can interrogate the SQL database on the instance to see how your solution import is (or is not) progressing. Ben Hosking (whose blog is mandatory reading for anyone who works closely with CRM) has written a really useful post which contains the SQL query you need to use on your organization database in order to identify any problematic job imports.  The good thing with this approach is, if the import has errored, the Data column contains the raw XML file that you are able to download via the CRM GUI using the ‘Download Log File’ button below when a solution import proceeds as you would expect normally:

SolutionUpdate_ExportLog

You can therefore very quickly drill-down to see if the solution import has failed due to a customisation issue. A common reason for failure may be due to duplicate logical name(s) for attributes, relationships etc.

If you are using CRM Online, then the first assumption (which I admittedly made) may be that there is no way in which to access the above information. Fortunately, there is an entity called ‘importjob’ that is made available for access via FetchXML

So, for example, to return all solution imports that have gone through your CRM, you would use the following FetchXML query:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="importjob" >
    <attribute name="completedon" />
    <attribute name="solutionname" />
    <attribute name="progress" />
    <attribute name="startedon" />
    <attribute name="completedon" />
    <attribute name="createdby" />
    <attribute name="data" />
    <attribute name="organizationid" />
    <attribute name="createdon" />
  </entity>
</fetch>

If you wanted to just return solution imports that are either stuck at 0% or have not yet successfully completed:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false" >
  <entity name="importjob" >
    <attribute name="completedon" />
    <attribute name="solutionname" />
    <attribute name="progress" />
    <attribute name="startedon" />
    <attribute name="completedon" />
    <attribute name="createdby" />
    <attribute name="data" />
    <attribute name="organizationid" />
    <attribute name="createdon" />
    <filter type="or" >
      <condition attribute="progress" operator="eq" value="0" />
      <condition attribute="completedon" operator="null" />
    </filter>
  </entity>
</fetch>

Sometimes your import may fail due to a problem with CRM itself. In these instances, the best course of action depends, once again, on your CRM deployment:

  • For On-Premise users, then the old IT adage applies here: try restarting the CRM and SQL Database Server instance. You may first need to locate the active process on SQL Management Studio that is performing the solution import and kill the process first. A database instance reset should automatically cancel this and prevent it from running again on instance startup, but its better to be safe than sorry.
  • The only recourse for Online users is to log a support request with Microsoft via the Office 365 portal. It is best to provide as much evidence as possible up-front and be advised that the Microsoft support engineer may ask you to demonstrate the problem again, which might prove difficult to perform during normal working hours if the problem is happening on your Production instance.

I was glad to discover that there is half way method of being able to interrogate possible platform issues yourself on CRM Online, but this particular example illustrates one of the drawbacks of CRM Online: little or no direct access to the organization database and/or instance level services. I would hope that in time Microsoft may develop the platform further in order to start exposing these elements to organization administrators. I would imagine that the vast majority of support queries that go through on the Office 365 portal would relate to requests that could be safely performed by CRM Administrators or Partners, leading to a cost and efficiency saving for Microsoft should this be implemented.

For those businesses or individuals who are currently considering Dynamics CRM, one of the decisions that you will ultimately need to make is regarding whether you intend to use CRM Online or CRM On-Premise. For those whose first reaction to the previous statement is “Say what?”, heres a brief breakdown of the two different options:

  • CRM Online: An instance of CRM that is accessible via Office 365.
  • CRM On-Premise: An installation of CRM on your own server(s).

The word on the street these days is all around cloud computing and services, and that all organisations should have most, if not all, of their infrastructure within a hybrid public/private cloud configuration. However, it could be that you are required to host your CRM within a specific location due to regulatory or contractual requirements for your business. Or that you already have existing costs allocated towards server infrastructure that must be used as part of your CRM project.  The list of potential reasons are endless, which is why CRM On-Premise exists in the first place and is still an essential requirement for many organisations.

So here’s a breakdown of some of the factors to consider, and my recommendation on the best approach to go for:

If you are already using Exchange Online with other Office 365 services, then CRM Online is the way to go

One of the potential headaches when it comes to configuring CRM for first use is around e-mail synchronisation, something which I have hinted at in a previous blog post. If you already use Exchange Online, then the setup steps involved are greatly reduced, as CRM will automatically detect your Exchange Online profile and settings if it is on the same tenant as your CRM Online instance. If not, then you’re going to have to look at other options such as the E-mail Router in order to link up your On-Premise Exchange Server, SMTP or POP3 e-mail system. These can be fiddly to setup and maintain, as you will require a dedicated machine that hosts the E-mail Router software and you may potentially have to liaise with other third party e-mail system providers in order to troubleshoot any issues.

Sometimes it’s nice having the latest new product without paying extra for it

For On-Premise CRM, you would need to factor any future upgrade plans as part of your initial cost-investment into the system. Given the increased frequency of CRM releases, this could start adding up to big bucks after the first year or two. As a On-Premise customer as well, you will also miss out on any major updates in between versions, such as Update 1 last year for CRM Online. This was quite a fundamental and significant update, in my opinion, that helped to make CRM even easier to use. With CRM Online, you are always guaranteed to get the latest updates and thereby take advantage of some of the latest and best features available within CRM. The trade off with this is that you must upgrade to the latest version of CRM eventually. You’ll be offered a date and time for the upgrade and can delay it, but you can’t stay in the past forever! This could present issues if, for example, you have written bespoke customisations that are no longer supported or deprecated. Be sure you have read and fully understand how updates work in CRM Online before making your decision.

Evaluate your internal resources first

It could be, for example, that your organisation is moving from an internal application system that uses SQL Server as the backend database system and that you have several team members who you have invested heavily on T-SQL administration/development training. The great thing about On-Premise CRM is that this skillset will not be lost, as you will need to maintain and manage your organisation(s) databases. And, if you’re really nice, you can also let them write beautifully bespoke SSRS reports directly against your databases and let them do all sorts of other fun data integration pieces using SQL Server.

The flip side of this should be obvious, but if you and your organisation don’t know your SELECT’s from your WHERE’S, then CRM Online could be the best choice as you don’t have to worry about managing and maintaining a SQL database, as Microsoft handles all of this for you. You can instead focus yours and your team’s attention and learning potentially more relevant things relating to CRM (Online) directly

Do you trust Microsoft?

Its a serious question nowadays. In the world of cloud computing, can you say with 100% certainty that the organisation(s) where you are hosting or storing some of your business’ key data and applications will a) ensure your data is kept securely and b) able to offer satisfactory guarantees in relation to service availability? Whilst (touching wood) Office 365/CRM Online outages have been few and far between, the risk is still ever omnipotent. You will therefore need to evaluate what the maximum amount of outage time is acceptable for your business and put in place procedures to ensure that your business can keep working (for example, nightly backups of your CRM Data so that you can still access your Data via a spreadsheet/database export). The benefit of having an On-Premise CRM system is that you will more than likely have control over your server machines, as well as all the data that is stored on them, and ensure your infrastructure is built to satisfy any concerns around outages or system failures.

Nice words for your Finance Team: Operational Expenditure is better than Capital Expenditure! 

Deciding to go with CRM Online could significantly simplify your organisations visibility over your month-by-month costs. If done correctly, you could even make the bold claim that you have successfully eliminated all capital expenditure (i.e. upfront software costs) costs relating to CRM systems within your business. Based on experience, most finance departments are happier knowing they have to pay X amount over a 12 month period, as opposed to being hit by large and unwieldy costs in a sporadic and uncertain way. So if you want to be make BFF’s within your finance/account team, then CRM Online is the fastest and best way to achieve this.

Legacy Systems or that annoying finance system that’s 15 years old, but runs 20% of our business work and cannot be replaced

Without traditional database access that On-Premise provides, it may prove difficult integrating your CRM system with any legacy system, particularly if it’s a non-SQL database. That’s not to say that it’s not possible to find a solution using CRM Online, but you may have to expand significantly more resources setting up staging environments with your CRM Online/Legacy System, or look at writing customised code that performs the tasks that you need in order to “glue” both of the systems together.

Make sure your technical team understand the limitations of CRM Online clearly, and that their feedback is factored in as part of the decision making process

I’ve already mentioned the most obvious limitation for CRM Online in the form of not having access to the CRM SQL Database. But there are other limitations too. For example, you are unable to directly query all of the information contained within the audit data entity.  There is a very good (although outdated) article on TechNet which gives a flavour of some of the limitations within CRM Online. It is very important that as part of any scoping exercise that your technical team is fully aware of the limitations of CRM Online, so that any potential difficulties around integration or data access can be mitigated from the outset.

Conclusions – or Wot I Think

If you are a small to medium business who are already using Office 365 or planning to move across in the near future, then CRM Online is the obvious and best choice to ensure the most streamlined user experience and ease of management and setup. If, however, you are a much larger organisation or are required to operate under specific compliance or regulatory requirements in respect to your business applications/data, then these are the types of scenarios where On-Premise CRM is pretty much an absolute requirement.

One of the great things about developing bespoke solutions for CRM is the ability to make changes to the sitemap navigation. For the uninitiated, the Sitemap is this area within CRM:

Sitemap

The areas and individual buttons can be modified to suit most requirements for organizations, to include links to custom entities, external applications or to an internal HTML/Silverlight web resource. As a result, CRM can be made to look highly bespoke and unique, as if it is a completely different CRM system altogether from the default setup.

We recently had a requirement to create a sitemap area button that would open a specific record. The record in question is one that will be updated frequently, so colleagues within the business require quick and easy access to it from the Sitemap area. We already know that this possible for opening specific entity views, as we have used this a number of times previously (for example, change the default view that opens when you click the ‘Accounts’ button to “Accounts I Follow”). MSDN provides a great outline of how you go about doing this:

To display a list of entity records within the application for a SubArea set the Entity attribute value. This displays the default view for that entity and provides the correct title and icon.

However, if you want to have a SubArea element that uses a specific initial default view, use the following Url pattern.

Url=”/_root/homepage.aspx?etn=<entity logical name >&amp;viewid=%7b<GUID value of view id>%7d”

Source: https://msdn.microsoft.com/en-gb/library/gg328483.aspx#BKMK_DisplayViewInApplicationUsingSiteMap

The question at this stage then is can we adapt the above method in order to open an entity record instead? Let’s give at a go, using our trusty XRMToolbox Sitemap Editor tool. The steps below assume that you already know how to use this tool and to make amends to the sitemap area.

On the above article page, we are told that in order to open an entity record via a URL, we need to provide the following query parameters:

  • etn: The logical name of the entity
  • pagetype: In this instance, should be set to “entityrecord”
  • id: The GUID for the CRM record to open. The best way to obtain this is to export the record to Excel and unhide all the columns; the GUID is then the value in the A column; you will need to change this to Upper Case via an Excel =UPPER function:

ExcelGUID

Then, in order to ensure that the GUID is accepted correctly in the URL, we need to surround it with curly braces. As these character types are not accepted as part of a URL string, we need to provide the following substitute character strings:

{ = %7B

} = %7D

e.g. {E16EE6D6-56B4-E511-80E2-2C59E541BD38} -> %7BE16EE6D6-56B4-E511-80E2-2C59E541BD38%7D

So let the trial and error begin! The most simple way of getting this to work would be to change the SubArea URL value to the full CRM instance URL. So, for example, our CRM Online URL would look something like this:

https://mycrminstance.crm.dynamics.com/main.aspx?etn=test_mycustomentity&pagetype=entityrecord&id=%7BE16EE6D6-56B4-E511-80E2-2C59E541BD38%7D

But if we have separate development/production environments, then this is impractical as the link will not work when moving our solution between environments. Our preferred setup therefore is to look at using a relative URL path that works across different environments.

What happens if we try adapting the URL example for views instead? So, in which case, our URL would be:

/_root/homepage.aspx?etn=test_mycustomentity&pagetype=entityrecord&id=%7BE16EE6D6-56B4-E511-80E2-2C59E541BD38%7D

SitemapURLError

That’s a no then! The next step then is to take a closer look at the example URL’s provided and making some guesswork in regards to how relative URL’s function. If we assume then that our full URL is:

https://mycrminstance.crm.dynamics.com/main.aspx?etn=test_mycustomentity&pagetype=entityrecord&id=%7BE16EE6D6-56B4-E511-80E2-2C59E541BD38%7D

Then our relative URL would be:

/main.aspx?etn=test_mycustomentity&pagetype=entityrecord&id=%7BE16EE6D6-56B4-E511-80E2-2C59E541BD38%7D

And guess what? It works! One comment to make on this though is that the record opens in a brand new window within Internet Explorer & Google Chrome, so I would therefore presume that this is the case across all browsers. There are some additional query string parameters that can be specified in the URL to make this look more like a quick-edit “pop out” window:

  • cmdbar: Setting this to “false” will hide the ribbon on the form
  • navbar: Setting this to “off” will hide the sitemap navigation bar

Our URL string and record window would therefore look this:

/main.aspx?etn=test_mycustomentity&pagetype=entityrecord&id=%7BE16EE6D6-56B4-E511-80E2-2C59E541BD38%7D&cmdbar=false&navbar=off

URLExampleWindow

The user can then make their changes to records, save and then close the window. Suffice it to say, it is good to know that it is possible to do this within CRM and that the trial and error steps involved were fairly minimal.

The Scenario: You are running CRM Online in conjunction with some legacy database/application systems. These systems are setup with a SQL Server Reporting Services instance that is looking to either an SQL Server, OLE DB etc. database.

The Problem: You need to make data from your legacy systems visible within your CRM. The information needs to be displayed on the Entity Form and show specific information from the legacy database that relates to the CRM record.

Admittedly, the above is perhaps somewhat unlikely situation to find yourself in, but one which I recently had to try and address. I suppose the most straightforward resolution to the above is to just say “Get rid of the legacy system!”. Unfortunately, the suggestion didn’t go down to well when I voiced it myself…

So at this point the next best answer looked to be try and utilise what we have within the existing infrastructure: an all singing, all-dancing SSRS and SQL Server database instance.

What if we were to try uploading an .rdl file that includes a FetchXML and our SQL/OLE DB database data source into CRM? Whenever you try to perform this, you will get this error message:

ReportUploadError_NoFetchXML

 

Rats! So there is no way in which we can include a non-fetch XML Data Source to our separate SSRS report instance. So is there anything else within CRM that can be utilised to help in this situation? Let’s first take a quick look at the following nifty little feature within CRM, courtesy of our good friend MSDN:

You can use an IFRAME to display the contents from another website in a form, for example, in an ASP.NET page. Displaying an entity form within an IFrame embedded in another entity form is not supported.

Use the getValue method on the attributes that contain the data that you want to pass to the other website, and compose a string of the query string arguments the other page will be able to use. Then use a Field OnChange event, IFRAME OnReadyStateComplete event, or Tab TabStateChange event and the setSrc method to append your parameters to the src property of the IFRAME or web resource.

You may want to change the target of the IFRAME based on such considerations as the data in the form or whether the user is working offline. You can set the target of the IFRAME dynamically.

Source: https://msdn.microsoft.com/en-gb/library/gg328034.aspx

Having worked extensively with SSRS in the past, I am also aware that you can use an SSRS URL string in order to specify properties about how the report is rendered, its size and – most crucially – what the value of required parameters should be. The friend that keeps on giving has a great article that goes through everything that you can do with an SSRS report URL and also how to use Parameters as part of your URL. So in theory therefore, we can place an IFRAME on our form and then use JScript to access form-level field values and modify the IFRAME URL accordingly.

Here are the steps involved:

  1. Go into Form Editor and add a new IFRAME to the form, specifying the following settings:

Name: The Logical name of the control, this will be required as part of the JScript code used later, so make a note of it.

URL: As this is a mandatory field, you can specify any value here as it will change when the form is loaded by the user. This is not practical as we don’t want this to be displayed if, for example, the field that we are passing to the URL has no value in it. Our JScript code will sort this out in a few moments

Label: This can be anything, and defaults to whatever is entered into the Name field

Restrict cross-frame scripting, where supported: Untick this option

Ensure that ‘Visible by default’ is ticked

Your settings should look something like this:

IFRAMESettings

  1. Create or modify an existing JScript Library for the form, adding in the following function (after modifying the values accordingly):
function onLoad_LoadSSRSReport() {

    //First get the page type (Create, Update etc.)

    var pageType = Xrm.Page.ui.getFormType();
    
    //Then, only proceed if the Form Type DOES NOT equal create, can be changed depending on requirements. Full list of form types can be found here:
    
    //https://msdn.microsoft.com/en-us/library/gg327828.aspx#BKMK_getFormType

    if (pageType != "1") {

        //Get the value that you want to parameterise, in this case we are on the Account entity and need the Account Name

        var accountName = Xrm.Page.getAttribute("name").getValue();

        //In order to "accept" the parameter into the URL, spaces need to be replaced with "+" icons

        accountName = accountName.replace(/ /g, "+");

        //Now, get the the name of the IFRAME we want to update

        var iFrame = Xrm.Page.ui.controls.get("IFRAME_myssrsreport");

        //Then, specify the Report Server URL and Report Name.

        var reportURL = "https://myssrsserver/ReportServer?/My+Reports/My+Parameterised+Report&MyParameter=";

        //Now combine the report url and parameter together into a full URL string

        var paramaterizedReportURL = reportURL + accountName;

        //Finally, if there is no value in the Account Name field, hide the IFRAME; otherwise, update the URL of the IFRAME accordingly.

        if (accountName == null) {
            iFrame.setVisible(false);
        }
        else {

            iFrame.setSrc(paramaterizedReportURL);
        }
    }
}
  1. Add the function to the OnLoad event handler on the form. Now, when the form loads, it will update the IFRAME with the new URL with our required parameter.

And there we go, we now have our separate SSRS instance report working within CRM! A few things to point out though:

  • If the report parameter supplied does not load any matching records, then SSRS will display a standard message to this effect. You would need to modify the report settings in order to display a custom message here, if desired.
  • It is recommended that you have https:// binding setup on your report instance and supply this to as part of the setSrc method. http:// binding works, but you may need to change settings on your Web Browser in order to support mixed mode content. Full instructions on how to set this up can be found here.
  • This may be stating the obvious here, but if your SSRS instance is not internet-facing, then you will get an error message in your IFRAME if you are not working from the same network as your SSRS instance. Fortunately, SSRS can be configued for an Internet deployment.
  • The steps outlined in 1) can also be used to specify a non-parameterised SSRS report within an IFRAME dashboard too. I would recommend using the following SSRS system parameters as part of the URL though:
    • rs:ClearSession=true
    • rc:Toolbar=false

e.g.

https://myssrsserver/ReportServer/Pages/ReportViewer.aspx?%2fMy+Reports%2fMy+Non+Parameterised+Report&rs:ClearSession=true&rc:Toolbar=false

One of the most challenging things about any system migration is ensuring that information from other business systems can be made available, and it is good to know that CRM has supported approaches that can help to bridge the gap.