I
thought I should somehow round up the “Minimal copy” blogs with some sort of
conclusions or rather recap perhaps. The base of this blog is that a minimal
copy of a production instance wound up being 4.3GB which later was downsized
with roughly 3GB.
The base of this text is “What are we
paying for” when a subscription of Microsoft Dynamics 365 Customer Engagement
is started. This has actually just changed but there are still some questions
from my side. As of now, or when your subscription renews, you will have 10GB
of database capacity, 20GB of file capacity and 2GB of log capacity per
subscription.
The change is to begin with that the
“attachments to notes or emails in Dynamics 365 Customer Engagement
applications and PowerApps” (from the license document) no longer is counted as
database storage, which is a good thing. I don’t know how many customers have
wanted to delete attachments and there’s even a solution moving attachments to
Sharepoint, which still is a good idea since Sharepoint is better at storing
documents.
The next thing that’s nice is that logs are
counted as a separate store. I can’t say from the top of my head how much 2GB
of logs are worth since it depends on how much auditing you are doing, the
possible downside of this is that you don’t get any extra log storage from
buying more licenses of Dynamics 365 Customer Engagement (I will address this
later).
 |
| Sometimes this is how I feel |
Ok, entity definitions and data. This means
we are paying for the data we put into the system and for the schema. Not only
the customizations we do but the standard schema as well. This might very well
be reasonable but I don’t think this is what most customers think they’re
paying for so it’s a good thing to know if you’re a partner and also good to
know if you’re a customer.
This is where things gets interesting to me
because a completely out of the box new instance of Dynamics 365 v9 on premise
(ok latin-something collation since finnish_swedish is not working atm) is
roughly 1.1GB compared to a Dynamics 365 v8.2 which is around 0.6GB. This 1GB
storage of an empty instance is also true when we have Dynamics 365 Customer
Engagement online, which I actually thought was a bit much when discussing it
with the support but it turns out that the vanilla-no-data instance has doubled
in size during the last version. So when
we look at 10GB of data per subscription, more than 1GB of that is taken per
instance we’re having on it. For example, if we would have 1 production instance
and 2 sandboxes (1 development and 1 test), 3GB of data would be consumed by
just the instances. This is something that’s good to know at least.
Moving on with the licensing experience
(ok, I don’t know if it’s still called this but it’s a too good a name to not
use. It was called this during a presentation of Dynamics CRM 2013) you will
get an additional 0,25GB of database storage and 2GB of file storage per
Enterprise license. No log storage is added by having licenses. Extra storage
is bought by the GB per type and I haven’t been able to find any price for this
but that might be a case of bad Google-fu on my part (sorry but Bing-fu doesn’t
sound as catchy).
When I was starting to dig into this I was
able to download a report from the Power Platform Admin Center (one of three or
four admin centers at the moment) which showed in which tables data was
consumed. That report has since been removed after Microsoft changed the
storage thingy to a new name and a new portal which doesn’t show as much
information as it used to, yet at least. These portals and information flows
tend to shift over time. The result as of 2019-05-20 is that you can’t tell
where your data is consumed. What didn’t show in that report though was how
much data that was consumed by “not your data” i.e. the system so a completely
empty instance will eat some 1GB of data storage as I wrote earlier. And with
that report being removed, I can’t tell what a completely empty instance will
show as consumed for contacts for example.
Conclusions
This all boils down to that there’s no real
way of telling what you actually consume and we have to rely on Microsoft
telling us what is actually in our instances which in this case wasn’t entirely
true and I had to push back rather hard to make them believe that 4.3GB of data
for an empty instance is not reasonable. This is easy to think that something’s
wrong in an instance that you would think is empty but when you have an
instance filled with data it’s quite the opposite.
In this case we made a minimal copy from
production to an empty instance and started to fill it with data from source
systems thinking we would use that instance as the new production so we cleared
the “old production”. After a while we made a choice to redo the migration and
did a minimal copy from the just filled instance to the “old production” and when that was done, the
“sort-of-.reliable-source” of this was erased. So, for most cases you risk
getting this issue in the instances you set up from another instance. And in
most cases that shouldn’t be all your instances, even if it’s not unthinkable
it’s more than one.
The data usage per table report that has been removed will hopefully be re-introduced shortly.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
Developer at CRM-Konsulterna
www.crmkonsulterna.se
