Tag Archives: Azure

#Azure : Storage Accounts

Leave a reply

Storage is an essential part of anything what you do in your day-to-day life and same applies to technology as well. Microsoft Azure Storage is a managed service provided by Microsoft cloud services. When you use any product or service, availability, resiliency, performance, scalability, durability, pricing, security and delivery play an important role, and here in case of Azure Storage it is all taken care by Microsoft.

Azure Storage provides two type of storage accounts: General Purpose and Blob.

While Azure Storage provides services in the following types:

Blob storage

File storage

Queues storage

Table storage

Disk Storage

Storage accounts and services are tightly integrated with each other. To use any one of the above service, you first create a storage account then you define the storage services based on the storage account type.

First, let understand the Storage accounts by an illustration:

Now, let understand the storage accounts in detail:

General purpose: A general purpose storage account cater all your azure storage services such as Tables, Queues, Files, Blobs and Azure virtual machine disks under a single account. This type of storage account has two performance tiers:

  • Standard storage performance tier: This performance tier fulfills all your data storage needs such as Tables, Queues, Files, Blobs and Azure virtual machine disks. This tier supports block blobs, page blobs and append blobs.
  • Premium storage performance tier: This performance tier is backed by SSDs and provides high performance IOPS, best for virtual machine disks and data intensive applications such as database. This tier supports only page blobs.

Currently, these general-purpose accounts are available in 2 versions.

General purpose v1: It is previous version of storage account and doesn’t provide latest and greatest storage capabilities, which is certainly available with new kind of storage. It also doesn’t provide access tier (Hot and Cold).

General purpose v2: This is a newer version of general purpose v1 storage and provide all the features, which are part of v1 storage. It also provides all the latest features available for blob, files, queues and tables with better performance and pricing. It also supports the access tiering (Hot and Cold) for different needs and performance.

You can upgrade your GPv1 account to GPv2 account, using PowerShell and Azure CLI.

Blob: A blob storage account is mainly to store unstructured data as blob (objects). It also provides access tier (hot and cold) to support different needs and performance. It only supports block blobs and append blobs. It provides only standard performance tier.

Access tiers: Access tiers are supported by General purpose V2 storage account and blob storage account to serve different needs.

  • A Hot access tier indicates that the objects in the storage account will be more frequently accessed. This allows you to store data at a lower access cost. Premium storage always falls under this access tier.
  • A Cool access tier indicates that the objects in the storage account will be less frequently accessed. This allows you to store data at a lower data storage cost.
Advertisement

#Azure : Map your traditional datacenter compute with cloud VMs

Leave a reply

Cloud has completely changed the IT architecture landscape. Since early days of IT till last decade, Architecture was an abstraction that used to play a key role at the time of transformation or new development. Once Architecture developed, it used to continue for many years with very minimal changes. Since cloud came in its inception, architecture has become a key in day to day work life of an IT professional because of its agility. If not daily then most probably weekly, you can observe some changes in the public cloud world and that needs to be taken care seriously.

In this post, I’ll try to simplify the cloud architecture for compute and will compare with traditional compute architecture. Apart from the simplification, I’ll provide you a logical design thinking approach that will make your life easy no matter what role you are playing in IT.

Let start from traditional datacenter.

If you are an experience IT professional, you must have seen or heard about these names at least once in your career.

Traditional type of Servers: Tower, Rack, and Blade servers.

A true traditional server that comes with multiple configuration options such as dual-processor or quad-processor etc.

New type of platforms: Converged and Hyper-Converged.

These new platforms are basically rack based servers that provide inbuilt advanced storage and networking capabilities by leveraging software defined data center technologies.

Virtualization: In last one decade, every organization has leveraged capabilities of virtualization that enable compute to run multiple virtual machines so that you can fully utilize your high-end servers and save cost in multiple aspects.

Now, let me explain complete compute story in public cloud such as Microsoft Azure.

When you look at compute available through cloud, you can easily determine that it is same kind of virtual machines, which we used to have in our virtualized environment. But in the cloud, the only difference is that you don’t worry about the underlying hypervisor and hardware that is being used behind the scene to provide you virtual machines.

In traditional datacenter, we use multiple racks to install different types of hardware and each rack connects with different power supply units through PDUs and these power supply units connect with main power supply unit. In many scenarios each rack deploys top-of-the-rack switches to provide network connectivity to the devices installed in the rack and in some cases one or two of the racks in the same row deploy these TOR switches. To overcome the challenge of entire datacenter failure, we use multiple datacenters in the form of high-availability and site-resiliency. When an administrator performs any maintenance activity in the traditional datacenter, he/she makes sure that the quorum is maintained while performing maintenance activity to avoid any kind of unexpected failures.

In cloud, H/W level high-availability is being provided by fault domain (unexpected) and maintenance level availability is being provided by update domain, and both features fit under one umbrella that i.e. known as availability sets. To provide high availability, Microsoft Azure uses multiple datacenters (at least two-three) in each region, and to support site resiliency Azure provides multiple region options in same geography or across multiple geographies.

I hope, now you will be able to sketch a clear picture in your mind about traditional datacenter vs cloud.

Now, let me help you with the logical design thinking approach. When you think to deploy a VM or set of VMs, follow the following steps in sequential order.

  1. Think about application and its big picture, keep end-users in your mind and their respective locations.
  2. Select the best suitable cloud region.
  3. Consider different tiering of solution.
  4. Consider security, high availability, site resiliency and load balancing requirements.
  5. Illustrate your network requirements.
  6. Illustrate your storage requirements.
  7. Illustrate your compute requirements.

Once documented all the above, create design diagram and find the approach to deploy your solution. For more details specific to Microsoft Azure compute, read the following blogpost.

#Azure : Virtual Machines

#Azure : Virtual Machine Configuration

#Azure : Virtual Machines High Availability

#Azure : Step-by-step Availability Sets

#Azure : Virtual Machines Scale Sets

#Azure : Large Virtual Machines Scale Sets

#Azure : Virtual Machines Scale Sets

Leave a reply

Microsoft Azure virtual machines scale sets are a next step in high availability and scalability of virtual machines. Virtual machine high availability can be achieved by availability sets in Microsoft Azure. Microsoft Azure virtual machines scale sets are a group of an identical compute resources deployed in multiple availability sets. It is a true scalable model of auto-scaling that can target large-scale services with big compute, large data and containerized workloads. As these virtual machine scale sets leverage multiple availability sets in the background, therefore scale operations are tacitly balanced across fault and update domains. These scale sets use five fault domains and five update domains in each availability set. Each virtual machine scale sets can host 0-1000 VMs based on platform images, and 0-300 VMs based on custom images.

To define autoscale configuration for consistent application performance, many permutation and combination can be used. Very common rules are compute, memory, and disk I/O utilization. Apart from these common rule of performance metrics, auto scaling of VMs can also depend on application response, or a fixed scheduled.

Note: Virtual Machines scale sets can also be deployed with availability zones.

Now, let me explain you how does this auto scaling works behind the scene. When a new VM added to the scale set, a VM instance Id will be provided to each VM that is unique within a scaleset. When you add or remove a virtual machine from the scale set, the existing Id doesn’t go anywhere. For Example: In a virtual machine scale set you have 10 VMs, if your 2 VMs removed from the scale set based on the configuration and need, and then after some time 5 VMs are added based on the load then new VMs will have Instance id 10, 11, 12, 13, 14 in an incremented manner and these VMs will be balanced across fault and update domains to maintain maximum availability.

Let see how to do it.

Login to the Azure portal and search for “scale” in the azure market place and select the “Virtual machine scale set”.

In the Virtual machine scale set panel, select “Create” to create a new Virtual machine scale set.

In the “create virtual machine scale set” fill the basics information.

Virtual machine scale set name = Enter the scale set name for your virtual machine scale set deployment.

Operating system disk image = Select the operating disk image from drop-down.

Subscription = select your subscription.

Resource group = Create a new resource group or select the existing one.

Location = Select the Azure region from drop-down.

User name = Enter the username that will be used for virtual machines.

Password = Enter the password for the user name.

Confirm password = Re-enter the password to confirm.

Scroll down and fill the required details under “Instances and Load Balancer”.

Instance count = Enter to VMs count between 0 – 100. If you enter any number more than 100 and up to 1000, all the configuration settings will be disabled except instance size. As large-scale sets with more than 100 VMs use managed disk by default and deployment of these large-scale sets take place across multiple placement groups.

Instance size = Select the VM size based on your requirement.

Enable scaling beyond 100 instances = By default “No”, if you select “Yes” then rest of the settings will be disabled as described under instance count.

Use managed disks = By default “Yes”.

Public IP address name = Define name of the public IP address that will be used for load balancer, which will be placed in front of the scale set.

Public IP allocation method = By default dynamic but Static can be selected.

Domain name label = Domain name label for the load balancer in front of the scale set.

Autoscale = By default disabled but if you enable this feature then you need to define the conditions for the auto scaling.

If Autoscale enabled, fill the required details.

Autoscale

Minimum number of VMs = Enter the minimum number of VMs that required in this scale set.

Maximum number of VMs = Enter the maximum number of VMs that required in this scale set.

Scale out

CPU threshold (%) = Enter the cpu threshold after that VM will be added.

Number of VMs to increase by = Enter the number of VMs that will added when your running VMs reach defined cpu threshold.

Scale in

CPU threshold (%) = Enter the cpu threshold after that VM will be removed.

Number of VMs to decrease by = Enter the number of VMs that will removed when your running VMs reach defined cpu threshold.

Once filled all the details, click on create to start the deployment process.

As you observed that in the entire process, virtual network and storage account was not asked anywhere because virtual machine scale sets take care of it behind the scene based on the configuration. Therefore, you don’t have to really worry about it.

#Azure : Step-by-step Availability Sets

1 Reply

In my previous post, I had explained about the high availability configuration for Azure virtual machines, Availability Sets, Fault domains and Update domains. In this blogpost, I’ll cover step-by-step configuration using Azure Portal. Availability Set configuration can be done in two ways, either by creating and configuring it in early stage based on your application architecture or set it up while creating a first VM for each tier and add rest of the same tier VMs to the respective availability set.

I am going to explain, how to create and configure availability set in advance.

Login to the Azure Portal and select “+ Create a resource”.

In the Azure Market Place, search for Availability Set.

From the search results, select “Availability Set”.

In the Availability Set panel, select create.

In the create availability set panel, define the parameters.

Name: Enter the name of the availability set.

Subscription: Select the subscription.

Resource group: Either create a new one or select an existing one based on your requirement.

Location: Select the location.

Fault domains: Select the number of fault domains, by default it is two but for specific Azure regions you can select up to three fault domains.

Update domains: Select the number of update domains, by default it is five but you go up to 20 update domains in each availability sets.

Use managed disks: Select Yes (by default) if you would like to use managed disk for all the VMs that will be create in this availability set otherwise “No”.

Once, you have filled all the details based on your requirement then select “create” to start the deployment of availability sets.

Wait for few seconds, your availability set will be created. Now, you can go head and create your VMs using this availability set.

While creating a virtual machine you get both the options, either select the existing availability set or create a new one.

If you select the “+ Create new” then again you have to fill the same details as filled earlier then select “OK”.

Once you created an availability set, you will not able to modify it and the same concept applies to VM as well. If you have created a VM as part of the availability set then you can’t come out or change the availability set until you delete and recreate it.

#Azure : Virtual Machines High Availability

Leave a reply

High availability is crucial for any production environment either it is in on-premises datacenter or in cloud. If you will go in detail of high availability, you will observer that HA can be achieved in the following levels from compute perspective:

Hardware level

Hypervisor/VM level

Operating System level

 

In this blogpost, I’ll cover high availability options available in MS Azure. First, make it clear that OS level HA has no difference between on-premises or in cloud. Now, let me provide the overview of H/W, and Hypervisor/VM level HA in on-premises datacenter or private cloud.

Hardware level HA: Dual or Quad processor, dual power supply, multi memory channel, multiple network slots, and multiple PCI card slots etc.

Hypervisor/VM level: All type 1 hypervisors provide high-availability configuration options like operating systems. Once, you configure HA for the hypervisor the VM can be created on top of that and hypervisor HA configuration maintains the availability for guest VMs if any host goes down.

Apart from the H/W and hypervisor level, all the datacenter components can be configured in high available mode such as multiple racks and power supply units etc. but when it comes to public cloud you can’t define the above configurations by your-self. However, cloud service provider does all these configurations for you in advance and to simply the things for you it just provides an availability feature.

Microsoft Azure provides “Availability Set” to provide high-availability at the VM level. This availability set feature takes care of both planned and unplanned failures. To define these planned and unplanned failures, availability set allows you to configure update domain and fault domains.

In simple words, availability set is a logical grouping of two or more virtual machines. When you setup the availability set keep the following principles in your mind:

Setup an availability set for one type of VMs. For example, in 3 tier application architecture create different availability sets for each tier.

For high availability of VMS, create multiple VMs in an availability set.

Attach load balancer with availability sets. It helps you to divide the load among the VMs.

Now, let me explain you update domain and fault domain.

Update domain: An update domain allows VMs to maintain availability during planned maintenance. Each update domain contains set of virtual machines and associated physical hardware that can be updated and rebooted at the same time. It allows Azure to perform incremental or rolling upgrades across a deployment. Once, you create an availability set then you can observe that there are five update domains by default set but you can configure up to twenty update domains.

Fault domain: A fault domain allows VMs to maintain availability during unplanned hardware failures, network outages, power failures and software updates. Fault domain describes the datacenter level components such as network switches and power supply serving a single rack can become a single point of failure for one rack or multiple racks. To avoid these circumstance, VMs in an availability set can have at least two fault domains. Many Azure region only supports two fault domains while other Azure regions can have maximum three fault domains.

If you would like to setup an availability set, follow the step by step availability sets blogpost.

#Azure : Virtual Machine Configuration

Leave a reply

When you have decided to use Azure IaaS virtual machines based on your requirements, you need to look at the configuration. Resource group is required to create any resource in Microsoft Azure. Let see the configuration of virtual machine.

Login to the Microsoft Azure Portal and select “+ create a resource”. Select compute and then select OS that needs to be deployed as part of the VM. In my case, I am deploying “Windows Server 2016 Datacenter”.

In the first step, define settings as required.

Name = Name of the virtual machine, same name will be applied as a host name.

VM disk type = Either HDD or SSD

User name = Default administrator name

Password = Password for the administrative user name

Confirm password = Confirm password for the administrative user name

Subscription = Select subscription from where the VM cost will be deducted

Resource group = Either “Create new” or “Use existing”

Location = Select the location of your Azure Region

Windows license = Select “Yes” if you have windows license otherwise “No”

Finally select “OK”

In the second step, select the VM size based on your requirement. You can short the VM size by selecting disk type, vCPUs and Memory.

In the third step, configure optional features.

High Availability = If you are deploying multiple VMs in the HA mode, create an “Availability set” and define fault & update domain as needed.

Storage = If you would like to use disk managed by Microsoft, select “Yes” in “Use managed disks” option. Otherwise select “No”, if you select “No” then you need to define a storage account.

Network = Select virtual network for the VM. If you don’t have any then a new will be created for you by default but still you can define your virtual network and use the same.

Subnet = select subnet, an ip to the VM will be assigned from this subnet

Public IP address = Use public ip address, if you want to access this VM directly through the internet. Otherwise you can select “None” here.

Network security group = Use network security group, if you would like to access or deny network traffic on the VM level.

Extensions = If you need to use any extensions as part of the VM deployment then add extensions such as PowerShell DSC, Custom Script Extension etc.

Auto-shutdown = Either “On” or “Off” and define the time and time zone based on your needs.

Notification before shutdown = Either “On” or “Off”

Monitoring = Either “Enabled” or “Disabled” for boot and guest OS diagnostics. If you enable the diagnostics then you need to use a storage account. This diagnostics user account either you can create or use the existing one.

Backup = Either “Enabled” or “Disabled”. If you enable backup option then you need to define “Recovery Services vault”, Resource group (for recovery service vault) and backup policy.

Once done select OK.

In the fourth step, review all the configuration and select “Create” to start the deployment process.

Wait for couple of minutes, your VM will be available for use. If you would like to reuse the VM configuration as-is or would like to reuse the VM configuration with customization then “Download template and parameters” for future deployments.

#AzureAD : Application Proxy

Leave a reply

I believe many of you have heard about reverse proxy multiple times in your IT career. If anytime you had published any web application through reverse proxy, you can easily understand the complexity and pain behind it. To publish a web application, you would have been worked with multiple teams for fulfilling security, network and DMZ requirements. Azure AD makes it quite simple for us, you just need to enable, download and install application proxy, and finally publish your internal web application. To use this application proxy server, you need a Windows server with either Windows Server 2012 R2 or Windows Server 2016 operating system and keep this VM as a standalone machine. So now, let’s have a look how to do it.

Login to the Azure Portal from application proxy VM and go to Azure Active Directory and then go to the Application proxy to download connector.

A web browser will open, select terms and condition and download the tool.

Once tool is downloaded, run the tool and agree to the license terms and condition and click on Install.

Now, AAD Application Proxy Connector installation will start.

Login to the Azure AD through your AAD admin account to complete the installation.

Now, installation will progress further and will finish in few minutes.

Now, go to the Azure portal and enable application proxy.

Once it is done, you will be able to find your application proxy server in active status.

Now, It is a time to publish your internal application. Therefore, go to the Enterprise applications under Azure AD.

Click in “On-premises application”.

Enter your internal url and save the settings. However, you should note down the external url to access this application.

Select Assign a user for testing.

Add users and define their roles and click on Assign.

Once, you are done please wait for some time. Now access your application from the internet by using the external url. You can also publish this app through myapps portal, the way we publish enterprise apps from the gallery.

Now, you can see that I am able to access my intranet portal. (I am not a developer, however I tried to modify the default IIS page )

If you have MFA enabled for your users, you can leverage an additional layer of security for your internal web applications as well.

#AzureAD : Azure AD Connect

1 Reply

Azure Active Directory Connect (a.k.a. AAD Connect) is a tool provided by Microsoft to connect your Windows Server Active Directory to Microsoft Azure AD. It incorporates all the features provided by preceding synchronization tools (Azure AD Sync and Dir Sync) and provides many advance features natively. Future release of AAD Connect is about to provide many FIM 2010 R2 (Forefront Identity Manager) and MIM 2016 (Microsoft Identity Manager) features such as connect to single or multiple on-premises LDAP directories, connect to on-premises AD and on-premises LDAP directories, connect to custom systems (i.e. SQL, Oracle, MySQL etc.) and connect to on-premises HR Systems (i.e. SAP, Oracle, eBusiness, Peoplesoft).

Here is the system pre-requisite to install AAD Connect:

  • At least Windows Server 2008 or later. (Note: If using Windows Server 2008 or 2008 R2 then apply the latest updates and hotfixes before starting the installation.)
  • Windows Server Standard edition or above, Essential is not supported.
  • Full GUI version of Windows Server, server core is not supported.
  • Server must have .NET Framework 4.5.1 or later and Microsoft PowerShell 3.0 or later installed.
  • At least Windows Server 2008 R2 SP1 or later if you have plan to use password synchronization feature.
  • At least Windows Server 2012 or later if you have plan to use group managed service account feature.
  • Server must not have PowerShell Transcription Group Policy enabled.

Now let’s have a look on how to install and configure AAD Connect. I am using Windows Server 2016 for AAD Connect server and will use local SQL server 2012 express edition. SQL Server 2012 express edition is a default DB option and recommended for small to medium AD environment with up to 100K AD objects. Otherwise, you can use SQL server instance with “customize” option at the time of installation.

First, go to your Azure AD tenant and create an account with global administrator directory role. This global administrator account will be used to configure AAD Connect.

Once user is created, login to the https://portal.azure.com to set the new password.

Now, open https://portal.azure.com on AAD Connect server and login with global administrator account.

Now click on Azure Active Directory in the left panel.

Now, Click on Azure AD Connect.

Now, click on “Download Azure AD Connect”. (Note: you can also download it directly from the web.)

Now, Run the executable file to install the Azure AD Connect tool.

Once installation is completed, a new wizard will open. Accept the term and conditions and click on continue.

Now, you have two options either go with express settings or click on customize. If your AAD Connect server is not domain joined then you will not have a choice to go with express settings.

Installation using express settings is too simple. You just need to make sure your AAD Connect server is domain joined and then follow the steps.

In this blogpost let me show you how to install AAD Connect with customize option. There are four optional self-explanatory configuration choices but I’m not going to select anyone for customization. However, I’ll explain these options in next step.

If you select first two options for customization then you need to provide an installation location path for “Specify a custom installation location” option and SQL server name and instance name for “Use an existing SQL Server” option. As well as you need to make sure required ports are open to connect to SQL Server.

“Use an existing service Account” customization option requires either Managed Service Account credentials or service account credential that is part of the domain in Domain Account option to connect with remote SQL Server. Make sure the user who is running the installation has SA role in SQL so that a login for the service account can be created. By default, AAD Connect creates four sync groups in local server but if you would like to select your own groups then specify those here and make sure those groups are local to the server, not in domain.

In my installation, I am not performing any optional configuration. Click on Install.

Once Installation starts, will take couple of minutes.

In User sign-in window select the sign on method and click Next.

Enter the credential of Azure AD global administrator. This step will verify your credentials.

Now, you need to connect your Widows Server Active Directory forest. This step is quite simple if your AAD Connect server is domain joined. Enter your forest fqdn and click on Add Directory.

Now, you have two option either create new AD account using Enterprise Admin credential or use existing account. In my case, I am creating a new AD account.

You may find the following error while creating a new account.

[Workaround: Go to your Active Directory and you will find a newly created user with MSOL_****** in Users container. Reset the password and copy the user name. While doing it please make you are assigning required permission (read and write) to this user.]

Required permissions:

For Password Sync: Replicate Directory Changes and Replicate Directory Changes All

For Password Writeback: Reset password

Enter the MSOL_***** credential under “Use existing AD account”.

Now, you can see that forest has been added under configured directories. Click on Next.

In Azure AD sign-in configuration you will find your Active Directory UPN Suffix but in Azure AD Domain section you can find three different states (Verified, Not Verified and Not Added).

If you want to change the Azure AD Domain status, go to the Azure portal and add custom domain. However, while adding custom domain you can verify your domain as well. In my case, I didn’t verify it.

Refresh, now you can see that status has been changed from “Not Added” to “Not Verified”. Select “continue without any verified domains” and click on Next.

Select required option and click on Next.

Select “Let Azure manage the source anchor for me” and click on Next.

Select required option and click on Next.

Select required features and click on Next.

Click on Install.

Configuration will take couple of minutes.

Once configuration completes, you will get this wizard. Click on Exit.

Now, you Windows Server Active Directory has been synced with Azure AD. If you want to do any customization after initial setup, you can open Azure AD Connect and make the necessary changes.

#Azure – Resource groups, Access control (IAM)

1 Reply

Resource groups in Microsoft Azure is a logical container and help customers to manage multiple resources in constructive manner. When you deploy multiple resources in a logical container then it is necessary to consider the security measures as well. Resource groups provide an option to manage the access control through Access control (IAM).

It offers multiple pre-defined RBAC (role based access control) roles. When you create a new subscription first time in Microsoft Azure, by default azure creates and associates it with an automatically created azure active directory. For example if I create my subscription with email address xyz@hotmail.com then an azure active directory with xyzhotmail will be created in the background. Going forward you can add multiple subscriptions into it.

However, once you are logged in to the Microsoft Azure then you can switch between the directories if you have multiple. But keep a note in your mind that one subscription belongs to only one directory in azure while one directory can belongs to multiple subscription.

RBAC roles can be assigned to the users and groups that are part of the associated azure active directory. Groups can be created in azure active directory while users either can be created in azure active directory or can be associated with their public email addresses.

Here is the list and their one line descriptions provided by Microsoft Azure.

Role name

Description

API Management Service Contributor

Can manage API Management service and the APIs

API Management Service Operator Role

Can manage API Management service, but not the APIs themselves

API Management Service Reader Role

Read-only access to API Management service and APIs

Application Insights Component Contributor

Can manage Application Insights components

Automation Operator

Able to start, stop, suspend, and resume jobs

Backup Contributor

Can manage backup in Recovery Services vault

Backup Operator

Can manage backup except removing backup, in Recovery Services vault

Backup Reader

Can view all backup management services

Billing Reader

Can view all billing information

BizTalk Contributor

Can manage BizTalk services

ClearDB MySQL DB Contributor

Can manage ClearDB MySQL databases

Contributor

Can manage everything except access.

Data Factory Contributor

Can create and manage data factories, and child resources within them.

DevTest Labs User

Can view everything and connect, start, restart, and shutdown virtual machines

DNS Zone Contributor

Can manage DNS zones and records

Azure Cosmos DB Account Contributor

Can manage Azure Cosmos DB accounts

Intelligent Systems Account Contributor

Can manage Intelligent Systems accounts

Logic App Contributor

Can manage all aspects of a Logic App, but not create a new one.

Logic App Operator

Can start and stop workflows defined within a Logic App.

Monitoring Reader

Can read all monitoring data

Monitoring Contributor

Can read monitoring data and edit monitoring settings

Network Contributor

Can manage all network resources

New Relic APM Account Contributor

Can manage New Relic Application Performance Management accounts and applications

Owner

Can manage everything, including access

Reader

Can view everything, but can’t make changes

Redis Cache Contributor

Can manage Redis caches

Scheduler Job Collections Contributor

Can manage scheduler job collections

Search Service Contributor

Can manage search services

Security Manager

Can manage security components, security policies, and virtual machines

Site Recovery Contributor

Can manage Site Recovery in Recovery Services vault

Site Recovery Operator

Can manage failover and failback operations Site Recovery in Recovery Services vault

Site Recovery Reader

Can view all Site Recovery management operations

SQL DB Contributor

Can manage SQL databases, but not their security-related policies

SQL Security Manager

Can manage the security-related policies of SQL servers and databases

SQL Server Contributor

Can manage SQL servers and databases, but not their security-related policies

Classic Storage Account Contributor

Can manage classic storage accounts

Storage Account Contributor

Can manage storage accounts

Support Request Contributor

Can create and manage support requests

User Access Administrator

Can manage user access to Azure resources

Classic Virtual Machine Contributor

Can manage classic virtual machines, but not the virtual network or storage account to which they are connected

Virtual Machine Contributor

Can manage virtual machines, but not the virtual network or storage account to which they are connected

Classic Network Contributor

Can manage classic virtual networks and reserved IPs

Web Plan Contributor

Can manage web plans

Website Contributor

Can manage websites, but not the web plans to which they are connected

Source: Microsoft

Now, you should know how the permission works here. There are three basic RBAC roles that apply to all resource types.

Owner: As suggested by name itself, full access to all the resources and has rights to manage the delegation for others.

Contributor: who can read, write/create and manage but can’t delegate rights to others.

Reader: who can view existing resources but can’t make any changes.

Now, let’s look at the inheritance of the resources. Same as other Microsoft technologies, permission inheritance works in a downwards manner here.

It means Subscription à Resource groups à Resources.

If pre-defined RBAC roles do not fulfill your requirement then you can create your own custom roles through Azure PowerShell, Azure CLI and the Rest API.

#Azure – Base Operating System

Leave a reply

Microsoft Azure supports multiple base operating system for VMs. There are many other supported scenarios where you get the base OS with application from the portal itself or you can use your customize image either for base OS only or base OS with application. In this blogpost, I’ll cover the list of base operating systems available for VMs.

List of supported operating systems in Microsoft Azure:

Operating Systems

Provided By

Pricing

Window Server 2016 (Datacenter, Datacenter – Sever Core, Nano Server, with Containers)

Microsoft

Free*

Windows Server 2012 R2 (Datacenter, Essentials)

Microsoft

Free*

Windows Server 2012 Datacenter

Microsoft

Free*

Windows Server 2008 R2 SP1

Microsoft

Free*

Ubuntu Server

Canonical

Free*

Red Hat Enterprise Linux 7

Red Hat

$0.06/hour

SUSE Linux Enterprise Server

SUSE

Free*

Debian Linux

Credativ

Free*

Oracle Linux 7

Oracle

BYOL

CentOS-based 7.3

Rogue Wave Software

Paid

Container Linux by CoreOS

CoreOS

Free*

Free BSD 10.3

Microsoft

Paid

Clear Linux OS

Clear Linux Project

BYOL

Open SUSE Leap 42.2

SUSE

Paid

Windows 7 Enterprise N with SP1 (x64)

Microsoft

Paid

Windows 8.1 Enterprise N (x64)

Microsoft

Paid

 

Free*: OS Price has included with VM pricing.


BYOL: Bring your own license


Paid: Additional OS cost will be added.

 

Note: The above information is true at present when I am writing this blog. List can be modified any time by Microsoft and therefore it doesn’t guarantee any accuracy for future use.