Deploying Microsoft Dynamics GP on an Azure SQL Managed Instance - Part 3/3
In Part 1 of this series, I walked through the process of signing up for an Azure SQL Managed Instance preview (further referred to herein as "Managed Instance" for simplicity sake) and the subsequent deployment process once approved. In Part 2, I looked at some of the issues you would ran into during the deployment of Microsoft Dynamics GP, particularly around the use of Dynamics GP Utilities to create an environment from scratch.
From reading these two articles you may have concluded -- rightfully so -- that it's not possible to deploy Microsoft Dynamics GP using a Managed Instance PaaS. This article focuses on a deployment approach that works.
Migrating Microsoft Dynamics GP to an Azure SQL Managed Instance
Since Dynamics GP Utilities is not yet equipped to create databases on a Managed Instance, the only way to take advantage of this new service is via a migration. This is, taking your on-premise databases and restoring them onto the cloud database service.
I first started by backing up my on-premise system and company databases to an Azure storage account. There are couple ways to do this: a) you can use Microsoft Dynamics GP's built-in backup functionality, or b) you can use Microsoft SQL Server to perform this operation via T-SQL statements or SQL Server Management Studio. I chose the first method, but for more information on the second method, you can refer to MVP Steve Endow's article Back up your Dynamics GP SQL Server databases directly to Azure Storage in minutes!
I first wrote about backing up Microsoft Dynamics GP databases to Azure using the built-in backup utility in my article Microsoft Dynamics GP backups with Windows Azure Blob Storage Service. Nonetheless, I will cover the subject once more in this article as I am sure the Azure Portal has changed since I first wrote that article.
During the Managed Instance deployment steps, a storage account was created to store the diagnostics log, so I figured for ease of explanation, I would use this same account to store my Dynamics GP backups, but I strongly recommend you create a separate storage account (as a part of the same storage resource group) to store database backups.
Backing up the System and Company Databases
1. Once your storage account is in place, open Microsoft Dynamics GP and go to Microsoft Dynamics GP > Maintenance > Backup.
2. Enter the storage account name. This can be found in the list of resources in the Azure Portal.
3. Enter the access key. The access key can be found by clicking on the Storage Account under resources, then by clicking Access Key under Settings in the Azure Portal. You can copy the key and paste it in the Back Up Company window in Dynamics GP.
4. Enter the URL to the container. Click on Containers, under Blob Service for your storage account. Proceed to click on the blob name displayed. Then click on Properties under the blog Settings.
5. Finally, you can enter a File Name in the Backup Company window then click on Verify Account, then OK to complete the backup.
You will need to complete this process for the system and each company database in your environment.
Restoring the databases onto the SQL Managed Instance
With the first part completed successfully, we now have to restore the databases onto the SQL Managed Instance. To show you how this part works, I found it useful to create this short video:
With the databases restored, I fired up Dynamics GP Utilities. The database version validation completed successfully and I was sent to the window where I could run additional Utilities functions - again, creating companies is not supported at this point.
I was able to launch Dynamics GP and went through running reports, entering and posting transactions, and running SmartLists and nothing seemed out of place and I did not get any error messages.
I want to be extremely clear that this configuration is not yet supported by the Microsoft Dynamics GP Support Team. It's also worth reminding you that the Azure SQL Managed Instance is still in preview mode, which means things may change (for the better for sure) that could still impact this limited test I did. So, if you are going to perform a migration, do so to test as much as you can, but please do not use as a production environment.
I will follow up this series with a video blog just summarizing all this experience and where I believe the Microsoft Dynamics GP development team can make a couple adaptations to make this all work for Dynamics GP customers and partners.
Until next post,
MG.-
Mariano Gomez, MVP
From reading these two articles you may have concluded -- rightfully so -- that it's not possible to deploy Microsoft Dynamics GP using a Managed Instance PaaS. This article focuses on a deployment approach that works.
Migrating Microsoft Dynamics GP to an Azure SQL Managed Instance
Since Dynamics GP Utilities is not yet equipped to create databases on a Managed Instance, the only way to take advantage of this new service is via a migration. This is, taking your on-premise databases and restoring them onto the cloud database service.
I first started by backing up my on-premise system and company databases to an Azure storage account. There are couple ways to do this: a) you can use Microsoft Dynamics GP's built-in backup functionality, or b) you can use Microsoft SQL Server to perform this operation via T-SQL statements or SQL Server Management Studio. I chose the first method, but for more information on the second method, you can refer to MVP Steve Endow's article Back up your Dynamics GP SQL Server databases directly to Azure Storage in minutes!
I first wrote about backing up Microsoft Dynamics GP databases to Azure using the built-in backup utility in my article Microsoft Dynamics GP backups with Windows Azure Blob Storage Service. Nonetheless, I will cover the subject once more in this article as I am sure the Azure Portal has changed since I first wrote that article.
During the Managed Instance deployment steps, a storage account was created to store the diagnostics log, so I figured for ease of explanation, I would use this same account to store my Dynamics GP backups, but I strongly recommend you create a separate storage account (as a part of the same storage resource group) to store database backups.
Backing up the System and Company Databases
1. Once your storage account is in place, open Microsoft Dynamics GP and go to Microsoft Dynamics GP > Maintenance > Backup.
2. Enter the storage account name. This can be found in the list of resources in the Azure Portal.
3. Enter the access key. The access key can be found by clicking on the Storage Account under resources, then by clicking Access Key under Settings in the Azure Portal. You can copy the key and paste it in the Back Up Company window in Dynamics GP.
4. Enter the URL to the container. Click on Containers, under Blob Service for your storage account. Proceed to click on the blob name displayed. Then click on Properties under the blog Settings.
5. Finally, you can enter a File Name in the Backup Company window then click on Verify Account, then OK to complete the backup.
You will need to complete this process for the system and each company database in your environment.
Restoring the databases onto the SQL Managed Instance
With the first part completed successfully, we now have to restore the databases onto the SQL Managed Instance. To show you how this part works, I found it useful to create this short video:
I was able to launch Dynamics GP and went through running reports, entering and posting transactions, and running SmartLists and nothing seemed out of place and I did not get any error messages.
I want to be extremely clear that this configuration is not yet supported by the Microsoft Dynamics GP Support Team. It's also worth reminding you that the Azure SQL Managed Instance is still in preview mode, which means things may change (for the better for sure) that could still impact this limited test I did. So, if you are going to perform a migration, do so to test as much as you can, but please do not use as a production environment.
I will follow up this series with a video blog just summarizing all this experience and where I believe the Microsoft Dynamics GP development team can make a couple adaptations to make this all work for Dynamics GP customers and partners.
Until next post,
MG.-
Mariano Gomez, MVP
Comments