You may have seen the announcement that Microsoft has released a version of the integrated Azure Stack system 1803 and Azure Stack Dev Kit Build 20180329.1.
In addition to the Infrastructure as a Service (IaaS) platform, the Microsoft Azure Stack also offers several Platform as a Service (PaaS) features that are similar to Microsoft Azure. Microsoft originally designed Azure for PaaS-based application development and added IaaS-based services. With the current release of Azure Stack, Microsoft is offering four PaaS-based services:
- Microsoft SQL Server and MySQL databases
- App service for websites
- For secure storage of Key Vault secrets such as passwords and certificates
- Azure functions for serverless computing
Check here if you want to know more about installing and configuring the Azure Stack SQL Resource Provider.
Each new build of the Azure Stack Dev Kit requires a new relocation because it is one node and there is no way to move to another node for a seamless upgrade. When evaluating the development of the Azure Stack Dev Kit 20180329.1, I ran into a strange problem adding a SQL server. In this blog post, I will share with you my experience on how to avoid the same.
Before adding or deploying a new service to Azure Stack, it’s important to check health from an environmental point of view. The following high-level steps show you how to check Health Azure stack:
- Log in to the Azure Stack Administration portal as an Azure Stack Cloud Operator at https: //adminportal.local.azurestack.external.
- Navigate to something Area management.
- Select the area where you will install the resource service. In this example, because we are using the Azure Stack Development Kit environment, it is a “local” area.
- In the Settings blade, check the results of the system health tests.
Everything looks healthy and can’t be noticed. After commissioning Provider of SQL resources in Azure Stack, we can start adding SQL Server servers. But before you do, there are some general requirements that you can read about all of them here.
In short, tThe SKU name should reflect the properties so that users can place their database properly. All SKU host servers should have the same features. For example, aWhen you add servers, you must configure them for a new or existing SKU to differentiate the service offering. For example, you may have an instance of SQL Enterprise that provides: database capacity, automatic backup, reserve high-performance servers for individual departments, and so on.
So while I am adding SQL Server, I got an error message with the status Failed to create SKU.
However, as you can see from the screenshot below, the SKU name was filled in correctly. I was able to continue and click Create.
Deployment fails with the following error: Sku StandardSKU not found (core: SkuNotFound)
The error message is clear, the SKU name cannot be found. However, when creating the SKU, I used the following format and everything seems to be fine.
I noticed that while typing the name Name in the text field, you must type the name without spaces, otherwise it will throw an error. For other fields, this is not required.
I checked with the Azure Stack team and they confirmed that I don’t use spaces in any of the four SKU text fields below, so I changed the SKU name to the following format without spaces.
SKU was successfully created.
And SQL Hosting Server was added successfully.
Last but not least, I was able to create a new database as a tenant and everything works as expected.
During the addition SQL Server (s), I also came across important points to note here:
- Make sure the forwarding and reverse lookup zones are configured in the Azure Stack.
- Be sure to specify SQL Server virtual machine for SQL authentication and SQL connection than Public. If not, you can go to the SQL VM and check the SQL settings and change them if necessary. Why Public and no Private or Local, because RP has no way to connect to VNET. In addition, the SQL VM must be available to all tenants.
- Make sure you use Public IP address and not Private IP when you add SQL Server servers because private IP addresses are not reachable from any other VNET server.
This issue has been identified by the Azure Stack team and will be fixed in the next release. I would like to thank the Azure Stack team for their support in this matter.
Hope this helps someone out there.
Thanks for locking my blog.
If you have any questions or feedback, please leave a comment.