As of late, I have been very interested in all things "Motion" as it relates to developing PowerApps applications - see #PowerApps: Motion Patterns with Parametric Equations . Although, most of the apps... (Continue reading)

As of late, I have been experimenting with motion in Microsoft PowerApps. This has actually helped me to revisit different mathematical models describing the motion of objects throw a two-dimensional space... (Continue reading)

Recently, Business Applications MVP Steve Endow and I delivered a session at the User Group Summits in Phoenix, and in particular, to the GPUG Summit titled, "Microsoft Dynamics GP and Azure Services"... (Continue reading)

The Integration Runtime (IR) is a customer managed data integration infrastructure used by Azure Data Factory to provide data integration capabilities across different network environments. It was formerly... (Continue reading)

With the release of Microsoft Dynamics GP 2018 R2, I had a first look at the update process, then quickly ran into a situation where the option to set up intelligent cloud insights wasn't showing in my... (Continue reading)

A few days later, my friend and fellow MVP Steve Endow introduced me to a new Azure preview feature called Azure SQL Managed Instance. Being a preview feature, there was a lengthy application process in order to gain access to it.

OverviewAccording to Microsoft, Azure SQL Managed Instance (further referred to herein as "Managed Instance" for simplicity sake) delivers the full capabilities of Microsoft SQL Server running on Azure service infrastructure. This is, all the limitations currently imposed by Azure SQL are, technically speaking, removed from a Managed Instance. The following diagram describes the key features.

Source: Microsoft

At this point, it is probably worth pointing out that prior to the introduction of Managed Instances, they were only two methods of deploying SQL Server in the Azure cloud computing platform:

IaaS: under this deployment model, a Windows Server virtual machine (VM) is provisioned with a license of Microsoft SQL Server. As a result, it is up to you to maintain the VM, applying all applicable service packs, back up and securing your databases, and worry about all the related database maintenance procedures. In essence, server administrative operations are no different than those performed on an on-premise deployment of SQL Server.

PaaS: this deployment model allows you to provision Azure SQL as a service, but presents a wide range of limitations for databases running in a traditional Microsoft SQL Server environment. One such limitation is the ability to run cross-database queries without the complexities introduced by Azure SQL (elastic pools, etc.), which is vital to support the system and company database architectural design of Microsoft Dynamics GP. In addition, Azure SQL features extensive deprecation of traditional system objects and stored procedure calls currently supported by traditional Microsoft SQL Server.

The Managed Instance Deployment Process/ExperienceDeploying an Azure SQL Managed Instance (in preview mode) is currently an exercise in patience. I began by following the instructions in detailed in this Microsoft Docs article:

Whitelist your subscription Configure a virtual network (VNet) Create new route table and a route Apply the route table to the Managed Instance subnet Create a Managed Instance Create a new subnet in the VNet for a virtual machine Create a virtual machine in the new subnet in the VNet Connect to virtual machine Install SSMS and connect to the Managed Instance

If I had to do this all over again, I would first wait until acceptance into the preview program has been confirmed, before going through the above steps. It's also worth noting that the deployment of the Managed Instance, in my particular case, took a bit over 27 hours. In the process, I ran into the following issues:

► At first, I did not receive a notification of acceptance (or rejection) within the program. This was easily resolved by opening an Azure subscription support case.

► When I initially provisioned my vNet, I created a single subnet spanning the full range of IPs afforded by the address space. Not being a network engineer, I am sure that this is something a seasoned professional wouldn't have done. It is recommended that subnets be smaller partitions within the address space. In any case, I initially assigned the Managed Instance to the only subnet I had and this caused the deployment to fail.

As it turns out, a Managed Instance requires its own subnet. Since my Azure environment is a sandbox, I had no problem in removing ALL resources and recreating them with the recommendations in the article. At the same time, I created specific resource groups for VMs, network resources, and storage resources, and furthermore set up a subnet for my VMs, different from the Managed Instance subnet -- in short, much, much cleaner! This is the result:

Resource Groups

Subnets

► Once I got this all going, the deployment process began. Somewhere pass the 27 hour mark I decided to check the provisioning status and found this error message, "Cannot process request. Not enough resources to process request. Please retry you (sic) request later.".

It took a few email exchanges with the SQL Cloud Lifter Ops team -- yes, there's such thing -- and I was up and running and ready to connect to my instance. For the record, I had over 3 teams helping me with this.

When it's all said and done, you will end up with the following resources:

1. A vNet2. A subnet for the Managed Instance, and for good measure a subnet for the VM3. A VM4. A route table associated to the Managed Instance subnet.5. A storage account that stores the deployment diagnostics for the Managed Instance.

In the next installment, I will go through the deployment steps for Microsoft Dynamics GP. There is a lot to cover, so I will give you time to digest the content of this first installment.