Azure Compute goes supernova…

Yesterday saw two key announcements on the Azure platform, with the launch of the new Fv2 VM series (officially the fastest on Azure) as well Microsoft sharing details on a partnership being formed with Cray to provide supercomputing capabilities in Azure.

Sun, Explosion, Planet, Moon, Orbit, Solar System

The Fv2 virtual machine addresses the need for large scale computation and runs on the fastest Intel Xeon processors (codenamed Skylake). The specification comes in seven sizes, from 2 vCPU/4Gb through to 72vCPU and 144Gb! The CPUs are hyper-threaded and operate at 2.7Ghz base with a turbo frequency of 3.7Ghz. These types of machines are generally targeted at organisations performing large scale analysis that requires massive compute power. For more details see: Note, at this time the Fv2 is only available in specific regions (West US 2, West Europe and East US)

The more eye-catching announcement was with regards to the partnership with Cray to bring supercomputing capabilities to Azure. A supercomputer is defined as:

A supercomputer is a computer with a high level of computing performance compared to a general-purpose computer. Performance of a supercomputer is measured in floating-point operations per second (FLOPS) instead of million instructions per second (MIPS). As of 2017, there are supercomputers which can perform up to nearly a hundred quadrillions of FLOPS[3], measured in P(eta)FLOPS.[4] The majority of supercomputers today run Linux-based operating systems. (Source:

Supercomputers have always felt like a bit of a mythical to me – as they have always been out of reach of the general public and the vast majority of organisations. The raw speed of the worlds fastest supercomputers (with China currently leading the road with the Sunway, operating at an insane 93 PFLOPS!) will still be something that is mythical in a sense, however Microsoft Azure is going a long way to bringing some of these capabilities to the Microsoft Azure platform, through their exclusive partnership with Cray.

This partnership is intended to provide access to supercomputing capabilities in Azure for key challenges such as climate modelling, scientific research, etc. It will allow customers to leverage these capabilities as they leverage any other type of Microsoft Azure resource, to help to transform their businesses by harnessing the power of the cloud. Microsoft are hoping this will lead to significant breakthroughs for many organisations as it opens the doors to supercomputing capabilities which will have previously been out of reach.

To read more, please refer to the Microsoft Announcement:

On a closing note, the other key advantage, and one of the key tenets of any cloud computing platform is that these resources are available on a consumption basis – you can use them for as long as you need to use them – without having any up-front capital investment, or having to pay for the time and effort required to build the capability on-premises! This is one of many compelling reasons you should be looking to build a platform like Microsoft Azure into your overall Cloud or IT strategy moving forwards.

Azure ‘Just in time’ VM access

When I first saw “’Just in time…(JIT)” as a new preview announcement for Azure VMs, my mind was cast back to one of my first roles in IT, working for an automotive firm who supplied parts for car manufacturers. JIT was (or is!) a supply chain strategy whereby the parts or products arrive at a specific point only when required. Although I wasn’t directly involved, it used to fill me with dread as some of the penalties for holding up the supply chain were eye watering Smile with tongue out Anyway, I digress…

In relation to the Azure announcement, JIT is a security process currently in preview in Azure, whereby access is granted to a virtual machine only when required. It is simple in it’s architecture, in that it uses ACLs/NSGs to lock down access to specific inbound ports until a request by an authorised user is made. This drastically reduces the attack surface of your virtual and reduces any potential attacks through basic port scanning and brute force.

Licensing wise, JIT is part of the standard tier of Azure Security. Azure Security Center comes in two tiers:

  1. Free tier – this is enabled by default on your subscription and provides access to key security recommendations to help protect your infrastructure
  2. Standard Tier – extends the cloud and on-premises capabilities of Azure Security Center. Additional features are noted below:
    • Hybrid Security
    • Advanced Threat Detection
    • JIT VM access
    • Adaptive application controls

The following link provides pricing details: (Note: the standard tier is free for the first 60 days to allow you to evaluate the components!)

Over the next few weeks I’ll aim to create blog posts for each of these areas to provide a rounded picture of what the standard security tier can provide for your organisation.

The preview of JIT can be found within the Azure Security Center pane, on the home page as seen in the below screenshot. As it is a preview you need to activate it:


An overview of some of the alert types and an activation link can be found on the next page:


If you click through the following page you will receive information around pricing and have the ability to “on-board” into the standard tier:


Once you click through, you need to apply the plan to your resources, select upgrade and then save the applicable settings:


If you navigate back to Security Center homepage – you will now see all of the new features activated within your subscription:


Enabling JIT is very simple. Click within the JIT context in the screenshot above, and you’ll be presented with the JIT pane. From within here, click the “Recommended” option, and you should see any VMs you have in your subscription not currently enabled for JIT:


From here simply click on the VM on the left hand side, review the current state/severity and then click “Enable JIT on x VMs”… A pane will appear recommending key ports that should be locked down. It is important to note from here you can add any additional ports, and also specific key things like source IPs that will be allowed access upon request, and the duration for which access will be granted.



Following this your VM will now go into a “resolved state” and you will be able to head back to the main JIT screen, navigate to the “configured” tab, and hit request access…


The request access screen will allow you to permit access to specific ports from either “MyIP” (which will detect the current IP you are accessing from) or a specific IP range. You can also specific a time frame, up to the maximum limit configured in an earlier step.

Note: the ability to request access will depend upon your user role and any configured RBAC settings in the Resource Group or Virtual Machine.


In summary? I think JIT is a great feature and another measure of the investment Microsoft are making in security on the Azure platform. It is a feature I will be talking about with clients and in conjunction with the other features of Security Center I think it is an investment many organisations will look to make.

Visibility and increasing your Azure Subscription limits and quotas

Azure contains a number of default subscription limits that should be considered as part of any Azure design phase. Majority of these limits are soft and you can raise a support case to have them raised. To avoid delays to any project I always recommend this is one of the first areas of consultation as there can be a lag between the request and it being actioned. The limitations are there for a number of reasons, primarily to help Microsoft control and capacity plan the environment whilst also ensuring usage is limited to protect the platform.

There is a very handy  view in the Azure Portal from which you can view by going to the new, preview “Cost Management + Billing” blade. From here go to “Subscriptions” and click the subscription you would like to view. From here you get some great statistics, e.g. spending rate, credit remaining, forecast, etc. all of which holds great value to assist you in planning and controlling your cost. If you navigate to “Usage and quotas” under the “Settings” menu you will see the following view:


There are other ways to view your usage quotas via PowerShell, however these are individual commands per resource. It wouldn’t take much to create a quick script that you can run regularly to expose this however the above view deals with it nicely I think. One of the example commands include “Get-AzureRmVmUsage –location <location>”


The bottom part of the page shows your current usage against your limits. It is now also very easy to “Request an Increase” – if you click this link you will be taken through a guided wizard to increase your limits.


Bear in mind this is resource and type specific, e.g. you will be asked to demonstrate the model you are using (Classic/ARM) , the impact on your business so they can set a priority, the location you need a request in and also the SKU family.


The final screen asks you to supply contact details and who should be notified throughout the ticket.


.. and there you go! – limits raised. Evidently this can take some time and it asks you to be pretty specific about what you are requesting therefore I highly recommend you take time to plan your deployments correctly to avoid any frustration.

Azure Portal–Ability to Quick Delete Resources

Very minor, and very finicky but one thing that’s always frustrated me in the Azure Portal is the inability to clear up my test subscriptions without having to resort to PowerShell. Occasionally I’ll spend some time spinning new services up directly in the portal rather than using PowerShell and when I’ve finished I like to clear things down to avoid costs which usually involves just deleting any resource groups I’ve spun up.

Now, the PowerShell to do this is pretty straight forward… can just use Get-AzureRmResourceGroup and Remove-AzureRmResourceGroup with a –force flag and a for-loop if you don’t want to iterate through, so why complain? Smile well sometimes launching a script or PowerShell is just too much which invariably means I’ll leave stuff running and then incur costs.

I’m not sure when this feature change came about (either last week during Ignite, or sooner, or has it been there all along and I’ve missed it?!) – however you can now do a select on all your resources (rather than individually), enter the word delete and then it’ll attempt to remove. This doesn’t always work as sometimes you’ll have nested resources that will block the deletion, however it’s a quick way to delete resources if you don’t want to resort to PowerShell.


Azure Network Announcements at Ignite 2017

My blog has been very quiet recently having taken a few weeks off to spend time with the family, before joining Insight UK as a Cloud Architect in the Hybrid Cloud Team. The new role is exciting and with all of the innovations in the cloud space across all vendors, it’s a great time to join Insight to help them with their quest to advise and help clients and the community in leveraging this.  However, enough of the excuses about why things have been quiet… Smile 

Image result for no excuses

Ignite 2017 is like Christmas for anyone with interest in the Microsoft ecosystem and there have been a ton of announcements from a technical, strategy and business perspective to keep us all busy for some time to come. I’ve been collating my thoughts and plan on pulling together an all up view of the event once it wraps up.

One of the key things to peak my interest (being heavily focused on Azure) is the announcements today in the networking space. The following Microsoft Azure Blog post by Yousef Khalidi, CVP of Azure Networking provides a great overview:

At first glance on the above blog I expected a small number of changes/innovations however there is 22 (with my very rough counting!) individual areas in the announcements. From general performance, better availability through to enhancements in monitoring and management. Some of the key areas that interested me include:

  • Virtual Network Service Endpoints – this is a very positive change. A number of customers questioned the need to publically address Azure services citing obvious security concerns and how this would be managed. There key question was always “how do I turn this off?” From an architecture perspective I guess the key challenge for MS was on-going management, how it would be accessed, etc. This new innovation removes the requirements for the public endpoint instead allowing you (if you want to!) restrict access to the service from your own VNet, not the internet. Awesome! As per the original MS blog, more info can be found here:
  • ExpressRoute peering changes – this interested me as one of the key topics I usually discuss with clients is the 3 different peering options avaialble over ExpressRoute; private, public and Microsoft. As the blog notes, private includes traffic to your own VNets, public is traffic to Azure VIPs and Microsoft is traffic to SaaS services, e.g. 365. Customers have had several challenges with the MS peering namely around routing configurations within their own network and with the ExpressRoute provider. More recently, it was my understanding that Microsoft Peering was actually not recommended unless specific compliance regulations demanded this. With the above announcements it will be interesting to dig into this in more detail to understand it better. One for the ExpressRoute black belt calls.. Smile
  • General monitoring improvements – it’s great to see that OMS is mentioned everywhere and is becoming a key focal point across lots of components in the MS space. There are some great improvements that will help customers in this announcement, e.g. availability of your connections, monitoring endpoints (e.g. PaaS or SaaS availability) and some cool innovations around real user measurements and traffic flow within Traffic Manager.

Each of the above topics deserves individual consideration, as evidently a lot of effort has gone in behind the scenes by the Azure team, and it’s great to see them listen to customers and act on recommendations made. Big thumbs up and look forward to trying some of these out!

A quick look at Instant File Restore in an Azure VM…

Instant File Restore directly from an Azure VM is a feature release that caught my eye recently. I remember being excited in the early days with on-premises virtualisation when backup companies, e.g. Veeam introduced the ability to mount VM backups and access the file system directly, thus allowing a quick restore and always thought it was a handy feature. Granted, it does not (always) replace proper In-VM backups of the application or service however it does provide a quick and easy way to restore a file/config, etc.

The feature went GA a couple of days ago, however the portal still has it as in-preview. More info can be found on the Azure Blog Post:

To start with you need an Azure Virtual Machine and some files you’d like to protect. I’ve created a simple VM from the marketplace running 2016 Datacentre. I created some test files on one of the disks:


You’ll then need to log into the Azure Portal, and you’ll need to have a Recovery Vault already configured with the virtual machine you want to protect added. The following screenshot shows the virtual machine ‘azurebackuptest’ added to the Recovery Vault:


If you do not have your machine added, then use the ‘Add’ button, and choose a backup policy. You now need to ensure you have a ‘restore point’ from which you can recover.

I’m now going to go back to my virtual machine and ‘permanently delete’ some files (so they’re gone from the recycle bin, too), as  you can see from the following screenshot:


We now have a virtual machine with missing files that’d we’d ordinarily need to recover from an In-VM backup agent – however we’ll use the File Recovery tools. Navigate to the vault again and choose ‘File Recovery (preview)’:


From here you need to select your recovery point, and download the executable.. it can take a minute or two to generate. Once you’ve downloaded the .exe, ‘unmount disks’ will flag up:


Now simply run the .exe file on the  machine where you’d like the disks to be mounted so you can copy them off. The exe will launch PowerShell and mount the disks as iSCSI targets (disconnecting any previous connections if you have any):


You can now browse the mounted disk and recover the files that were deleted earlier:


Once complete, remember to kill the PowerShell session as indicated in the previous screenshot, and don’t forget to click ‘unmount’ disks from the Azure Console:


That’s it! A straight forward feature but one that can be very handy occasionally and starts to bring even more parity between Azure and equivalent on-premises capabilities.

Protecting the keys to your cloud

A hot topic when migrating to Cloud providers is Security; where is data stored, how is it stored, how is it accessed, who can access it, all of the standard questions, etc. However, there is key theme that runs through all of these questions – it is focused directly on the cloud provider and misses arguably one of the biggest attack vectors; service administrators aka those with “keys to the kingdom”!

Working with clients over the last few years, I have been involved in several conversations surrounding securing admin access to cloud providers. Whether the end service is a SaaS based offering, e.g. Office 365 or an application built upon a subset of PaaS/IaaS services in Azure it is key to think about how you are going to provide access to IT staff as well as end-users so you can successfully manage and maintain those services on an on-going basis. 

The vast majority of organisations have a variety of roles within their IT department, e.g. Service Desk, Roaming Support, Network Engineers, Server Engineers, Architects, etc. Each of these have specific activities and functions that need to be performed to fulfil their role – from unlocking accounts, to creating new users or changing policies/settings.

For a long time organisations have been seeking the holy grail of RBAC (it’s not all negative, many succeed!) – however it is a difficult journey. From an on-premises Microsoft perspective, many organisations still have a legacy of over-provisioned “privileged accounts”, e.g. Domain/Enterprise Administrators and these are usually allocated directly to a “user account” which rarely has any “controls”, e.g. two-factor authentication, logging or time-bound access configured.

The lack of proper controls over privileged accounts is a serious attack vector and is even more so critical when moving to cloud. Access to administrative consoles or portals for on-premises systems is often tightly controlled through perimeter protection and they are rarely publicly exposed. With Cloud this is flip-reversed with portals primarily internet facing, e.g. or It is therefore crucial that you secure the identity used to access administrative features appropriately, through Role Based Access Controls (RBAC) such as “Privileged Identity Management (PIM)”, “Time-Bound Access”, “Multi-Factor Authentication” and allocation of specific roles as opposed to high permission accounts (e.g. Global Administrator). RBAC controls are a topic in their own right and there are many good articles on the web discussing what to consider, and how to achieve this.

As the journey to the cloud is still in its in infancy (but progressing at speed!), I would heavily recommend time is invested in getting your RBAC model correct before the legacy situation discussed earlier becomes a reality again. A few key areas you should consider on this journey include:

  • Develop a “Logical Model”. This should provide a logical view of your organisation, the standard users, operational teams, third party engineers, partners/consultants and contractors. Ultimately this should cover any user interacting with any system, regardless of permission or right. This activity may require a high degree of business analysis to understand the environment
  • Detail the roles that exist within each of the above categories, e.g. for each operational team there may be several roles that exist underneath that, there will be different roles that exist within your standard users (potentially departmental) and there may be a several types of contractor you employ
  • Understand the controls you want to apply, for example – is there any activation constraints to elevate your permissions (change request), how are you apply the access/permission (PIM), is it a time/bound permission, does the access need to be witnessed, will the account perform a system operation, does it require auditing and/or does the session need to be recorded
  • Design your account strategy, for example – what type of accounts are you creating, are you using standard user accounts or creating specialist ADM accounts? Are specialist system accounts used and authorised through PIM, are you apply MFA to these accounts?
  • Map out your “Physical Model”. This should include all available systems, technologies, etc. to whatever granularity you are trying to achieve. Some systems contain very in-depth RBAC controls, e.g. Office 365, Azure, System Center, etc. (to relate to Microsoft technologies) – examples for Office 365 can be found here:

Most importantly, an end-to-end RBAC model may take some time to achieve. It is important that you fully understand to what degree of granularity and control you want to get to prior to embarking on a project of this nature. My personal recommendation is that organisations should take a light-touch approach initially, – developing the logical model, implementing some controls and mapping these to your physical model/systems that contain built-in RBAC roles. Some of the more advanced systems that require in-depth analysis to create “roles” can be left until you have a more mature model. As this topic primarily revolves around Cloud systems, it is good news to hear that majority of the major providers operate good standards with regards to administrative and end-user based roles which you can easily map your logical model against.

Some links for further reading:

Servicing in a Cloud World

To kick things off on this rather derelict looking blog ;-), I wanted to start with a topic that I’ve been discussing with several customers recently, namely ‘Servicing in a Cloud World’. Why? Because it’s super important and requires a step change in the way IT organisations react to change, and communicate/engage this with their end-users.

Widespread adoption of Cloud technologies is almost old news now, organisations have been, and are currently, actively migrating services to a variety of cloud models. This includes anything from IaaS to PaaS to SaaS and they are therefore handing responsibilities over to the provider on a sliding scale. The most extreme end of this scale is any SaaS based solution as the provider not only manages/administers the solution for you, but also owns the roadmap which includes both feature additions and deprecations.

The following diagram taken from the “Change Management for Office 365 clients” guide by Microsoft, illustrates the difference between a traditional release model vs a servicing release model:


In a traditional release model with infrastructure/platform or services managed and administered by the organisation, typically releases happen after several months of planning, developing and testing. The actual “release” is then usually governed through change/release management processes which would generally involve some form of impact assessment as well as a mechanism by which to alert the target user base that the release is coming. This may then be supported by engagement through training / user guides, etc.


In a servicing release model where the infrastructure/platform or service is managed and administered by the provider, releases typically happen much faster and much more aggressively. This is due to the provider being incentivised (generally through a PAYG subscription approach) to be innovative on the platform to retain or attract new custom. As illustrated in the figure, this means the each stage of the lifecycle of the release is generally much smaller. This model is advantageous for organisations as it means they can leverage capability much sooner rather than having to invest in the planning/development and testing themselves. A well-understood benefit of Cloud, right?!

Onto the point of this post; organisations typically have well-defined and robust change and release management processes grown through many years of managing and delivering services out to their userbase (as discussed earlier in reference to the traditional release model). They are experts at managing changes and releases that are under their own control. However, it is crucial that organisations adapt these processes in reaction to the “servicing world”. These include gaining a full understanding of the providers roadmap in the following areas:

  • Minor / Major Changes
  • Feature additions
  • Feature modifications
  • Feature deprecations
  • New product releases (in the same portfolio)
  • Servicing (which can include downtime)
  • Maintenance

As noted earlier, these releases are typically much more frequent than previous, and will require roles and responsibilities across the IT org to adapt – making sure that they not only focus on the actual release but to understand how this will impact end users as well, who will likely require support as the frequency of change and adoption of new features/technologies will be unfamiliar.

To provide some support to this post, Office 365 Message Centre averages about 12-15 “notifications” per week (note, this changes frequently!) – anything from a new product, a feature change or a service announcement. Ultimately, as more services move to Cloud – the roles and responsibilities within IT need to adapt accordingly as IT professionals work to support their organisations operating in a cloud servicing world.