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!
A query reveals: the basic functionality is divided into separate solutions (Sales, Service, Marketing, Scheduling, …), most of them hidden. 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, tricks and tweaks 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.
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, if you have upgraded your instance from v8.2 instead of having an instance created brand new 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.
Let’s check again the background, as for admins apparently no solution is available:
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
Activesolution (eg usingModifiedByfield). Now, they are distributed betweenActive,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?
