Azure Stack – Updating Microsoft Extensions via PowerShell

I recently came across an extremely useful PowerShell script to manage images and extensions within the Azure Stack marketplace thanks to this post by Kris Turner:

This script will download all current Microsoft virtual machine extensions from the marketplace. It also downloads Ubuntu Server and Windows Server images as well. Once all have been downloaded, it will compare versions and prompt you to remove older versions if desired.

Deploying a Secured Service Fabric Cluster in Azure Stack

The goal of this post to help fill in the gaps from the Microsoft Azure Stack User Documentation on deploying a secured service fabric cluster using the Azure Stack Developer Kit (ASDK). The same steps could easily be used on the Azure Stack integrated system.

Azure Stack – Identifying and Deleting False Alerts in 1.1807.0.76

Issue: When updating from 1.1805.7.57 (1805 hotfix) you may encounter an issue with Alerts displayed that are not actually true. The alerts, upon further investigation, appear to be false, but they cannot be closed from the portal.
Version Impacted: 1.1807.0.76 (only seems to be present when upgrading from 1.1805.7.57)
Microsoft Response: Being unable to clear the alerts after updating to 1807 is currently a known issue and fixes are under investigation. There is no resolution at this time.

The two alerts I received specifically were the following:

  • Azure Stack update stopped with errors – Critical – Capacity
  • Activation Required – Warning – Azure Bridge

vRealize Orchestrator – Resolving the ${message} blue screen issue

Here’s an issue that frustrated me for a while until I was able to finally resolve it. If you’re here reading this too, I feel your pain… Hopefully this helps you out as well!

I’m deploying vRealize Orchestrator (vRO) 7.3 in our lab for testing as I continue to build our cloud environment. To help detail the issue we have been having, I’ll provide a quick overview of our environment.

Learning Puppet

In this learning puppet series, you will see my thoughts and notes as I work to teach myself puppet within my own home lab. Any issues I come across will be documented here along with any notes I wish to save to document my journey.

I hope find this series helpful and I challenge you to take on this task with me as well! I have absolute zero experience with using puppet as a configuration management tool. In the past, I have used various shell scripts or powershell scripts to automate configuration tasks. Puppet provides an easier and better way to standardize configuration across your infrastructure.

I will be using the Puppet Learning VM along with a book “Puppet 4.10 Beginner’s Guide” by John Arundel. The book is fairly dated, but after reading several reviews I feel this is a good place to start and then we catch up to the latest release (5.x) from there.

To begin, let’s discuss the lab configuration. My initial thought is to start small with the Learning VM and a small local instance. Once I’m comfortable enough, I would like to test out a larger instance using AWS. Puppet has a Pay As You Go enterprise instance on AWS that is free for 1 – 10 nodes. Even though that may be free, the compute/storage in the lab to run it won’t be which is why I will want to refer to AWS much later.

Home lab configuration:

  • Puppet Master
    • Ubuntu 16.04.2 LTS (Xenial)
    • 6GB RAM
    • 2 x CPU
    • 100GB storage
  • Puppet nodes
    • Ubuntu 16.04.2 LTS (Xenial)
      • DNS1 – DNS server for the home lab
      • WEB1 – Apache/PHP server for testing
      • DB1 – MySQL DB server for testing

VMware, XtremIO, and Native Multipathing


So, you have your XtremIO installed, configured, and ready for use. Now what? If you’re like most I’ve worked with, you have probably already started creating volumes, presented them to your ESXi hosts, and have created datastores. Often times, I am finding myself working with customers who express some performance concerns post-migration to XtremIO and it is usually due to a commonly overlooked item in the EMC Host Configuration Guide.

The most overlooked item is in regards to VMware Native Multipathing. If you’re familiar with the EMC VNX arrays, you probably noticed that the VNX devices presented in vCenter defaulted to a Round Robin path policy. This is because VMware had a rule in place that identified CX/VNX arrays to accommodate for ALUA (active/active) and would assign that policy (VMW_SATP_ALUA_CX) to those devices which set them to Round Robin instead of Fixed Path.

With the XtremIO, there is no such in rule in place. By default, the XtremIO devices will identify with policy VMW_SATP_DEFAULT_AA and I have noticed that the path selection policy is set to Fixed (Default).

To overcome this, it is recommended to create a new Storage Array Type policy per the EMC XtremIO Host Configuration Guide.

esxcli storage nmp satp rule add -c tpgs_off -e “XtremIO
Active/Active” -M XtremApp -P VMW_PSP_RR -O iops=1 -s
VMW_SATP_DEFAULT_AA -t vendor -V XtremIO

This creates a custom rule for XtremIO devices, sets the path selection policy to Round Robin, and then sets the path switching frequency from a default of 1000 I/O packets to 1. This ensures optimal distribution and availability of load between I/O paths to the XtremIO storage.

As you may see in the Host Configuration Guide, it is noted below:

Note: With NMP in vSphere versions below 5.5, clustering is not supported when the
path policy is set to Round Robin. For details, see vSphere MSCS Setup Limitations in
the Setup for Failover Clustering and Microsoft Cluster Service guide for ESXi
5.0 or ESXi/ESX 4.x. In vSphere 5.5, Round Robin PSP (PSP_RR) support is introduced.
For details, see MSCS support enhancements in vSphere 5.5 (VMware KB 2052238).

Note: Use this method when no XtremIO volume is presented to the host. XtremIO volumes already presented to the host are not affected by this procedure (unless they are unmapped from the host).

If you find yourself in the situation above with volumes already mapped and datastores created, you can simply storage vMotion your VMs over to new XtremIO volume datastores with this new rule in place.


To continue with part 3 of this series, I will quickly recap where we left off.

  • We have a source VNX and a target XtremIO that we need to migrate boot LUNs and VMware RDMs to
  • SANcopy enabler installed on source VNX
  • VNX SP ports are zoned to XtremIO target brick (in my case, I am using brick 4 of a 4-brick cluster)
  • We have identified our source LUNs and created our target XtremIO volumes

For our BOOT from SAN LUNs, we do not need these to be incremental SANcopy sessions as they are only 30GB in size each. To cutover the boot LUN, we will do the following:

  1. Place the host maintenance mode to evacuate any/all VMs on the host
  2. Shutdown the host
  3. Start the SANcopy session
  4. Once complete, remove the source volume from the VNX host storage group
  5. Map the boot volume to the VMware host as HLU 0 on the XtremIO
  6. Adjust host boot from SAN policy (in my case, I am working with UCS hosts)
  7. Boot host and verify successful boot
  8. Exit maintenance mode

The SANcopy session can be created in either the VNX GUI or CLI using naviseccli. You will need to know the following: source LUN name (or ID), source LUN GUID (wwn), target XtremIO FC ports, target volume mapped HLU # to the VNX initiator group.


As you see here, I mapped host 1’s target boot volume as HLU 1 to the VNX initiator group. (Host 2 mapped as HLU 2, etc.) I decided to create my SANcopy sessions in the CLI as I have about 40 host boot LUN sessions to create.

naviseccli -h -User sysadmin -Password sysadmin -Scope 0 sancopy -create -name “LUN 47_BOOT LUN_ESXP10” -srcwwn 60:06:01:60:BB:B4:30:00:61:28:DD:1D:82:F0:E1:11 -fibre -destportwwn 51:4f:0c:50:62:07:af:30 10 -throttle 8 -verify -o

This syntax breaks down like this:

naviseccli -h (SP IP) -User <username> -Password <password> -Scope 0 sancopy -create <session name> -srcwwn <source LUN GUID / WWN> -fibre -destportwwn <XtremIO target FC WWN> <destination LUN number (HLU)> -throttle <0 – 10> -verify -o

While scripting out my session create commands, I am alternating between SCs and ports on the XtremIO to balance the load out.


As for our incremental sessions, we need to create a Reserved LUN Pool that the incremental sessions will use. For that we will follow EMC best practices and create our incremental sessions accordingly. More to come on that soon!