Latest Customer Engagement Licensing Change Could Lead to Dynamics 365 Storage Cost Increase
With the latest Dynamics 365 licensing changes (see Dynamics 365 Licensing Guide – April, 2020), there’s one change that small business owners and IT administrators should be aware of. If you’re running Microsoft Dynamics 365 Customer Engagement (CRM), then you need to be aware that the data storage model is changing, and could potentially lead to a Dynamics 365 Storage Cost Increase.
Where to Look to Identify Biggest Data Storage Offenders
The first place to look to see if you may be impacted is the Power Platform Admin Center. Just navigate to https://admin.powerplatform.microsoft.com and look at the summarized storage capacity usage. Note that the storage capacity summary shows how much data storage is used by all the environments in the tenant. The storage capacity is broken down by Database, Log, and File type. Database is your actual data, Log is your audit logs, and File is file attachments.
Until this change, a lot of third-party add-ins were geared towards reducing the amount of space used by file attachments in your CRM system. It is hardly necessary to worry about files saved in your CRM system now, because you’ll have 20 GB for the tenant to start, and an additional 2GB for each full-licensed user. So, if you have 15 users, you’ll have 50GB of file storage — more than enough for most user environments.
However the Database Storage metric is more likely to be over the available capacity. You get 10GB for the tenant, and an incremental 0.25GB for each full-licensed user. As shown on the capacity summary image above, you can see that 10GB + 15 users x 0.25GB = 13.75GB. And you can see that we’re using 11.07 out of 13.75GB. Again note, this is the summary page and measures across all your environments (e.g., your Production plus your Test environments). The screenshot below shows the breakdown by environment (or organization).
Impact of Dynamics 365 Storage Costs Increase
Here we can start to get an idea of the impact of the Dynamics 365 Storage Costs Increase, if you have a few years of data, and a full-copy test environment, you may be over your allotted capacity for the CDS Database Capacity metric. Under the previous licensing, you could buy additional capacity for $5 / GB per month. Now it’s $40 / GB per month.
type of storage capacity | Included Capacity | Incremental Capacity for Each Full-Licensed User | Additional Storage Cost |
CDS Database Capacity (e.g., relational database data) | 10GB | 250MB / user | $40 / GB per month |
CDS File Capacity (e.g., file attachments) | 20GB | 2GB / user | $2 / GB per month |
CDS Service Log Capacity (e.g., audit logs) | 2GB | none | $10 / GB per month |
Dynamics 365 Storage Costs Increase Mitigation
There are two places to look to see what could be major factors impacting your CDS database usage. First, look to see if you have multiple environments with equivalent database sizes. If you have a test or demo environment of equal size to production, chances are you can pare that down. Rarely does the test environment need to have all the historical data that the production environment has.
In our example, above, you can see that we have 4.66GB in prod, 3.1 GB in the demo environment, and 1.13GB in our Test environment. If you don’t need a test, demo, or training environment, then these environments can be deleted to free up capacity. If you do need them, you still have options.
What Tables are Using the Most Storage Capacity?
From the screenshot, below, you can see the top ten tables that are using up database capacity. As indicated in the graphic, there are a few tables that you may not be able to do anything about. If you have managed solutions that you’ve imported, and are still using, you won’t be able to delete data from, or reduce the size of those tables. (Though, if you don’t need those solutions in your test environment, you can delete them from there.)
A good place to start is to download all the tables data, showing which tables are using the most data – from biggest to smallest. The table names listed are what are called schema names or logical names, as opposed to the friendly display name of the table. You can get more information about the specific tables via either the Metadata Browser or the Metadata Documentation Generator using the XrmToolBox.
Backup Essential Data to Long-Term Storage, then Delete Older Data
Once you identify the tables taking up the most space, you can get to work reducing the data size. If the data is non-essential, you can run bulk delete jobs now, and schedule recurring bulk delete jobs to periodically delete the data to keep it in check. Another strategy would be to delete just the older data. For example, customer support cases could be deleted if they’re older than one year old. Maybe there are certain types of customer support calls that can be deleted, but you definitely want an archive in case you ever need to refer back to them. In this case, we can “save-off” a copy of your CRM data to an Azure SQL Database. Then you can configure the database with a long-term retention backup policy (LTR) to automatically retain the database backups in separate Azure Blob storage containers for up to 10 years for the Azure SQL Database.
Unexpectedly Large Web Resources Table
We had a recent case with a client, where they have a Dynamics 365 Customer Engagement Plan license, and had all the major apps installed; like Sales, Customer Service, Project Service Automation, and Field Service. We noticed that the database size increased dramatically overnight, and this was because of the Web Resources table, which is where the size of the solutions files would show in the database. After a call with Microsoft, we were advised that there was a “technical glitch” — that happened around August, 2020 — where the database web resources table increased unexpectedly in size. We were told that all these four apps (sales, customer service, project service, and field service) should only take up approximately 1.5-to-2.0 GB in the web resources database table. Since we inquired about this issue on behalf our customer, we were told that they (Microsoft) would look to have the web resources database table shrunk back down to the expected size.
Note, in the screenshot below, that this is showing the data storage issue for just one “org” — meaning that if you have the same problem in two organizations, you will have twice the unexpectedly oversized Web Resources table data storage problem.