In this Azure cloud development tutorial, we will create a network watcher and demonstrate its functionalities.

You can learn more about the Azure Virtual Network in ServerWatch’s guide: What is Azure VM?

How to Create Network Watcher in Azure

To begin, log in to the home page of Azure Portal and search for the phrase Azure Network Watcher.

On the Network page, click Add to create a new network watcher.

A new network watcher will be created. Now, click on the watcher and select all of the regions you want the watcher to continuously monitor.

Next, we need to deploy the network watcher and wait for the resource to be created.

Once completed, go to the network watcher, as shown below:

View the Overview section of the network watcher, as depicted here:

Use Azure Powershell to Work with Network Watchers

You can also use the Azure Powershell to work with an Azure network watcher. Once the virtual machine is created, you can use the below commands to operate the network watcher.

To enable network watcher, use the following command:

$networkWatcher = Get-AzNetworkWatcher -Name NetworkWatcher_easteurope -ResourceGroupName rgname

In the above example, you have to provide the network watcher name and resource group name.

To troubleshoot with IP Flow, developers can use the PowerShell command:

Test-AzNetworkWatcherIPFlow

The following code demonstrates how to create a network watcher from PowerShell:

$subscriptionId = ''
$networkWatcherName = ''
$resourceGroupName = ''
$apiversion = "2016-09-01"
$requestBody = @"
{
'location': 'West Central US'
}
"@
armclientput "https://management.azure.com/subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.Network/networkWatchers/${networkWatcherName}?api-version=${api-version}" $requestBody

To delete a network watcher from the PowerShell, use the following command:

Remove-AzNetworkWatcher -Name NetworkWatcher_westcentralus -ResourceGroupName NetworkWatcherRG

Final Thoughts on Creating an Azure Network Watcher

In this Azure cloud computing tutorial, we have shown you how to create an Azure network watcher. The goal of this article was to help developers understand the basic details of Azure network watchers and how to configure them.

Read more Azure cloud computing development tutorials.

The post Create and Configure Azure Network Watcher appeared first on CodeGuru.

Read: How to Create an Azure File Sync Service

How to Configure Azure Firewall

To begin learning how to configure Azure Firewall, we have to first create a virtual network. To do so, login to Azure Portal and search for the phrase Virtual Networks.

Click Create Virtual Network, select your Subscription and Resource Group. If you do not have one, go ahead and create a new Resource Group.

Next, add the name of your virtual network and select Region.

Click Next and then add or update your IP addresses:

Read: Azure Storage Account Replication Types

Then, in the Security tab, select the following options, as depicted in the next image:

Click on the Review + Create tab, then click Create.

Wait for your deployment to complete. Once finished, click on Go to Resource.

Choose + Subnet Link to a Subnet in the newly created virtual network.

Add all the details required for the subnet and save it. You will now have two subnets under the newly created virtual network.

Read: Configuring Load Balancer in Azure

How to Create a New Firewall in Azure Firewall

Next, we will need to create a new firewall. Search for the phrase Firewall in the Azure Portal and click Create.

Add the name of the firewall, then select the Region, Resource Group, and Availability Zone.

After this, we will want to select Firewall Tier Standard and then Firewall Management: Use a Firewall Policy to Manage This Firewall or create a new firewall policy, as depicted below:

Select the previously created virtual network and update the IP Address space.

Next, create a Public IP or select an existing one if unused.

After adding all of the basic firewall details, the screen will look like the image below:

Finally, click Review + Create. Review all of the provided details to make sure they are accurate and create the firewall.

Now we have successfully deployed the Azure Firewall within our firewall. Take note of the Firewall Private IP, Firewall SKU, and the Firewall Subnet.

Read more Microsoft Azure tutorials and cloud development guides.

The post Configuring Security Rules In Azure Firewall appeared first on CodeGuru.

In this database development tutorial, we will explain the step-by-step process used to create a dedicated SQL Pool in Microsoft’s Azure Synapse Analytics.

How to Create a Dedicated SQL Pool

To start, we want to create a dedicated SQL Pool in Azure. Log into the Azure Portal with your free or paid subscription. Then click on Create a Resource.

Next, in the Search Bar of Azure Portal, type Dedicated SQL Pool.

Choose Dedicated SQL Pool (Formerly SQL DW) and create a new Dedicated SQL Pool by clicking on the Create button.

Next, we need to either create a new Resource Group or select an existing one.

Enter the name of the new Resource Group and click Ok.

Now, fill in the basic details of the Dedicated SQL Pool.

Read: How to Migrate On-premise SQL Database to Azure

How to Create a New SQL Server in Azure

At this point, a new SQL Server needs to be created If you do not have a server setup already. If you do, you can skip this part. To create the new SQL Server, click on Create New and enter the Server Name and Location. If you already have an SQL Server, you can enter that information here.

Next, for now, you can simply use SQL Authentication. Enter in your Server Admin Login details and a secure password. Once finish, click OK.

Now, after you have entered the SQL Pool details with your SQL Pool Name and set the server, you also need to choose your performance level – choose wisely, as per your project needs.

Select the Performance Level and you will be prompted with a new Configuration option.

In the Performance Level screen, you can scale your system per your performance and storage scalability needs. Once set, click on Apply.

Next, click on the Networking tab. Select the appropriate options and then click on the Additional Settings tab.

Make sure you choose the Sample under the Use Existing Data section, which will create a sample database named AdventureWorksDW.

Then, click on Review + Create. Finally, click on Create to initiate the deployment process.

A notification will pop on the screen as the deployment is in progress; you can see the resources that will be created in real-time.

During deployment, you can also click on the Operation Details to learn about the operation which contains data from Operation ID, Timestamp, Duration, and more.

Once the deployment is complete, you will be provided with a Go to Resource link.

In the Resource Overview section, you can learn more about the Resource Sample Pool that was created. The server’s name, connection strings, and performance levels are all detailed here. Developers can also check out the metrics visualization of the DWU Usage that we just created.

Read more database programming and database administration tutorials.

The post Create a Dedicated SQL Pool in Azure appeared first on CodeGuru.

Read: Create an Azure File Sync Service

How to Create an Azure Database Migration Service

In this section, we will demonstrate how to create an Azure Database Migration Service instance. To start, open the Azure Portal and search the phrase Azure Database Migration Service.

On the Azure Database Migration Service screen, select Create. Choose one option from the Database Migration options and continue to use Azure Database Migration Service.

Next, select the Subscription, create a new Resource Group (or choose an existing one), specify a Name for the instance of the Azure Database Migration Service, select the Location , and choose Azure as the Service Mode and Pricing Tier. Then, click Networking.

In the Networking tab, choose an existing virtual network or create a new one.

In the next screen, review the details of the Migration Service and hit Create.

Wait for the resource to be created. Once finished, click Go to Resource.

Select New Migration Project.

On the New Migration Project Screen, specify a name for the project, then select SQL Server Data Source, in the target server type. Next, choose Azure SQL Database and then, for type of activity, select Data Migration. Click Create and Run Activity.

Read: Azure Storage Account Replication Types

SQL Server to Azure Database Migration Wizard

Next, in the Source tab, enter the SQL Server Source Database details.

In the Select Source Databases screen, check all the databases you want to be migrated to Azure.

Next, in the Target Database tab, enter the Server Name, Authentication Type, User ID, and Password.

Select or enter the Target Database Name in the Map to Target Databases tab.

Next, select the list of objects for migration.

Finally, in the Summary tab, verify all the details you have entered and selected. Click Start Migration to migrate data from your on-premise database to the cloud.

Final Thoughts on On-Premise SQL Database Cloud Migration

In this database administration tutorial, I have shown you how to migrate a database to an SQL managed instance using the Azure Database Migration Service. Hopefully this article will help database developers to better understand the basics of Azure database migration.

Read more Microsoft Azure tutorials and cloud development guides.

The post How to Migrate On-premise SQL Database to Azure appeared first on CodeGuru.

Read: How to Secure Azure Storage Accounts

How to Create an Azure Storage Account

To begin, open the Azure Portal, then click +Create a resource on the New menu.

Next, click Storage and then choose Storage account – blob, file, table, queue.

On the Create Storage Account page, select your Subscription and Resource group. Create a new resource group if you do not have an existing one.

Enter the new Resource Group name and click Ok.

Next, in the Instance details, enter the Storage Account Name, select Region, Performance, and Redundancy options. After entering these details, click Review + Create.

Once all of the validation is passed, click the Create button.

Wait for the Resource Deployment to complete.

After successfully creating the Azure Storage Account, open it. Click Files under the Service.

Next, you need to create a file share. To do so, click the + File Share link.

Enter the name for the File Share and select Tier. Then, to finish, click Create.

The File Share will now be created.

Read: Setting Up Budgets and Configuring Alerts in Microsoft Azure

How to Create an Azure File Sync Service

To create an Azure File Sync Service, open the Azure Portal and search for Azure File Sync.

Click Azure File Sync. Once the screen appears, click the Create button to deploy the File Sync service.

In the Deploy Storage Sync screen, you need to enter the Name and select the Subscription, Resource Group, and Location. After selecting these, click Review + Create.

Next, review all of the details you entered and choose Create.

Wait for the File Sync Deployment to complete.

After creating the File Sync Service, you need to create a Sync Group. To do so, open the LocalSync and then click + Sync Group.

Next, on the Sync Group, enter the Sync Group Name and select a Storage Account by clicking Select Storage Account and choosing the Storage Account that you created earlier.

After selecting your Storage Account, you need to find the File Share Name. Select File Share and click the Create button.

Next, you need to create a server endpoint for the Sync Group you created. Before creating a server endpoint, however, we need to set up our server. For that, we need to install and configure Storage Sync Agent Setup.

Finally, you need to add a server endpoint page. You can select your server on the Registered Server drop down menu and enter the path to sync the cloud.

Read more Microsoft Azure and cloud computing tutorials.

The post Create An Azure File Sync Service appeared first on CodeGuru.

Read: Setting Up Budgets and Configuring Alerts in Azure

What are the Types of Azure Storage Replication?

Replication options to be selected during the creation of an Azure Storage account can be seen in the image below. By default, Azure Storage replicates data three times within a primary region that is selected during creation. Azure also offers the following redundancy options you can configure for replication within the primary region:

Locally Redundant Storage (LRS)

Locally redundant storage (LRS) replicates your data synchronously to three disks within a data center in the primary region. This storage replication type offers a moderate level of availability at a lower cost.

LRS replicates three times within a single data center in the primary region. The locally redundant storage provides 99.99% of the durability of your data. Using this type of strategy, data will be copied inside the same data center racks in different fault domains for the purpose of high availability. A write request to a storage account that is using LRS happens synchronously; the write operation returns successfully only after the data is written to all three replicas.

Zone-redundant Storage (ZRS)

ZRS synchronously replicates data in Azure availability zones in the primary region. This Azure storage replication type provides a higher level of resilience at a higher cost. Each Azure availability zone is an individual physical location with its own independent networking, power, and cooling resources. ZRS provides a minimum of 99.99% durability for objects during a given year.

Microsoft recommends using ZRS in the primary region for scenarios that require high availability. ZRS is also recommended for restricting the replication of data within a country or region to meet data governance requirements.

A write request to a storage account that is using ZRS happens synchronously. The write operation returns successfully only after the data is written to all replicas across the three availability zones.

Read: Azure Service Bus Publisher and Subscriber

Geo-Redundant Storage (GRS)

GRS provides additional redundancy for data storage, compared to LRS or ZRS replication types. In addition to the three copies of data stored in one region, there are three copies stored in a paired Azure region. GRS provides all the features of LRS storage in the primary zone, and, additionally, provides a secondary LRS data storage in another region. Geo-redundant storage is assured by 99.99%.

In GRS, data is copied to a secondary region. Secondary regions are pre-assigned and cannot be configured or changed. Disadvantages of GRS include the fact that users can not read data from the secondary region using this replication strategy unless Microsoft Azure automatically performs a failover to the secondary region.

Read-Access Geo-Redundant (RA-GRS)

The RA-GRS replication strategy works similar to GRS but allows read-access to data stored in the secondary region. Developers can use multiple readable endpoints. This increases the SLA for read operations to 99.99%. Users can select the replication strategy during the creation of a storage account. Once the storage account has been created and the user sets the replica strategy, the user can switch to a different strategy, depending on the type of strategy initially configured.

Object Replication for Block Blob Storage

Object Replication for Block Blob Storage is a special replication method that is available only for Block Blob Storage accounts. The object replication method is asynchronous; you can use it to automatically move data to an archive tier.

Read more Azure Storage account tutorials, guides, and walkthroughs.

The post Azure Storage Account Replication Types appeared first on CodeGuru.

Pipeline Using Azure DevOps

To start, login to your Azure DevOps account and choose Pipelines, Builds:

Azure DevOps Account Overview

For first time users, you can also select the New Pipeline button, as shown in the following figure:

Azure DevOps Pipeline

Click Create Pipeline to create your first Pipeline:

Azure DevOps Create New Pipeline

Select your repository type, for which you want to set-up a build. For the following example, we have selected the Other Git Repository option:

Azure DevOps Code Repository

To connect the Git Repository, add the URL and enter your Username and Password:

Azure DevOps Connect Git Repository

After you successfully login to Git, select the Branch as depicted here:

Azure DevOps Code Branch Selection

Azure DevOps Pipeline has many pre-defined templates to choose from, based on the needs of the developer or project. In this example, we have selected the ASP.NET Template and clicked Apply:

Azure DevOps Pre Defined Template

The following template has five configuration steps: Tasks, Variables, Triggers, Option, and Retention. Configure each of these steps before moving on:

Azure DevOps Template Configuration

Next, run the Pipeline using a trigger setting, or, we can schedule the build time. Developers can set the continuous integration during any new check-in process. You can also specify a scheduled day and time to autorun the build. You can see here when to build and branch filters where you can include or exclude a specific branch:

Azure DevOps Run Pipeline

Step-by-step execution logs and all of the jobs and tasks can be viewed in real-time. Once all jobs are executed successfully, you can see the result on the Builds dashboard:

Azure DevOps Build Log

Developers can see the build history by clicking the History tab. If you want to see the progression, click on the build number from the grid and it will display all the progression.

You can see the build artifact’s published details, build Pipelines status and associated changes for the latest changes or latest build as well. Azure DevOps also supports Git Repository – you can add code as depicted below:

Azure DevOps Clone Repo

The post Continuous Integration Using Azure DevOps appeared first on CodeGuru.

How to Configure a Load Balancer in Azure

This load balancing tutorial assumes that the reader knows how to create a virtual machine in Azure and that you also know how to install IIS.

To demonstrate load balancer functionality, we have created two virtual machines (VMs) and named them:

• Virtual Machine 1: LBDemo1
• Virtual Machine 2: LBDemo2

After creating the above Windows virtual machines, we installed IIS.

After you have replicated these two steps, open the virtual machine LBDemo1 and copy the Public IP address to verify the IIS web status. See below:

LBDemo1 Created

To verify the IIS service is running in the LBDemo1 virtual machine, just paste the Public IP address in the web browser and hit Enter. The IIS server should be running successfully:

IIS Default Web Page

Next, open the virtual machine LBDemo2 and copy the Public IP address to verify the IIS web status:

LBDemo2 VM Created

Again, to verify the IIS service is running in the LBDemo2 virtual machine, just paste the Public IP address in the web browser and hit Enter, as we did before. The IIS server should be running successfully.

IIS Default Web Page

Next, in the Azure portal, click on the + Create a Resource, and then type Load Balancer. On the Load Balancer page, click the Create button to start creating a new load balancer.

Create Load Balancer

Now it is time to name your load balancer and assign it an IP address name. Give it the name: DemoLB and the Public IP address name of LBIP. Then, click the Review+Create button.

Add Load Balancer Public IP

After successfully creating the load balancer, open the load balancer and check the Overview section. You will find a section titled Backend Pool, Note that Load Balancer Rule and Health Probe are not filled n. See below:

Load Balancer Overview

Next, we will add the above-created virtual machines to the load balancer. To add the load balancer, click Backend Pools and then +Add.

Load Balancer Backend Pools

In the Backend Pool Name page, enter the Backend Pool Name and then select the virtual machine. Click Add to add both of the virtual machines we created in previous steps.

Backend Pools

After adding both of the virtual machines in the Backend Pool you will get the following page:

Backend Pools Created

After this, we need to configure Health Probes.Click Health Probes:

Health Probes

Then, click +Add to enter the Health Probes details:

Create Health Probes

Enter a name for Health Probes, the Protocol, Port, and other pertinent details, as depicted below:

Add Details for Health Probes

The following Health Probe should be successfully created:

Now, we need to create the Load Balancing Rules. Click Load Balancing Rules and then +Add.

In the Load Balancing Rules, map the Public IP address and Port Number of incoming traffic to the private IP address and port number of the virtual machine:

Add Load Balancer Rules

Finally, we can verify if our load balancer is configured. If so, it should be visible in our Backend Pool and Public IP address. Copy the Public IP address and enter into a web browser. The default IIS page from the LBDemo1 virtual machine should respond.

If we shut down the LBDemo virtual machine and refresh the web browser, the default IIS page from the LBDemo2 virtual machine server will respond.

The post Configuring Load Balancer In Microsoft Azure appeared first on CodeGuru.

Azure Storage accounts give a few significant security benefits to protect data in the cloud, including:

• Protects the information in storage
• Protects information being sent to storage
• Supports cross-domain program access

Read: Introduction to Azure DevOps

What are Azure Storage Account Keys?

Azure Storage accounts can approve authorized apps like Active Directory to control access to the data in blobs and queues. This verification approach is recommended. Another approach could be a shared key or shared secret for different storage models. This authentication alternative is one of the easiest to use and it supports blobs, files, queues, and tables.

We will demonstrate this security method here. To begin, open the Azure Management Portal and go to Azure Storage Account, then click on Access Keys, as depicted in the following image:

Access Azure Storage Access Keys

In Azure Storage Accounts there are two keys that are created by Azure for storage accounts: primary and secondary. These two keys are 512-bit storage access keys that are used for authenticating access to Azure storage accounts. They give access to everything in the account. Developers can find these storage account keys in the Azure Portal view of the storage account from Settings > Access Keys. See below:

Azure Storage Keys

Read: How to Access Azure Storage Account File Shares from .NET

Types of Azure Storage Access Control

Before going further, let’s briefly discuss a few types of access control methods Azure employees for storage accounts.

Role Based Access Control

To access data in a storage account, the customer makes a request over HTTP or HTTPS. Azure Active Directory and role-based access control (RBAC) are supported by Azure Storage for resource management and data operations.

Cross-origin Resource Sharing (CORS)

Cross-origin resource sharing (CORS) supports cross-domain access for Azure Storage. CORS uses HTTP headers allowing web applications at one domain to access information from a server of different domains.

Azure Encryption

Data in a new storage account is encrypted with Microsoft-managed keys by default. You can continue to rely on Microsoft-managed keys for the encryption of your data, or you can manage encryption with your own keys, which is known as customer-managed keys:

Azure Storage Encryption

Setting up Shared Access Signatures in Azure Storage

Let’s continue. Navigate to your Azure Management Portal and go to Azure Storage Account, then click on Shared Access Signature.

Access keys provide complete access to the entire storage account. Using Shared Access Signature (SAS), programmers can restrict access to individual storage services. Developers just need to select the required services that they would like to restrict access to using SAS. You can choose multiple services to restrict.

Azure Storage Share Access Signature

If you want to allow access by permissions, you can provide permissions based on the following, under the Allowed Permissions section:

The Allowed Permissions section allows developers to provide different permissions to different levels of access. You can have one developer work on all the items that have Read Operations and another to work on Update Operations.

Coders can also control storage access by specifying Start Date/Time and End Date/Time, as shown here:

Control Access based on Date and Time

You can further configure these Start and End Date/times based on time zone.

If you want to control access by protocol (like HTTP/HTTPS), you can disable basic HTTP requests by checking the HTTPS only radio button:

Allowed Protocols

Finally, you can control Access by IP Address too:

Allowed IP Addresses

Once you configure all of the required settings and determine access levels, click on the Generate SAS button, which is available at the bottom of the page, to generate the SAS token:

Read more Microsoft Azure tutorials and guides.

The post How to Secure Azure Storage Accounts appeared first on CodeGuru.

Read: Azure Service Bus Publisher and Subscriber

What are the Benefits of Azure Bicep?

Azure Bicep was created to improve the syntax of ARM templates. Typically, the syntax of ARM templates is cumbersome compared to other solutions. Bicep syntax, meanwhile, can more easily be compared with the ARM JSON syntax. Developers can create complex template deployments by creating smaller module Bicep files. Most importantly, Bicep will automatically detect resource dependencies, taking some of the load off of programmers.

How to Create Azure Bicep Files

Developers can use Microsoft-provided Visual Studio Code extensions for the Bicep language to enhance the functionality that Bicep brings to the table. These extensions, specifically, provide language support and resource autocompletion to assist with creating and validating Bicep files, reducing coding errors, and making the writing of code more efficient.

To add a Bicep extension, in Visual Studio Code, select Extensions, search for Bicep, and install the extension. See the image below for more:

Take a look at the following template Bicep code. Notice the compact code structure; it is maybe half the size of the typical ARM template. Bicep is smart enough to figure out if resources are dependent on each other. Additionally, Bicep knows it first needs to deploy appServicePlan and automatically adds the dependsOn part when it gets converted from Bicep to an ARM template. Here is the code:

param name string = 'sample-bicep-webapplication'
param location string = resourceGroup().location
param sample string = 'Sample'
param sampleCode string = 'G1'
resource webApp 'Microsoft.Web/sites@2022-01-01' = {
  name: name
  location: location
  properties: {
    name: name
    siteConfig: {
      metadata: [
        {
          name: 'TECHNOLOGY_STACK'
          value: 'dotnetcore'
        }
      ]
    }
    serverFarmId: appServicePlan.id
  }
}
resource appServicePlan 'Microsoft.Web/serverfarms@2022-01-01'  = {
  name: name
  location: location
  properties: {
    name: name
  }
  sample: {
    Tier: sample
    Name: sampleCode
  }
}

The following code snippet is used by Bicep for deployment of your resources array, with the link to the template and a link to the parameters file if available.

"resources": [
  {
    "type": "Microsoft.Resources/deployments",
    "apiVersion": "2022-01-01",
    "name": "linkedTemplate",
    "properties": {
      "mode": "Incremental",
      "templateLink": {
        "uri": "https://mystorageaccount.blob.core.windows.net/AzureTemplates/newStorageAccount.json",
        "contentVersion": "1.0.0.0"
      },
      "parametersLink": {
        "uri": "https://mystorageaccount.blob.core.windows.net/AzureTemplates/newStorageAccount.parameters.json",
        "contentVersion": "1.0.0.0"
      }
    }
  }
]

Bicep v0.3 has been integrated with the Azure Command-Line-Interface (CLI). Besides building a Bicep file, there is also a command needed to deploy your file to a resource group or subscription. The commands to do this are in the AZ Deployment group.

Read: Setting Up Budgets and Configuring Alerts in Microsoft Azure

How to Convert ARM Templates to Azure Bicep

Azure Bicep can be easily used to convert an ARM template to Bicep code. The command for this is az bicep decompile. It takes a JSON file as input and attempts to make it into Bicep.

To decompile ARM template JSON files to Bicep, use Azure CLI:

az bicep decompile --file AzureARM.json

Developers can export the template for a resource group and then pass it directly to the decompile command. Refer to the following example:

az group export --name "my_resource_group_name" > AzureARM.json
az bicep decompile --file AzureARM.json

Conclusion to Creating Infrastructure As Code Using Azure Bicep

This programming tutorial explained how to create Azure Bicep deployment templates. Be sure to check back often for more tutorials using Azure Bicep.

Read more cloud computing and Azure programming tutorials.

The post Create Infrastructure as Code in Azure Bicep appeared first on CodeGuru.