External Access to Azure Stack

Here is a little community gift for the new year (2017). Azure Stack expert Ruud Borst (@Ruud_Borst) recently published a blog post titled “Expose the Azure Stack Portal through NAT”. Ruud included a PowerShell script in this blog post that simplifies extending external access to Azure Stack.

The PowerShell script runs on your Azure Stack host and will make the IP mappings in NAT on MAS-BGPNAT01 to expose your Azure Stack instance externally to your network.

We no longer have to work through a bunch of tedious steps to give external access to Azure Stack. Thanks Ruud! Great example of community power. With Ruud’s script it can be done even if you already have Azure Stack deployed. The link to his blog post and script is here:

https://azurestack.eu/2016/12/expose-portal-azurestack-through-nat

Running the script is as easy as running something like this:

.\Expose-AzureStackPortal.ps1 -PortalExternalIP YOURFIRSTIPHERE -ACSExternalIP YOURSECONDIPHERE

Add -AppServiceAPIExternalIP if you are using the App Service RP you will need to specify a 3rd IP. SQL and MySQL both use the -PortalExternalIP so no need for an extra IP for these.

A successful run of the script should look like this:

VERBOSE: Created NAT external addresses 192.168.1.40 and 192.168.1.45 for Portal and ACS.

VERBOSE: Created Static NAT port mappings on 192.168.1.40 to 192.168.102.7 for Portal
VERBOSE: Created Static NAT port mappings on 192.168.1.40 to 192.168.102.12 for XRP
VERBOSE: Created Static NAT port mappings on 192.168.1.45 to 192.168.102.3 for ACS
VERBOSE: Created Static NAT port mappings on 192.168.1.40 to 192.168.102.14 for SQLrp
VERBOSE: Created Static NAT port mappings on 192.168.1.40 to 192.168.102.1 for MySQLrp

The last step in this process is to make sure you add the DNS records on your external network or to the host file on external servers or clients. Ruud explains this in his blog. I extended Azure Stack to my Buchatech lab environment so I went the DNS route.

For DNS entries I used a CSV file and PowerShell to import all of the DNS records I needed for Azure Stack. I used a PowerShell script from a fellow MVP. The blog post with that script can be found here:

http://www.lazywinadmin.com/2012/10/create-dns-entries-using-powershell-and.html

Here is what the CSV file should look like:

name ip type zone dnsserver
 portal 192.168.1.40 A azurestack.local dc.buchatech.com
 api 192.168.1.40 A azurestack.local dc.buchatech.com
 xrp.tenantextensions 192.168.1.40 A azurestack.local dc.buchatech.com
 keyvault.tenantextensions 192.168.1.40 A azurestack.local dc.buchatech.com
 health.adminextensions 192.168.1.40 A azurestack.local dc.buchatech.com
 compute.adminextensions 192.168.1.40 A azurestack.local dc.buchatech.com
 network.adminextensions 192.168.1.40 A azurestack.local dc.buchatech.com
 storage.adminextensions 192.168.1.40 A azurestack.local dc.buchatech.com
*.blob 192.168.1.45 A azurestack.local dc.buchatech.com
*.queue 192.168.1.45 A azurestack.local dc.buchatech.com
*.table 192.168.1.45 A azurestack.local dc.buchatech.com
sqlrp 192.168.1.40 A azurestack.local dc.buchatech.com
mysqlrp 192.168.1.40 A azurestack.local dc.buchatech.com
A azurestack.local dc.buchatech.com
A azurestack.local dc.buchatech.com
A azurestack.local dc.buchatech.com
A azurestack.local dc.buchatech.com

Here is the CSV file I used so you don’t have to create it.

Azure Stack DNS Entries

Notice something different I did with my DNS is I did not add *.azurestack.local. I did not do this because it caused any of the storage DNS entries to respond with the PortalExternalIP instead of the ACSExternalIP. Here is a screenshot of my Azure Stack DNS zone in my Buchatech domain:

After adding the DNS records and installing the Azure Stack certificate in the trusted root authority store I was able to access the Azure Stack portal and connect via PowerShell or Visual Studio without VPN. 🙂

Here is a screenshot of me connecting to Azure Stack’s portal from my Buchatech.com domain on one of my utility servers.

A huge thanks to Ruud for building that PowerShell script. I am excited about bringing access to Azure Stack on my other lab network because this opens up all sorts of possibilities and will net some cool blog posts very soon!

Happy Stacking!

Read more

Detailed SQL RP Azure Stack TP2 Deploy & Config

Microsoft has made a new version of the SQL resource provider (RP) for Azure Stack TP2 available. It can be found here in the documentation: https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-sql-resource-provider-deploy. This RP is an add-on for Azure Stack and allows you to offer SQL as PaaS.

This is a great SQL self-service scenario for Hybrid Cloud. The aforementioned link contains documentation on how to deploy the SQL RP. There are some “Gotchas” with the RP and some other information that is important when deploying and configuring this RP.

I am going to walk through my deployment and configuring experience covering the “Gotchas” and other important information in this blog post. This post will be broken out into the following sections:

  • Deployment
  • RP Configuration
  • Offer/Plan Setup
  • Tenant provisioning of SQL PaaS

Ok. Now let’s dive into it.

– DEPLOYMENT –

Before you begin go to the document link and review the RP documentation. You can download the RP on this page from the Download the SQL Server RP installer executable file link.

Once the RP is downloaded extract the files and scripts by running AzureStack.Sql.5.11.251.0.exe. You should have the following:

mastp2-sql-rp-1

Now from an elevated PowerShell window run DeploySQLProvider.ps1.

NOTE: Important this should not be run from PowerShell ISE. It fails when it is run from ISE and you may end up with a partial deployment that requires cleanup.

NOTE: Also you can specify a local location for the SQL 2014 SP1 Enterprise Evaluation ISO if you have it downloaded already. To do this run the script with a parameter of -DependencyFilesLocalPath. If not specified the ISO will be downloaded during deployment. I prefer to let the script download it as a part of the deployment.

This script will do the following:

The script will prompt you to input local admin account info. Note that the password you input here will also be used for the SQL SA account.

mastp2-sql-rp-2

The script will then prompt you for your Azure Active Directory tenant name. This is YOURDOMAIN.onmicrosoft.com.

You will then be prompted for an Azure Active Directory account. This should be the account you deployed Azure Stack TP2 with. This will be used to access Azure Stack and create stuff such as the resource provider, resource group and other resources needed by the RP.

mastp2-sql-rp-4

You need to enter a resource group name. You can leave the default if you want.

mastp2-sql-rp-5

You will then be prompted for the SQL server VM Name. Ignore the title of the pop-up here.

mastp2-sql-rp-6

The script will then run through all of its steps. Here is what the script does as detailed in the official documentation:

  • If necessary, download a compatible version of Azure PowerShell.
  • Create a wildcard certificate to secure communication between the resource provider and Azure Resource Manager.
  • Download an evaluation build of SQL Server SP1 from the internet or from a local file share.
  • Upload the certificate and all other artifacts to a storage account on your Azure Stack.
  • Publish gallery package so that you can deploy SQL database through the gallery.
  • Deploy a VM using the default Windows Server 2012 R2 image that comes with Azure Stack.
  • Register a local DNS record that maps to your resource provider VM.
  • Register your resource provider with the local Azure Resource Manager.
  • Connect the resource provider to the SQL server instance on the RP VM

As the script runs you will see it run through each of the steps with detail and status. Be patient. I have had this take anywhere from 30 minutes to 45 minutes. Good time to go take a break.

mastp2-sql-rp-7

Once the script is done it will show that the installation is successful as shown in the following screenshot.

mastp2-sql-rp-8

NOTE: You could run the deployment script with the required parameters to avoid the prompts. For example:
DeploySQLProvider.ps1 -AadTenantDirectoryName “YOURDOMAIN.onmicrosoft.com” -AzCredential “user@YOURDOMAIN.onmicrosoft.com” -LocalCredential “username”

If for some reason the RP deployment fails you will need to view the logs to troubleshoot. Logging will be found in: LOCATIONOFYOURDOWNLOADEDRP\SQL PaaS RP\Logs in the following format DeploySQLProvider.ps1_20161205-171516.txt as shown in the following screenshot.

mastp2-sql-rp-9

– RP CONFIGURATION –

Read more

Azure Stack TP2 deployment failure 60.120.123

I recently deployed the new Azure Stack TP2 release. This install is way better. I did run into one small issue during the deployment. Below is what I ran into and the solution.

Failure in Deployment log:

2016-11-18 02:18:36 Error    1> Action: Invocation of step 60.120 failed. Stopping invocation of action plan.

Finding the root of the failure:

When walking back the step index in the summary xml log the error landed on step 60.120.123.

-<Task EndTimeUtc="2016-11-18T08:15:23.1042963Z" Status="Error" StartTimeUtc="2016-11-18T08:10:40.5896841Z" ActionType="Deployment-Phase4-ConfigureWAS" RolePath="Cloud">

-<Action EndTimeUtc=”2016-11-18T08:15:23.1042963Z” Status=”Error” StartTimeUtc=”2016-11-18T08:10:40.5896841Z” Type=”Deployment-Phase4-ConfigureWAS” Scope=”Internal”>

-<Steps>

-<Step EndTimeUtc=”2016-11-18T08:15:23.1042963Z” Status=”Error” StartTimeUtc=”2016-11-18T08:10:40.5896841Z” Name=”(Katal) Configure WAS VMs” Description=”Configures Windows Azure Stack on the guest VMs.Index=”123“>

-<Task EndTimeUtc=”2016-11-18T08:15:23.1042963Z” Status=”Error” StartTimeUtc=”2016-11-18T08:10:40.5896841Z” RolePath=”Cloud\Fabric\WAS” InterfaceType=”Configure”>

-<Exception>

<Message>Function ‘ConfigureWAS’ in module ‘Roles\WAS\WAS.psd1’ raised an exception: Time out has expired and the operation has not been completed. at Stop-WebServices, D:\WAP\Setup\Scripts\Configure-AzureStackMasd.ps1: line 699 at Restart-WebServices, D:\WAP\Setup\Scripts\Configure-AzureStackMasd.ps1: line 712 at Invoke-Main, D:\WAP\Setup\Scripts\Configure-AzureStackMasd.ps1: line 649 at <ScriptBlock>, D:\WAP\Setup\Scripts\Configure-AzureStackMasd.ps1: line 738 at <ScriptBlock>, <No file>: line 21</Message>

<StackTrace> at CloudEngine.Actions.PowerShellHost.Invoke(InterfaceParameters parameters, Object legacyConfigurationObject, CancellationToken token) at CloudEngine.Actions.InterfaceTask.Invoke(Configuration roleConfiguration, Object legacyConfigurationObject, MultiLevelIndexRange indexRange, CancellationToken token, Dictionary`2 runtimeParameter)</StackTrace>

<Raw>CloudEngine.Actions.InterfaceInvocationFailedException: Function ‘ConfigureWAS’ in module ‘Roles\WAS\WAS.psd1’ raised an exception: Time out has expired and the operation has not been completed. at Stop-WebServices, D:\WAP\Setup\Scripts\Configure-AzureStackMasd.ps1: line 699 at Restart-WebServices, D:\WAP\Setup\Scripts\Configure-AzureStackMasd.ps1: line 712 at Invoke-Main, D:\WAP\Setup\Scripts\Configure-AzureStackMasd.ps1: line 649 at <ScriptBlock>, D:\WAP\Setup\Scripts\Configure-AzureStackMasd.ps1: line 738 at <ScriptBlock>, <No file>: line 21 at CloudEngine.Actions.PowerShellHost.Invoke(InterfaceParameters parameters, Object legacyConfigurationObject, CancellationToken token) at CloudEngine.Actions.InterfaceTask.Invoke(Configuration roleConfiguration, Object legacyConfigurationObject, MultiLevelIndexRange indexRange, CancellationToken token, Dictionary`2 runtimeParameter)</Raw>

</Exception>

</Task>

</Step>
Solution:

The first option is to re-run the deployment from the specific failed step. Do this by using the following syntax:

Import-Module C:\CloudDeployment\CloudDeployment.psd1 -Force

Import-Module C:\CloudDeployment\ECEngine\EnterpriseCloudEngine.psd1 -Force

Invoke-EceAction -RolePath Cloud -ActionType Deployment -Start 60.120.123 -Verbose

The second option for this specific issue is to re-run the deployment with network parameters included. Use the following Syntax:

.\InstallAzureStackPOC.ps1 -AdminPassword $adminpass -AADAdminCredential $aadcred -AADDirectoryTenantName X.onmicrosoft.com -NatIPv4Subnet 192.168.5.0/24 -NatIPv4Address 192.168.5.3 -NatIPv4DefaultGateway 192.168.5.1 -EnvironmentDNS 192.168.5.1 -Verbose

Read more

Azure Stack Round Table Video

Microsoft MVP Lee Berg @LeeAlanBerg just finished the Azure Stack Roundtable video from MMS. This video has me and two other Microsoft MVP’s  Damian Flynn @damian_flynn and Mikael Nystrom @mikael_nystrom having a great discussion about many Azure Stack topics. In the video questions such as “does VMM still have a purpose in an Azure Stack?” world, “how is Azure Stack compared to Open Stack?”, and “how can an IT Pro get management to invest in DevOps and Azure Stack?”.

Check out the video here:

https://youtu.be/98fA4In9TSc

ASRoundtablepic

Here are links to Azure Stack sessions from MMS:

http://mms2016.sched.org/type/azure+stack

You can download all the slide decks.

Read more

Write once, deploy anywhere (Azure or Azure Stack)

This blog post is a follow up to the MMS 2016 session I recently delivered together with Microsoft Azure Stack PM Daniel Savage. The session title is “Future-proof your Career with Azure Stack in the New Hybrid Cloud World!” link here: https://www.buchatech.com/2016/04/presenting-at-mms-2016-azure-stack-backup-oms.

My demo is this session was titled “Write once, deploy anywhere“. The purpose of this demo was to show using a single ARM template (JSON file) and a single PowerShell script to deploy a VM regardless of deploying to Azure or Azure Stack. The demo was a success so yes this is really possible. In this post I will break down the JSON file, the PowerShell script, how it works and the download link for the files.

Getting the JSON file and the PowerShell script just right was a challenge as there are still some slight differences between the settings of Azure and Azure Stack. Note that this is the case with Azure Stack TP1 and I fully expect that this will change when it GA’s. In any case it is good to look at this stuff now to start to learn the ins and outs. In the end it was the combined Power of the ARM template and PowerShell to overcome any challenges. Let’s start off by taking a look at the differences in ARM between Azure and Azure Stack in the following table:

Property

Azure

Azure Stack

Location

Azure region (example: CentralUS)

local

blobStorageEndpoint

blob.core.windows.net

blob.azurestack.local

vmSize

Standard_D1

Standard_A1

vmName apiVersion

2015-06-15

2015-06-15

StorageAccountName apiVersion

2015-06-15

2015-06-15

nicName apiVersion

2015-06-15

2015-05-01-preview

vrtualNetworkName apiVersion

2015-06-15

2015-05-01-preview

networkSecurityGroupName apiVersion

2015-06-15

2015-05-01-preview

dnsNameForPublicIP apiVersion

2015-06-15

2015-05-01-preview

torageAccountName apiVersion

2015-06-15

2015-05-01-preview

NOTE: For the apiVersion on the resources Azure Stack requires 2015-05-01-preview. Resources in Azure ARM templates default to apiVersion 2015-06-15. So if we left the resources in the ARM template at apiVersion 2015-06-15 the deployment would fail on Azure Stack. However we are in luck as Azure will accept apiVersion 2015-05-01-preview. So I set vmName and StorageAccountName to apiVersion 2015-06-15 and the rest of the resources apiVersion to 2015-05-01-preview.

vmName and StorageAccountName use the same apiVersion for both Azure and Azure Stack. So Azure Stack accepts 2015-06-15 for both. Even those these are not different across Azure and Azure Stack I still wanted to list it anyway in the table.

If you have multiple subscriptions you will need to input the subscription ID. In my case my Azure has multiple subscriptions but my Azure Stack does not in this lab. In my script for Azure you need the subscription ID. In Azure Stack you do not. You may need to modify this behavior in the script if your scenario is different.

For the deployment it consists of two files. These files are:

Writeonceblog (1) AzureandAzureStack.json

CreateVMAzureorAzureStack.ps1

Here is what we have if we crack open the JSON file.

Writeonceblog (2)

A few things to note about the PowerShell script is that

  1. We prompt to identify if it is an Azure or Azure Stack deployment. We then run the appropriate block of code.
  2. In each of the deployment types (Azure or Azure Stack) we have some things hard coded in (for example blobStorageEndpoint and vmSize) and somethings pulled in dynamically by prompting for them during the script execution (for example subscriptionId and adminPassword).
  3. We are pulling in the parameter and variable values when using New-AzureRmResourceGroup and New-AzureRmResourceGroupDeployment.

NOTE: I am not a PowerShell expert. I am sure there are better more efficient ways to accomplish what I am doing here in the PowerShell script. Nothing was available to accomplish the write once, deploy anywhere goal so I put something together. Feel free to enhance the script and release back to the community.

Here is an example of the location parameter and variable in the JSON file.

The parameter:

Writeonceblog (3)

The variable:

Writeonceblog (4)

Referenced in the vmName resource:

Writeonceblog (5)

Here is an example of how we are leveraging this in the PowerShell script.

For Azure:

Writeonceblog (6)

For Azure Stack:

Writeonceblog (7)

Writeonceblog (8)

Writeonceblog (9)

Note that you can deploy VM’s to Azure or Azure Stack in many ways (Visual Studio, the portal etc..). I decided to leverage PowerShell to do the deployment’s as it gives me a great amount of flexibility. For the official article on using PowerShell to deploy VM’s to Azure Stack visit:

https://azure.microsoft.com/en-us/documentation/articles/azure-stack-deploy-template-powershell

Now let’s look at deploying a VM to both Azure and Azure Stack using a single PowerShell script and a single ARM template.

— AZURE —

Run the script and you are prompted for some of the VM info.

Writeonceblog (10)

Then you are prompted to log into your Azure account.

Writeonceblog (11)

Read more

How to add SUSE Linux image to Azure Stack

In Azure Stack you can publish your own images essentially virtual machines that can be used when deploying a new virtual machine. This is handy for publishing servers that need to be pre-configured in a certain way for consumers of your cloud. In order for your published images to show up as an option in compute within Azure Stack the images need to be added to the Platform Image Repository (PIR) within the Compute Resource Provider (CRP).

SUSE has recently published a pre-built SUSE Linux Enterprise Server 12 SP1 image that has been prepped specifically for Azure Stack. This image is ready to go and can be published to the CRP’s PIR without any needed prep of the virtual machine. In this blog post I am going to walk through the steps I took to add this image to my Azure Stack.

SUSE already has an image out there for Azure. The SUSE image used on Azure does not work right now on Azure Stack. As of right now Azure and Azure Stack have different “initialization code”. In the future I would expect these to be the same. The SUSE image also includes SUSE/azurectl a command line tool that helps you manage SUSE updates from a Linux VM hosted on Azure. More info on this here: https://github.com/SUSE/azurectl. To download the SUSE Azure Stack image go to https://download.suse.com and complete the fields as show in the following screenshot.

AS-Suse-1

You will be brought to a login page to access the download. If you do not have a SUSE account sign up for one and login. You will see the actual download at that point. Go ahead and download it onto your Azure Stack Host.

AS-Suse-2

Extract the SLE-12-SP1-Server-Azure-Stack-x86_64.vhd and copy it to C:\ClusterStorage\Volume1\Share\VM.

AS-Suse-3

Microsoft has the steps for adding images to Azure Stack’s Platform Image Repository (PIR). The process is essentially running a PowerShell script. The script is included with Azure Stack. The script creates the image directory needed in C:\ClusterStorage\Volume1\Share\CRP\PlatformImages, the JSON file in that directory, and makes a copy of the VHD in that directory. The JSON file contains the meta data about the image that shows in the Azure Stack Portal. Here is the link to the Microsoft document: https://azure.microsoft.com/en-us/documentation/articles/azure-stack-add-image-pir/

Here are the steps for running the script:

In PowerShell navigate to:

D:\CRP\VM\Microsoft.AzureStack.Compute.Installer\content\Scripts

Run this script in PowerShell:

.\CopyImageToPlatformImageRepository.ps1

NOTE: My DATAIMAGE drive letter was D. You may have a different letter.

You will be prompted for the following:

  • PlatformImageRepositoryPath use this \\SOFS\Share\CRP\PlatformImages\
  • ImagePath I put C:\ClusterStorage\Volume1\Share\VM\SLE-12-SP1-Server-Azure-Stack-x86_64.vhd
  • Publisher I put SUSE
  • Offer I put LinuxServer
  • Sku I put SUSE-Linux-Ent-12-SP1
  • Version I put 12.0.0
  • OsType I put Linux

AS-Suse-4

NOTE: These prompts are used to populate the JSON file for the image. Here is an example of the JSON file:

{

“Publisher”:”SUSE”,

“Offer”:”LinuxServer”,

“Sku”:”SUSE-Linux-Ent-12-SP1″,

“Version”:”12.0.0″,

“PlatformImage” :{

“OsDisk” : {

“OsType”:”Linux”,

“FileName”:”SLE-12-SP1-Server-Azure-Stack-x86_64″

}

}

}

Alternatively you could run the script as:

.\CopyImageToPlatformImageRepository.ps1 -PlatformImageRespositoryPath ‘\\SOFS\Share\CRP\PlatformImages’ -ImagePath ‘C:\ClusterStorage\Volume1\Share\VM\SLE-12-SP1-Server-Azure-Stack-x86_64.vhd’ -Publisher ‘SUSE’ -Offer ‘LinuxServer’ -Sku ‘SUSE-Linux-Ent-12-SP1’ -OsType ‘Linux’

As long as the script worked you should have the following as an end result in C:\ClusterStorage\Volume1\Share\CRP\PlatformImages:

AS-Suse-5

AS-Suse-6

If you have the Azure Stack portal open close out of the browser and go back in. It should be listed as an available image in Compute as shown in the following screenshot.

AS-Suse-7

Notice the difference between a Windows image and a Linux image. The Linux image gives you an authentication option of Password or SSH Key.

Windows Linux
 AS-Suse-8  AS-Suse-9

Read more

Azure Stack TP1 Deployment Issues

I recently deployed the Azure Stack POC TP1 bits on a Lenovo ThinkPad W530. The W530 has 32GB of ram, 2 x 500GB SSD’s and 8 cores. I deployed Azure Stack to a VM using nested virtualization. The VM only had 27GB of ram. It surprisingly is fast with the TP1 bits and works well as a small lab for testing. There are several blogs out there that detail deploying Azure Stack on lower hardware specs and with nested virtualization. Here is one of the posts: http://www.jofe.ch/install-azure-stack-poc-into-a-vm/

Also there is an issue with nested virtualization. The issue is the AS host VM crashes when you RDP into any of the AS fabric virtual machines. So if you deploy the lab this way it will be limited.

I did run into some issues during the deployment and will cover these in this post. They are:

Read more

On-premise SharePoint & Office 365 Cloud Hybrid

Thinking about moving your SharePoint to the cloud? If Office 365 is on your list of cloud options but you are not sure you can do a Hybrid solution. This allows you time to evaluate SharePoint on Office 365. There are many other reasons to consider a on-premise/cloud hybrid environment but you need to know … Read more