Understanding the relationships between components when leveraging an Enterprise Agreement (EA)

Various advanced scenarios on how AAD in intertwined between subscriptions & the EA

Transfer vs Change Directory

Apparently there is a bit of confusion between the “Transfer” and the “Change Directory” buttons for a subscription ;

In essence ;

Transfer Subscription = Change the Owner AND Change the Directory

What does that mean?

If you want to transfer the billing of a subscription, you do a “Transfer“.(Do note: Transferring a subscription will also change the directory to the one linked to the new owner. If this is a different one, then you’ll be linked to a new AAD Tenant.)

If you do not want to transfer the billing, and just change the directory, you do a “Change directory“.(Do note: Changing a directory will not remove the account owner. And (s)he’ll still have owner rights on it! Also be aware that all rights set linked to the previous tenant will disappear. So you’ll have to reinstate IAM. For which you can easily leverage management groups...)

Remember the last time you went shopping for a shirt? Then you surely also recall the moment in time when you were looking to find the right shirt size for yourself…

You probably also noticed that sizes might differ a bit depending on the context. A woman’s size vs & men’s size is totally different. There are geographical differences… and some people just like to wear cloths that have more “free space”.

So is today’s post about buying cloths? Hell no… 😉 But it’s to point out that there are analogies between finding the right shirt for you, and finding the right Azure Virtual Machine. Today we’ll delve into the aspects that will guide you a given T-shirt size in Azure ; for instance, why choose an FS1 above an A1_V2, where they both have 1 core & 2GB of memory. Though there is a price difference of 10€ per month on them.

From template code to deployment… If we really want to control this, then we’ll be pushing these templates through a CI/CD (continuous integration / continuous deployment) pipeline. What does that mean? We are going to put our template in a source code repository (like Github). Everytime we update the code, we’ll going to kick in a “build”. During this build we’ll be packaging it (read : create a zip file of it) and it is also strongly advised to do testing here too. Next up, if all goes well, we’ll be using that package to deploy to all our environments. And in the end, we want to be able to have a nice view on this too…

Why do it like this? Quality! We all make mistakes. We want to detect them early and not repeat them. And every change, we want to put it through the exact same process… time and time again!

Prerequisites

Starting off, I’m assuming you already have VSTS (Visual Studio Team Services) in place. If not, register for it! It’s free up till 5 users. And let’s be honest, at about 5€ per user / month & 8€ per build agent per month, … it’s still a steal! 😉

Today’s blog post will showcase how you can leverage the DSC pull feature of Azure Automation when deploying workloads to Azure. To many, the following question will pop up ; “Why use a pull mechanism, whilst I could use the DSC extension to push my configs?”. The answer is pretty simple The pull mechanism facilitates the lifecycle flow of workloads better. You can easily update the config of the virtual machine and do follow-up on the rollout of your configuration.

In my last post I talked about the possibility to manage “Azure Resource Manager Policies” via the portal. Where the policy is a good location to view the policies, this is not the area you want to be managing your policies! In today’s post, we’ll look how we can automate these things. This to ensure that all policies are effective towards their scope and remain that way. Once your subscriptions grows, you can have way too many resources & resource groups at your hands. Setting up things manually is not the way to go…

Microsoft Azure Enterprise Scaffold

How to do governance in Azure is a very common questions. So if you have found yourself asking questions in regards to that topic, do not feel strange! One of the prime resources I can recommend in this area is the “Microsoft Azure Enterprise Scaffold” ;

The scaffold is based on practices we have gathered from many engagements with clients of various sizes. Those clients range from small organizations developing solutions in the cloud to Fortune 500 enterprises and independent software vendors who are migrating and developing solutions in the cloud. The enterprise scaffold is “purpose-built” to be flexible to support both traditional IT workloads and agile workloads; such as, developers creating software-as-a-service (SaaS) applications based on Azure capabilities.

In the past I’ve noticed a lot of people are afraid of “Azure Resource Manager Templates“. I can imagine that a bulk of JSON code isn’t always that user friendly… So today we’ll take a look at another IaC (Infrastructure-as-Code) approach you might like. We’re going to do a small demo where we’ll be using “Terraform” to deploy a network on Azure. So how to get started?

We’ll be creating a kind of service user in Azure which Terraform will use to log in.

We’ll be authoring a small configuration file that will serve as the input for our network

Up in the Clouds

Views are my own

The content of this blog will, at all times, portray my own views. At no time will this reflect the views of the organization I am linked to. Neither can the information provided be used as support statement.