Azure Stack – The Azure in your data center

28 Aug

With the beginning of this year Microsoft Inspire conference (formerly Microsoft Worldwide Partner Conference – WPC) the long-awaited Microsoft Azure Stack became GA and is now order able from hardware vendors. But before you order your own Azure Stack instance it’s important to know what Azure Stack exactly is and if it makes even sense for you.

The continued Cloud OS Vision

(image source: Microsoft)

Long, long time ago 😉, about 4 years ago, together with the release of Windows Server and System Center 2012 R2, Microsoft came up with the vision to give the customers a platform which is consistent to Azure. The idea behind that is that regardless if your application is running in Azure, in your On-Premises data center or in the data center of a local Service Provider, always the same platform is underneath. But when we look back, with the 2012 R2 suit and the Windows Azure Pack as customer facing Self-Service portal, this goal was not really reached. In the meantime, even the consistent experience of the Self-Service portal is gone. Azure Pack was based on the “old” Azure Management Portal which is now, in public Azure, mostly replaced by the new ARM based Azure Portal.

Azure Stack the successor of Windows Azure Pack?
Since the announcement of Azure Stack (which is now nearly two year ago by the way) there is ongoing some confusion in the IT world. For many Azure Stack seems to be the successor and replacement for System Center and Windows Azure Pack or simply anything was Microsoft has released for the data center before Azure Stack. But, this is not what Azure Stack is supposed to be. Even when the Cloud OS vision is clearly still recognizable in Azure Stack it is, however, a completely new product category which has Microsoft never done in this form before. Even more it is not an alternative for Azure or the replacement of traditional virtualization infrastructures (based on System Center and Hyper-V, VMware or whatever). Azure Stack is much more Azure or part of your Azure strategy. And therefore, you must commit to Azure when you want to use Azure Stack.

(image source: Microsoft)

The integrated system experience – Or the Azure Stack Appliance
So, what does “a new product category” mean? It is relatively simple. Azure Stack is not delivered as a software which you can setup on your own defined hardware and configure for your individual needs. Azure Stack will be basically delivered as an appliance which is specified, build and updated by the hardware vendor of your choice and Microsoft. Or in other words Azure Stack is a SAN equivalent system which provides not storage but Azure Services in your data center. This means, for you as a customer, that you have more time to focus on running applications, provide value-added services to your customers and develop modern cloud applications instead of keeping your virtualization infrastructure up & running.

New IT roles for operating the “Appliance”
In Microsoft eyes to running an IT infrastructure in this new “Appliance” form, leads to two new roles in IT. The Cloud Architect and the Cloud Administrator or Operator.

The Cloud Architect is the one who does ensure that the Azure Stack “Appliance” can get properly integrated in the existing IT infrastructure (Network, Monitoring Systems, Identity System etc.). He does also plan the offering on the Azure Stack for internal or external customers. These are short-term tasks which can also perfectly done by an external partner.

After Azure Stack is integrated in your IT infrastructure the Cloud Operator or Administrator is responsible to operating the Azure Stack. But this is not a very high skilled role and probably also not a very time intensive task. Because of the appliance approach Azure Stack is operated by a simple management web interface (like the Azure Portal) and not by complicated Administrator consoles for which a deep knowledge of the whole system is necessary. The Cloud Operator will mainly monitor the integrated Azure Stack system and when a red light comes up he will either do simple remediate actions (e.g. restarting a service or apply an update) or he will contact the support which is provided jointly by Microsoft and the hardware vendors.

(image source: Microsoft)

Do I need Azure Stack?
Azure Stack is and will not be the all mighty platform for everyone and every use case. Azure Stack is for you when you want to adopt the cloud model and develop and run modern cloud applications, which are depends at most partially on (IaaS) VMs. But because of various reasons you cannot go directly to Azure. Such reasons can for example be requirements for low latency, law and regulations which restricts to store data outside of a specific country or bad or no internet connectivity. For all other use cases there is still Hyper-V, System Center and Windows Azure Pack. They will be fully supported and maintained from Microsoft for, at least, the next 5 years. Windows Azure Pack, for example, is compatible with Windows Server 2016 and will be support until 2027.

So in short this means:

Azure Stack is for you when:

  • You want to adopt the cloud model and focus on delivering services instead on building and operating infrastructures (no DIY infrastructure)
  • You want to develop or run modern cloud applications based on Azure services
  • But you cannot go to Azure (because of regulations, latency, bad connectivity, etc.)

Azure Stack is not your platform when:

  • You need traditional virtualization or even physical servers
  • You do not want or you cannot adopt the cloud model and use public cloud or Azure at all
  • You have a lot of legacy application which have the need for old operating systems (2008, 2008 R2, 2012…)

So, I need one. Where can I get it and what does it cost?
First, you must select your preferred hardware vendor. Today you have the choice between HPE, Dell EMC or Lenovo. In the future, also systems from Cisco and Huawei will be available. When you have selected a hardware vendor you must decide which size of the integrated system you need. Currently configuration with 4, 8 or 12 nodes are available which cannot be extended in the first 6 Month. After that Microsoft promises to come up with an update which add the functionality to extend the Azure Stack integrated systems.

After you have chosen your preferred vendor and size you will order the integrated system (hardware) directly from the hardware vendor and the hardware pricing is defined by the hardware vendor.

When it comes to licensing cost, Azure Stack works the same as Azure which means you pay only what you use (pas-as-you-use). That means every service and every VM you are provisioning on Azure Stack will be billed on hours or transactions base. Exactly like it is in public Azure. However, the prices are a bit lower because you already payed for hardware, power, connectivity etc. For completely disconnected Azure Stack setup, Microsoft offers also a “capacity model”, which allows you to license the whole capacity at once. This way you will pay a fixed yearly fee, based on the counts of physical cores in your system. For more details about the prices the pricing datasheet from Microsoft gives you a great overview.

(This blog post has also been posted under

Open high ports (over 49151) on a Windows Server Gateway

19 Jan

In a cloud infrastructure with System Center Virtual Machine Manager (SCVMM), Hyper-V and Azure Pack the Windows Server Gateway could provide the tenants with the possibility to connect their virtual network, provided by Hyper-V Network Virtualization (HNV, NVGRE), with the Internet via NAT. The tenant has then also the possibility to open and forward inbound ports to his VMs. For example he can open Port 80 to run a Webserver which is public reachable over the internet.
Basically this works very well. But lately I had a situation where I had to forward TCP Port 60000. So I was going the Azure Pack Tenant Portal and was trying to add a new Network Rule like I did it several times before:











But then it happens. The operation failed with a strange error:image

Then I had a look in SCVMM and found this, not very instructive, error:

So I digged in a little deeper and discovered on the gateway VM that SCVMM adds the external address for the tenants with the port range 1-49151. So that’s explains why you can not forward Port over 49152 on multitenant Windows Server NAT Gateway:

Probably the SCVMM defines this port range for the external address because all ports above 49151 where per RFC6335 actually destined for dynamic ports or private ports. In Windows the this range is also specified for the dynamic client port range for outgoing connections. (RPC Communication and so forth)

Bonus, Possible solutions

Option 1, manual intervention with
PowerShell :
But the RRAS Role in Windows which is also used for multitenant NAT Gateway has no restriction which would hinder you define external address with the whole port range from 1-65535 with PowerShell. In fact when you set an external address with PowerShell the default values for PortStart and PortEnd is 1024 and 65535.
This means you can remove the external address set by scvmm and add the address again with PowerShell with the whole port range. This can achieved by the following steps:

  • Get all external IP Address with Get-NetNatExternalAddress and note the values form the parameter “NatName” and “IPAddress” from the definition which you want to change.
  • Remove the existing external Address definition:

  • Add a New external Address with the same value for NatName and IPAddress but with the new port range:


Afterward you can head again to the tenant portal and now you can add a Network Rule with a port greater that 49151 without any problem. Smiley

Option 2, Registry setting for SCVMM:
After some further research I found that SCVMM has a undocumented Registry setting where you can specify the end port for the external address definition on the NAT Gateway. By creating the following Registry Key SCVMM configures automatically the whole port range (1 to 65535) if a tenant activates the NAT Gateway for his VNet in the Tenant Portal.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings\NATPortRangeEnd, REG_DWORD, Value: 65535

Disclaimer: Use these settings at your own risk! These where NO official solutions from Microsoft and changing these settings will lead probably to a unsupported situation! So be careful! Zwinkerndes Smiley