Experiencing Azure Stack in Public Azure – by using Azure Stack policy module to an Azure Subscription or a Resource Group


It is possible to have an experience akin to Azure Stack right in public Azure. As you might already know all of the features available in public Azure are not going to be available immediately in Azure Stack. Also not everyone can set up an Azure Stack POC node due to the hardware requirements needed to set it up. With this in mind the Azure Stack team has a Azure ARM policy module that you can apply to the following:-
(a) An Azure subscription OR
(b) to an Azure Resource Group in a subscription.

Azure Stack ARM Policy
To understand more about the Azure Stack ARM policy please refer to the link Manage Azure policy using the Azure Stack Policy Module.

However there is a bug in the documentation, and the following script is what I used to apply the Azure Stack policy to a Resource Group in my subscription. You should be able to copy the below script into a PowerShell ISE and then run it line by line. Fix any errors, if they occur.

## PowerShell BEGIN####### ## To download the tools folder, run the following command: # Change directory to the root directory cd \ # Download the tools archive invoke-webrequest https://github.com/Azure/AzureStack-Tools/archive/master.zip -OutFile master.zip # Expand the downloaded files expand-archive master.zip -DestinationPath . -Force # Change to the tools directory cd AzureStack-Tools-master ## Import the AzureStack.Policy.psm1 module: import-module .\Policy\AzureStack.Policy.psm1 ## Apply policy to a Resource Group in subscription. ## The following command can be used to apply a default Azure Stack policy against your Azure subscription. Before running, ## replace Azure Subscription Name with your Azure subscription. Login-AzureRmAccount $resourceGroupName = ‘AzureStack’ ## Just created this myself in the subscription from portal. New-AzureRmResourceGroup -Name $resourceGroupName -Location "South Central US" Get-AzureRmSubscription $s = Select-AzureRmSubscription -SubscriptionId $subscriptionID = $s.Subscription.SubscriptionId ## $s = Select-AzureRmSubscription -SubscriptionName "Windows Azure MSDN - Visual Studio Ultimate" $policy = New-AzureRmPolicyDefinition -Name AzureStack -Policy (Get-AzureStackRmPolicy) ## New-AzureRmPolicyAssignment -Name AzureStack -PolicyDefinition $policy -Scope /subscriptions/$s.Subscription.SubscriptionId/resourceGroups/$resourceGroupName ## OR (read the comments in the link - https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-policy-module#policy-in-action ) ## New-AzureRmPolicyAssignment -Name AzureStack -PolicyDefinition $policy -Scope /subscriptions/$s.Subscription.SubscriptionId/resourceGroups/$resourceGroupName New-AzureRmPolicyAssignment -Name AzureStack -PolicyDefinition $policy -Scope /subscriptions/$subscriptionID/resourceGroups/$resourceGroupName ## PowerShell END#######

Once you do this, you could go to the ResourceGroup (in my case “AzureStack” ) in the portal and then you would be able to provision and experience resource that are possible in Azure Stack (proper) right within public Azure.

Once setup, you could log into your public subscription and see it in effect. Navigate to the specific ResourceGroup and click on "Policies" and then Click on "Assignment Rule" and you can see the actual policy rule in JSON format. Click pic for full view mas-arm-policy mas-arm-policy-2

Examine this rule in JSON format, to see if it actually constraints the resource group. I think the PG will have to be constantly be updating this as they make updates. Also note that this may not exactly reflect Azure Stack objects that you can create as this JSON code that implements the policy needs to keep constantly in sync with what is a continuous cadence of updates to Azure Stack. It is a moving target, but you get to see how policies can be leveraged.

1. One of the ways you can put this to good use is to take the JSON file which is available in an Azure Stack and apply it to a subscription/Resource Group in public Azure and technically for the most part (from the template point of view) you have an environment that is similar to "Azure Stack" - subsetted in public Azure. You can then work to create your application deployments in this isolated "Azure stack" like environment in public Azure, generate the template and (again) for the most part export that template out and use it in Azure stack. This allows one to be productive in generating templates which are not yet out there, but still needed for Azure Stack.
2. Assuming you have the correct JSON file that implements the Azure Stack ARM policy in Azure, you can test out what is possible in Azure Stack and validate your assumptions on what you can do in Azure Stack. So you don't work assuming that certain things are possible without infact verifying it.
3. I anticipate some Azure Stack environments to not have all of the Resource Provider's made available. But a consumer of the Cloud model can then using this method request the Service Provider to make available the RPs which Microsoft has made available for Azure Stack.

This assumes you have the correct and the latest and greatest JSON fragment that accurately reflects the capabilities and API levels that represent the Azure Stack environment. which by the way will be updated frequently by MS.