The sheer breadth of ways that you can utilise Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E) can sometimes boggle the mind. Whether it’s through a traditional web browser, mobile app, the new interactive service hub or even through your own website created via the SDK, organisations have an ever-increasing array of routes they can go down when deploying the application into their environment. Despite this, more often than not, you would expect a “standard” deployment to involve using the application via a web browser, either on a local machine or potentially via a Remote Desktop Session (RDS) instance. Whilst Microsoft’s support articles provide fairly definitive software requirements when working on a Windows desktop machine, it is difficult to determine if, for example, Google Chrome on a Windows Server 2012 RDS session is supported. This is an important omission that requires clarification and is worth discussing further to determine if a definitive conclusion can be reached, based on the available evidence.

In this week’s post, I will attempt to sleuth through the various pieces of evidence I can find on this subject, sprinkling this with some experience that I have had with CRM/D365E and RDS, to see if any definitive conclusion can be established.

Before we get into the heart of the matter, it may be useful to provide a brief overview of what RDS is

RDS is a fancy way of describing connecting to a remote computer via the Remote Desktop Connection client on your Windows or OS of choice. Often referred to as Terminal Services, it is a de facto requirement when accessing remote servers for a variety of reasons. Most commonly, you will witness it deployed as part of an internal corporate network, as a mechanism for users to “remote on” when working outside the office. Due to the familiarity of Windows Server compared with each versions corresponding Desktop OS, the look and feel of working on a normal computer can be achieved with minimal effort, and you can often guarantee that the same types of programmes will also work without issue.

Whilst RDS is still frequently used, it could be argued to have taken a back seat in recent years with the rise in virtualisation technologies, from the likes of Citrix and VMware. These solutions tend to offer the same benefits an RDS server can, but places more emphasis on utilising a local desktop environment to essentially stream desktops/applications to end users. As a result of the rise of these technologies, RDS is perhaps entering a period of uncertainty; whilst it will continue to be essential for remote server management, there are arguably much better technologies available that provide an enriched end-user experience, but offer the same benefits of having a centralised server within a backed up/cloud environment.

Now that you (hopefully!) have a good overview of what RDS is, let’s take a look at the evidence available in relation to CRM/D365E and RDS

Evidence #1: Technet Articles

The following TechNet articles provide, when collated together, a consolidated view of supported internet browsers and operating systems for CRM/D365:

From this, we can distill the following:

  • Windows 10, 8.1, 8 and 7 are supported, so long as they are using a “supported” browser:
    • Internet Explorer 10 is supported for Windows 7 and 8 only.
    • Internet Explorer 11 is supported for all Windows OS’s, with the exception of 8.
    • Edge is supported for Windows 10 only.
    • Firefox and Chrome are supported on all OS’s, so long as they are running the latest version.
  • OS X 10.8 (Mountain Lion), 10.9 (Mavericks) and 10.10 Yosemite are supported for Safari only, running the latest version
  • Android 10 is supported for the latest version of Chrome only
  • iPad is supported for the latest version of Safari only (i.e. the latest version of iOS)

The implication from this should be clear – although the following Windows Server devices (that are currently in mainstream support) can be running a supported web browser, they are not covered as part of the above operating server list:

  • Windows Server 2016
  • Windows Server 2012 R2
  • Windows Server 2012

Evidence #2: Notes from the Field

I have had extensive experience both deploying into and supporting CRM/D365E environments running RDS. These would typically involve servers with significant user load (20-30 per RDS server) and, the general experience and feedback from end users has always been…underwhelming. All issues generally came down to the speed of the application which, when compared to running on a standard, local machine, was at a snail’s pace by comparison. Things like loading a form, an entity view or Dialog became tortuous affairs and led to serious issues with user adoption across the deployments. I can only assume that the amount of local CPU/Memory required for CRM/D365E when running inside a web application was too much for the RDS server to handle; this was confirmed by frequent CPU spikes and high memory utilisation on the server.

I can also attest to working with Microsoft partners who have explicitly avoided having issues concerning RDS and CRM/D365E in-scope as part of any support agreement. When this was queried, the reasoning boiled down to the perceived hassle and complexity involved in managing these types of deployment.

To summarise, I would argue that this factors in additional ammunition for Evidence piece #1, insomuch as that RDS compatible servers are not covered on the supported operating system lists because these issues are known about generally.

Evidence #3: What Microsoft Actually Say

I was recently involved as part of a support case with Microsoft, where we were attempting to diagnose some of the performance issues discussed above within an RDS environment. The support professional assigned to the case came back and stated the following in regards to RDS and CRM/D365E:

…using Windows remote desktop service is supported but unfortunately using Windows server 2012 R2 is not supported. You have to use Windows server 2012. Also windows server 2016 is out of our support boundaries.

Whilst this statement is not backed up by an explicit online source (and I worry whether some confusion has been derived from the Dynamics 365 for Outlook application – see below for more info on this), it can be taken as saying that Windows Server 2012 is the only supported operating system that can be used to access CRM/D365E, with one of the supported web browsers mentioned above.

The Anomalous Piece of Evidence: Dynamics 365 for Outlook Application

Whilst it may not be 100% clear cut in regards to supported server operating systems, we can point to a very definitive statement in respect to the Dynamics 365 for Outlook application when used in conjunction with RDS:

Dynamics 365 for Outlook is supported for running on Windows Server 2012 Remote Desktop Services

Source: https://technet.microsoft.com/en-us/library/hh699743.aspx

Making assumptions here again, but can we take this to mean that the web application is supported within Windows Server 2012 RDS environments, as suggested by the Microsoft engineer above? If not, then you may start thinking to yourself “Well, why not just use this instead of a web browser on RDS to access CRM/D365E?”. Here are a few reasons why you wouldn’t really want to look at rolling out the Dynamics 365 for Outlook application any time soon within RDS:

  • If deploying the application into offline mode, then you will be required to install a SQL Express instance onto the machine in question. This is because the application needs to store copies of your synchronised entity data for whenever you go offline. The impact of this on a standard user machine will be minimal at best, but on a shared desktop environment, could lead to eventual performance issues on the RDS server in question
  • With the introduction of new ways to work within CRM/D365 data in an efficient way, such as with the Dynamics 365 App for Outlook, the traditional Outlook client is something that is becoming less of a requirement these days. There are plenty of rumours/commentary on the grapevine that the application may be due for depreciation in the near future, and even Microsoft have the following to say on the subject:

    Dynamics 365 App for Outlook isn’t the same thing as Dynamics 365 for Outlook. As of the December 2016 update for Dynamics 365 (online and on-premises), Microsoft Dynamics 365 App for Outlook paired with server-side synchronization is the preferred way to integrate Microsoft Dynamics 365 with Outlook.

  • I have observed performance issues with the add-in myself in the past – outlook freezing, the occasional crash and also issues with the Outlook ribbon displaying incorrectly.

As you can probably tell, I am not a big fan of the add-in, but the writing on the wall is fairly clear – Microsoft fully supports you accessing CRM/D365E from the Outlook client on Windows Server 2012 RDS.

After reviewing all the evidence, do we have enough to solve this case?

Whilst there is a lot of evidence to consider, the main thing I would highlight is the lack of a “smoking gun” in what has been reviewed. What I mean by this is the lack of a clear support article that states either “X Browser is supported on Windows Server X” or “X Browser is NOT supported on Windows Server X“. Without any of these specific statements, we are left in a situation where we have to infer that RDS is not a supported option for using the CRM/D365E web application. Certainly, the experience I have had with the web client in these environment types would seem to back this up, which may go some way towards explaining the reason why this is not implicitly supported.

So where does this leave you if you are planning to deploy CRM/D365E within an RDS environment? Your only option is to ensure that your RDS environment is running Windows Server 2012 and that your users are utilising the Outlook client, given that there is a very clear statement regarding its supportability. If you are hell bent on ensuring that your end users have the very best experience with CRM/D365E, then I would urge you to reconsider how your environment is configured and, if possible, move to a supported configuration – whether that’s local desktop or a VDI, running your browser of choice. Hopefully, the benefits of utilising the application will far outweigh any overriding concerns and business reasons for using RDS in the first place.

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.