Monday, August 28, 2017

Out of order...

While mountain biking I had an accident during which I broke my clavicle. As such this blog will be silent for a while.

Rest assured, 'I'll be back' to quote a famous line of an equal famous movie.

Thursday, August 24, 2017

Mobile First–Cloud First’ Strategy – How About System Center – 06 – SCVMM


Advice to the reader
This posting is part of a series of articles. In order to get a full grasp of it, I strongly advise you to start at the beginning of it.

Other postings in the same series:
01 – Kickoff
02 – SCCM
03 – SCOrch
04 – SCDPM
05 – SCSM


In the sixth posting of this series I’ll write about how System Center Virtual Machine Manager (SCVMM) relates to Microsoft’s Mobile First – Cloud First strategy. Like SCOrch & SCSM I don’t think that SCVMM is going to the cloud…

SCVMM
First released in 2007 to enterprise customers only, it was targeted for managing large numbers of virtual servers based on Microsoft Virtual Server (yikes!) and later (Q2 2008), hypervisors based on Hyper-V. 

Since then VMM has grown into a product of its own, with every release new functionalities being added, whereas others were removed, for instance:

  1. P2V migration removed from SCVMM 2012 R2 onwards;
  2. Support for Citrix XenServer removed form SCVMM 2016;
  3. Creation and management for private clouds, added in SCCM 2012 R2.

Private Cloud
Let’s dwell a bit longer on the last item of the previous list, the creation and management of Private Clouds.

On October 18th 2013, Microsoft announced the General Availability of Windows Server 2012 R2 (Cloud OS) and System Center 2012 R2. All new here was the Private Cloud vision of Microsoft.

Back then Azure was still branded Windows Azure and offered IaaS mostly (VMs, storage) and PaaS (websites, SQL, Python SDK and Traffic Manager).

As such, the public cloud was limited in its reach and capabilities. None the less, Microsoft top brass envisioned everyone going to the cloud. First everyone would build their own cloud (Private Cloud) and later on, move it into the public cloud, like Azure.

In order to enable the private cloud based on Microsoft technologies, System Center 2012 R2 had to make it happen. And SCVMM 2012 R2 would be the enabler of everything, bringing compute, storage and networking together, abstracting it and offering it as ready to use/consume building blocks for the (internal) customers of the IT department.

Instead of having to worry about compute, storage, networking, connectivity, middle tiers (like SQL and web for instance), a business unit could provision itself with just as many web/SharePoint servers (for instance) as required, as long it fit into the amount of resources assigned to them, hence the private cloud.

All through a portal. In the back SCVMM would initiate the required workloads, using a library of images, additional software and configuration items. Also with deep integration with SCOM (to monitor the provisioned VMs and the underlying hypervisors) and SCOrch, SCVMM could rollout almost anything, no matter how many tiers required.

Simply because the moment a certain type of installation was out of the reach of SCVMM, one or more SCOrch runbook could take care of it, complete with the registration and handling of the required tickets in the service system like SCSM.

The promise and the reality
On itself it sounded awesome. Finally the fully automated data center was there. Just roll out a bunch of servers, network components and loads of storage and SCVMM would take care of the rest. Even bare metal deployment of new Hyper-V hosts could be handled by SCVMM!

So say goodbye to rogue IT and – as IT department – be back in control in such a way by really helping the organization forward and not by frustrating it. Now a business unit could allocate workloads as required, all with ‘nothing’ more of a self-service portal and the click of a mouse button…

However, reality turned out to be a ‘bit’ harsher. For instance, the maintenance of SCVMM can be quite a challenge, especially when the SCVMM ‘fabric’ (all the components and servers used for the SCVMM environment) consists out a lot of servers, combined with a huge SCVMM library.

Especially the latter can be a real pain to maintain and to keep healthy. Orphaned resources in the SCVMM library are a ‘special’ treat. And yet, without the library SCVMM is dead in the water. Other challenges with the library are (but not limited to…): The migration of the library to a new set of servers, or making it high available (and keeping it like that!), or upgrading it to the latest version.

All in all it made SCVMM quite a challenge to run and maintain. However, the end user experience wasn’t that good either. Like any other software, a good GUI is crucial. And somehow, Microsoft seems to have issues with providing good user interfaces, whether full blown or web based. SCVMM isn’t an exception here unfortunately…

Trial & error. Self-service portal SCVMM
From the beginning the self-service portal of SCVMM turned out to be a challenge to say the least. Slow, buggy, not covering all required aspects of a full blown self-service portal, you name it. The SCVMM self-service portal had it all.

SCVMM 2012 R2 ditched it completely and had it replaced by System Center 2012 R2 App Controller. This replacement also delivered (basic) integration with Azure, enabling moving VMs to Azure. Actually, you had to store the VM in App Controller, and then copy it to Azure using the Azure Transfer Wizard, incorporated in App Controller. Afterwards additional steps in Azure were also required. As a result the ‘integration’ between your private cloud and Azure became a joke.

Due to the lack of success App Controller is dropped in the System Center family. When still requiring a self-service portal wrapped around SCVMM 2016, Microsoft recommends Windows Azure Pack instead, which is another challenge on itself.

However, between System Center 2012 R2 and System Center 2016 the world evolved quickly. Also Microsoft. So the private cloud mantra was scuttled because the world didn’t embrace it to the extend as the Microsoft top brass back then anticipated. Time for another approach!

Say hello to hybrid cloud (and goodbye to private cloud)
Instead Microsoft noticed that companies weren’t ready to roll out many different hard to manage and maintain System Center components in order to build their own private cloud.

Sure, the SDD (software defined datacenter) is still something wanted by many companies, but it’s easier to build and to maintain using other hardware/software incorporated solutions. On top of it, many companies chose all together not to board the private cloud train since it didn’t bring them to where they wanted to get.

Instead companies started to look for more hybrid solutions where their data, applications and workloads are running in different environments, whether on-premise (100% datacenter or 20% private cloud, who cares?) and in the public cloud. As a result their workforce can work anytime, anywhere with any device (when the apps are right that is).

Hence, the hybrid cloud was born, with a far bigger life expectancy and future ahead then the (Microsoft) private cloud ever had. Main reason here is that the hybrid cloud is based on the needs and requirements of the customers themselves, whereas Microsoft’s private cloud was forced upon the very same customers by Microsoft HQ. And even Microsoft HQ can’t dictate the world what to do or what to use. I guess their blew a different wind back then at Microsoft HQ compared to the more recent years.

Hybrid cloud: Nail to the coffin of SCVMM
As a direct result the role of SCVMM has dwindled big time. It’s back to it’s original function as intended when introduced back in 2007: Managing large numbers of hypervisors, primarily based on Hyper-V Sure you can also manage – a bit that is – VMware hosts through vCenter with it, but you really don’t want to go there, believe me.

Which is good, because SCVMM 2012 R2 never really delivered in enabling the private cloud. To much of a pain to maintain, configure and the lot. Also limited use cases since per type of configured server you have to go through the process of building it and save the related configurations as profiles. Only doable and justifiable when you roll out tens to hundreds of servers like that. However, in the smaller IT shop undoable and unrealistic.

Verdict
Sure, in a hybrid scenario there are still valid use cases for SCVMM, as long as you’ve got a considerable amount of Hyper-V hosts running locally. However, when migrating/moving to the cloud, the use case of SCVMM lessens.

Yeah I know that Microsoft has released more information about delivering features and enhancements on a faster cadence for some System Center components, SCVMM included.

None the less, workloads will move more and more into the cloud. Whether VM based (IaaS) or service based (PaaS). As such the role of SCVMM will diminish over time. It will never get the role it had once with the GA of System Center 2012 R2 (enabling the private cloud).

Therefore with the move to Azure, SCVMM won’t stick and will shrink (at its best!) into a tool to manage Hyper-V based workloads running locally.

But when looking into how the Azure portal is growing into reach – in conjunction with Azure Automation Webhooks and Hybrid Workers – changes are that with the Azure Portal you’ll end up managing your local Hyper-V and perhaps even VMware hosts from the Azure portal.

With that the role of SCVMM will be downplayed even more and put into the role of an emergency tool when there is no internet connection, or the starting point of rolling out new Hyper-V hosts and the moment they’re online, management will taken over by the Azure portal.

Coming up next
In the seventh and last posting of this series I’ll write about SCOM (System Center Operations Manager). See you all next time.

Wednesday, August 23, 2017

Azure Under The Hood – 01 – A New Series

How stuff works
My whole life I want to know ‘how stuff works’. Just hitting a button and use a vacuum cleaner, dish washer, laptop, RC car, mobile or whatever, won’t ‘fly’ with me for a long time. Soon I’ll be prying, investigating and ‘researching’ the WHY something works and based on what principals.

Sure, it has cost me some childhood birthday presents (a radio I once got for my birthday was dismantled within a day and beyond repair…), but I always LEARNED from it. That attitude didn’t change when PCs came into my life, or better my father’s professional life.

Of course, the first months I kept a respectful distance and only used the PC (IBM PS/2) as allowed by my father, all the while keeping a keen eye at the big white case, wondering what magic was happening right there under my nose. So you can imagine how thrilled and happy I was when the PC broke down and the technician had to be called! Somehow my father wasn’t that happy about it…
Personal System 2 Series of Computers.png

I ascertained to be there when the technician came around to fix it. So when he opened the PC case I was just a few inches away, firing of questions, pointing out all the different parts in order to learn as much as possible. The PC got repaired and I learned a lot that day. Some years later I started to assemble my own PCs…

Azure & me
This attitude/curiosity hasn’t really changed over the years. No, I won’t break anything apart anymore in order to try to learn from it. Today there is Google, YouTube, Wikipedia and the lot. Saves me a lot of hassle and money as well. Sure, it takes a lot of the investigation fun away, but keeps me out of trouble as well.

But still. It gnaws at me when I use something without having a deeper understanding of it all. Same goes with Azure. Yes, I know what a computer is, what a network does, what a datacenter is for. But Azure is WAY MORE THAN THAT!

As such I’ve done a lot of investigation. Read a lot of books, online articles, watched many video’s and so on. Simply to gain a deeper understanding of what’s happening under the hood of Azure, or better when you’re clicking around in the Azure portal.

The funny thing is that Microsoft is quite secretive about it. Even towards MVPs they don’t share a lot. And when I found some information, I had to double check it, in order to know for a full 100% that I am not violating any NDA. When in doubt, I don’t share it.

The new series
As a result I’ve collected a lot of interesting non-NDA information all about Azure under the hood, to be shared with you out there. No, it won’t make you (nor me for that matter) an ‘Azure-Under-The-Hood-Expert’, but at least it will give you a better understanding of how Azure works.
Image result for cloud under the hood

In the time to come I’ll share that information. But please feel free to comment and send your own findings. I’ll use that as well and name you as well of course as the source.

See you all next time!

Microsoft By The Numbers

Bumped into this website by accident.
image

It shows how many people are using Microsoft products and services. The numbers are VERY impressive… And NO, the presentation of it all isn’t dull, like an Excel sheet (boring!) or long list (yawn!).

Instead it’s more like an animated infographic. Go here to see what I mean and be amazed. You can even download the related PowerPoint slide deck and use it.

Tuesday, August 22, 2017

Azure Managed Disks: How Azure VMs Are Moving To PaaS

Introduction
When implementing Azure VMs one is using Azure as an IaaS solution offering. At least this is how Microsoft introduced Azure VMs back in 2012. However, things are moving with a fast pace in IT and in todays cloud things are moving with lighting speed.

As such it’s time to take a new look at Azure VMs in order to know whether they still adhere to the IaaS cloud delivery model only, or that things have changed a ‘bit’.

Azure VMs as IaaS
Sure, when you opt for the ‘classic’ approach to roll out an Azure based VM, it’s IaaS at its best. You need to provision a Storage Account, perhaps even Diagnostics storage account for monitoring, a Virtual Network and so on. Let’s focus on the Storage Accounts here.

When rolling out Azure VMs in the classic manner you have to think about your Azure subscription limits, since per subscription one is only allowed a certain amount services and resources. For instance per Azure subscription one is ‘only’ allowed 200 Storage Accounts (default) with a maximum of 250 (requires contacting Microsoft Support).

Of course, you could use only ONE Storage Account for all your Azure based VMs. But that approach isn’t going to ‘fly’ since per Azure Storage Account there are limits as well, like 20,000 IOPS per Azure Storage Account. So when you ‘hook up’ too many Azure VMs to the same Azure Storage Account, the available IOPS per Azure VM will drop dramaticly, resulting in under performing VMs.

In an ideal world one would prefer to facilitate one Storage Account per Azure VM. However, when requiring 250+ VMs, this approach isn’t viable. Even when the total amount of Azure VMs stays well below the 250 mark, there are still quite a few reasons why not to use 1:1 (VM:Storage Account) approach.

As a result, deploying an Azure VM requires planning, preparations, guidance and administration afterwards. Without it, sooner or later your company will have serious problems with Azure VM resource allocation and the lot…

Azure VMs as IaaS++
How nice would it be to roll out Azure VMs without  the headache of managing storage accounts? Instead, Azure manages storage for you! In this case you only have to think about the type & size of the disks.

All of the above (and much more) is delivered by Azure Managed Disks.

So now we’re talking about a new kind of Azure VMs. Sure the Azure VMs themselves are still adhering to the IaaS cloud delivery model, BUT a very important component of that same Azure VM (the disks and underlying storage) has become a different ball game all together.

Instead of doing it all yourself, Azure manages it for you. So the disks – when using Azure Managed Disks that is – have become IaaS++ at least, perhaps even more like a PaaS solution? Of course, this ‘statement’ could result in a never ending discussion on semantics. Let’s not go there please.

But no matter how you look at it, Azure VMs with Azure Managed Disks have evolved the cloud IaaS delivery model in that respect to a whole new level.

Verdict
Azure VMs with Azure Managed Disks are the next level of how Azure can enlighten the regular burden of VM management and administration as a whole. It also brings Azure VMs as IaaS to a new level. One might say IaaS++ or even – the storage management that is when Azure Managed Disks is being used – as a PaaS cloud delivery model.

Should my company use Azure Managed Disks?
Good question! Before you make any decision it’s vital to know what Azure Managed Disks deliver and how their costs are stuctured.

For instance, Azure Managed Disks deliver better high availability out of the box. Simply because these disks are automatically placed in different storage units. So when one storage unit goes down, it won’t affect many VMs but one or a subset instead.

Also with Azure Managed Disks it’s much easier to copy an image across multiple storage accounts and so on.

On top of it all, there are two types of ‘flavors’ (AKA performance tiers) for Azure Managed Disks: Premium (SSD based) and Standard (HDD based).

Also good to know: With Azure Managed Disks you can create 10,000 Azure Managed Disks per subscription, per region and per storage type! For example, you can create up to 10,000 standard managed disks and also 10,000 premium managed disks in a subscription and in a region. As a result you can create thousands of VMs in a single subscription.

As you can see, there is much more to Azure Managed Disks, all of which has to be taken into account when making a decision.

Recommended resources
For a better understanding of this article I recommend to read these resources:

Monday, August 21, 2017

Azure Active Directory (AAD): Where Is My Data Stored?

Situation
A customer wants to use Azure Active Directory (AAD) but needs to know where the data (like user name, credentials and attributes) is stored. On itself a solid question. However, the answer wasn’t easily found. Or better, quite obscure.

The basics
Before the answer is found (and clarified) one most familiarize him/herself with some Azure ‘slang’. In this posting I limit myself to the ones related to this article.

  • Geo: Abbreviation for geography. At this  moment Azure is to be found in 13 geo’s and two more are announced (France & South Africa).
  • Region: Can be looked upon as one HUGE data center, hosting many Azure services. For instance, there is an Azure region in Amsterdam (Netherlands) and one in Dublin (Ireland)
  • Region Pair: Two directly connected Azure regions, placed within the same geography BUT located greater then 300 miles apart (when possible). An Azure Region Pair offers benefits like data residency (except for AAD…), Azure system update isolation, platform provided replication, physical isolation and region recovery order.

Example of a Geo, with its Azure Regions and Region Pair is Geo Europe. This Geo has two Azure Regions: one in Amsterdam (Netherlands), named West Europe and the other Azure Region located in Dublin (Ireland), named North Europe. Together they make up the Region Pair for Geo Europe.

Azure data storage location by default
By default most Azure services are deployed regionally, enabling the customer to specify the Azure Region where their customer data will be stored. This is the case for VMs, storage and Azure SQL databases.

So when you deploy a set of VMs in the Region West Europe with related storage, that data will be stored in Amsterdam (Netherlands). And yes, and some parts of that data will be replicated to North Europe as well since both Regions are part of the same Region Pair. Reasons for this replication might be of an operational nature and/or of data redundancy options selected by the customer.

This is as expected. However it get’s trickier…

USDS (United States of Data Storage)?
However, there ARE exceptions to the above. In quite a few cases customer data will be stored outside by the customer selected Region (and Region Pair as such).

For instance there are some Azure regional services like Azure RemoteApp, Microsoft Cognitive Services, Preview, beta, or other prerelease services and Azure Security Center which data may be transferred and stored globally by Microsoft. And many times it will end up (in some form) in the USA, or United States of Data Storage…

How about AAD?
AAD isn’t an Azure service offered locally, but is designed to run globally. Any Azure service designed to run globally, it doesn’t allow the customer to specify a certain Region where to store the data related to that same Azure service.

And again, Microsoft isn’t very clear about where that data is exactly stored: ‘…Azure Active Directory, which may store Active Directory data globally…’.

To make it even more confusing the same website states: ‘…This does not apply to Active Directory deployments in the United States (where Active Directory data is stored solely in the United States) and in Europe (where Active Directory data is stored in Europe or the United States)…’

Azure services which operate globally are:

  • Content Delivery Network (CDN);
  • Azure Active Directory (AAD);
  • Azure Multi-Factor Authentication (AMFA);
  • Services that provide global routing functions and do not themselves process or store customer data (Eg: Traffic Manager, Azure DNS).

Still not sure where AAD stores its data…
Because Microsoft is a bit elusive about where EXACTLY AAD data is stored, it’s better to look how AAD is made up technically. Many times the technicians don’t do politics Smile.

The article Understand Azure Active Directory architecture is quite recent and very informative. It tells about primary and secondary replicas used for storing AAD data. And the latter ones make it interesting: ‘…which (the secondary replicas) are at data centers that are physically located across different geographies...’.

Basically it tells me that AAD data is replicated globally. It will turn up in the USA (USDS) as well. As the matter of a fact, it will turn up in every Region servicing Office 365. Simply because without AAD there is no Office 365 consumption.

And for sure, the same article clarifies it even more with the header Data centers: ‘…Azure AD’s replicas are stored in datacenters located throughout the world…’.

Verdict
When using AAD you know for certain that user data (user names, credentials and meta data for instance) ARE replicated globally.

Do I need to worry?
That depends. Know however, that Microsoft goes to extreme lengths to secure your data. Physical access to their data centers is limited to a subset of highly screened people. On top of it all, Microsoft doesn’t allow governments and agencies to access customer data that easily.

And yes, Microsoft offers the Trusted Cloud. Looking at the sheer amount of certifications and data residency guarantees, you can rest assured that Microsoft does its outmost best to offer the most secure cloud services platform ever built.

Alternatives?
Sure, you can look for alternatives. Like Amazon AWS S3. However, the meta data related to those ‘buckets’, also containing customer data, isn’t guaranteed to stay at a certain location either…

Another approach could be using Azure Geo Azure Germany. Because of VERY strict privacy laws, the exceptions for data storage for regional and global Azure services DON’T apply…

Recommended resources
For a better understanding of this article I recommend to read these resources:


Cross Post: Speeding up OpsMgr Dashboards Based On The SQL Visualization Library

Dirk Brinkmann (Microsoft SCOM PFE, based in Germany) has posted an excellent article all about an easy (and undocumented) way to speed up the SCOM/OpsMgr dashboards bases on the SQL Visualization Library MP.

Go here to read all about it.

Thank you Dirk for sharing!