Search

Antony Ellis Dynamics 365 CRM

The blog where Microsoft Dynamics 365 knowledge is shared and development made easier

Month

March 2017

Understanding Dynamics 365 Solutions

What’s The Story

There are two types of solution in Microsoft Dynamics 365.

Managed and unmanaged.

Which one should be used in any given situation is up for debate (no it really is). On one hand you have Microsoft saying that unmanaged should be exported as Managed when targeting any instance which is not the development environment typically meaning UAT and Production.

This is part of the ALM guidance which is only 76+ pages so enjoy the read. I’m going to try and keep this article snappy to give you the main considerations and background to the whole managed vs unmanaged debate based on my practical experience of using both approach in CRM implementations.

Understanding Solution Levels

Any dynamics 365 instance has the following layers or levels:

  • System Layer
  • Unmanaged Layer
  • Managed Layer

System layer is known as the “default solution” it contains all out of the box customisations, so is the vanilla instance if you will of a CRM instance once provisioned. Now, when we create unmanaged solutions, we are creating a container or view into the default solution, the solution itself (or the reference) is stored in the unmanaged layer but understand, as they are unmanaged solutions, we are effectively modifying the default solution. This means that an unmanaged solution cannot be uninstalled. I think of unmanaged solutions as “a view” into the system or if you like the source code of the solution and a managed solution is the assembly. If you delete a unmanaged solution, it will only delete the reference entry in the unmanaged layer, the customisation remain in the default solution.

A managed solution on the other hand is non-editable though some managed properties can be set, they (and their specific customisations) can also be uninstalled (mostly) from the system. Managed solutions can be layered (stacked) on top of each other so in a sense provide version control. How effective is that version control? Why would we want cross solution dependencies (layered functionality)? How easy is it to update a managed solution in a target instance especially if the customer breaks or changes something directly in those environments? All are separate considerations when looking at the listed pros and cons of each approach.

The Cumulative Nature Of Solutions

As the header states, whether managed or unmanaged, they effectively make additions to the platform as we are customising the system either at the system layer or managed layer. For this reason, if something new is added to the system it can never be completely removed (there are fragments of it left in the metadata) but what is true is that if you delete a component/attribute/relationship in an unmanaged solution it will be removed from the platform vs. not having that option if you deployed as a managed solution. Did you get that if not read the last line again… you can not delete anything when you deployed as managed. That should signal alarm bells if you are NOT an ISV and are for example working in an Agile environment on a Dynamics 365 implementation.

Managed Solutions Overview

Managed solutions are “cumulative” even if you overwrite a managed solution with a newer version it will not remove the old components or change that metadata. The only way to remove components is to uninstall the managed solution completely however that will also drop any reference or user data that you may have previously imported (I’ll touch on the holding workaround and Dynamics 2016 new features later on). A managed solution funnily enough means everything is well err managed so that means components such as:

  • Entities
  • Javascript
  • Views
  • Attributes
  • Relationships
  • Forms
  • Option Sets

Will not be removed, even when they are not included in an updated managed solution version. Also you can not go in there and manually delete managed components directly so all of those old relationships, attributes and the rest will sit in the system bloating it over time. Managed solutions can also be a nightmare when you are looking to update them with a new version especially if you have removed things like relationships from dev and then try to import conflicting changes.

Which One Should Be Used

There are a few key things to consider. Managed solutions really were created so that Microsoft Partners/Independent Software Vendor (ISV) had a means to protect their IPR, package up and sell solutions to the market along with the means to issue updated versions in a controlled way. The official line is that a mature customer would want a robust and version controlled release cycle and so managed solutions (in theory) provide this capability as they are layered and you can’t edit them or remove directly in the target environments (without completely uninstalling).

Scratch that for a second, take note “Ever noticed in life there is often a big difference between what one should do as deemed to be best practice vs. reality of what actually happens?”.

I’m going to summarise when one is preferred over the other… here goes:

  • Use Managed solutions if you are a ISV and plan to release to the market place.
  • Use Unmanaged solutions where you are working on an ever-changing platform meaning customisations are happening all the time so it is not a fixed deployment.

If you can’t trust the development team to update solution versions before export, check-out and check-in code into TFS or whatever code repository you have in place and follow a good release practice then I would argue that’s a fundamental issue outside of whether to use managed or unmanaged solutions. Restricting a deployment and adding technical complexity is not the answer.

To me, it seems to come down to a couple of things namely “trust” and “paranoia”. You need to trust that developers are not silly enough to go and customise the system in UAT/Production thereby causing issues the next time one tries to import a solution. You also would ensure that the customer has the security roles appropriate to their level of knowledge.

If you have a team of developers all working on CRM, chances are you may not even have a “core solution” because that would be huge and take ages every time you wanted to deploy or customise the application ribbon. Once the core CRM has been customised and released to Production, chances are there will be multiple maintenance type sprints a decision would be needed on whether to have the one main solution or to have multiple unmanaged solutions representing the sprint and user story (separate article on that one!) which you would deploy individually to UAT and then Production in the right order.

Add to this mixture, the problem of then having to work with Managed solutions across UAT and Production environments.

In a nutshell, using managed solutions adds more complexity to the development and release process for very little gain (unless you are a ISV).

Now in Dynamics 2016, to be fair Microsoft has added functionality so you can be very specific on what customisations should be included in a solution, along with patching, cloning and a stage for upgrade option, so this helps with reducing potential conflicts and dependencies that would otherwise cause a solution import to fail. Wonderful… but guess what, that is still adding more complexity to the release process. Holding solutions can also be used to help with data retention when looking to drop old components or fix any conflicting issues.

In my experience, there doesn’t appear to be a “right” or “wrong” answer to the question. I personally always go with the Microsoft/best practice recommendations but quite honestly, I have only ever seen managed solutions make implementations more complex for both the customer and development team for “zero” benefit. If there is good communication in the team, appropriate security models setup for the customer and fit for purpose release and development processes one can avoid the pain of managed solutions by addressing the real issues and project challenges head on.

Further Reading

http://www.crmconsultants.co.uk/managed-vs-unmanaged-solutions/

http://www.crmconsultants.co.uk/improving-release-management-with-solutions-in-dynamics-crm-2016/

http://gonzaloruizcrm.blogspot.co.uk/2012/05/crm-2011-deleting-attributes-entities.html

http://gonzaloruizcrm.blogspot.co.uk/2012/01/managed-or-unmanaged-solutions-in-crm.html

https://social.microsoft.com/Forums/en-US/80f9be38-1e55-4de8-953c-2143fb7e5510/crm-2011-removing-entity-relationships-in-managed-solution?forum=crmdevelopment

 

Advertisements

CRM 2016 -Problems after renaming the CRM Server

Big, big, major caveat here this article talks about stuff that is unsupported by Microsoft regarding the Dynamics platform just so we are clear from outset. Recently I stumbled across an old article from The Hosk concerning how changing the server name in 2011 broke the deployment.

It got me thinking whether the same would be true for CRM Dynamics 2016 so I had a play with one of my local virtual machines and committed the Sin of changing the server name. Actually, committed many sins one of them was not taking a backup of my VM first and thereby rendering it useless at this point in time.

Anyways, as I should have expected this completely buggered up the Dynamics CRM application. Now before I get into what I did to fix it, it’s worth pointing out that the safest approach is to uninstall Dynamics CRM and then re-install after you have changed the server name. In addition would not recommend the approach I took either especially on a commercial server. So following the server name change the following were broken:

  • CRM Deployment manager
  • CRM application
  • SQL Server (Configuration)
  • MSCRM_CONFIG database
  • SSRS
  • Registry Settings!

Ouch.

Concerning Active directory

  • PrivUserGroup
  • SQLAccessGroup
  • ReportingGroup
  • PrivReportingGroup

 

In my case didn’t need to change anything here or mess about with domain GUID’s/entries because the organisation was still on the same domain and active directory therefore had the same GUID’s as before and new that the server was the same server so it just updated the member list automatically using the new server name. This may not be the same behaviour for older versions of Active Directory.

Fixing Deployment Manager (Connection Error)

This was completely buggered to point where it could not connect to CRM. The deployment manager is mostly dependent upon the registry for its settings at least when it comes to making the connection and of course MSCRM_CONFIG database. When trying to run the deployment manager it came back with an error stating the MSCRM_CONFIG database was not available and/or removed.

  1. Rename the server and don’t tick restart at this point
  2. Close all browser windows/crm tools
  3. Go to registry and update
    1. HKEY_LOCAL_MACHINE/SOFTWARE/MICROSOFT/MSCRM
    2. Change the old server name to new server name in keys (configDB key, serverURL)

Update the MS_CONFIG DB tables and change any reference to old server name with the new server name you will need to check each of the fields to be safe in these tables:

  • Server
  • Organization
  • SystemUserOrganizations

At this point if you were to restart the server you would find the CRM application will be working again however other things will still be broken for example the end point URL’s displayed in the organisation still have old server names and the deployment manager is broken when you try to create a new organisation.

Fixed Yet?

Nope. To finish off we need to update SQL Server, Deployment manager settings and the Reporting Services configuration manager.

Fixing SQL Server

This was needed for both the create New Organisation and the CRM Diagnostic check (Run within the new organisation and repair, remove CRM setup application) to work, otherwise you will get errors saying that the Instance name must not be the same.

Firstly … check what the server name is at the moment concerning SQL Server

SELECT @@Servername

This returned old Server Name In SQL Server

Even though we have updated the CRM settings, the SQL Server instance still has references to the old server name. In order to resolve this we need to go into SQL Server and run the following T-SQL:

use master

go

SELECT @@Servername

exec Sp_dropserver ‘Value returned by @@ServerName’

exec Sp_addserver ‘The current server name’,local

Restart the SQL Server instance after executing the above T-SQL.

Fixing the SSRS Configuration

If the SQL Server Name is still showing the old server name you need to click on Change Database and redeploy the reporting database either to a new database or overwrite the existing one.

picture1

Fixing Deployment Manager (New Organisation and Web Service End Points)

To fix the browse link going to wrong (old server) and to ensure end-points displayed in CRM organisation application is correct you need to the update the following which you get to by right-clicking on the top node in deployment manager (Microsoft Dynamics CRM Server) then editing the properties:

picture2

After which the Deployment Manager new organisation functionality should work. It is worth noting the above was also needed to fix the CRM diagnostic checks which are done by both deployment manager or when you try to change the CRM installation via add/remove programs.

Finally: Restart the Server.

Did it work?

For me it appears to be working ok.

Should you do it?

Nah absolutely not! It is best to do a clean re-install. The moment I encounter a strange issue within this dev environment you can bet money on it that I will do a clean install of CRM 2016 because it will always be in the back of my mind “could this be related to that time I changed the server name!” however for academic purposes thought would share the experience.

Powered by WordPress.com.

Up ↑