The Azure Stack have several Resource Providers that can be utilized to bring value to the stack.
We have an Azure Stack in the company and have had an early adopter experience. To make the most of our testing and offering we added App Service, MySQL, SQL RP´s after deployment.
In our multi-tenant usage registered Stack we noticed on our own bill that it was a bit high $$ and realized that it was the shared workers that was behind this, during a couple of Azure Stack work shops we had scaled it to 12 instances for labs. The shared workers are billed to the registration CSP-subscription, the dedicated are billed to the customers subscriptions when they are in use in an app plan but you as a stack provider can have several of them running and prepared without any extra cost.
If you want to add or remove worker instances this can be mitigated with PowerShell or through the portal:
There are some caviats about this and that can be read in the app service documentation, if you want to give the user subscriptions access to serverless functions on a consumption plan you have to have enough shared workers available…. read more here
Carefully monitor the capacity and usage of your add-on RP´s so the experience for the customer always is great!
Build test environments by using the Azure Stack Development Kit (ASDK).
This objective may include but is not limited to: use PowerShell commands; install updated ASDK; troubleshoot failed installs; post-deployment registration
Configure DNS for data center integration.
This objective may include but is not limited to: configure external DNS name resolution from within Azure Stack; configure Azure Stack DNS names from outside Azure Stack
Configure connectivity for data center integration.
This objective may include but is not limited to: manage firewall ports needed at the edge; configure connectivity to the data center; install and renew certificates for public endpoints
Connect to and perform API-based administration on Azure Stack.
This objective may include but is not limited to: connect to the stack by using PowerShell; configure client certificates; configure firewall to support remote administration; establish RBAC roles for the Azure Stack fabric; create subscriptions for end users
Configure and administer the App Service resource provider.
This objective may include but is not limited to: configure system; configure source control; configure worker tiers; configure subscription quotas; scale worker tiers and App Service infrastructure roles; add custom software; configure Azure Stack networking security
Configure and administer database resource providers.
This objective may include but is not limited to: configure and administer the SQL adapter; configure and administer the MySQL adapter; set up SKUs; set up additional hosting capacity
Configure and administer IaaS services.
This objective may include but is not limited to: implement virtual machine images; prepare Linux and Windows images; prepare a custom image; upload an image
This objective may include but is not limited to: create quotas; configure plans; configure offers; configure delegated offers; create add-on plans
This objective may include but is not limited to: add new tenants; remove tenants; manage authentication and authorization; establish RBAC roles for the tenant space
Manage the Azure Marketplace.
This objective may include but is not limited to: enable Azure Marketplace on Azure Stack; plan new packages; create and publish new packages; download Azure Marketplace items
Enable DevOps for tenants.
This objective may include but is not limited to: enable version control for tenants; manage ARM templates; deploy ARM templates; debug ARM templates; use Microsoft Visual Studio Team Services to connect to Azure Stack; use continuous integration and continuous deployment to automate a pipeline that targets Azure Stack
Plan and implement a backup-recovery and a disaster-recovery solution.
This objective may include but is not limited to: back up Azure Stack infrastructure services; perform cloud recovery of Azure Stack, replicate and fail over IaaS virtual machines to Azure; back up and restore PaaS resource data; back up and restore backup and restore of user IaaS virtual machine guest-OS, disks, volumes, and apps
Manage and monitor capacity, performance, updates, and alerts.
This objective may include but is not limited to: manage storage; monitor available storage; integrate existing monitoring services; manage public IP address ranges; monitor infrastructure component health; monitor Azure Stack memory, public IP addresses, and storage tenant consumption; apply updates; update system firmware; review and react to alerts
Manage usage reporting.
This objective may include but is not limited to: provide access to the usage database; test usage by using the ASDK; collect the usage data by using the Provider Usage API and the Tenant Usage API; investigate the usage time versus the reported time
Last week I updated my Azurestack Devkit to 1804, well with the devkit I have to do a redeploy, during the deployment it got stuck on creating the ADFS VM so i did a reset on that one and -rerun and it got into happyland!
After the deployment was successful I logged into the admin portal and found this, the default subscription have two pals now.
Upgrading our multinode stack did though not give the same view
The docs release notes have been updated to clarify about this and it also states that you should not use the new subscriptions yet
I have been exploring a bit with both Azure and Azurestack and when you onboard your VM´s to Log Analytics and the security center you soon get noticed about 100s of drilions attempts to log on to your mashine if you have made it available through RDP. Although there now is a way to take care of this in a better way using the Security Center JIT Access giving a timespan for opening the port and also limiting to certain IP/networks! Some times an JIT access is not what you can live with but an alternative port could be utilized then the following can be applied.
A recent update to the Azure portal have now surfaced where you get the option to dowload the RDP file with an alternative port instead of the standard 3389, that does not
set the NSG to allow for the new port
set the VM´s internal RDP service to respond to it
So to get the possibility to connect to the virtual machine we need to update the NSG and also reconfigure the virtual machine to actually listen on the new rdp port
First I add a row on the NSG
and then i utilize the custom script extension and change the listener on the virtual machine for RDP
New-NetFirewallRule-DisplayName'Allow RDP in Custom Port'-Profile@('Domain','Private','Public')-DirectionInbound-ActionAllow-ProtocolTCP-LocalPort@($NewPort)
If I am utilizing an AzureStack all above can be achieved but in the portal the connect button will be greyed out so you can still connect to it but you need to manually enter the public IP and custom port:
There is a new (re-released) course on the openedx.microsoft.com site where you can sign up and start learn about Azure Stack and also from the 30th of March do labs to enhance the learning experience! This lab environment is an awesome opportunity if you do not have access to a multinode or devkit setup and want hands on experience!
Extract from the site:
You will work your way through the online labs to become familiar with:
The components and architecture of Microsoft Azure Stack
Deploying Microsoft Azure Stack
DevOps using Microsoft Azure Stack
Resources in Microsoft Azure Stack
Managing IaaS in Microsoft Azure Stack
Managing PaaS in Microsoft Azure Stack
Managing updates in Microsoft Azure Stack
Performing monitoring and troubleshooting in Microsoft Azure Stack
Understanding how licensing and billing works in Microsoft Azure Stack
Labs included are (online labs will be available on 3/30/18)
Connecting to Microsoft Azure Stack using Azure PowerShell
Configuring Delegation Using the Azure Stack Administrator Portal
Registering Azure Stack with an Azure Subscription using Azure PowerShell
Add a Windows Server 2016 Image to Azure Stack using Azure PowerShell (Disconnected Scenario)
Add a Windows Server 2016 Image to Azure Stack (Connected Scenario)
Add a Linux Image to Azure Stack using Azure PowerShell (Disconnected Scenario)
Validating ARM Templates with Azure Stack
Each lab includes the following:
Detailed procedures for individual lab tasks
Access to a Windows Server 2016 Domain Controller for performing hands-on lab exercises hosted on Microsoft Labs Online (MLO)
Access to Azure Stack Admin and Tenant portals
Short “how-to” videos for viewing each task should you get stuck and need to see how it’s done
As I described earlier I had an eval image in my marketplace that I used to provision servers and I wanted some of them to be converted so they could be correctly activated and reconfigured away from eval.
The AzureStack uses the function within Hyper-V for the VM´s that is called Automatic Virtual Machine Activation and as you can see in the device manager the device Microsoft Hyper-V Activation Component and the VM´s should have the appropriate AVMA key on them and if the host is licensed with the right key the VM will activate automatically.
On this page you can find the keys you need for the different guest-OS that it can be used with! A Windows Server 2016 AVMA host can activate guests that run the Datacenter, Standard or Essentials editions of Windows Server 2016 and Windows Server 2012 R2.
Utilizing the DISM command I can check what license I had and then use DISM /online /Set-Edition:ServerDatacenter /ProductKey:xxxxxx-xxxx-xxxx-xxx-xxxx /AcceptEula
If you just want to change a key and not versions you can utilize the slmgr /ipk <AVMA_key> instead of the DISM!
So now we have come to some interesting parts in my experience with our multinode Stack, In this post I will go through Marketplace management and installation of App Service RP.
To actually get something into the marketplace for tenants we need to either populate it ourselves with custom images or utilize the marketplace syndication. After deploy of the stack you need to register it to Azure.And when you have successfully done that you will get possibiltiy to download azure images that have been made available.
In the powershell tools you can find the command to upload a custom image that you might want to make available for your tenants, there is though no way to make them just available for one tenant. I utilized the superfunction Convert-WindowsImage and created a new insider Windows Server 17093 for my tenants marketplace.
then using the Azurestack tools you upload it with Add-AzsVMImage
Important: You as a Stack Admin will be responsible to make sure that the latest Images have been updated on your Marketplace, there is no automation magic that will download a new Windows Server Image once it has been released in Azure and thus keeping your marketplace up to date for tenants and they can deploy without having to patch and patch and patch before they utilize their systems…
Looking at one example my SQL VM that I have downloaded from Azure was version 14.1000 and now there is a new that I need to update to:
App Service RP
Installation of the SQL RP was very much straight forward and just follow the instructions and run (there is though one thing and that is regarding the above marketplace, you will need a Windows Server Core available for the SQL RP)
for the App Service there is a bit of more work and the prerequisite says a file server :” For production deployments, the file server must be configured to be highly available and capable of handling failures.” and a SQL server: “For production and high-availability purposes, you should use a full version of SQL Server 2014 SP2 or later, enable mixed-mode authentication, and deploy in a highly available configuration.“. Luckily You can run these in default subscription and not in a tenant subscription… But still there are some serious life cycle management that needs to be handled here with patch and update, security etc on these 6 servers (AD, FS, SQL)
After when You have those prerequisites in place it is time to start the App Service wizard, and there we had the first encounter of problems.. I had the superduper SSL cert with everything including SANs or so I thought……
Coming back to my second post you should verify a thousand and thousand times with the certificate department at your company that they do not try to take any shortcuts and miss any critical SANs. In our case an assumption that a wildcard was enough to take this rocket out of orbit for a couple of hours and getting a bit more grey hair! So make sure you have a SAN name in your certificate that says sso.appservice.<region>.<xx>.domain.yy and you will not get “The certificate dns is invalid: azurestack”
Next thing that we encountered which showed a bit later was that we deployed using the eval image (this was not to obvious in the wizard, as we had both a eval and a regular in our syndicated marketplace)
And as you can see in the Wizard during app deploy it does say latest 2016 Datacenter and nothing about eval!
Now Microsoft and the Azure team have removed the Eval from the Syndication so if you do not create your own custom image with Eval you will not get into this problems and need to mitigate this..
Once the Win 2016 Eval was removed we could get a ordinary version up on the workers by scaling their scale sets down and up, but we had to fix the controllers manually.
Also make sure that you do not lock down the SQL and fileservers vnet and public IP´s with a too narrow NSG and not let app workers and controllers reach smb shares and sql services or your app service will die and not respond!
Now we have come to my fourth post on my series of AzureStack multinode experince, previously I have been writing on the importance on the network and certificates for a successful deployment.
This post will describe the success path with updates to be applied and keeping us compliant with the support cycle, you can only be up to 3 updates behind or you will be left without support!
When we got our stack it was deployed with 1709 and during the installation process the OEM-engineers that where onsite added 1710 and 1711. When the 1712 came out we did the update ourselves. Based on our learnings it is good to have ms support standby so start with a support case because to have a more successful run of the update pack you will want to check status and space on the infrastructure VM´s and it is only in a broken glass support session connected to the privileged endpoint on a ERCS node you can get help and verify the state! Probably in future update packs they will address issues and thus making it more stable and resilient and you then will not be needing a support call but better be safe than sorry!
First as the documentation describes, upload the update files to the storage account called “updateadminaccount” where you would add a container (private) with the update:
When all the files are uploaded you can go into the update and start. When highlighting the patch the “update now” link above lights up and you can press it to start the update process!
The whole process takes about 8-12 hours depending on the size of the update and how many nodes you have in your Stack!
We had one hotfix that needed to be applied after the update of 1712 and the learning from that was that the apply failed and failed and failed but not giving a good explain on why but we learned that was because we did not RTFM and uploaded the whole folders content and not just the xml,exe and bin but also a Supplemental Notice.txt (in our defence, the update packs does not contain the text file), so removing that one and then the retry succeeded without any issues!
We have some users on-boarded on the AzureStack multi-node system and they do testing and when they forget to remove stuff and we need to make some changes we might need to remove their resources and as Stanislav mentioned there is a way to actually take over a subscription. There is though a small thing that needs to be added to the PowerShell cmds that can change a Azure Stack user subscription owner when you have a multitennant setup of your Stack, your users will have their own tenant ID´s on the subscriptions.
So to be able to access and remove resources from an user that left his subscription and resources burning you will have to do a update on both Owner and TenantId
So set up your enviroment with the AzureStack tools and PowerShell environment, connect as a cloud operator to the default subscription and then run the following::
# Get all User subs
# save the user subscription you want to take over into variable
Here is my second post on experience with our lovely AzureStack multinode that we now have running.
First of all, there is now a good doc on the AzureStack site for Datacenter Integration and it is really important to read and understand the text. It is also vital to also have the networking guys on the wagon!
For a success in the deployment you will need to have a NAT functionality within your router/fw or have a transparent proxy. The doc says it is needed for the Infra Network that is called public, it is not public reachable but do need internet access. Some routers have advanced functionality with Policy based routing that can send infra traffic to a fw and public VIP traffic directly to and from internet!
Also during deployment the BMC network will need access to internet because the deployment VM running on the HLH will need to do a AAD login and registration if the stack is not being deployed as a disconnected version.
Before you can get a deployment up and running you will need to make sure that the certificates that you ordered are rock solid! Follow the documentation and do not take any short cuts in wild card certs etc…
There is a sample cert INF template file that you can use: