Traces of the Icebreakers — hidden solutions of a vanilla Dynamics version 9


Lately, we have had a lot of headaches around Microsoft patches, being applied in our v9 instances (read Ben Hosking’s article HERE), without any notice.

I have started to wonder: what lies behind the scenes? What is the infamous Icebreakers solution (which created Hidden Dependencies for almost everyone), and is it alone? Yet, as I searched through the internet, couldn’t find any related information.

So, this time, let’s look under the hood! And well, if you stay with me, at the end you will also have a good proof of Dynamics’s shift from a monolithic model into a modular, app-centric platform!


Down below

While writing this post, my newborn (no preinstalled apps) trial instance is on Version 1612 (9.0.2.193) (DB 9.0.2.193) online.

At the moment, v9 instances by default come with 4 solutions. They contain some OOB custom controls (read Luke Benting’s article HERE), the Environment Maker security role (Flow/PowerApps, let us unite!) and the basic CRM Hub. Don’t get stuck though, check the hidden parts, as there is the yet unknown!

46 solutions found on vanilla

A query reveals: the basic functionality is divided into separate solutions (Sales, Service, Marketing, Scheduling, …). Adjoining services (Lync, Yammer, ..) are packed into their own modules, making them replaceable and detached from the main.

And well, there it is, the Icebreakers. Based on a quick look into it’s components (bit of unpacking here, decompiling there, ..), I suspect it will work with Actionable Messages to gather insights based on a given contact’s email address and show them in organised categories for the user to ease conversation starters. But more on this maybe later in another post.

the 4 OOB apps come in 13 solutions at the moment

A note: if you choose any of the starting apps (Customer service, Sales, …), the msdynce_CRMHub won’t be installed, but instead the relevant Apps and Hubs will be added. Also, as expected from modularity - unaffected by the choice - all the other hidden solutions will be added with the same version, as if you wouldn’t have chosen any starting apps.

What is interesting though, that there is a difference between the installed solutions, when you have upgraded your instance from v8.2 instead of having an instance created as v9.


Comparison to v8.2

To better understand and value the changes, I have restored my trial instance to v8.2. At the moment, Version 1612 (8.2.2.1659) (DB 8.2.2.1659) online is available.

the solution view in UI

Let’s check again the background:

The empty system has 10 solutions in total, although none of them visible in the user interface. On a closer look, most of these are just placeholders or containers for compatibility, so the real magic is indeed packed into a small slice of them.


Relevance

Now you may say “Why should this matter to me at all?” with a puzzled look on your face. Well, this modular shift means:

  • Ability for Microsoft to deliver bug-fixes quicker without updating the whole system
  • Ability for Microsoft to deliver minor updates with ease to specific components
  • Ability for Microsoft to add in or amend preview features in a comfortable way

We can expect (and already experience) more frequent patches in our online instances!

  • Reduced amount of built-in platform bugs, as testing of modules can be more thorough
  • widely spread OOB dependencies — check Solution XML. Previously, we could only create dependencies on the Active solution (eg using ModifiedBy field). Now, they are distributed between Active, msdynce_Service, msdynce_Marketing, …

And more importantly: Online instances can end up on different versions as they are not patched at the same time — even within the same region! This could (and does) introduce unexpected and even yet unseen deployment issues of the most various kind!


What do you think? How are you mitigating the risk of unannounced platform changes in your business? What are your thoughts about the shift towards modularity in the background?