In this hands-on lab, you will implement three different environments and use Azure BCDR technologies to achieve three distinct objectives for each environment. These objectives include a migration to Azure, Azure region-to-region failover, and a PaaS implementation using BCDR technologies to ensure high availability of an application.

At the end of this hands-on lab, you will be able to design and build complex and robust IaaS BCDR solutions.

Exercise 1: Configure BCDR services

Duration: 15 minutes

Synopsis: In this exercise, attendees will secure a Privileged Access Workstation (PAW) workstation using the Azure Security Center Just-in-Time Access feature.

Task 1: Create Azure recovery services vault

Using LABVM, connect to the Azure portal using your web browser at https://portal.azure.com.
Select +Create a resource, then enter Backup and Site Recovery, and select Create.
Complete the Recovery Services Vault blade using the following inputs, then select Review + create and finally Create:
- Resource Group: BCDRAzureSiteRecovery
- Vault name: BCDRRSV
- Location: Central US (your secondary region)
Once the BCDRRSV Recovery Service Vault has been created, open it in the Azure portal. Select the “Site Recovery” tab.
This is your dashboard for Azure Site Recovery (ASR), for the HOL.

Task 2: Deploy Azure automation

Open the Azure portal at: https://portal.azure.com.
Select +Create a resource and then enter Automation in the search box.
Select Automation and then Create.
Complete the Add Automation Account blade using the following inputs and then select Create:
- Name: Enter a Globally unique name starting with BCDR.
- Resource group: Use existing BCDRAzureAutomation
- Location: Select a site in your area (but NOT your Primary site).
- Create Azure Run As account: Yes
Note: Azure Automation accounts are only allowed to be created in certain Azure regions, but they can act on any region in Azure (except Government, China or Germany). It is not a requirement to have your Azure Automation account in the same region as the BCDRAzureAutomation resource group but CANNOT be in your primary site.
Once the Azure automation account has been created, open the account and select Modules gallery under Shared Resources.
When the Modules load, scroll down and locate and select AzureRM.profile.
Select Import.
On the Import blade, select the OK button.
It will take a few minutes to update the modules. Select Modules under Shared Resources, and you can wait until the import has completed.
Next, you'll need to install AzureRM.Network version 5.4.2 from PowerShell Gallery (The lab requires a specific version). Open your browser and navigate to the following URL: https://www.powershellgallery.com/packages/AzureRM.Network/5.4.2.
After the PowerShell gallery page loads, select Azure Automation under Installation Options.
Select the Deploy to Azure Automation button.
Enter your Azure credentials when prompted. Back in the Azure Portal Azure Automation blade, select the BCDR automation account created previously and select OK.
The portal will begin the import process and should only take about a minute.
Next, navigate back to the Azure Automation Account blade and select Runbooks.
Select Import a runbook.
Select the Folder icon on the Import blade and select the file ASRRunbookSQL.ps1 from the C:\HOL\Deployments directory on the LABVM. The Runbook type should default to PowerShell Workflow. Notice that the Name can't be changed. This is the name of the Workflow inside of the Runbook script. Select Create.
Once the Runbook is imported, the PowerShell runbook will load. If you wish, you can review the comments to better understand the runbook. Once completed select Publish to make the code available for use in the portal.

Note: You might notice the Test Pane link. This script can't be tested from here as there are more configurations required, and it relies of being called by Azure Site Recovery to feed its variables.
Select Yes, to configure that this Runbook will be published.
Navigate back to the Azure Automation account.
Select +Import a runbook.
Select the Folder icon on the Import blade and select the file ASRRunbookWEB.ps1 from the C:\HOL\Deployments directory on the LABVM. The Runbook type should default to PowerShell Workflow. Notice that the Name can't be changed. This is the name of the Workflow inside of the Runbook script. Select Create.
Once the Runbook is imported, the PowerShell runbook will load. If you wish, you can review the comments to better understand the runbook. Once completed, select Publish to make the code available for use in the portal.
Select Yes to configure that this Runbook will be published.
Navigate back to Runbooks, and make sure that both Runbooks show as Published.
From LABVM, select Start and select PowerShell ISE (make sure to right-click and Run as Administrator).
Open the file C:\HOL\Deployments\ASRRunBookVariable.ps1. Review the script and enter the automation account name you created earlier. Then select the green play button to execute the script. You will need to authenticate to Azure.

Note: If you are using an account that has multiple subscriptions you may need to change the subscription associated with your current Azure session. You can comment out the Connect-AzAccount command in the script and complete the login and the use the Connect-AzAccount and Set-AzContext cmdlets to create the proper context for this HOL. For help, you can review this article: https://docs.microsoft.com/en-us/powershell/azure/manage-subscriptions-azureps?view=azps-2.7.0#change-the-active-subscription.
Once the script has run, you will see the following output from PowerShell ISE. This script created a variable that will be used with the PowerShell Runbook in Azure Automation to help with the Failover and Failback of the Azure IaaS environment.
Move back to the Azure portal and locate the Azure Automation account. Select the Variables link in the Shared Resources section.
Notice that the variable BCDRIaaSPlan has been created. This variable will be used along with ASR to orchestrate part of the failover.

Note: When you configure the ASR Recovery Plan for the IaaS deployment you will use the SQL Runbook as a Pre-Failover Action and the Web Runbook as a Post-Failover action. They will run both ways and have been written to take the “Direction”, of the failover into account when running.

Exercise 2 – Configure environment for failover

Duration: 90 minutes

In this exercise, you will configure the three environments to use BCDR technologies found in Azure. Each environment has unique configurations that must be completed to ensure their availability in the event of a disaster.

Note: Make sure prior to starting each task that the deployment that you started in Exercise 1 has completed for each as you come to that task. This can be determined by reviewing the deployments for each Resource group in the Azure portal. If it says Succeeded, then you can begin the task.

Task 1: Configure on-premises to Azure IaaS failover

In this task, the OnPremVM will be configured to replicate to Azure and be ready to failover to the BCDRIaaSSecondarySite. This will consist of configuring your Hyper-V host with the ASR provider and then enabling replication of the VM to the Recovery Service Vault.

From the Azure portal, open the BCDRRSV Recovery Services Vault located in the BCDRAzureSiteRecovery resource group.
Select Site Recovery in the Getting Started area of BCDRRSV blade.
Next, select Prepare Infrastructure in the For On-Premises Machines section. This will start you down a path of various steps to configure your VM that is running on Hyper-V on-premises to be replicated to Azure.
On Step 1 Protection Goal select the following inputs and then select OK:
- Where are your machines located?: On-premises
- Where do you want to replicate your machines to?: To Azure
- Are you performing a migration?: No
  
  Note: You may see a checkbox that says, I understand, but I would like to continue with Azure Site Recovery checked.
- Are your machines virtualized?: Yes, with Hyper-V (Your VM is running as a nested VM in Azure).
- Are you using System Center VMM to manage your Hyper-V hosts?: No
On Step 2 Deployment planning, confirm you have completed deployment planning by selecting Yes, I have done it then select OK.

Note: You can read more about planning an ASR to deployment here: https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-hyper-v-deployment-planner.
On Step 3 Prepare source select +Hyper-V Site.
On the Create Hyper-V site blade, enter the name: OnPremHyperVSite. Select OK.
The portal will deploy the site providing you notifications. Wait for the creation process to complete, and the ASR portal will update once this is done. Your new site is now shown under Step 1: Select Hyper-V site.
Next select +Hyper-V Server.
A new blade will appear. You will need to download the vault registration key to register the host in the Hyper-V site of ASR. Select the Download button which will save the file to your Downloads folder on the LABVM.
Open a NEW tab in your web browser and connect again to the Azure Portal at https://portal.azure.com.
Select Resource groups, then on the next blade select BCDROnPremPrimarySite.
Locate and select the HYPERVHOST VM object.
Select Connect and open the RDP file that is downloaded.
Enter the credentials for the VM:
- Username: mcwadmin
- Password: demo@pass123
You will be prompted with a warning about a certificate. Select Yes to connection (you can always select yes to these prompts during this HOL).
Select Yes on the Networks prompt.
On the HYPERVHOST select Configure this local server in the Server Manager Dashboard.
On the right side of the pane, select On by IE Enhanced Security Configuration.
Change to Off for Administrators and select OK.
Open Internet Explorer on HYPERVHOST and browse to the following URL. This will download the Azure Site Recovery Provider for Hyper-V.
```
http://aka.ms/downloaddra_cus
```
Select Run.
Select On and then Next.
Select Install on the Provider Installation screen.
Once the Provider has been installed you will come to a screen that will request for you Register or Finish. Select Register.
Minimize your Remote Desktop window and locate the vault registration key which is in the Downloads directory of LABVM. Right-click the file and copy it. Move back to HYPERVHOST and paste the file to the desktop.
On the Vault Setting screen select Browse.
Locate the Vault file on the desktop and select Open.
The Vault Settings will now be populated. Select Next.
On the Proxy settings screen retain the settings Connect directly to Azure Site Recovery without a proxy server and select Next.
The provider will then connect and configure the Azure Site Recovery registration for the Hyper-V Server.
After a few minutes, the wizard will be complete with the message The Server was registered in the Azure Site Recovery vault. Select Finish to close the Provider installation.
Select Start, Windows Administrative Tools.
Locate then double-click the Hyper-V Manager.
When the Hyper-V Manager opens, select the Server name in the left pane and then you will see that the OnPremVM virtual machine is running on your HYPERVHOST. This is an Ubuntu 16.04.3 LTS server running Apache, PHP and MySQL. Double-click on the VM to open.
The console for the OnPremVM will load. Press Enter to get a login prompt.
Login to the VM using the following credentials:
- Username: mcwadmin
- Password: demo@pass123
Once logged in enter a few commands and notice that you can get to the internet and that the local IP address of the VM is currently 192.168.0.10.
```
ping 8.8.8.8 -c 4

ifconfig
```
Open Internet Explorer on HYPERVHOST and browse to the following URL of the OnPremVM. This is very simple PHP application running on the OnPremVM connected to the MySQL Server that is running locally on the VM. This is to simulate an application is that running on one VM in the on-premises data center.
```
http://192.168.0.10/bcdr.php
```
From the command prompt of the OnPremVM, update the OS with the latest patches by using the following command. You will need to enter the password again.
```
sudo apt-get update -y
```
After the updates complete, install the Azure Guest Agent for Linux on the VM using the following commands:
```
sudo apt-get install walinuxagent -y
```
Note: You may see some errors and warnings including some related to “cloud-init” and new updates being available. This is normal behavior since this VM thinks it should be in Azure. This may take 5-10 minutes.
Once you're returned to the command prompt, type exit into the terminal and hit Enter to log out of OnPremVM.
Sign out of HYPERVHOST and return to the Azure portal running on your LABVM.
You will need to return to the Prepare Source screen and select +Hyper-V Server. Notice the warning that it could take up to 30 mins for this server to appear, but in practice you should cancel out of this window by selecting Step 2 and then answer yes again with I have done it to the question of Deployment planning.
Once the Server appears, select OK.
On Step 4 Target Prepare review the screen to better understand the various steps. Select +Storage account to add a storage account that will be used for the OnPremVM when it is failed over to Azure.
Select Create New and provide a unique name for your storage account containing the name of the VM OnPremVM with added characters to make it unique. Also, select the Premium tier for the storage account and select OK.

Note: Be sure to select Premium Performance or you may run into issues later in the lab.
Select +Storage account again and create a second storage account using the Standard performance tier, then select OK.
The portal will submit a deployment, and you must wait until this completes. It will be created in the BCDRAzureSiteRecovery resource group.
You will be failing the OnPremVM into the Secondary site that was deployed with your IaaS installation, so you already have a Virtual Network created. Select OK on the Target blade to continue.
On the Replication Policy screen, select the +Create and Associate item.
Enter the name: OnPremVM-POL. Review the settings that you can configure and then select OK.
Azure will run a deployment and start the process of creating and then associating the Hyper-V Site with the replication policy.

Note: This will take a couple of minutes to complete. Please wait until this completes prior to moving on.

Once complete, select OK.
Select OK again, and the process for adding the Hyper-V Server to the Recovery Services Vault will be complete.
Next, select Step 1: Replicate Application.
On the Source blade select: Source: On-premises, Are you performing a migration: No, and Source location: OnPremHyperVSite and select OK.
Complete the Target blade, select the following values and select OK:
- Post-failover resource group: BCDRIaaSSecondarySite
- Storage Account: Select the account you just created (onpremvm8675309).
- Storage Account for replication logs: Create a new one using the prefix bcdrasrrepllogs.
- Azure network: Configure now for selected machines.
- Post-failover Azure network: BCDRFOVNET
- Subnet: WEB (172.16.1.0/24)
Next on the Select virtual machines select OnPremVM and then select OK.
Complete the OnPremVM selections of the Configure properties blade using these inputs and then select OK:
- OS Type: Linux
- OS Disk: OnPremLinuxVM
- Disks to Replicate: OnPremLinuxVM [127.00GB]
On the Configure replication settings blade review the selections and notice that the OnPremVM-POL that you created has been selected. Select OK.
On the final screen, select Enable replication.
The deployment will be submitted. You can select Site Recovery Jobs to review the process.
After a few minutes, the Enable replication will move to Successful. Select Overview and Site Recovery on the BCDRRSV blade. You should now see that there is one (1) Healthy Replicated Item.
Select Healthy 1 and you will see the replicated items list. Notice it shows that the VM is healthy, but the replication has just started, so it shows 0% synchronized. It will take a few minutes for the VM to replicate.

Note: If the OnPremVM does not immediately go to a healthy replication state, or ever gets in an unhealthy state, you may need to “Disable Replication” and recreate it using the steps above.
Select OnPremVM. Review the Replication details for OnPremVM. Once the VM has replicated, the selections across the top menu bar of the dashboard will allow you to work with this VM.

Note: It will take about 15 minutes for the VM to replicate, so you can move on and come back to review the environment later.
Scroll down and review the Infrastructure view of the BCDR environment you have created for OnPremVM. You can select Hyper-V Virtual Machine to review what is protected.
Next, select Compute and Network.
Details of the VM will be shown, and you can make configuration changes. Change the Size of the VM to DS2_v2, and then select Save.

Note: It could take a few minutes for these screens to populate, so be patient. You can come back to this step later to adjust the size if you wish.

Task 2: Configure IaaS SQL Always On availability groups for region to region failover

In this task, you will build a Windows Failover Cluster and configure SQL Always On Availability Groups. This will be in place to ensure that if there is an issue in the Primary site in Azure you can failover to the Secondary site and have access to the data for the application. You will also configure Front Door to ensure that the Web Application will always answer to the same DNS name even when it is failed over to the Secondary site.

From the LABVM navigate to the Azure Portal, and navigate to Resource Groups and then BCDRAzureSiteRecovery.
Select +Add.
In the Search box, enter Storage Account, and then select Storage account — blob, file, table, queue.
Select Create.
Complete the Create storage account form using the following details, then select Review + create:
- Resource group: Use existing BCDRAzureSiteRecovery.
- Storage account name: Unique name starting with bcdrcloudwitness
- Location: Any location in your area that is NOT your Primary or Secondary site.
- Performance: Standard
- Account kind: Storage (general purpose v2)
- Replication: Locally-redundant storage (LRS)
Once the storage account is created, locate and select Access keys under Settings.
Copy the name of the account and the first access key to notepad and save the file as C:\HOL\Deployments\CloudWitness.txt on your LABVM.
From the LABVM, connect to the Azure portal and locate the BCDRIaaSPrimarySite Resource group.
Select BCDRDC1 and then select Connect.
Once in the RDP session to BCDRDC1, select Start and then Remote Desktop. You will need to connect to SQLVM1 for the next steps.
Connect to SQLVM1 using the following credentials:
- Username: CONTOSO\mcwadmin
- Password: demo@pass123
Minimize your Remote Desktop window and locate three files: ClusterCreateSQLVM1.ps1, ClusterUpdateSQLVM1.ps1 and CloudWitness.txt in the C:\HOL\Deployments directory of your LABVM. Right-click the files and copy them, then move back to your SQLVM1 and paste the files to the desktop.
On SQLVM1, select Start and then select PowerShell ISE (make sure to right-click and Run as Administrator).
Open the ClusterCreateSQLVM1.ps1 in the PowerShell ISE window. Then select the green play button. This script will create the Windows Failover Cluster and add all the SQL VMs as nodes in the cluster. It will also assign a static IP address of 10.0.2.99 to the new Cluster named AOGCLUSTER.

Note: If you get a The term 'New-Cluster' is not recognized error, then run the following command to install the Failover Clusters feature and try again:
```
Add-WindowsFeature RSAT-Clustering-PowerShell
```
Note: It is possible to use a wizard for this task, but the resulting cluster will require additional configuration to set the static IP address in Azure.
After the cluster has been created, select Start and then Windows Administrative Tools. Locate and open the Failover Cluster Manager.
When the cluster opens, select Nodes and the SQL Server VMs will show as nodes of the cluster and show their status as Up.
If you select Roles, you will notice that currently, there aren't any roles assigned to the cluster.
Select Networks, and you will see two networks: Cluster Network 1 and Cluster Network 2. Both should show the status of Up. If you navigate through to the networks, you will see their IP address spaces, and on the lower tab you can select Network Connections and review the nodes.
Right-click AOGCLUSTER, then select More Actions, Configure Cluster Quorum Settings.
On the Configure Cluster Quorum Wizard select Next, then choose Select the quorum witness. Then, select Next again.
Select Configure a cloud witness and Next.
Open the CloudWitness.txt file on the desktop of SQLVM1 and copy the Storage account name and KEY1 values and paste them into their respective fields on the form. Leave the Azure Service endpoint as configured. Then, select Next.
Select Next on the Confirmation screen.
Select Finish.
Select the name of the Cluster again and the Cloud Witness should now appear in the Cluster Resources. It's important to always use a third data center, in your case here a third Azure Region to be your Cloud Witness.
Select Start and Launch SQL Server 2017 Configuration Manager.
Select SQL Server Services, then right-click SQL Server (MSSQLSERVER) and select Properties.
Select the AlwaysOn High Availability tab and check the box for Enable AlwaysOn Availability Groups. Select Apply and then select OK on the message that notifies you that changes won't take effect until after the server is restarted.
On the Log On tab, change the service account to contoso\mcwadmin with the password demo@pass123. Select OK to accept the changes, and then select Yes to confirm the restart of the server.
Open a new Remote desktop session (this can be done from within SQLVM1), and repeat these steps to Enable SQL Always On. Change the username to contoso\mcwadmin on each of the other nodes SQLVM2, and SQLVM3. Make sure that you have restarted the SQL Service on each node prior to moving to the next node.

Note: If you get confused what server you are on open a command prompt and simply enter the command hostname.
After you have completed the process on each SQLVM Node, reconnect to SQLVM1 using Remote Desktop.

Note: Remember that you must use the BCDRDC1 VM as your jumpbox to get into the environment. You can use the Azure portal to connect to BCDRDC1 and then use Remote desktop from there to SQLVM1.
Use the Start menu to launch Microsoft SQL Server Management Studio 17 and connect to the local instance of SQL Server. (Located in the Microsoft SQL Server Tools folder).
Select Connect to sign on to SQLVM1.
Right-click Always On High Availability, then select New Availability Group Wizard.
Select Next on the Wizard.
Provide the name BCDRAOG for the Availability group name, then select Next.
Select the ContosoInsurance Database, then select Next.
On the Specify Replicas screen next to SQLVM1, select Automatic Failover.
Select Add Replica.
On the Connect to Server dialog box enter the Server Name of SQLVM2 and select Connect.
For SQLVM2, select Automatic Failover and Availability Mode of Synchronous commit.
Select Add Replica.
On the Connect to Server dialog box enter Server Name of SQLVM3 and select Connect.
At this point, the wizard should resemble the following:
Select Endpoints and review these that the wizard has created.
Next, select Listener. Then, select the Create an availability group listener.
Add the following details:
- Listener DNS Name: BCDRAOG
- Port: 1433
- Network Mode: Static IP
Next, select Add.
Select the Subnet of 10.0.2.0/24 and then add IPv4 10.0.2.100 and select OK. This is the IP address of the Internal Load Balancer that is in front of the SQLVM1 and SQLVM2 in the BCDRVNET Data Subnet running in the Primary Site.
Select Add.
Select the Subnet of 172.16.2.0/24 and then add IPv4 172.16.2.100 and select OK. This is the IP address of the Internal Load Balancer that is in front of the SQLVM3 in the BCDRFOVNET Data Subnet running in the Secondary Site.
Select Next.
On the Select Initial Data Synchronization screen, make sure that Automatic seeding is selected and select Next.
On the Validation screen, you should see all green. Select Next.
On the Summary page select Finish.
The wizard will configure the AOG.
Once the AOG is built, select Close.
Move back to SQL Management Studio on SQLVM1 and expand the Always On High Availability item in the tree view. Under Availability Groups, expand the BCDRAOG (Primary) item.
Right-click BCDRAOG (Primary) and then select Show Dashboard. You should see that all the nodes have been added and are now “Green”.
Next, select Connect and then Database Engine in SQL Management Studio.
Enter BCDRAOG as the Server Name. This will be connected to the listener of the group that you created.
Once connected to the BCDRAOG, you can select Databases and will be able to see the database there. Notice that you have no knowledge directly of which server this is running on.
Move back to PowerShell ISE on SQLVM1 and open the PowerShell script named ClusterUpdateSQLVM1.ps1. Select the Play button. This will update the Failover cluster with the IP Addresses of the Listener that you created for the AOG.
Move back to SQL Management Studio and select Connect and then Database Engine.
This time, put the following into the IP address of the Internal Load balancer of the Primary Site AOG Load Balancer: 10.0.2.100. You again will be able to connect to the server which is up and running as the master.
Once connected to 10.0.2.100, you can select Databases and will be able to see the database there. Notice that you have no knowledge directly of which server this is running on.

Note: It could take a minute to connect the first time as this is going through the Azure Internal Load Balancer.
Move back to Failover Cluster Manager on SQLVM1, and you can review the IP Addresses that were added by selecting Roles and BCDRAOG and viewing the Resources. Notice how the 10.0.2.100 is Online since the current primary replica is on the Primary Site.
Now that the AOG is up and running online the Contoso Insurance Web Application should be available. Minimize the RDP window and from the LABVM open the Azure portal and navigate to the resource group BCDRIaaSPrimarySite. Select WWWEXTLB-PIP which is the Public IP address for the external load balancer WWWEXTLB in front of WEBVM1 and WEBVM2 in your Primary region.
Locate the DNS name address and copy it to your clipboard.
Open a new tab in the browser and navigate to the DNS name. The Contoso Insurance PolicyConnect application should load in your browser. Select the Current Policy Offerings button to check for database connectivity.
If you can see the offerings, then the application is able to access the database. You can also go back to the home page and interact with the application including adding, editing or deleting data.

Note: If you see the following screen shot then something is not configured correctly with your environment. The connection string of the application is configured to use the name of bcdraog.contoso.com which is the name for the SQL AOG listener. This configuration is part of the connection string located in the web.config file which is on WEBVM1 and WEBVM2 in the C:\Inetpub\wwwroot directory. If you for some reason you named something incorrectly you can make a change to this file and then iisreset /restart from the command line on the WEBVMs.
Once you have verified that the application is up and running, you will need to build a Front Door to direct traffic to the edge of your Primary and Secondary Site. Select +Create a resource, then search for and select Front Door within the Azure Portal.
Complete the Basics tab of the Create a Front Door blade using the following inputs, then select Next: Configuration >:
- Resource group: Use existing BCDRIaasPrimarySite
- Location: Automatically assigned based on the region of BCDRIaaSPrimarySite.
Select the plus icon on the Frontend hosts box to set the host name of Front Door.
In the Add a frontend host pane, enter the following values, then select Add:
- Host name: Enter a unique name with the prefix of bcdriaas.
- Session affinity: Disabled
Select the plus button on the Backend pools box to begin adding endpoints to the backend pool.
On the Add a backend pool pane, enter the following value, then select the Add a backend link.
- Name: BCDRIaaSPrimarySiteLB
- Health Probes – Protocol: HTTP
On the Add a backend pane, enter the following values, then select Add:
- Backend host type: Custom host
- Backend host name: Paste in the DNS name for the Public IP Address (named WWWEXTLB-PIP) associated with the Load Balancer for the Web VMs within the BCDRIaaSPrimarySite resource group.
Select Add a backend again and add another backend host to the pool. Create it similar to before, but with the following settings:
- Backend host type: Custom host
- Backend host name: Paste in the DNS name for the Public IP Address (named WWWEXTLB-PIP) associated with the Load Balancer for the Web VMs within the BCDRIaaSSecondarySite resource group.
- Priority: 2
Select Add to create the backend pool.
Select the plus button on the Routing rules box.
On the Add a rule pane, enter the following values, then select Add.
- Name: BCDRIaaS
- Accepted protocol: HTTP only
- Backend pool: BCDRIaaSPrimarySiteLB
- Forwarding protocol: HTTP Only
Select Review + Create.
Once validation has completed, select Create to provision the Front Door service.
Select the Frontend host URL of Azure Front Door, the Policy Connect web application will load. This is connecting to the WWWEXTLB External Load Balancer that is in front of WEBVM1 and WEBVM2 running in the Primary Site in BCDRIaaSPrimarySite resource group and connecting to the SQL Always On Listener at the same location.

Note: Be sure to use HTTP to access the Azure Front Door frontend host URL. The lab configurations only supports HTTP for Front Door since WebVM1 and WebVM2 for the BCDRIaaS environment are only setup for HTTP support; not HTTPS (no SSL\TLS).

Note: If you get a “Our services aren't available right now” error (or a 404 type error) accessing the web application, then continue on with the lab and come back to this later. Sometime this can take a ~10 minutes for the routing rules to publish before it's “live”.

Task 3: Configure IaaS for region to region failover

In this task the WEBVM1 and WEBVM2 will be configured to replicate from the Primary Site to the Secondary site to support an Azure region to region failover. This will consist of configuring the VMs to replicate and integrating with the Azure Automation to failover the SQL Always On group from the Primary Site to the Secondary. Once the failover is complete the website will again answer to the Front Door hostname.

From the Azure portal on LABVM, open the BCDRRSV Recovery Services Vault located in the BCDRAzureSiteRecovery resource group.
Select Site Recovery in the Getting Started area of BCDRRSV blade.
Next, select Step 1: Replicate Application in the For On-Premises Machines and Azure VMs section. This will start you down a path of various steps to configure your WEBVMs that are running on Azure at your Primary Site.
On Step 1 Source select the following inputs and then select OK:
- Source: Azure
- Source Location: East US 2 (Your Primary Region)
- Azure virtual machine deployment model: Resource Manager
- Source resource group: BCDRIaaSPrimarySite
On Step 2 Virtual Machines, select WEBVM1 and WEBVM2 and then select OK.
On the Configure settings blade, select the Target location as Central US (your Secondary Site Azure Region).
Select Customize.
Update the rest of the blade using the following inputs and the select OK:
- Target resource group: BCDRIaaSSecondarySite
- Target virtual network: BCDRFOVNET
- Replica Managed Disk: Accept the new account.
- Cache Storage: Accept the new account.
- Target Availability Type:
  - WEBVM1: zone 1
  - WEBVM2: zone 2
Note: Double check these selections, they are critical to your on-premise to Azure failover!
Next, select Create target resources.
Then select Enable replication.
The Azure portal will start the deployment. This will take approximately 10 minutes to complete. You will receive a notification once it has deployed.
Return to the Recovery Services Vault BCDRRSV and you will now see that three (3) items are being replicated.
Select the Replicated Items link under Protected Items.
You should see three items: OnPremVM, WEBVM1 and WEBVM2. The OnPremVM will show as protected and the others may still need to synchronize a bit more.
Once WEBVM1 and WEBVM2 have reached Protected status, you can move on to the next step.

Note: It can take up to 30 minutes for this action to complete.
Under the Manage area select Recovery Plans (Site Recovery).
Select +Recovery plan.
On the Create recovery plan blade, provide the Name: BCDRIaaSPlan and Source: select your Primary site.
Complete the rest of the blade using the following inputs and then select OK:
- Target: Secondary region
- Allow items with deployment model: Resource Manager
- Select Items: Select WEBVM1 and WEBVM2
After a moment, the BCDRIaaSPlan Recovery plan will appear, select it to review.
When the BCDRIaaSPlan loads notice that it shows 2 VMs in the Source which is your Primary Site. Then select Customize.
Once the BCDRIaaSPlan blade loads, select the ellipse next to All groups failover.
Select Add pre-action.
On the Insert action blade, select Script and then provide the name: ASRSQLFailover. Ensure that your Azure Automation account is selected and then chose the Runbook name: ASRSQLFailover. Select OK.
Once the BCDRIaaSPlan blade loads, select the ellipse next to Group 1: Start.
Select Add post action.
On the Insert action blade, select Script and then provide the name: ASRWEBFailover. Ensure that your Azure Automation account is selected and then chose the Runbook name: ASRWEBFailover. Select OK.
Make sure that your Pre-steps are running under All groups failover and the Post-steps are running under the Group1: Start. Select Save.
After a minute, the portal will provide a successful update notification. This means that your machines are fully configured and ready to Failover and Back between the Primary and Secondary regions.

Task 4: Configure PaaS for region to region failover

In this task you will deploy the website to App Services using Visual Studio, migrate a database to Azure SQL Database and configure it for high-availability using an Azure SQL Database Failover Group. The Front Door will be used to direct traffic. If there is a failover of the database it will happen transparently, and the users will never know there was an outage. There is no reconfiguration required for this to function properly.

From the LABVM, open the Azure portal at: https://portal.azure.com.
Navigate to the BCDRPaaSPrimarySite resource group. Select the SQL Server resource.
This server will host your SQL Database for the Contoso Insurance Web App. Select Properties under the Settings area.
Copy the name of the SQL Server to notepad. Also, notice that the Server Admin Login is the same. Save this file as C:\HOL\Deployments\SQLSERVER.txt.
Use the Start menu in the LabVM to launch Microsoft SQL Server Management Studio 18 and connect to the local instance of SQL Server (Located in the Microsoft SQL Server Tools 18 folder).
Select Connect to Sign On to the Local SQLEXPRESS on LABVM.
Right-click Databases, then select Restore Database.
Select Device and then the Ellipse.
Select Add.
Navigate the folder menu and locate the C:\HOL\Database folder and then select on ContosoInsurance.bak and then OK.
Select OK.
Select OK to restore the ContosoInsurance database.
Select OK at the restored successfully prompt.
Expand Databases and then right-click on the ContosoInsurance database, select Tasks, then Deploy Database to Microsoft Azure SQL Database.
Select Next on the Introduction screen.
Select Connect.
In the Connect to SQL Server screen, copy the name of your Azure SQL Server from the SQLSERVER.TXT. Change the Authentication to SQL Server Authentication and enter the credentials for the server then select Connect.
- Login: mcwadmin
- Password: demo@pass123
Update the remainder of the Deployment Settings screen using these inputs and then select Next:
- Edition of Azure SQL database: Standard
- Maximum database size (GB): 1
- Service Objective: S1
Select Finish and allow the Database to be migrated to Azure.
Select Close once the database has been migrated to Azure SQL Database.

Note: If you get an error stating something similar to “unresolved reference to the object #aspnet_Permissions” then select Close and retry the database import process again.
Move back to the Azure portal on LABVM. Open the BCDRPaaSPrimarySite resource group and notice that there is a new SQL Database called ContosoInsurance.
Select ContosoInsurance to open the resource.
Under Settings, select Configure.
On the Configure pane, select the Premium pricing tier category, then select Yes for the Would you like to make this database zone redundant? option.

This will configure the Azure SQL Database to span across Availability Zones within the Azure Region it is hosted, and offer higher availability.
Select Apply to save the pricing tier changes.
On the ContosoInsurance database resource, select the Overview pane, then select Show database connection strings.
Select the Copy to clipboard link to capture the connection string and then paste it to your SQLSERVER.TXT file.
In the Azure portal, move back to the BCDRPaaSPrimarySite resource group and then select the SQL Server resource.
Under Settings, select Failover groups.
Select +Add group.
Complete the Failover group blade using these inputs and then select Create:
- Failover group name: Enter a lowercase unique name 3-24 characters using the prefix bcdrpassfog.
- Secondary Server: Select the secondary SQL Server from your BCDRPaaSSecondarySite.
- Database within the group: ContosoInsurance
The portal will submit a deployment.
The portal will update once the Failover group has been deployed. Select the group.
The Failover group (FOG) portal will appear. Copy the name of the Listener endpoint to your clipboard and then copy this to your SQLSERVER.TXT file.
In the SQLSERVER.TXT file, update the server name in the connection string with the name of the FOG listener endpoint. Also, change the user name and password to the credentials for the SQL Server:
- Username: mcwadmin
- Password: demo@pass123
The new connection string will be used for the Web App. This will ensure that when the SQL Database is failed over that the server is always pointing to the Failover group. Open the Web App in the BCDRPaaSPrimarySite resource group.
Select the URL. The empty Web App will appear.
Under Settings, select Configuration.
Scroll down to the Connection strings settings and add a new connection string using the following inputs, then select OK to add the connection string.
- Name: PolicyConnect
- Value: Paste in the updated string you created with the failover group name from the SQLSERVER.TXT file.
- Type: SQLAzure
Note: You must use the Name PolicyConnect. This is the name that is recognized by the Application in the source code.
Select Save on the Configuration blade.
Repeat the same procedure on the Web App located in the BCDRPaaSSecondarySite resource group using the same connection string:
- Name: PolicyConnect
- Value: Paste in the updated string you created with the failover group name from the SQLSERVER.TXT file.
- Type: SQLAzure
On the LABVM open Visual Studio. You will be required to login to Visual Studio. If you don't have an account you can create a free account following the prompts.
Select Open a project or solution.
Open the Solution located at C:\HOL\WebApp\ContosoInsurance.sln.

Note: You may see a security warning about opening projects from trustworthy sources. Select OK if prompted.
Locate the ContosoInsurance application in the Solution Explorer on the right-hand area of Visual Studio.

Note: If for some reason the Solution Explorer is not seen you can select View -> Solution Explorer on the Menu bar of Visual Studio.
Right-click the ContosoInsurance Application and select Publish.
On the Publish screen on the Target step select Azure and then Next.
On the Publish screen on the Specific target step select Azure App Service and then Next.
On the Publish screen on the App Service step select application under BCDRPaaSPrimarySite and finally Finish.
Select Publish to publish the ContosoInsurance application to Azure.
Once the publish has succeeded, open the Azure Web App in a browser to see that it's running successfully.
Select the Current Policy Offerings button, and the page should load with data showing. This means that you have successfully implemented the Web App and it has connected to the Failover Group database.
Execute the same steps for the BCDRPaaSSecondarySite.
Once the publish to the has succeeded, open the Azure Web App in a browser to see that it's running successfully.
Select the Current Policy Offerings button, the page should load showing data (various coverage plans). This means that you have successfully implemented the Web App, and it has connected to the Failover Group database.
Close Visual Studio and move back to the Azure Portal. The next step will be to deploy a Front Door for this PaaS implementation. Select +Create a resource then search for and select Front Door in the Azure Marketplace and select Create.
Complete the Basics tab of the Create a Front Door blade using the following inputs, then select Next: Configuration >:
- Resource group: Use existing BCDRPaasPrimarySite
- Resource group location: Automatically assigned based on the BCDRPaaSPrimarySite.
Select the plus button on the Frontend hosts box to set the host name of Front Door.
In the Add a frontend host pane, enter the following values, then select Add:
- Host name: Enter a unique name with the prefix of bcdrpaas.
- Session affinity: Disabled
Select the plus button on the Backend pools box to begin adding endpoints to the backend pool.
On the Add a backend pool pane, enter the following values, then select the Add a backend link:
- Name: BCDRPaaS
- Health Probes – Protocol: HTTP
On the Add a backend pane, enter the following values, then select Add:
- Backend host type: App service
- Backend host name: Select the Primary Web App (named like bcdrprimarysiteXXX.azurewebsites.net) that's in the BCDRPaaSPrimarySite resource group.
Select the Add a backend link again, and add another backend host name with the following values, then select Add:
- Backend host type: App service
- Backend host name: Select the Secondary Web App (named like bcdrsecondarysiteXXX.azurewebsites.net) that's in the BCDRPaaSSecondarySite resource group.
Select Add to create the backend pool.
Select the plus button on the Routing rules box.
On the Add a rule pane, enter the following values, then select Add:
- Name: BCDRPaaS
- Backend pool: BCDRPaaS
- Forwarding protocol: Match request
Select Review + Create.
Once validation has completed, select Create to provision the Front Door service.
Select the DNS name of the Front Door, the Policy Connect web application will load. This is connecting to one of the two Web Apps running in the Primary Site or Secondary Site and talking to the Azure SQL Database Failover Group primary replica using the SQL FOG Listener.

Note: If you get a “Our services aren't available right now” error accessing the web application, then continue on with the lab and come back to this later. Sometime this can take a ~10 minutes for the routing rules to publish before it's “live”

Exercise 3: Migrating to Azure Key Vault

Duration: 30 minutes

Synopsis: In this exercise, attendees will learn how to migrate web application to utilize Azure Key Vault rather than storing valuable credentials (such as connection strings) in application configuration files.

Task 1: Create an Azure Key Vault secret

Switch to your Azure Portal.
Select Key Vaults, then select your Azure Key Vault.
Select Secrets, then select +Generate/Import.
For the Upload Options, select Manual.
For the Name, enter InsuranceAPI.
For the Value, copy the connection string information from the InsuranceAPI solution Web.config file in Exercise 2.
Select Create.
Select Secrets.
Select InsuranceAPI.
Select the current version.
Copy and record the secret identifier URL for later use:

Task 2: Create an Azure Active Directory application

In the Azure Portal, select Azure Active Directory, then select App Registrations.
Select +New application registration.
For the user-facing display name, type AzureKeyVaultTest.
For the supported accounts, select Accounts in this organization directory only…
For the Redirect URL, type http://localhost:12345.
Select Register.
Copy and record the Application ID for later use.
In the left menu pane, under the Manage heading, select Certificates and secrets link.
Under Client secrets, select New client secret.
For the description, enter InsuranceAPI.
For the Expires, select In 1 year.
Select Add.
Copy and record the key value for later use.

Task 3: Assign Azure Active Directory application permissions

Switch back to Azure Portal and select your Azure Key Vault.
Under the Settings heading, select Access Policies.
Select + Add Access Policy.
Choose Select principal field value. In the right-hand pane, type AzureKeyVaultTest. Select the item.
Choose the Select button at the bottom.
Select the Secret permissions drop-down, check the Get and List permissions.

Your selection summary should look like this.
Select Add button.
Select Save button at the top.

Task 4: Install or verify NuGet Package

Close the previous Visual Studio solution, then from the extracted GitHub directory, open the \Hands-on lab\WebApp\InsuranceAPI_KeyVault\InsuranceAPI.sln solution.

Note: Be sure you re-open the correct solution.
Switch to Visual Studio.
In the menu, select View->Other Windows->Package Manager Console.

In the new window that opens, run the following commands:

Install-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Install-Package Microsoft.IdentityModel.Clients.ActiveDirectory -Version 2.16.204221202

Install-Package Microsoft.Azure.KeyVault

Note: These already exist in the project but are provided as a reference. If you receive a codedom version error when you debug, run this command.

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

From Solution Explorer, double-click the Web.config file to open it.

Notice the appSettings section has some token values:
Replace the ApplicationId (ClientId) and ClientSecret with the values from Task 2.
Replace the SecretUri with the Azure Key Vault secret key Uri from Task 1.
Save the Web.config file in Visual Studio.

Note: You can take this lab a step further and publish the Web App to an Azure App Service and enable System-assigned Managed Identities. This will allow you to completely remove any authentication from your configurations and utilize Key Vault references.

Task 5: Test the solution

Open the Web.config, and comment out or delete the connectionString from the file at line 78.
Open the Global.asax.cs file, and place a break point at line 28.

Note: This code makes a call to get an accessToken as the application you set up above, then make a call to the Azure Key Vault using that accessToken.
Press F5 to run the solution.

You should see that you execute a call to Azure Key Vault and get back the secret (which in this case is the connection string to the Azure Database).
Press F5 to continue the program.
Navigate to http://localhost:portno/api/Users, you should get an error. Because you encrypted the column in the previous exercise, EntityFramework is not able to retrieve the value(s) using default settings. In order to do seamless decryption, you would need to:
- Run the \Hands-on lab\Database\02_PermissionSetup.sql script if you have not already done so.
- Add the AzureKeyVaultProvider for Entity Framework reference to the project.
- Register the provider code in order for .NET to handle the encrypted column.
- Add an access policy to the Azure Key Vault that gives key permissions (decrypt, sign, get, unwrapkey, verify) to the Azure AD application.
- Add the Column Encryption Setting=Enabled to the connection string.
- Detailed steps can be found in this blog post
- A third solution (\Hands-on lab\WebApp\InsuranceAPI_KeyVault_Encrypted\InsuranceAPI.sln) was added to the GitHub repo that has the necessary references and code added.
  - Simply update the web.config file with your client id and secret after adding the required Key Vault permissions above.
  - Update the Key Vault connection string to have the Column Encryption Setting=Enabled.
  - Review the code added to the global.asax.cs file.
  - Run the project and navigate to the above page.

Exercise 4: Securing the Network

Duration: 45 minutes

Synopsis: In this exercise, attendees will utilize Network Security Groups to ensure that virtual machines are segregated from other Azure hosted services and then explore the usage of the Network Packet Capture feature of Azure to actively monitor traffic between networks.

Task 1: Test network security group rules #1

In the Azure Portal, select Virtual Machines.
Select paw-1, then select Connect.
In the dialog, select Download RDP file Anyway. Open the downloaded RDP file and connect to the Virtual Machine.

Note: Default username is wsadmin with p@ssword1rocks as password and you may need to request JIT Access if you have taken a break between exercises.
In the PAW-1 virtual machine, open Windows PowerShell ISE as administrator.
- Select the Windows icon.
- Right-click Windows PowerShell ISE, choose More, then select Run as Administrator.

Copy and run the following command:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted

In the dialog, select Yes.
Select File->Open, browse to the extracted GitHub directory and open the \Hands-on lab\Scripts\PortScanner.ps1.

Note: You would have downloaded the GitHub repo and extracted this in the setup steps. If you did not perform those steps, perform them now. You can also choose to copy the file from your desktop to the VM.
Review the script. Notice that it does the following:
- Installs NotePad++
- Adds hosts entries for DNS
Note: When using multiple virtual networks, you must setup a DNS server in the Azure tenant.
- Executes port scans
Press F5 to run the script. You should see the following (the Azure ARM Template created a default rule to block all traffic):
- Port scan for port 3389 (RDP) to DB-1 and WEB-1 is unsuccessful from the PAW-1 machine.
- The information above for port 3389 (RDP) is visible after running the script and pressing F5.
- Port scan for port 1433 (SQL) to DB-1 and WEB-1 is unsuccessful from the PAW-1 machine. DB-1 is running SQL Server but traffic is blocked at NSG and via the Windows Firewall.
- Port scan for port 80 (HTTP) to DB-1 and WEB-1 is unsuccessful from the PAW-1 machine, if traffic was allowed, it would always fail to DB-1 because it is not running IIS or any other web server.

Note: The ARM template deploys a Deny All rule. If you were to simply create a Network Security Group from the UI, you would not experience this behavior.

Task 2: Configure network secuirty groups

Switch to the Azure Portal.
Configure the database server to only allow SQL Connections from the web server:
- Select Network Security Groups.
- Select DbTrafficOnly.
- Select Inbound Security Rules.
- Select +Add.
- For the Source, select IP Addresses.
- For the Source IP address, enter 10.2.0.4.
- For the Destination, keep Any.
- For the Destination port range, enter 1433.
- For the Priority, enter 100.
- For the Name, enter Port_1433.
- Select Add.
Configure the web server to allow all HTTP and HTTPS connections:
- Select Network Security Groups.
- Select WebTrafficOnly.
- Select Inbound Security Rules.
- Select +Add.
- For the Source, keep Any.
- For the Destination, keep Any.
- For the Destination port ranges, enter 80,443.
- For the Priority, enter 100.
- Change the Name to Port_80_443.
- Select Add.
Note: In some rare cases it may take up to 15 minutes for your Network Security Group to change its status from Updating. You won't be able to add any other rules until it completes.
Configure both the database and web server to only allow RDP connections from the PAW machine:
- Select Network Security Groups. For both the DbTrafficOnly and WebTrafficOnly, do the following:
  - Select Inbound Security Rules.
  - Select +Add.
  - For the Source, select IP Addresses.
  - For the Source IP address, enter 10.0.0.4.
  - For the Destination port range, enter 3389.
  - For the Priority, enter 101.
  - For the Name, enter Port_3389.
  - Select Add.
Configure all Network Security Groups to have Diagnostic logs enabled.
- Select Network security groups. For each NSG (DBTrafficOnly and WebTrafficOnly), do the following:
  - In the content menu, select Diagnostic logs, and then select Add diagnostic setting.
  - For the name, enter the NSG name and then add Logging to the end.
  - Check the Send to Log Analytics checkbox, in the Log Analytics box, select Configure.
  - Select the azseclog… workspace.
  - Select both LOG checkboxes.
  - Select Save.
  - Repeat for all remaining Network Security Groups.

Task 3: Test network security group rules #2

Switch back to the PAW-1 virtual machine.
Press F5 to run the PortScan script. You should see the following:
- Port scan for port 3389 (RDP) to DB-1 and WEB-1 is successful from the PAW-1 machine.
- Port scan for port 1433 (SQL) to DB-1 is successful, and WEB-1 is unsuccessful from the PAW-1 machine.
Note: You may need to disable the windows firewall on the DB-1 server to achieve this result.
- If IIS has been setup on WEB-1, the port scan for port 80 (HTTP) to DB-1 is unsuccessful and WEB-1 is successful from the PAW-1 machine

Task 4: Install network watcher VM extension

Switch to the Azure Portal.
Select Virtual Machines.
Select db-1.
In the blade menu, select Extensions, then select +Add.
Browse to the Network Watcher Agent for Windows, and select it.
Select Create.
In the next Install extension dialog window (note that it could be blank) select OK. You should see a toast notification about the script extension being installed into the Virtual Machine.

Task 5: Setup network packet capture

In the main Azure Portal menu, search All services for Network Watcher.
In the context menu, select Network Watcher.
Expand the subscription regions item you are running your labs in.
For the East US region (or whatever region you deployed your VMs too), select the ellipsis, then select Enable Network Watcher.
In the new context menu, select Packet capture.
Select +Add.
Select your subscription.
Select your resource group.
For the target virtual machine, ensure that db-1 is selected.
For the capture name, enter databasetraffic.
Notice the ability to save the capture file to the local machine or an Azure storage account. Ensure that the resource group storage account is selected. If you check your resource group, the storage account is prefixed with “diagstor”.
For the values, enter the following:
- Maximum bytes per packet: 0.
- Maximum bytes per session: 1073741824.
- Time limit: 600.
Select OK.

Task 6: Execute a port scan

Switch your Remote Desktop connection to the PAW-1 virtual machine.
Uncomment the last line of the script, and press F5.

Note: You should see the basic ports scanned, and then a port scan from 80 to 443. This will generate many security center logs for the Network Security Group which will be used in the Custom Alert in the next exercise.

Exercise 5: Azure Sentinel Loggin and Reporting

Duration: 20 minutes

Synopsis: In this exercise, you will setup Azure Sentinel to point to a logging workspace and then create custom alerts that execute Azure Runbooks.

Task 1: Create a dashboard

Open the Azure Portal.
Select All services, then type Sentinel, select Azure Sentinel.
In the blade, select +Add, select the Log Analytics resource for your resource group, then choose Add Azure Sentinel.
In the blade, under Threat Management, select Workbooks.
In the list of workbooks, select Azure Network Watcher, choose Save.
Select the region and choose OK.
In the list of workbooks, select Azure AD Audit logs, select Save.
Select the region and select OK.
Select View saved workbook, take a moment to review your new workbook.

Note: You may not have data in the log analytics workspace. Wait for 10-15 minutes.

Task 2: Create an Analytics alert

Navigate back to the Azure Sentinel workspace, in the Configuration blade section, select Analytics then select +Create then Scheduled query rule.
On the General tab, enter PortScans for the name.
For the description, enter A custom rule to detect port scans, select Next: Set rule logic.
In the Rule query text box, type:
```
AzureDiagnostics
| where ruleName_s == 'UserRule_DenyAll' and Type != 'AzureMetric' and type_s == 'block' and direction_s == 'In' and Resource == 'WEBTRAFFICONLY' and OperationName == 'NetworkSecurityGroupCounters'
| summarize AggregatedValue = sum(matchedConnections_d) by ruleName_s, primaryIPv4Address_s
| where AggregatedValue > 0
```
Note: If you were quick going through the labs, then you may not have log data in the Log Analytics workspace just yet that corresponds to “AzureMetric”. You may need to wait 15-30 minutes before a query will execute.

Note: Since the introduction of Azure Security Center and Sentinel, the backend logging has changed a few times as well as the way the calculations are done in the rule query (timespan in query vs outside query, etc.). The ultimate goal of this query is to find when a series of failed connection attempts have been made against a network security group and a specific deny rule. If for some reason the UI/backend has been modified since the last published lab, modify the query to accomplish this goal.
Under Map entities, for the IP, select the primaryIPv4Address_s column.
Under Query scheduling, for the Run query every setting, type 5 minutes.

Note: This is a lab and you want to see the results as quickly as possible. In a production environment, you may want to choose a different time threshold.
For the Lookup data from the last, type 1 hours.
Under Alert threshold, for the Generate alert when number of query results, enter 1.

Note: We want to hit the threshold quickly for lab purposes. This query and value may not be appropriate for production and is only for learning purposes.

Review the current data to determine what would trigger the alert. Notice the red threshold line intersects the blue event data line.
Select Next: Automated response, notice you have no playbooks to select yet.
Select Next: Review.
Select Create.

Note: It may take a few minutes for the alert to fire. You may need to run the PortScan script a few times from paw-1

Task 3: Investigate a custom alert incident

In the main menu, select Azure Sentinel.
Select Incidents.
Select the new PortScans incident.

Note: It may take 15-20 minutes for the alert to fire. You can continue to execute the port scan script to cause log events or you can lower the threshold for the custom alert.
In the dialog, choose Investigate.
In future versions, you will get to see insights about the alerts and the resources related to what caused it to fire:

Task 4: Create an run a playbook

In the Azure Sentinel blade, select Playbooks.
In the new window, select + Add Playbook.
The Create logic app blade will display:
- For the name, enter Email.
- Select your existing resource group.
- Toggle the Log Analytics to On and then select your azuresecurity Log Analytics workspace.
Select Create, after a few moments, the Logic Apps Designer will load. If the designer does not load, wait a few minutes and refresh the Playbook list. Select the Email playbook.
Select the Get a notification email when Security Center detects a threat template.
Select Use this template.
For the Office 365 Outlook connection, select the + link, enter your Azure/O365 credentials.

Note: This would need to be a valid Office 365 account, if you do not have a valid Office 365 account, then utilize a basic email template for Outlook.com.
For the Security Center Alert connection, select the + link.
Select Continue.
For the email address, enter your email.
Select Save. You now have an email alert action based on LogicApps for your custom security alert to use.
Lastly, after you have created the new Playbook, ensure that the status is Enabled. If not, then select Enable in the menu.

Task 5: Execute Jupyter Notebooks

In the Azure Sentinel blade, select Notebooks.
In the blade top menu navigation, select Clone Notebooks.
If not already logged in, select your Azure credentials, the GitHub repo will start to clone into your workspace.

You will see the GitHub progress meter.
Navigate to My Projects and select the Run on Free Compute.
Search for the Get Started.ipynb notebook. You may have to page through the results to find the Get Started.ipynb notebook. Select it. In this example, it was located on the second page.
In the menu, select Kernel->Change kernel, then select Python 3.6.
Choose the Run button until you execute the entire Notebook, note that some steps will required your input.

When the cell has an asterisk, it is still processing. Wait for a number to appear.

This cell has completed processing. You should see a number.

Note: You can find the open source GitHub notebooks at https://github.com/Azure/Azure-Sentinel.

At this point, you may have to enter the code.

Your final cell processing should provide an output.

Task 6: Creating Reports with Power BI

Navigate back to your Azure Sentinel browser window. Select Logs.

Note: You may see a Welcome to Log Analytics splash page in the blade. Select Get Started.
In the Schema tab under Active, expand the LogManagement node, notice the various options available.
In the schema window, select AzureDiagnostics, then choose the eye icon.
In the top right, select Export, then select the Export to Power BI (M Query) link.
Select Open, a text document with the Power Query M Language will be displayed.
Follow the instructions in the document to execute the query in Power BI.
Close Power BI.

Exercise 6: Using Compliance Tools (Azure Policy, Secure Score and Compliance Manager)

Duration: 30 minutes

Task 1: Review a basic Azure Policy

Open the Azure Portal. Select All Services, then type Policy. Select Policy in the list of items.
In the blade menu, select Compliance, and review your Overall resource compliance percentage.
For the scope, ensure the proper subscription is selected, then select ASC Default (subscription:.
In the Initiative compliance blade, review your compliance metrics.
Scroll to the results area and select the Non-compliant resources tab.
In the filter search box, type PAW-1 and select it when displayed.

Note: You may not see resources display right away. If this is the case, then scroll through some other non-compliant resources.
With the Policies tab selected, review the policies that the resource is non-complying against.

Note: New policies are being created and your number may be different from the image below.
Choose one of the policies. Review the Definition JSON of the policy definition, notice how it is based on ARM Template format and is looking for specific properties to be set of the non-compliant resources.

Note: You can use these out of box templates to build your own policies and apply them as blueprints.

Task 2: Review and create Azure Blueprints

In the Policy blade, under Authoring, select Definitions. These are a list of all defined policies which can be selected for assignment to your subscription resources.
In the Policy blade, under Related Services, select Blueprints.
In the Blueprints blade, select Blueprint definitions.
Select +Create blueprint.
Review some of the sample blueprints, then select Start with blank blueprint.
For the name, type gdprblueprint.
For the location, select the ellipses, then select your subscription in the drop down.
Choose Select.
Select Next: Artifacts.
Select + Add artifact.
For the Artifact Type, select Policy Assignment, review all the policies available to you (at the time of this writing you would see 37 definitions and 311 policies).
In the search box, type unrestricted, browse for the Audit unrestricted network access to storage accounts.
Select Add.
Select Save Draft. It may take a few minutes. The blade will automatically change when the save operation finishes.
For the new blueprint, select the ellipses, then select Publish Blueprint.
Select Publish.
For the version type 1.0.0.
For the new blueprint, select the ellipses, then select Assign Blueprint.
Review the page, then choose Assign. This policy will now be audited across all your storage accounts in the specific subscription.

Task 3: Secure Score

In the Azure Portal, select All Services, then type Security, select Security Center.
In the Security Center blade, under POLICY & COMPLIANCE, select Secure score.
Review your overall secure score values and then notice the category values.
On the bottom half of the window, select your subscription, you will be presented with the items that have failed resource validation sorted by the score value that is assigned to that particular recommendation item.
Select the An Azure Active Directory administrator should be provisioned for SQL Servers, on the recommendation blade, you will be presented with information about how to remediate the recommendation to gain the impact value to your score.

Task 4: Use Compliance Manager for Azure

Note: You may need to additional permissions to run this portion of the lab. Contact your Global Administrator.

In a browser, go to the Service Trust/Compliance Manager portal (https://servicetrust.microsoft.com).
In the top corner, select Sign in, you will be redirected to the Azure AD login page.
If prompted, select or sign in with your Azure AD\Office 365 credentials.
In the menu, select Compliance Manager->Compliance Manager Classic.
Select on the +Add Assessment link.
Select Create a new Group, for the name type AzureSecurity, select Next, set the Would you like to copy the data from an existing group toggle to No, select Next.
For the product dropdown, select Azure.
For the certification dropdown, select GDPR.
Select Add to Dashboard. You will now see a new assessment for Azure and GDPR in progress:
Select Azure GDPR.
Review the various controls that you can implement:
On the top menu, choose Trust Documents, then select Audit Reports.
Notice the various tabs that you can select from, select FedRAMP Reports.
These are all the FedRAMP reports sorted by date that have been performed and publicly posted for Azure customer review. Select the item displayed and briefly review the document.