Running SCSM 2016 TP5 on SQL AlwaysOn Availability Group - "Execution of user code in the .Net Framework is disabled"

Posted on Aug 3, 2016

Now that the new Service Manager release is just around the corner, more and more customers are asking to deploy Service Manager 2016 TP5 in production. Benefits of deploying Service Manager 2016 TP5 are listed below. For a complete list of new features in Service Manager 2016 TP5, please see

  • New Self-Service Portal
  • Performance improvements
  • Support for Lync 2013 and Skype for Business
  • Changes to Setup supporting SQL AlwaysOn Availability Groups installation
  • Support for .NET Framework 4.5.1

One cool thing is that Setup now supports SQL AlwaysOn Availability Groups installation. No more hacks and workarounds when Performing a fresh installation of Service Manager with SQL Server 2014. :-)

First installation of SCSM TP5 on SQL AlwaysOn Availability Groups was done quickly and without any issues. However as soon as the Service Manager DB switched from the initial SQL AlwaysOn node to the other one, all my custom classes and forms stopped working. All I got was the following error message when creating a new object from SCSM console:

Execution of user code in .NET Framework is disabled. Enable “clr enabled” configuration option.

CLR Error

The error message pretty much shows the solution to the problem. I checked both SQL Always On nodes to see if “clr enabled” configuration option is actually enabled.

CLR Configuration Option Disabled

As suspected, the option was only enabled on the one node which was the primary one at the time of Service Manager installation. It seems as if the SCSM 2016 TP5 installer does not configure “clr enabled” configuration option on all nodes of a SQL Always On cluster.

Luckily, enabling this configuration option is a piece of cake :-) The following SQL commands will enable “CLR Enabled”. Check out for more information

    sp_configure 'show advanced options', 1;
    sp_configure 'clr enabled', 1;

CLR Configuration Option Enabled

I will try to reach out to the product team to check with them if this is an isolated case or if this may happen for all installations on SQL Server 2014 AlwaysOn Availability Groups.