I was having a chat with a colleague recently about the new Interactive Service Hub (ISH) in CRM, in particular the new entity forms that are used as part of this. One of the questions that came up was “From a form scripting point of view, do ISH forms let you utilise all of the same references, properties and methods available as part of a Main form?”. As is generally the case in these situations, we can turn to our good friends TechNet and MSDN for answers. Specifically, we are able to find out the following on MSDN:

All the form scripting events and methods supported by the CRM mobile clients (phone and tablet) are supported in the interactive service hub.

If your organisation is fortunate enough to be using CRM 2016 Update 1 or CRM 2016 Service Pack 1, then you can also utilise the following methods/events as well:

Source: https://msdn.microsoft.com/en-us/library/mt671135.aspx#Anchor_1

So what does this mean in practical terms and how should this factor into your decision to utilise Interactive Forms over standard CRM forms? Here are a few things to consider, as well as my own thoughts on the best way to proceed:

If you are on CRM 2016, then get yourself Update 1/Service Pack 1 ASAP

There are a number of important new methods that can be used for interactive forms as part of this update. For example, you get much better options when it comes to working with IFRAME controls, interacting with the currently loaded record you are working with (via getID), loading a new record form (via openEntityForm or openQuickCreate) and setting focus to a particular field on a form (via setFocus). This goes above and beyond what is currently supported via the CRM tablet apps, and it is good to see that this CRM update has added these in. Having access to these methods may help to decide whether you can safely migrate or start using ISH forms within your organisation. And, as we have seen previously, the update process to SP1 for CRM 2016 is relatively straightforward, so why wouldn’t you look at upgrading?

Be sure you familiarise yourself with Interactive Form debugging

Anyone who works with CRM form scripting will be familiar with the trials and tribulations of browser debugging your scripts via Developer Tools on your browser of choice: open up your script library, set your breakpoints and then perform the actions needed to trigger your script. Try this with the new Interactive Forms, and you will notice that your custom library is not loaded onto the form. What the fudge?!?

Before panicking too much, the good news is that scripts can still be debugged, but you just have to go down a slightly different route. The CRM Team have written an excellent blog post that covers not just debugging for interactive forms, but for all forms as well. The first two options suggested seem to be the most straight-forward way of debugging interactive forms, but you can’t help but laugh at the fact that one of the suggested options is to use functionality within Google Chrome! 🙂 Joking aside, using Dynamic JScript in the manner outlined looks to be an effective way of setting breakpoints in a familiar manner. I may have to look at trying this at some point in the future.

You cannot programmatically switch to a different entity form in the Interactive Service Hub

It is sometimes useful to change the currently loaded form that a user is presented with depending on certain conditions. For example, if a user enters certain data within a Lead form to indicate the record should be treated as high priority, you may want a new form to be opened that contains additional fields, subgrids etc. that need to be completed in order to progress the record accordingly. Within the Xrm.Page.Ui reference, we have two methods that help us achieve this objective: formSelector.getCurrentItem, which returns the GUID for the currently loaded form, and formSelector.items, which returns a list of GUID’s for all forms that the current user has access to. The bad news is that, because these two methods are not supported in the mobile app, you will also be unable to use them within the ISH. This is likely due to the fact that, similar to Mobile Forms, only one form is presented to user when using the ISH, which is dictated by the form order and the users security permissions.

ISH forms do not contain a Ribbon

This may be one of the major reasons that prevent against an en masse adoption of ISH forms in the near future. One of the benefits of using the default CRM forms is the ability to modify the the CRM ribbon in order to add, remove or modify button behaviours across the application. This is great if you decide that you don’t want your users to have access to the Delete button, need to modify the order of the buttons to match the ones that are used the most or you need to setup a custom button that performs a web server call to an external system. Again, similar to the mobile application, there is no ribbon anywhere on the ISH, which means you may be missing out on key functionality going down this route.

ISH can only currently be used with a limited list of entities

If you are hoping to get your CRM setup to use ISH for your Sales related entities, then don’t get too carried away at this stage. You are currently limited to using ISH with a specific list of CRM entities. The full list, courtesy of our good friends again, is as follows:

  • Account
  • Contact
  • Case
  • All Activity Entities (System/Custom)
  • Social Profile
  • Queue Item
  • Knowledge Article
  • Custom Entities

Expect this to change in future, as one of the things that I have previously highlighted as part of Update 1/Service Pack 1 was the ability to add Feedback onto any entity within CRM, including custom ones. It would make sense that the Sales side of CRM gets some love and attention to include Leads, Opportunities etc. as part of ISH (so we may not even call it this if that happens!).

Conclusions or Wot I Think

It is clear that, whilst some of the headline benefits of using ISH are clear – visual experience, ability to drill down to individual records and efficient record filtering – , there are some very crucial and important technical limitations with the feature that need to be factored in before you decide to just completely migrate across to ISH. I would say that if your organisation has not been extensively customised to utilise form level scripting and other types of bespoke development work, then you can perhaps get away with making the jump. By contrary, you should be holding off and evaluating your existing customisations first to see if a) they are supported/unsupported by ISH or b) if there is some way to drop certain form scripting, ribbon customisations etc. in favour of using something default within CRM (for example, a Business Rule instead of a Jscript function). It could be that you can ditch a whole load of code that is not required as part of this exercise and instead utilise base functionality within CRM, something which is always preferable.

One thing I have been wondering about is the eventual aim with the ISH: is it intended that this will eventually replace the existing CRM user experience or will it continue to just be an alternative way of using CRM? It will be interesting to see how the feature is developed over the next couple of releases of CRM; one of the key indicators of this replacing the “old style” CRM forms is if we start to see all form scripting options made available in ISH and the introduction of the Ribbon.

In the meantime, make sure you do check out ISH at some stage, as the potential of setting up a visually attractive reporting and day-to-day application tool is huge. Just don’t let your Sales team see it yet, as you will end up disappointing them!

I was interested to read on TechNet that it is now supported to perform a Multiple-Server role installation of Dynamics CRM 2016 on Windows Server 2012 R2 instances that are configured in Core installation mode:

With the exception of the Microsoft Dynamics CRM Help Server and Microsoft Dynamics CRM Reporting Extensions roles, you can install any Microsoft Dynamics CRM 2016 Server server role on a Server Core installation of Windows Server.

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

At this stage you may be asking, “What is a Core installation of Windows Server 2012 R2?” or “Why would it be preferable to install CRM on a Core Server?”. Starting from Windows Server 2008, server admins can choose to install Windows Server without a GUI interface and without most of the common features that you would expect from a Windows Desktop environment. All you are able to see and interact with if you choose to log into a Windows Server core is the following:


I would imagine that most novice service admins (like me!) would start panicking at this stage…

The idea behind Core installations is that the server would be administered remotely from a server/desktop environment (using Server Manager, Powershell etc.), with it being really unlikely that you would need to logon or remotely connect to the server via remote desktop connection. As a Core installation is missing pretty much everything you would expect from a standard Windows working environment, it is potentially ideal for scenarios where you have limited resources within your virtualised server environment. Alternatively, if you are intending to deploy a resource-intensive application to the server (like Dynamics CRM!), ensuring that the application has access to as many system resources as possible could be desirable. More information about Core installations, including their supported roles/features, can be found on this helpful MSDN article.

So lets go through the process of setting up a Windows Server 2012 R2 Core Installation and then performing a CRM installation on the machine for all roles, with the exception of the ones highlighted above. We’ll take a look at some of the options available to us as part of a silent install and evaluate to see what the benefits are for an organisation to deploy On-Premise CRM in this manner:

  1. To start off, we need to get our Windows Server 2012 R2 instance setup. The installation of this is really straight-forward and simple, so will not be covered in-depth. The only thing you need to note is that Server Core Installation option needs to be specified, as opposed to Server with a GUI, as you go through the required steps:ServerCore_Setup
  2. Once your server is setup and you have logged in for the first time, you will need to get the server joined to the domain that will be used for your Dynamics CRM instance. Fortunately, this can be rather straightforwardly done in Server Core by using the SConfig command on the prompt window. Type in the following in the command prompt window and hit return:


The command prompt window will turn blue and change to resemble the following (image courtesy of Technet):


At this point, type 1 and hit enter, following the instructions in order get the Server connected to your target domain. A restart will be required as part of this. An (optional) step before restarting is to also rename the Computer to something more description e.g. CRM-SERVER.

  1. Once your server is on the Domain, you can disconnect from the Core server for now. In order to get underway with the installation, there is some prep work that needs completing first, which will require having the following files downloaded:
      • Microsoft Dynamics CRM Installation executable (.exe)
      • A configuration .xml file for the install. This is what the installer will refer to during the installation process for all of the required options. For this example, we will be using the following .xml file:

    <Patch update="true"></Patch>
    <Database create="true"/>
    <Reporting URL="http://MySSRSServer/MyReportServer"/>
    <basecurrency isocurrencycode="GBP" currencyname="GB Pound Sterling" currencysymbol="£" currencyprecision="2"/>
    <Organization>My CRM Organisation</Organization>
    <WebsiteUrl create="true" port="5555"> </WebsiteUrl>
    <InstallDir>c:\Program Files\Microsoft Dynamics CRM</InstallDir>
    <CrmServiceAccount type="DomainUser">
    <SandboxServiceAccount type="DomainUser">
    <DeploymentServiceAccount type="DomainUser">
    <AsyncServiceAccount type="DomainUser">
    <VSSWriterServiceAccount type="DomainUser"> 
    <MonitoringServiceAccount type="DomainUser">
      <SQM optin="false"/>
     <muoptin optin="true"/>

Both files, once ready, should look something like this:


  1. The next step, presumably the trickiest, is actually getting the installation files onto our Core server. As we saw, on the Core installation we have limited command line functionality, making it impractical to simply “copy & paste” the files across. Fortunately, Core installations are configured so that the root drive can be accessed over a network connection; meaning that we can drop our files anywhere on the C:\ drive and access them via the cd command on the prompt window. To begin with, we will navigate to our computer using Windows Explorer on our other machine, replacing the JG-CRM with the name of your Core server:ServerCore_Setup4We can then navigate through and create a temporary folder on the drive root where we can move across all of our required files:ServerCore_Setup5Finally, because the CRM2016-Server-ENU-amd64.exe file is a self-extracting executable, we need to first extract all of the files into a temporary location on our non-Core server; then, ensure that all of these files are copied across to our Core Server, along with our config. xml file:ServerCore_Setup6
  2. With everything copied across, we can begin the installation. Going back onto our Server Core, we first need to navigate to the location of our installation folder using the cd command:ServerCore_Setup7

Next, we can run the CRM setup executable (SetupServer.exe), specifying the following required parameters:

/Q – Quiet Mode installation

/config C:\CRMInstall\CRMServerInstall_Config.xml – The file path to the config XML file that was copied across earlier


  1. Once we hit return on the above, the command will be accepted and you will immediately be given control back to the command prompt window: ServerCore_Setup9At this stage, you may assume that something has gone wrong. But don’t panic – this is just a result of specifying a quiet mode installation. CRM will begin installing in the background and stop if any errors are encountered. Progress can be monitored by reviewing the CRM setup log files from our other server, by navigating to the currently logged in users AppData\Roaming\Microsoft\MSCRM\Logs folder:ServerCore_Setup10
  2. Assuming your installation has been completed successfully, the following Server Roles will now be available on your Server Core:
    • Web Application Server
    • Organization Web Service
    • Discovery Web Service
    • Asynchronous Processing Service
    • Sandbox Processing Service
    • Deployment Web Service

The Help Server role will not have been installed, so therefore we must run the setup for this on another non-Server Core server. The Reporting Extensions role would need to be installed on the server that has your SSRS instance, so therefore it could not be installed on our Server Core server used above. I have also deliberately left out the Deployment Tools role as part of the above, which I would strongly recommend is installed on another Windows Server instance (for ease of access more than anything). The process is the same as part of any standard CRM installation and, therefore, will not be covered as part of this post.

Thoughts & Summary

Some of the more obvious benefits of having a Server Core CRM deployment have already been hinted at. For example, I think it is definitely useful to be a in a position where you can ensure that your CRM deployment is completely free from competing with other Server resources; a Server Core installation allows you to achieve this aim quickly and easily, in a way that is fully supported by Microsoft. Installing CRM in this manner also presents some interesting opportunities for managed hosting providers, as the manner of deployment and installation (via quiet mode installation) could be easily automated in order to enable re-sellers to quickly roll-out hosted CRM instances to their customers.

Taking a look at the other side of the coin, installing CRM via this route definitely requires some patience and perseverance. I encountered several issues during installation which cancelled the install entirely, due to incorrect Service Account Details, lack of account permissions etc. It will therefore take you a number of attempts before you can start to identify the common problems that need to be dealt with before commencing the silent installation, which would ideally need to be dealt with via PowerShell script automation or similar. I would also question why it is not possible to do a Full Install (minus Reporting Extensions) on a Server Core instance. My assumption would be that the Help Server & Deployment Tools rely on Windows Server features that are stripped out during a Core installation. If your ultimate aim is to minimise hardware costs by utilising Server Core, then having to factor in additional servers/hardware for an additional Windows Server on top of this seems excessive. You would then also begin to question why you would just not use a standardWindows Server instance to start with. Finally, there doesn’t appear to be any (obvious) means of specifying specific server roles to install as part of the silent installation. This kind of defeats the whole purpose of using Server Cores to scale out the workload of your CRM server across multiple Windows Servers.

In conclusion, should you be opting to have a CRM Server Core installation in the near future? I would say “not yet” for the simple reason that you cannot select specific Server Roles to install as part of installing CRM in this manner. In my mind, this eliminates one of the most obvious benefits of marrying together CRM and Server Core. Perhaps in future, when/if you can specify individual Server Roles in the config file (or if someone can correct me in the comments below!), this will become something that can be looked at more seriously. For now though, you can save yourself the hassle.

It is sometimes desirable to grant Send on Behalf permissions in Exchange for users who are accessing another mailbox in order to reply to email messages. Some typical scenarios for this may include a personal assistant who manages a company directors mailbox, a group of users who manage a central support mailbox or for ad-hoc scenarios, such as when a colleague is out of the office. Send on Behalf permissions provide the best level of courtesy when responding to an email by letting the person know that someone else is answering an email addressed to an individual, and I would say it is generally the more recommended approach compared to granting Send As permission.

Within Office 365/Exchange Online, we can very easily grant Send on Behalf permissions for a standard user mailbox (i.e. a user that has been granted an Exchange license on the Office 365 portal) via the user interface; just go into the mailbox in question, navigate to mailbox delegation and then simply add in the users who need the required permissions:


Then, give it twenty minutes or so and then the user can then send as this user from the From field in Outlook successfully – nice and easy, just the way we like it 🙂

But what happens if we wanted to grant the very same permissions for a shared mailbox? Say that we had an IT support help desk with a shared mailbox that several different users need Send on Behalf permissions for. Within the Office 365 GUI interface, we have options only to grant Send As and Full Access permissions:


So, in order to accomplish our objective in this instance, we need to look at going down the PowerShell route. Microsoft enables administrators to connect to their Office 365 tenant via a PowerShell command. This will then let you perform pretty much everything that you can achieve via the user interface, as well as a few additional commands not available by default – as you may have already guessed, granting Send on Behalf permissions for a shared mailbox is one of those things.

Microsoft have devoted a number of TechNet articles to the subject, and the one found here is an excellent starting point to get you up and running. The salient points from this article are summarised below:

  • Ensure that the latest versions .NET Framework and Windows PowerShell are installed on your 64 bit Windows machine. These can be added via the Turn Windows features On or Off screen, which can be accessed via the search box on your Windows Start Menu or in Control Panel -> Programs and Features -> Turn Windows features On or Off,
  • Download and install the Microsoft Online Services Sign-In Assistant
  • Download and run the Azure Active Directory Module for Windows PowerShell

Once you’ve got everything setup, open up PowerShell and run the following script, altering where appropriate to suit your requirements/environment:

# Remove result limits due to console truncation


# Connect to Office 365. When prompted, login in with MSO credentials

Set-ExecutionPolicy Unrestricted -Force 
Import-Module MSOnline  
$O365Cred = Get-Credential  
$O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection  
Import-PSSession $O365Session -AllowClobber  
Connect-MsolService –Credential $O365Cred

# Add additonal users to Send on Behalf permissions for mailbox. add= list if a comma seperate list. Each email address should be in double quoted brackets

Set-mailbox ‘MySharedMailbox’ –Grantsendonbehalfto @{add="john.smith@domain.com"}

# Confirm that user has been succesfully added to send on behalf permissions for mailbox

Get-Mailbox 'MySharedMailbox' | ft Name,grantsendonbehalfto -wrap

# Display exit script (to keep window open in order to view the above)

Read-Host -Prompt "Press Enter to exit"

The nice thing about this code snippet is that you can grant multiple users Send on Behalf permissions at the same time, which is really handy.

Based on my experience, the above has been a pretty regular request that has come through via support in the past. I am unsure whether this is common across different organisations or not; if it is, then I am really surprised that the Office 365 interface has not been updated accordingly. The important thing is that we can ultimately do this in Office 365, as you would expect via an on-premise Exchange Server. As such, organisations can be assured that if they are planning a migration onto Office 365 in the near future, they won’t be losing out feature-wise as a result of moving to the platform. And, finally, it is always good to learn about something new, like PowerShell, so we can also say that we’ve broadened our knowledge by completing the above 🙂


When I first took a look at some of the additions I was looking forward to as part of the CRM 2016 Spring Wave, I made reference to the new Email Signature feature. At the time, there did not appear to be any way of accessing this via the GUI interface within CRM; this is despite the fact there were, clearly, new system entities in the system corresponding to Email Signatures. There appears to have been some small update or change since my original post however, as it is now available within Online/On-Premise 8.1 CRM instances 🙂 . To take advantage of the new feature depends on what version of CRM you are running:

Once you’ve finished updating, you are good to go. To then setup an Email Signature for your user account, you will need to do the following:

  1.  Navigate to the Email Signature window within CRM. This can be accessed in either 1 of 2 ways:
    • The first is via the Set Personal Options screen, on the Email Signatures tab:1 2 3
    • The second is via the Sitemap Area, in Settings -> Templates -> Email Signatures:9 10
  2. Regardless of how you have got there, press the New button to open the New Email Signature window:154
  3. Give your signature a name and then populate the text area with your desired signature. You can make use of the rich text formatting in order to style your signature. Or, alternatively, you can copy & paste your signature from another application (Word, Outlook etc.):5
  4. Once you are happy with your signature, press Save. At this point, the signature will now be available whenever you create a new email record. However, in order to make the signature appear automatically whenever you draft a new email, you will need to press the Set as Default button:6If you need to revert this at any point, then you can use the Remove Default button, which replaces the above button:7
  5. Press Save and Close to finish setting up your signature. It will now be visible within the Email Signature subgrid view:8 11
  6. Now, when you navigate to create a new Email record, your newly created signature will be visible on the email:12
  7. If, for whatever reason, you need to select a different Email Signature, then press the Insert Signature button, which will then prompt you to select a new Email Signature to use:1413

I am really glad that this feature has finally been added to CRM, however…

There appear to be three glaring issues, that really need to be addressed in order to make Email Signatures work better:

  • Email Signatures are only configurable on a per-user basis. What that translates to is that if one user creates an email signature and sets it as their default, another user can log in and see this, but cannot apply it to themselves or set it as their default; if the second user wanted an email signature, they would need to create one manually. The implications for this should be fairly obvious, and I find it somewhat confusing that there is not way to setup a common template that can be then be applied and customised individually for each user on CRM.
  • There is no option, unlike Email Templates, to insert dynamic Data Field Values. So you cannot, for example, populate an e-mail signature based on information from the Job Title field on the currently logged in User account. This makes the feature impractical as a central Email Signature management tool; instead, you would have to go through the potentially rather tedious task of setting up Email Signatures for every user account on a system. Not so bad if you have a dozen or so users on your CRM instance, but if you have hundreds of users…you get the point.
  • Whilst recently studying for the CRM 2016 Service exam, I was really impressed to see that the Knowledge Article feature had been given a face lift in line with the new Interactive Service Dashboard. In particular, the text editing functionality has been improved significantly, with a range of new text editing options – many of which are not included as part of creating an Email Signature. Below is an image highlighting each of the new text editing features not available on Email Signatures, but available as part of the enhanced Knowledge Article functionality:16As you can see, there are a number options as part of the above which would be incredibly useful from a Email Signature creation point of view – Insert Image, Font Colour and View Source (perhaps the most crucial, if your organisation uses HTML signatures). I wonder why, therefore, the new Email Signature feature was not modeled in the same vein as the above.


Previously, in an attempt to replicate email signature functionality, the recommended approach was to setup an Email Template. This is beneficial when it comes to larger CRM deployments, as the dynamic data fields functionality can be utilised when creating a common template. The introduction of the new Email Signature functionality does not, in my view, mean there should be a change to this approach. I think if your CRM deployment contains a small amount of users and you have a very simplistic, existing email signature, then you can perhaps get away with using this new feature without causing yourself too many problems. Until the above issues are addressed however, I would not recommend migrating away from what you are using currently to provide email signature functionality within your CRM. This is a real shame, as I was hoping the introduction of this feature would resolve some of the headaches that I have encountered previously working with complex email signatures in CRM. Fingers cross we see Email Signatures get a bit more love and attention as part of the next major release of CRM.

The current talk around CRM at the moment is all about the Spring Wave AKA the CRM 2016 Update 1. Unlike Dynamics CRM 2015 Update 1, released at the same time last year, On-Premise customers can also take advantage of the latest update now by downloading Service Pack 1. Now it’s worth pointing out that some features, such as Guided Help and Field Service Management, are not made available to On-Premise customers at this time. Nevertheless, I think it’s a really positive step forward that On-Premise customers get most, if not all, of the latest updates as part of the Spring Wave, at the same time as Online customers. I’ve already talked previously about some of the great things to expect as part of the Spring Wave, so I would strongly recommend that organisations look at scheduling in their on-premise upgrade sooner rather than later. The main reason is the simplicity involved behind the actual upgrade process, which is the focus for this week’s blog post:

How to Download Service Pack 1

If you have enrolled your Dynamics CRM installation into Windows Update, then currently SP1 does not appear when your run Check for Updates on your CRM Server (this will change starting from Q3, according this knowledgebase article). Therefore, you will need to download the update manually via the following link:


There are a number of install files available as part of the update. On first glance, it can be difficult to determine which update file relates to which component of your CRM installation, so I have provided a summary of this below:

CRM2016-Client-KB3154952-ENU-Amd64.exe – Outlook Client (64 Bit)
CRM2016-Client-KB3154952-ENU-I386.exe – Outlook Client (32 Bit)
CRM2016-Mui-KB3154952-ENU-Amd64.exe – Outlook Client (64 Bit) Language Pack – English
CRM2016-Mui-KB3154952-ENU-I386.exe – Outlook Client (32 Bit) Language Pack – English
CRM2016-Router-KB3154952-ENU-Amd64.exe –  Email Router (64 Bit)
CRM2016-Router-KB3154952-ENU-I386.exe – Email Router (32 Bit)
CRM2016-Server-KB3154952-ENU-Amd64.exe – Server Update
CRM2016-Srs-KB3154952-ENU-Amd64.exe – Reporting Extensions

There is also a final file – CRM2016-Tools-KB3154952-ENU-amd64.exe – which I believe may be some kind of utility to perform database upgrades. I have been unable to get this working successfully on my end and, from the looks it, the server update performs the database upgrade as part of the update. If anyone knows what this is for and how it works, let me know in the comments below.

Installing the Update

The update is really simple – this is backed up by the fact that it can be completed in as little as 6 button presses!

After running the self-extracting installer, you will be greeted with the first screen of the setup process:


As is always the case, accept the license agreement:


Then, confirm that you are ready to begin the installation:


The installation process shouldn’t take long (about 10 -15 minutes when I performed it). Once complete, you’ll then be able to view the installation log file and specify whether or not you want to restart the server immediately:



As part of the update, your organisations and databases will be automatically updated to the latest version. So, no need to manually perform this yourself after the update.

Reporting Extensions Update

The only thing to point out with this is that this will need to be installed on the same machine as your CRM’s SSRS instance. Depending on your On-Premise deployment, your SSRS instance may be installed on a different server. The actual process of installing the update is identical to the above. Fortunately, however, a server reboot is not required 🙂

Outlook Client Update

Updating the Outlook client is also very similar and straightforward. Any existing connections will still work after the update. You will also need to install the update(s) for any currently installed language pack(s) immediately after this update is complete. In most cases, this will just be the one update for your CRM organization’s base language. Depending on the size and complexity of your CRM deployment, you may need to plan carefully to ensure a successful roll-out; you may be happy to note that the existing CRM client should still work with a 8.1 CRM instance, so you can always choose to defer this part of the update entirely.

The Testing Conundrum

As with any application update, it is always prudent to ensure that you have performed some kind of testing. This can be invaluable in identifying issues that can then be resolved in good time, without causing disruption to colleagues/end-users of the application.

The difficulty in this particular case is that the update appears to automatically update all organizations on a CRM instance in one fell swoop. So you cannot, for example, setup a copy of your primary CRM instance that you can perform a test upgrade on. You would therefore have to deploy an entirely separate CRM instance which you can perform the necessary testing on. You can use a trial key to cover the initial licensing hurdle, but you will still need to allocate hardware and put time aside to get your temporary testing environment setup.

Given that this release is not a “major” release of the application, I would argue softly that you can probably throw caution to the wind and perform the update with a minimal amount of testing, particularly if your CRM instance has not been significantly customised/extended. There does not appear to be anything majorly changed under the hood of CRM for this release that could cause problems (unlike the 2015 Spring Wave release for CRM Online). In order to best inform your decision on this, you should consider the following factors:

  • Are you able to schedule your CRM update over a weekend or extended out of hours slot, and have resources in place to perform any post-update testing? If the answer is yes, then you may be able to get away with not performing any pre-update testing.
  • What is the maximum amount of time your CRM instance can be taken down for during normal working hours?
  • Does your CRM utilise the Email Router, CRM for Outlook and/or multiple language packs? If yes, then performing upgrade testing of these components may be beneficial.
  • Does your business have a spare Windows Server instance that can be used for a test upgrade, without incurring additional cost to the business? If yes, then a major impediment has been eliminated, meaning that you should look at performing a test update.

Has anyone performed an On-Premise upgrade to SP1 yet? Let me know your experience and comments below!