How to Schedule Azure VM Deployment – Step-by-Step Guide

by Mark | Jul 30, 2019 | Azure, Azure VM Deployment, Deployment, Features, How To, Schedule

How to schedule the deployment of Azure VMs

Automate Azure VM Deployment

If you need to schedule the regular deployment of your Azure VMs, you can do this easily with one of our Azure tools, AVMD (Azure VM Deployer). With the Azure VM deployer you can deploy single and multiple Virtual Machines quickly, easily and repeatably.

AVMD is completely FREE, you can download it from here and start using it right away.

Hopefully you have AVMD all setup and an azure admin account with the appropriate permissions to your Azure tenant to start the scheduled deployment of your Azure VMs.

Azure VM Deployment Use Cases

Use Case	Description
Dev/Test Environments	Scheduling Azure VM deployment for development and testing environments allows for efficient use of resources by creating and deleting VMs as needed. For example, a development team might schedule VM deployment during business hours and delete them at the end of the day to avoid wasting resources.
Batch Processing	Scheduling Azure VM deployment for batch processing can help optimize resource utilization by only creating VMs when needed. This can be particularly useful for applications that require large amounts of compute resources for short periods of time, such as data analysis or video encoding.
Disaster Recovery	Scheduling Azure VM deployment for disaster recovery can help ensure that backup VMs are always available and up-to-date. This can be critical in the event of a system failure or other outage.
Scheduled Maintenance	Scheduling Azure VM deployment for scheduled maintenance can help minimize the impact of maintenance on users by automatically redirecting traffic to other VMs while maintenance is performed.
High Availability	Scheduling Azure VM deployment for high availability can help ensure that VMs are always available to users. This can be achieved by automatically creating new VMs when existing ones fail or become unavailable.
Cost Optimization	Scheduling Azure VM deployment can help optimize costs by only creating VMs when they are needed, and deleting them when they are no longer needed. This can be particularly useful for organizations that have variable workloads or need to closely manage their cloud spend.

Launch the Azure VM Deployer

To start automating and scheduling deployment of your Azure VMS, simply open up Azure VM Deployer and let is synchronise with your Azure environment.

Scan your Azure Tenancy First

First, ensure that you have the AVMD tool downloaded and set up on your machine. You’ll also need an Azure admin account with the necessary permissions to your Azure tenant to deploy VMs. Once you’re ready to begin, launch the Azure VM Deployer and allow it to synchronize with your Azure environment.

Azure VM Deployment Settings

You can now start filling out all the settings to deploy your VMs to your Azure subscription.
Provide a Name for your Virtual Server
Choose the Servers Operating System
Azure Subscription
Azure Availability Zone Location
Azure Resource Group
Choose the Azure Virtual Machine size
Provide a local Administrator account and password
Join the VM automatically a domain (You will need an account with Domain Join Permissions)
Which Azure Storage account you wish to deploy the VM to
Any additional disks you want to add to the VM during deployment
The Azure vNet and Subnet
Further additional options if you want VM diagnostics, Azure Log Analytics, a Basic NSG, Public IP, Azure Resource Tags and finally if you want to shutdown the VM post deployment.Click Add to queue when you have filled out all the Azure VM details and it will populate these settings to the Deployment Queue.

Provide a name for your Azure VM

For any additional VMs, keep filling out the details and add them to the queue too. If the servers are all the same type and settings you just need to update the server name before adding them to the deployment queue.

Azure VM Details

Now when you have added all the Virtual Machines you wish to deploy to Azure you are now ready to start deployment, but you may want to just confirm that your VM settings are correct. Simply right click the blue icon next to each Virtual Machine in the Deployment Queue and choose Show Details

Azure VM Deployment Schedule Creation

Now lets start the deployment of your Azure Virtual Machines. Click the DEPLOY button in the bottom left hand corner and you are now presented with the options to deploy right now or schedule the VM deployment of your Azure VMs.

Azure VM New Deployment Schedule

In this example we will schedule the deployment of the Azure VMs, so click on schedule, then on OK to start the schedule creation.

Azure VM New Deployment Schedule

We are now prompted to create the schedule to deploy your Azure Virtual Machines, click on New.

Scheduled Deployment Execution

In this example we will schedule the deployment of the Azure VMs, so click on schedule, then on OK to start the schedule creation.

Schedule Creation

We are now prompted to create the schedule to deploy your Azure Virtual Machines, click on New.

Schedule Settings

Simply put in the date and time you wish for your Azure VMs to deploy at then click OK. (You can set to schedule this once off, or a reoccurring daily, weekly or monthly schedule.)

Schedule Date and Time Settings

Confirm that the date and time you want to schedule the VMs for deployment to your Azure subscription is correct.

Confirm the Schedule is Correct

Click on OK in the scheduler window and the deployment task is now confirmed.

Scheduled Deployment is underway

My scheduled deployment has now kicked off and we can see in my Azure Portal that the machines are now deploying.

Scheduled Deployment Alerting

If you had set up your email alerts, you will receive an email letting you know that your VMs have now deployed to Azure.

After some time your Azure Virtual Machines should have now deployed. As seen in the Azure Portal I can see that our Azure VMs are up and running, in the correct resource group, Azure Subscription and Azure Location.

Dont forget that the Azure VM Deployer is completely free and one of our Azure Management Tools.

Azure VMs are now deployed

After some time your Azure Virtual Machines should have now deployed. As seen in the Azure Portal I can see that our Azure VMs are up and running, in the correct resource group, Azure Subscription and Azure Location.

Dont forget that the Azure VM Deployer is completely free and one of our Azure Management Tools.

Azure FAQs

Question	Answer
What is Azure VM deployment?	Azure VM deployment is the process of creating and managing virtual machines in the Microsoft Azure cloud platform.
What are the benefits of using Azure VMs?	Azure VMs offer a wide range of benefits, including scalability, flexibility, security, and cost-effectiveness.
How do I create a new Azure VM?	You can create a new Azure VM through the Azure portal, Azure CLI, or Azure PowerShell.
What operating systems are supported on Azure VMs?	Azure VMs support a wide range of operating systems, including Windows Server, Linux, and various distributions of Unix.
What are the different VM sizes available in Azure?	Azure offers a variety of VM sizes, ranging from small, low-cost instances to large, high-performance instances.
How can I manage and monitor my Azure VMs?	You can manage and monitor your Azure VMs through the Azure portal, Azure CLI, or Azure PowerShell, as well as third-party tools such as Azure Monitor and Azure Log Analytics.
What are availability sets in Azure VM deployment?	Availability sets are used to ensure high availability for VMs by distributing them across multiple physical servers in a data center.
How can I secure my Azure VMs?	You can secure your Azure VMs through a variety of measures, including network security groups, firewall rules, and encryption.
What is Azure Site Recovery and how does it work with VMs?	Azure Site Recovery is a disaster recovery solution that can be used to replicate and recover VMs in the event of a site outage or other disaster.
How can I optimize the performance of my Azure VMs?	You can optimize the performance of your Azure VMs through various means, such as selecting the appropriate VM size, optimizing disk performance, and using caching.

Filtering Users and Groups using Azure AD Connect

by Mark | Dec 8, 2016 | Azure, How To

Filtering Users and Groups using Azure AD Connect

Microsoft’s Azure AD Connect allows you to sync your on-prem AD to your Azure AD / Office 365. If you leave all the settings as default, then AD Connect will happily sync all your AD objects. This is fine for some, however many large organisations do not want to sync their entire environment. There are options to filter the objects by selecting specific OU’s, but sometimes this isn’t granular enough. Another option is to select a group and filter based on its memberships – but this is considered “pilot” mode and should not be used in a production environment. Personally, this is my preferred method, it’s easy to setup and you can add or remove users and groups to this “sync” group whenever you wish – but who am I to argue with Microsoft.

So if you can’t filter based on OU, and you don’t want to go against Microsoft’s “best practice”, what other options do you have?

Well, you need to look use the “Synchronization Rules Editor”.

The rules editor allows you to create filter rules, to either filter in or filter out the AD objects you want to sync.

In the below example I will show you how to filter out Users and Groups from syncing.

The rules editor uses the AD Attributes of the object to determine whether or not to sync them. By attributes, I mean these…

If you have Exchange in your environment then you will have the extensionAttribute 1 – 15 in your schema. I tend to use these attributes, but you may decide to use any that suits.

OK, so what I want to achieve is to only sync the users or groups that have the extensionAttribute1 set to “Sync to Azure”. Any object without this value will not get synced.

First, lets modify the attribute for 1 user and 1 group.

Open AD Users and Computers and click View, and make sure the Advanced Features option is ticked. Without this option you won’t see the attributes tab.

Find a test user and open the properties, then click on the Attribute Editor tab.

Scroll through and find the extensionAttribute1 and click Edit. Set the value to Sync to Azure.

Repeat the process for a Group.

OK, now that we’ve set the attribute on both a user and group object, launch the Synchronization Rules Editor.

We will now create two rules, one to filter users, and another to filter groups.

Ensure the Direction is set to Inbound and click the Add new rule button.

Give the rule a descriptive name and provide a description. I suggest something useful so when you come back in 3+ months it will make sense to you.

Set the Connected System to your domain.
Set the Connected System Object Type to User
Set the Metaverse Object Type to Person
Set the Link Type to Join
Set the Precedence to 50 (or any value lower than the lowest value – if you haven’t created any other rules, then 50 will be fine).
Click Next

Click the Add Group button, and then the Add Clause button.

Set the Attribute to the attribute you selected as the “filtering attribute”. In our example, it’s extensionAttribute1.

Set the Operator to NotEqual

And enter the value to look for, which in our example is “Sync to Azure”.

Click Next.

Click Next on the Join Rules window, as it’s not used with this rule.

In the Transformations section, click Add transformation

Set the FlowType to Constant
Set the Target Attribute to cloudFiltered
In the Source field, enter true
Leave all other settings and click Add

The new rule should now appear at the top of the list.

OK, so that’s the Users rule done. Let’s move onto the Groups rule.

The groups rule is a little tricker, so instead of trying to create it from scratch, we’ll use the existing one.

Select the In from AD – Group Join rule and click Edit.

Click Yes to the message – which will disable the existing rule and create a copy for us to work with.

Give the rule a name and description.

Set the Precedence to 55.

Click Next

In the Scoping Filter section, select both of the existing clauses and click Remove Clause.

Once all the Clauses have been removed, click Add Clause.

Set the Attribute to the attribute you selected as the “filtering attribute”. In our example, it’s extensionAttribute1.

Set the Operator to Equal (with the user rule we set it to NotEqual, but here we use the Equal operator).

And enter the value “Sync to Azure”, or whatever value you are using.

Click Next.

In the Join rules, ensure the Source Attribute is set to objectGUID and the Target Attribute is sourceAnchorBinary.

Click Next.

Leave the settings as default in the Transformations window and click Save.

If you receive an expression warning, click Yes to continue saving the rule.

You should now have two rules in your rule set.

OK, now that we’ve made our rules, we need to kick off a full sync.

Open up a PowerShell console, and enter: Start-ADSyncSyncCycle -PolicyType Initial

Once the sync finishes, log into the Azure or 365 portal and have a look under the Users and Groups sections.

As you can see, only my two test users have been synced

And in the groups, only my two test groups are synced too.

While you are here, please take the time to check out our software products for Azure, VMWare, Hyper-V and SCCM.

Azure VM Scheduler tasks not running

by Mark | Dec 7, 2016 | AVMS, Azure, Cloud Computing, Errors, Fixes, How To, Schedule

Troubleshooting Azure VM Scheduler (AVMS) Task Issues

If your scheduled AVMS tasks aren’t running as expected, don’t worry — this guide will walk you through common issues and how to resolve them quickly.

Error 1: Proxy Authentication Required

Check the AVMS log file located at:

C:\Program Files (x86)\SMIKAR Software\AVMS\avms.log

Look for entries similar to the following:

01/11/2016 11:23:46 AM Attempting to ADD-azureaccount using account XXXX@XXXX.onmicrosoft.com
01/11/2016 11:23:46 AM Failed to ADD-azureaccount using account XXXX@XXXX.onmicrosoft.com - error user_realm_discovery_failed: User realm discovery failed: The remote server returned an error: (407) Proxy Authentication Required.

This typically means your on-site proxy server requires authentication. The AVMS console works under your domain account (which has proxy access), but the scheduled task runs under the system account — which usually doesn’t.

To fix this:

Open Control Panel → Task Scheduler
Find the AVMS task, right-click, and choose Properties
Change the user from System to a domain account with proxy permissions

Azure VM Scheduler Tasks

Azure VM Scheduler Tasks Properties

Your scheduled task should now run successfully using this authenticated user.

Error 2: Email Notification Hang

Check the log again for an incomplete sequence like this:

01/11/2016 12:46:56 PM Started code block to Stop VMs
01/11/2016 12:46:56 PM Adding servers to array for email
01/11/2016 12:46:56 PM email form created notifying task has started

If the log halts here, it’s likely due to an issue with your email notification settings. Confirm that:

Your SMTP server address, port, and credentials are correctly configured in AVMS
Firewall or outbound rules aren’t blocking mail traffic

Alternatively, you can disable email notifications if you don’t need them — but note that you won’t receive job start/complete alerts.

Need More Help?

Still having issues? Contact support@smikar.com or visit our AVMS page for more resources.

70-534 – Maintaining the Azure Cloud

by Mark | Oct 19, 2016 | 70-534, Azure, Cloud Computing

70-534 – Maintaining the Azure Cloud

Azure Hand Cloud

Azure Overview

As explained in the previous post around the Azure Datacentres, Microsoft’s Azure offerings have to be reliable, have high performance and be incredibly resilient. Therefore maintaining the Azure Datacentres can be quite a complex procedure. Microsoft has to have a plan in place for the two possible scenarios of maintenance, planned and the unplanned. Planned maintenance happens on a schedule, while unplanned maintenance occurs in response to an unexpected event, normally due to a hardware failure.

Azure Planned Maintenance

Microsoft routinely schedule maintenance of their hosting hardware. Whether these are a firmware update or applying a security patch to the underlying hypervisor. While most of these will not effect the virtual machines you have running on this infrastructure, there are some circumstances which may cause your VMs to shutdown and restart. Obviously Microsoft providing a multi-tenanted environment, it would be near impossible to schedule the downtime of all their customers servers that would be effected by the maintenance, so hence this may occur to your VMs

Azure Availability Sets

So how do you avoid this and ensure your application keeps on going? Well Microsoft have an Service Level Agreement (SLA) in place only for multi instance VMs in the same logical group, which is called an availability set. When Microsoft performs maintenance, they ensure that not all the virtual machines within the same availability set will be restarted at the same time. So to give your applications the best chance, ensure that you have at least two virtual machines performing the same function (perhaps clustered for example) within the one availability set. Always remember that a single virtual machine will not have an SLA available and could be restarted at any time. During an Azure datacentre maintenance, the single instance VMs are brought down in parallel, then upgraded and restarted in no particular order. So if you have your applications on single instance Virtual Machines, they will naturally be unavailable during the maintenance window. Microsoft does send customers an email prior to any scheduled maintenance, detailing the date and time the outage is to be expected, but this is only for planned maintenance. Unplanned maintenance you will of course not be notified.

Azure Resilience

As shown in the example picture above, we have two Front End servers for the application within their own availability set, with the corresponding database servers also in their own one. AppSrv1 will be on a different host, and perhaps even rack to AppSrv2. Should the host running AppSrv1 have an issue and have the need to restart all the virtual machines running on that host, then this will not effect AppSrv2. Same thing goes for the database servers. It is best practice to also separate your application databases and other roles and have them in their own availability sets.

Where possible, always create multiple instances of your virtual machines and have them within the same availability set. If you do this you will then qualify for the Microsoft SLA.

Azure Update Domains

Azure Update Domains (sometimes these maybe called Upgrade Domains) are utilised for planned updates to the Azure Cloud service. The default number of Update domains is five with a maximum of twenty available to each availability set. Your virtual machines are spread across update domains to avoid outages to your applications and as Microsoft rolls out updates to their infrastructure, they will only ever update one update domain at any time. This will avoid unnecessary outages to your system

Azure Unplanned Maintenance

So what happens when there is unplanned maintenance I hear you ask? As I am sure you are quite aware, problems with hardware can be a regular occurrence at times. Failures with the network, server issues and even total rack failures can and do happen. Azure detects these failures automatically and will migrate your virtual machines to another host that is healthy.

Azure Fault Domains

Azure fault domains are a boundary between the infrastructure within the same datacentre to help prevent issues caused by unplanned outages. Multiple virtual machines that are deployed in the same availability set are also allocated to different fault domains. Fault Domains can be on separate racks, separate power supplies, different switches and sometimes even cooling systems. Fault Domains within Azure are assigned in a pattern, FD0, FD1, FD0, FD1 and so forth. All this helps alleviate any unplanned localised hardware failures that will interrupt services to your virtual machines. It is very unlikely that there will be issues with two or more fault domains, in fact it is more likely that there is a whole datacentre outage, which in this case you would need cross region replication.

Azure Fault Domain Example

Now we have shown two fault domains with the availability sets detailed in the earlier diagram. You can see that AppSrv1 and DBSrv1 are in the same fault domain, and therefore more than likely on the same hardware or within the same rack. Should the rack or hardware have a failure, then AppSrv2 and DBSrv2 will not be effected by this outage and will continue delivering your applications.

VM Fault Domain

AppSrv1 0

AppSrv2 1

DBSrv1 0

DBSrv2 1

When you boot your servers within your availability set they will be allocated to a fault domain in an order, e.g. FD0, FD1, FD0, FD1, FD0, FD1 etc. The pattern of fault domain allocation never changes and will always follow this pattern.

So how does this work?

It is worth noting, that each availability set automatically creates two Fault Domains and is assigned to five Update Domains. For example, you build an availability set with six virtual machines. The first five are allocated to the five Fault Domains, and the sixth virtual machine is then added in to the first Fault Domain, with the first VM. In the worst case, VMs number one and six could be restarted at the same time if a maintenance event was to occur. As Update Domains are only ever restarted one at a time and that the restart order of the Update Domains isnt always sequential, these can be restarted in any order.

Cross Region Redundancy

Now, what happens in the unlikely event that a complete Azure Datacentre has an issue. Cross region redundancy is available within Azure which is basically a backup copy of your data in a secondary Azure datacentre (replication of your VMs to a second region). You can set up Cross Region Redundancy for your applications that require this level of service (thinking Tier 1 applications for the most part). You select the primary region to deliver your services from, choose a secondary region and Azure will take care of the replication. In the event of something catastrophic of the primary region, the system will automatically failover to the secondary region. The beauty of this service is that this happens automatically, there is no manual intervention required. Azure automatically takes care of the replication and the failover.

Service Throttling

As Microsoft’s Azure is a multi-tenant environment, with many many customers, how can Microsoft fairly monitor consumption? Service throttling will ensure consistent delivery of services to every customer they have according to the customers subscription limits. If throttling does ever occur, the experience that will be delivered will be degraded services. Azure bases this throttling on a few different criteria. From the amount of data stored, the number of transactions and system throughputs. You do always have the option to increase your limits should you ever reach them. As always, you should plan your architecture within Azure with performance in mind, but if the need arises you can scale up and scale out as needed.

FAQs

Question	Answer
What is Azure planned maintenance?	Azure planned maintenance is when Microsoft schedules maintenance of their hosting hardware, which could include firmware updates or applying security patches to the underlying hypervisor. Some virtual machines may need to be shutdown and restarted during this process.
What is Azure Availability Sets?	Azure Availability Sets is a feature that allows customers to group virtual machines together in the same logical group to ensure that they are not all restarted at the same time during maintenance. Having multiple instances of virtual machines in the same availability set qualifies customers for the Microsoft SLA.
What is Azure resilience?	Azure resilience refers to the ability of a system to withstand and recover from hardware failures or other unexpected events. To ensure resilience, it is best practice to separate application databases and other roles, and to have them in their own availability sets.
What are Azure Update Domains?	Azure Update Domains are used for planned updates to the Azure Cloud service. Virtual machines are spread across update domains to avoid outages to applications, and Microsoft will only ever update one update domain at any time.
What is Azure unplanned maintenance?	Azure unplanned maintenance occurs in response to unexpected events such as hardware failures. Azure automatically detects these failures and migrates virtual machines to another healthy host.
What are Azure Fault Domains?	Azure Fault Domains are a boundary between infrastructure within the same datacenter to prevent issues caused by unplanned outages. Multiple virtual machines deployed in the same availability set are allocated to different fault domains, which can be on separate racks, power supplies, switches, or cooling systems.
How do I ensure my applications are resilient in Azure?	To ensure application resilience in Azure, it is recommended to group virtual machines in the same availability set, separate application databases and other roles, and have them in their own availability sets.
How does Azure handle unplanned outages?	Azure automatically detects unplanned outages and migrates virtual machines to another healthy host.
How does Azure prevent outages during planned maintenance?	Azure uses Azure Availability Sets and Azure Update Domains to prevent outages during planned maintenance.

Well thats it for todays post. Ill continue with the Architecting Azure Solutions 70-534 study in a further post. Make sure you book mark this site for further updates.

70-534 – Azure Datacentres

by Mark | Oct 18, 2016 | 70-534, Azure, Cloud Computing

70-534 – Azure Datacentres

The second post of many more to come to help you understand and pass the Architecting Microsoft Azure Solutions exam and gain that sort after certification.

Well first things first, lets cover off the Microsoft Azure Datacentres. The datacentres may be known as Azure GFS datacentres (Global Foundation Services) or they were newly renamed to Microsoft Cloud Infrastructure and Operations (MCIO).

Microsoft’s Azure datacentres are in all 17 different regions throughout the world all networked together with access available to these datacentres from 140 different countries. They are operate in 10 different languages and 24 different currencies. Not only can you run your servers and applications in these datacentres, they also are used by Microsoft to deliver their own services, like Office 365 services, Bing search, Xbox live as well as the Azure platform. These datacentres are huge (some as big as three large cruise ships placed end to end) with over one million servers serving over one billion customers. They have to be to provide infrastructure to themselves as well as all their clients around the world with real time replication, low latency and very very high reliability.

The regions they are available in are;

Azure Region Location

Central US Iowa

East US Virginia

East US 2 Virginia

US Gov Iowa Iowa

US Gov Virginia Virgina

North Central US Illinois

South Central US Texas

West US California

North Europe Ireland

West Europe Netherlands

East Asia Hong Kong

Southeast Asia Singapore

Japan East Tokyo, Saitama

Japan West Osaka

Brazil South Sao Paulo State

Australia East New South Wales

Australia South East Victoria

Central India Pune

South India Chennai

West India Mumbai

Choosing a Microsoft Azure Datacentre

Whenever choosing a datacentre to build your environment in, its always best practice to choose the one that is closest to your users, this will help with any latency, performance and reliability issues. Not all of the Microsoft Azure datacentres share the same set of services. (Microsoft regularly roll out new services. To see which services are available and where, visit the Microsoft website https://azure.microsoft.com/en-us/regions/services/). Australia has an additional constraint that only customers residing within Australia and New Zealand can uses the services within that region. Additionally, China which you may have noticed isnt specified above, delivers Azure services independently from the others as it is offered by one of their largest Internet Service Providers, 21Vianet. Data within the China Azure infrastructure remains within China and doesnt replicate or share data to the other regions.

Azure Datacentre Resiliency

Having datacentres that big and making them highly available creates a huge problem. Just think about having to manage over one million servers, patching them, updating firmware, replacing failed hardware. The number of servers alone is enough to make the average administrator faint. The advantage that Azure has over the average datacentre is, the amount of physical hardware servers. When one server starts to fail, its virtual machines can be migrated to another healthy server. Faults are detected and migration is handled automatically. The ability to quickly recover, or in most instances, migrate these virtual machines live, means high resilience is built in. This is known as Mean Time to Recover (MTTR), which allows Microsoft to provide the availability of services to their customers, quickly and without user intervention.

Azure Security

Microsoft takes security of seriously. Imagine all the data belonging to all these customers and Microsoft have a rogue employee start stealing data. Well Microsoft has locked down Azure only so that the administrators only have enough access and time to do the task they require. This is known as Just in Time Administrator Access. By default, Microsoft administrators do not have access to customer data and can only gain access when granted by the client and only during a predetermined window. All their administrator access and actions are logged, monitored and audited. Physical access to the Microsoft Azure Datacentres and hardware is also monitored with continuous surveillance.

As you can imagine, Microsoft Azure datacentres would be a target for all sort of nefarious type of hackers and threats. Threat management is also provided as part of the service. Data is scrubbed and monitored for any potential threats prior to it coming in to your precious servers. Intrusion detection, Denial of Service attack prevention, regular penetration testing, data analytics and machine learning tools help to keep your servers and data safe. Azure scans all software during all physical server builds. They also have real time protection and on demand scanning of their cloud services and virtual machines.

Deployment of patching is automated to the Azure infrastructure. Patching deployment is based on the severity of the patch. Azure will also patch customers virtual machines unless the customer has requested to manually patch their systems themselves (ie using SCCM or WSUS or the like).

Having so many customers share infrastructure between them in the multitenant environment, could be a huge security risk. Azure logically isolates each customer from each other so that no customer should be able to access any other customers data. For customers own security and compliance, Microsoft Azure provides a set of tools to help the client achieve this. Azure offers technology like data encryption in transit and at rest (Azure storage is encrypted). Azure also obtains some of the highest security certifications, such as ISO27001 and ISO27002,
HIPPA, FISMA, FedRAMP etc (The Microsoft Azure Trust Centre details the certifications held further. Please visit https://www.microsoft.com/en-us/trustcenter/Compliance for more information).

Azure Datacentre Designs

With so many datacentres that are this large and with so many customers utilising their services and expecting reliability and performance, every Azure datacentre is designed with infrastructure availability as the main concern. Every critical component of Azure is built with redundancy in mind. Multiple Uninterruptible Power Supplies (UPS), huge arrays of batteries and large generators with fuel reserves to compensate in case of a tremendous disaster.

As you can imagine, running each of these datacentres is a huge expense for Microsoft. So each datacentre is also designed with to lower their total cost of ownership. Each of the Azure datacentres operate with a lower Power Usage Effectiveness (PUE) rating as low as 1.125, in comparison an average datacentre PUE rating is an 1.8. A low PUE means that the datacentre consumes less power and Microsoft achieve this by looking at the datacentre as a whole, not just focusing on each single component.

Azure Datacentre FAQs

Question	Answer
What are Microsoft Azure Datacentres?	Microsoft Azure Datacentres are facilities that house and maintain servers and other infrastructure for running applications and services on the Azure platform. They are located in 17 different regions throughout the world and are used by Microsoft to deliver their own services as well as provide infrastructure to clients around the world.
What are the regions in which Microsoft Azure Datacentres are available?	Microsoft Azure Datacentres are available in 17 different regions around the world, including Central US, East US, West US, North Europe, West Europe, East Asia, Southeast Asia, Japan East, Japan West, Brazil South, Australia East, Australia South East, Central India, South India, and West India.
How do I choose a Microsoft Azure Datacentre?	When choosing a Microsoft Azure Datacentre to build your environment in, it’s best practice to choose the one that is closest to your users to improve latency, performance, and reliability. Not all of the datacentres share the same set of services, so it’s important to check which services are available and where on the Microsoft website. Additionally, customers residing within Australia and New Zealand can only use the services within the Australia region.
What is Azure Datacentre Resiliency?	Azure Datacentre Resiliency refers to the high resilience built into Microsoft’s Azure datacentres, which allows virtual machines to be quickly recovered or migrated live to another healthy server in the event of a failure. Faults are detected and migration is handled automatically, resulting in a Mean Time to Recover (MTTR) that allows Microsoft to provide the availability of services to their customers quickly and without user intervention.
How does Microsoft ensure the security of its Azure Datacentres?	Microsoft takes the security of its Azure Datacentres seriously, and has implemented measures such as Just in Time Administrator Access, physical access monitoring, and continuous surveillance to prevent unauthorized access. Threat management is also provided as part of the service, which includes intrusion detection, Denial of Service attack prevention, regular penetration testing, data analytics, and machine learning tools to help keep customers’ servers and data safe. Azure logically isolates each customer from each other to reduce the risk of security breaches in the multi-tenant environment.

Well thats enough for the moment. I will continue on to the next blog post for the 70-534 exam another day.

« Older Entries

Next Entries »

How to Schedule Azure VM Deployment – Step-by-Step Guide

How to schedule the deployment of Azure VMs

Automate Azure VM Deployment

Azure VM Deployment Use Cases

Dev/Test Environments

Batch Processing

Disaster Recovery

Scheduled Maintenance

High Availability

Cost Optimization

Launch the Azure VM Deployer

Scan your Azure Tenancy First

Azure VM Deployment Settings

Provide a name for your Azure VM

Azure VM Details

Azure VM Deployment Schedule Creation

Azure VM New Deployment Schedule

Azure VM New Deployment Schedule

Scheduled Deployment Execution

Schedule Creation

Schedule Settings

Schedule Date and Time Settings

Confirm the Schedule is Correct

Scheduled Deployment is underway

Scheduled Deployment Alerting

Azure VMs are now deployed

Azure FAQs

What is Azure VM deployment?

What are the benefits of using Azure VMs?

How do I create a new Azure VM?

What operating systems are supported on Azure VMs?

What are the different VM sizes available in Azure?

How can I manage and monitor my Azure VMs?

What are availability sets in Azure VM deployment?

How can I secure my Azure VMs?

What is Azure Site Recovery and how does it work with VMs?

How can I optimize the performance of my Azure VMs?

Filtering Users and Groups using Azure AD Connect

Filtering Users and Groups using Azure AD Connect

Azure VM Scheduler tasks not running

Troubleshooting Azure VM Scheduler (AVMS) Task Issues

Error 1: Proxy Authentication Required

Error 2: Email Notification Hang

Need More Help?

70-534 – Maintaining the Azure Cloud

70-534 – Maintaining the Azure Cloud

Azure Overview

Azure Planned Maintenance

Azure Availability Sets

Azure Resilience

Azure Update Domains

Azure Unplanned Maintenance

Azure Fault Domains

Azure Fault Domain Example

So how does this work?

Cross Region Redundancy

Service Throttling

FAQs

What is Azure planned maintenance?

What is Azure Availability Sets?

What is Azure resilience?

What are Azure Update Domains?

What is Azure unplanned maintenance?

What are Azure Fault Domains?

How do I ensure my applications are resilient in Azure?

How does Azure handle unplanned outages?

How does Azure prevent outages during planned maintenance?

70-534 – Azure Datacentres

70-534 – Azure Datacentres

Azure Region Location

Choosing a Microsoft Azure Datacentre

Azure Datacentre Resiliency

Azure Security

Azure Datacentre Designs

Azure Datacentre FAQs

What are Microsoft Azure Datacentres?

What are the regions in which Microsoft Azure Datacentres are available?

How do I choose a Microsoft Azure Datacentre?

What is Azure Datacentre Resiliency?

How does Microsoft ensure the security of its Azure Datacentres?