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: http://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 the "got-chas" of doing this.

Here is a quick list of a few common things to consider when looking at a Hybrid.

  • How will ...
Read More