Over the past few months, since the feature was released with the fall update, we have seen many people trying out the new Intelligent Cloud functionality in Microsoft Dynamics 365 Business Central. This functionality is designed to bring all the data (or, at the very least, all of the relevant data) from an on-premises instance of Business Central to a cloud instance. This enables many of the features that are only available in a cloud system to be used on your real business data. More information about the feature can be found in the official documentation. This blog post details the most common issues that you may encounter while setting up your Intelligent Cloud and gives you the tools that you need to fix these issues so that you can reach a high rate of success in replicating your on-premises data. Failed to enable your replication Figure 1 - Failed to enable replication - generic error message You may get this error when walking through the Intelligent Cloud Setup wizard. Currently, the error message is fairly generic and doesn't do too much to help the user identify the issue. A fix for this is coming in a future update so that you can better understand the cause of the error. The good news is that there is a way to find out exactly what the issue is when you get this error message. It is typically caused by one of the following three things: Your Self-hosted Integration Runtime is not set up properly The compatibility level of your SQL database is not high enough (must be >= 130) The provided connection string is not valid or contains credentials that are not valid The first thing you'll need to do is open up your Self-Hosted Integration Runtime window and verify that it is actually connected to Azure Data Factory. Your window should look similar to the following. Figure 2 - Self-hosted Integration Runtime window Once you've verified that your Self-hosted Integration Runtime is properly set up, the next thing to do is jump over to the Diagnostics tab. This is where you can test the connection to your SQL Server and also where you can look at the runtime logs to see the errors that might have happened when the SQL connection was attempted. Figure 3 - Self-hosted Integration Runtime, diagnostics tab The logs from the Self-hosted Integration Runtime are stored in the Event Viewer, which will open when you click View logs. It may take some time to load all of the logs. Once the window opens and fully loads, scroll down to look for any logs around the time that you saw the error from the setup wizard. In my case, I had a bad user name or password, which is indicated by the error message in the log. Figure 4 - Relevant errors within the Integration Runtime logs If you ever get an error with an unknown or unspecified cause, this should be the first place you go to find out what happened. The majority of errors will show up here. Change tracking is not enabled Once you've successfully set up replication and try it out for the first time, you may run into a situation where change tracking is not enabled for certain tables. The workaround is fairly easy: just enable change tracking on those tables. All of those details are described in this separate blog post. While we're on this topic, one thing that you should be aware of is the retention period for your change tracking data. The Intelligent Cloud uses change tracking to make the replicating data more efficient. After all, it'd be wasteful to move all of the data every time the replication runs rather than just the data that has changed. To make this work most effectively, the change tracking retention period will need to be at least as long as the time between your scheduled replication runs. For example, if your replication is scheduled to run once per day, then make your retention period at least one day. Figure 5 - Change Tracking Retention Period The table does not exist in the local instance Figure 6 - Table does not exist in local instance This issue will typically be limited to extension tables. If the version of your on-premises Business Central instance is the same as the cloud instance, then you shouldn't see this error message for any of the core tables. Still, failures on extension tables can lead to big issues later on. For example, let's say there is an extension in the cloud that extends the Item table (as is the case in Figure 6), but that extension is not installed in the on-premises system. In this scenario, the data for the Item table may replicate okay, but the data in the extended table will not come across because it doesn't exist on-premises. The reason this is an issue is because when the system attempts to collect all of the Item records, it does a join on the extended tables. But those tables are empty (because the data didn't get replicated), so the result of the join is an empty set. This illustrates why it's important to look at the extensions installed in the cloud and install them on-premises as well. You can determine which extension is the suspect by looking at the GUID in the table name. In Figure 6, the suspect is c526b3e9..., which happens to be the Sales and Inventory Forecast extension. To alleviate the error, I would just install that extension on-premises. Note that having additional extensions in your on-premises system (ones that do not live in your cloud instance) is okay. Any tables from those extensions will just be ignored. It's only the converse scenario that can cause issues. Finally, it may be that the error is for an extension table that you don't really care about. If this is the case, then you can just ignore the error. Achieving 100% success rate with your replication is not necessary to take advantage of the Intelligent Cloud. The schema does not match Figure 7 - The schema of the on-premises table does not match the corresponding Business Central cloud table This should be the least common error that you see when replicating your data. The primary cause for an error like this is that either a cumulative update was applied to the on-premises system before the cloud tenant was upgraded or vice versa. We try to avoid schema changes as much as possible between minor updates, but they do sneak in on occasion. In addition, the Intelligent Cloud replication is currently on the aggressive side of enforcing schema parity. So even if the schema change was only extending a table field from, say, Text to Text, you would get this error. This is something we will be toning down in the future so that minor updates will have a much lower risk of causing failures. The workaround for this error is to bring each side to the same Business Central version. In order to avoid getting into this situation, the best thing to do is to wait to apply the CU in the on-premises instance until you know that your cloud tenant has been upgraded to the corresponding version. Data from the table is unavailable Figure 8 - Data from table x is unavailable. Intelligent Cloud replication for this table was unsuccessful. One of the engineering decisions we made before releasing this feature was to flag tables that have failed to replicate with a 'Blocked' indicator. This effectively prevents the Business Central client from accessing any data within such a table. The reason behind this decision was to prevent users from seeing potentially stale or inconsistent data and then making business decisions based on that bad data, which could be really bad. So, depending on which tables have failed to replicate, you might see errors like the one in figure 8 when you try to sign in to one of the replicated companies or when you try to view certain data. The workaround for this issue is to sign into the Business Central demo company and look at what tables failed and fix the issues. We've thought a lot about this 'Blocked' indicator and may remove it in the future, but that's undecided at the moment. What we do plan to do is implement various improvements to make it so that table failures happen less often, one of which is to reduce the schema matching requirements. As you set up your Intelligent Cloud in Dynamics 365 Business Central, I hope that everything goes smoothly the first time. But if you do run into any trouble, these tips should help you quickly solve the issues so that you can achieve a high replication success rate and take full advantage of your data in the cloud. As always, we'd love to hear your feedback. Tell us what you think of the Intelligent Cloud feature in the comment section below.