Azure

Backups vs Replication vs High Availability vs Fault Tolerance vs Disaster Recovery

Posted on by Imran Rashid
Reading Time: 10 minutes


In IT, the following terms come up frequently:

  • Backups
  • Replication
  • High Availability
  • Fault Tolerance
  • Disaster Recovery

In this post, I will explain what each one means, why they exist, and when to use them, using simple language and real‑life examples.

An important thing to remember is that these are not competitors, they work together.

A good setup often uses:

Backups → recover from mistakes, corruption, or attacks (get my data back)
Replication → keep data in sync between locations (supports faster recovery)
High Availability → reduce or avoid downtime (stay online during failures)
Fault Tolerance → keep running even if something fails (no interruption)
Disaster Recovery → survive major outages and disasters (recover from the worst)

Let’s start in the following order: Backups, Replication, High Availability (HA), Fault Tolerance and then Disaster Recovery (DR).

Backups


What is a backup?
A backup is a saved copy of your data from the past. If something goes wrong, for example, files are deleted, corrupted, or a system fails, you can use a backup to restore your data to an earlier point in time.

Backup Example 1:
You regularly copy your important files (documents, photos, work files) from your laptop to an external hard drive and then disconnect it. If your laptop is lost, damaged, or the hard drive fails, you can plug in the external drive and restore your files. The backup is a separate copy created earlier, so even if the laptop is gone, the data still exists.

Backup Example 2:
A small business stores customer records, invoices, and reports on a company server. Every night, these files are backed up to a secure off‑site location. One day, ransomware encrypts the main server. The business wipes the server and restores the data from the previous night’s backup, allowing work to continue. The business is able to restore data from a safe, unchanged copy created before the incident. This protects against accidental deletion, cyber attacks, and system failure.

Note: Ransomware attack
An attacker encrypts your files so you can’t access them and then demands a payment (usually money) in exchange for unlocking or decrypting the data.

Backup Example 3:
A company backs up its database every night. If someone deletes data by mistake, IT restores yesterday’s backup.

Summary of when backups are used


Backups are used when data needs to be recovered from a previous safe copy, such as in the following situations:

  • Accidental deletion – “Oops, I deleted the wrong file”
  • Ransomware attacks – Data is encrypted or made unusable, and systems must be restored from a backup created before the attack.
  • Data corruption – Files or databases become damaged or unreadable due to software issues, hardware failure, or crashes.

Pros of backups

  • Backups are usually less expensive than High Availability or Disaster Recovery solutions.
  • Protects against human mistakes – Helps recover data after accidental deletion or overwriting.
  • Allows point‑in‑time restore – You can restore data from a previous state (for example, yesterday or last week).

Cons of backups

  • Systems may be unavailable during restore – Services can be down while data is being recovered.
  • Recent changes may be lost – Any data created after the last backup is not included in the restore.
  • Recovery is not instant – Restoring data can take time, especially when large amounts of data are involved.


Replication


What is replication?
Replication means automatically copying data to another location so that changes are copied continuously or near real time. Once replication is set up, it usually runs automatically in the background. When data changes on the main system, the same change is sent to the replica without manual action.

Replication Example 1:
You type notes on your laptop and they quickly sync to another laptop. If you delete a sentence on one device, it disappears on both. Replication keeps copies in sync, so any change, good or bad, is automatically copied to all replicas.

Replication Example 2:
A database is continuously replicated to another server, creating a live duplicate. The second server is kept up to date, even if no failover has happened.

Replication Example 3:
An online store uses replication to keep a second copy of its database up to date. A staff member accidentally deletes thousands of customer orders from the main database. Because replication copies every change, the deletions are also applied to the second server. As a result, both databases are missing the orders.

Replication Example 4:
A company has a file server in one data centre and continuously copies changes to a second server in another location. When a file is updated on the primary server, the same change is automatically copied to the second server after a short delay (depending on replication configuration).

When replication is used

  • To reduce downtime by keeping a ready to use copy available if the primary system fails.
  • Replication is commonly used in high availability designs and disaster recovery strategies to improve resilience.

Pros

  • Fast recovery – Systems can switch to a replicated copy quickly when a failure occurs, reducing recovery time.
  • Minimal data loss – Data is copied in near real time
    Note: A small amount of data loss may occur if the latest changes were not able to replicate before the failure.
  • Supports business continuity – Replication reduces downtime and helps businesses continue operating during outages or infrastructure failures.
  • Systems stay current – Replicated systems remain up to date with ongoing changes.

Cons

  • Replicates mistakes and corruption – If data is accidentally deleted or becomes corrupted, replication copies the same problem to all replicas. Replication improves availability, but backups are still required to recover from mistakes or data corruption.
  • Does not protect against human mistakes – Actions such as accidental deletions, overwriting data, or running the wrong command are replicated automatically and cannot be reversed using replication alone. Some platforms combine replication with snapshots or point‑in‑time recovery, which allows rollback, but this capability comes from the snapshot or recovery layer, not from replication itself.
  • More expensive than backups – Replication typically requires additional infrastructure, storage, networking, and management, making it more costly than traditional backup solutions.

High Availability (HA)


What is High Availability (HA)?
In today’s world, smooth operations of applications is crucial for businesses, but issues to those applications can pose challenges. High Availability helps IT systems stay available during common failures and periods of heavy usage. It is designed to keep services running for long periods with minimal downtime, often by automatically switching to healthy components when something fails. Many platforms also allow planned manual switchovers during maintenance or upgrades.

High Availability and replication work together, but they are not the same thing.
Replication is commonly used in High Availability, especially for data (like databases), but High Availability also uses things like load balancers and multiple servers to keep services running. High Availability focuses on keeping services online, while replication ensures that data already exists on another system. When a failure happens, High Availability mechanisms (often automatic failover) can switch to the replicated copy, allowing the system to continue operating with minimal or no downtime.

In short, High Availability keeps a service running by having another copy ready. For websites, that can mean multiple servers behind a load balancer. For data (like a database), it often means keeping a second copy of the data in sync so the system can switch over quickly.

HA Example 1:
A supermarket has multiple checkout tills. If one till breaks, customers are redirected to another till, so the shop continues operating without closing.

HA Example 2:
A shopping website runs on multiple servers at the same time behind a load balancer. If one server fails, incoming traffic is automatically redirected to another server, so customers can continue shopping as normal.

HA Example 3:
A hospital system runs patient records on two servers at the same time. If one server fails, the service continues with minimal downtime, so doctors and nurses can still access patient information.

HA Example 4:
A company uses two internet connections from different providers. If one internet connection goes down, traffic automatically switches to the other, so staff can continue working without noticing any outage.

Note: Load balancer
A load balancer distributes traffic across multiple servers so the service stays available.

When High Availability is used

  • Public websites and apps
  • Banking and payment systems
  • Online shopping platforms
  • Any service that must always be on

Pros

  • Minimal downtime
  • Automatic failover when failures occur (common in many HA setups)
  • Better user experience

Cons

  • Typically requires more infrastructure and can cost more than backup alone
  • More complex to design and manage
  • Does not protect against accidental data deletion (backups are still required)


Fault Tolerance (FT)


What is Fault Tolerance (FT)?
Fault Tolerance is related to High Availability, but it goes a step further. It is the ability of a system to continue operating during a failure, often with very little or no noticeable interruption, depending on the design. This usually requires duplicate components already running in parallel, so if one component fails, another can take over immediately. Because fault tolerance requires extra redundancy, it is usually more complex and more expensive than high availability.

Fault Tolerance Example 1:
A server has two power supplies connected to separate power sources. If one power supply fails, the server continues running on the other one, and users don’t notice any disruption.

Fault Tolerance Example 2:
A storage system uses RAID. If one disk fails, the system continues running and data remains available while the failed disk is replaced.

Fault Tolerance Example 3:
A critical service runs on two identical systems in parallel. If one system fails, the other continues processing without needing a restart, so users do not experience any downtime.

Fault Tolerance Example 4:
A network has two separate network paths (for example, two switches or links). If one path fails, traffic automatically switches to the other path and the connection stays up.

Fault Tolerance Example 5:
A company uses a Standard (zone‑redundant) Azure Load Balancer with virtual machines deployed across multiple Availability Zones. If one Availability Zone has an issue, the load balancer automatically routes traffic to the healthy zones, allowing the service to continue running.

Fault Tolerance Example 6:
A company stores important files in an Azure Storage account. Azure Storage automatically keeps multiple copies of the data to improve durability and availability during hardware, power, or network failures. The level of resilience depends on the redundancy option chosen, such as copies within one datacentre, across Availability Zones, or in a secondary region. Check out the following diagram to learn more about Storage account replication options in Azure: Storage_Replication_Options.

When Fault Tolerance is used?

Fault tolerance is used when a system must keep working even if something breaks.

Instead of waiting for someone to fix the problem, the system is designed with redundancy so another component can keep things running.

Fault tolerance is used when:

  • Even a short outage is unacceptable (downtime has a serious impact).
  • The service must continue operating even if a server, disk, or network component fails.
  • The system is considered mission‑critical (for example, payment processing or critical business systems).

Fault tolerance is achieved using techniques like redundancy and failover, so the system can continue operating even when a failure occurs.

Pros of Fault Tolerance

  • No interruption during failures, users don’t notice the issue
  • Very resilient to component failures because redundancy is already running
  • Best option for systems where downtime is not acceptable

Cons of Fault Tolerance

  • More expensive – requires extra duplicated components running in parallel
  • More complex to design and manage (because systems need to stay in sync)
  • Does not replace backups – if data is deleted or corrupted, fault tolerance can keep the service online, but you still need backups to restore a clean copy.
  • Disaster Recovery (DR) is still required for datacentre‑level or regional disasters.

High Availability (HA) is not always Fault Tolerance (FT)

A company runs two web servers behind a load balancer, so if one server fails, the other can keep the website online. However, both servers are placed in the same rack or share the same power or network equipment. If that rack fails, both servers go down and the website becomes unavailable. To make the system fault tolerant to a rack failure, the company places the servers in separate racks with separate power and network paths. Now, a single rack failure won’t take out both servers at the same time. Fault tolerance isn’t about having two servers, it’s about making sure the two servers don’t fail for the same reason.

Disaster Recover (DR)


What is Disaster Recovery (DR)?
Disaster Recovery is a plan and setup used to restore systems and data after a major failure or disaster, such as a data centre outage, cyberattack, or natural disaster.

Unlike High Availability, which tries to keep systems running, Disaster Recovery assumes a major outage can happen and focuses on how to bring everything back after a serious incident. For example, a complete data centre/region failure, such as a natural disaster, flooding, tornado, something which takes the entire region offline. You will declare a disaster and initiate a failover from your primary site to your secondary site. You could attempt to recover all of the data in the secondary site from backups but this could take a long time.

HA = stay running through smaller failures
DR = recover after a major outage that high availability alone cannot handle

Note: DR failover can be manual or automated depending on the tools used, but it usually involves a planned process and may take longer.

Why Disaster Recovery is different from High Availability


High Availability (HA) aims to prevent downtime by switching to healthy systems when something fails, often without users noticing. It is designed for small, common failures, such as a server crash or hardware fault.

Disaster Recovery (DR) is used when HA is not enough, for example when an entire site or region is unavailable. DR focuses on restoring services and data after a major outage, and it can take longer than HA.

Disaster Recovery follows planned recovery steps (which can be manual or automated) to bring systems back online after a serious incident. High Availability focuses on keeping systems running, often automatically, and often without users noticing, during smaller failures. They are different, but they work together. High Availability reduces everyday downtime, and Disaster Recovery provides a fallback when a major disaster occurs.

DR Example 1:
Your office burns down, so you move work to a backup building that was prepared in advance. This is an example of Disaster Recovery.

DR Example 2:
An organisation has two data centres: a primary and a secondary. The secondary data centre is used for Disaster Recovery. Data is continuously replicated to the secondary data centre. If the primary data centre goes offline, failover to the secondary site is performed as part of the Disaster Recovery plan.

DR Example 3:
A company’s file server is taken offline after a cyberattack. The Disaster Recovery (DR) plan is activated to rebuild the server and restore business operations. As part of the DR plan, data is restored from backups, and work resumes after recovery is complete.

DR Example 4:
A ransomware attack encrypts an organisation’s systems. The affected systems are wiped and rebuilt, and clean data is restored from backups. This is an example of Disaster Recovery.

When Disaster Recovery is used

  • Data centre failure
  • Cloud region outage
  • Floods, fires, or cyber attacks

Pros

  • Protects against large‑scale disasters
  • Covers entire systems and services, not just data
  • Can combine replication and backups for faster recovery and data protection

Cons

  • More expensive than backups alone
  • Recovery is not always instant and may involve downtime
  • Requires careful planning, documentation, and regular testing. The right test frequency depends on the organisation and workload, but disaster recovery plans should be practiced regularly.

Why do all these matter and when should an Organisation consider them?


Many organisations don’t think about backups, replication, high availability, or disaster recovery until something breaks. But when a system goes down, the impact can be serious: work stops, customers can’t access services, revenue can be lost, and trust can be damaged. For some systems, there can also be compliance or legal consequences. That’s why it helps to decide in advance what level of downtime and data loss is acceptable, then choose the right approach based on that.

A simple way to choose between these options is to understand two terms:

  • RTO (Recovery Time Objective): the maximum time you can tolerate the service being unavailable after an outage. In other words: “How long can we be down before it becomes a real problem?”
  • RPO (Recovery Point Objective): the maximum amount of data loss you can tolerate, measured in time. In other words: “If we have to restore, how far back in time can we rewind without major impact?”

Think of it like this: the faster you need to be back online (low RTO), the more you move towards HA/replication. If you mainly need to get data back (even if it takes longer), backups matter most.

I hope you found this post useful. Please feel free to share any feedback or comments below. Thank you

How to Configure Conditional Access Reauthentication in Azure PIM

Posted on by Imran Rashid
Reading Time: 5 minutes


In this blog post, I’ll provide a step by step guide on how to enforce admin reauthentication when elevating a role in Azure Privileged Identity Management (PIM) using a Conditional Access policy.

But why would you want an admin to reauthenticate?

Once an admin signs in to the Azure portal, they typically don’t need to authenticate again during that session. Sounds convenient, right? But here’s the problem. If an admin needs to access PIM to elevate their role, they can do so without reauthenticating, because they’re already signed in. This creates a potential security risk. If a bad actor gains access to an authenticated session, they could elevate the admin’s role and cause serious damage to your environment.

By enforcing reauthentication through Conditional Access, you add an extra layer of protection. The admin will be required to verify their identity again before they can elevate to a privileged role, helping to prevent unauthorised access and safeguard your platform.

In this blog post I will:

  • create an Authentication Context.
  • create a Conditional Access policy (including the Authentication Context), that prompts for reauthentication when an admin attempts to elevate a role in PIM.
  • associate the Authentication Context with a PIM role
  • test the configuration

Task 1: Create an Authentication Context


Authentication Context can be used to enhance the security of data and actions within applications. These applications might include your own custom apps, line of business (LOB) solutions, SharePoint, or services protected by Microsoft Defender for Cloud Apps.

For example, an organisation may store files in SharePoint sites, ranging from something simple like a lunch menu to something more sensitive like a secret BBQ sauce recipe. While everyone might have access to the lunch menu site, access to the secret BBQ sauce recipe site could require users to be on a managed device, use a FIDO2 security key, and accept specific terms of use. Authentication Context can help enforce these policies.

Authentication Context can also be applied in Privileged Identity Management (PIM). For instance, you might require administrators requesting high privilege roles, such as Global Administrator, to authenticate using a FIDO2 key, only allow access from a trusted location, a compliant device and so on.

In this blog post, we’ll focus on a specific use case, prompting administrators to reauthenticate before an admin role is assigned to them via PIM.

Let’s go through the steps

  1. Access Entra ID via the Azure Portal portal.azure.com or Entra portal at entra.microsoft.com

  2. In the search bar, type Conditional Access and click Microsoft Entra Conditional Access
Image2



3. From the left pane, click Authentication Contexts

Image4


4. Enter a name, description and click save

Image5

Image6

Task 2: Create a Conditional Access policy and associate it with the newly created Authentication Context

  1. Click Policies from the left pane and + New policy
Image7

  • Give your policy a suitable name
  • Target the users/groups
  • Click target resources. From the drop down (Select what this policy applies to) click Authentication Context.
  • The Authentication Context I created earlier is visible for me to select.
  • Don’t save changes just yet

    Continue to step 2 below
Image8



2. Scroll down and click sessions

Image9

  • Click Sign-in frequency
  • Click Every time
  • Click the select button
Image10


3. Switch the toggle to on and click create

Image11


Note: You may wish to leave the toggle on report only mode which will ensure the policy does not apply but will provide you with audit logs. Once convinced all is working as it should do, you can enforce the policy by turning it on. Ensure you test with a group of pilot users.

Task 3: Assign the Conditional Access policy to PIM

  1. Search for and access PIM (Microsoft Entra Privileged Identity Management)
Image12


2. In this example, I’ll be assigning the Authentication Context I created earlier to the User Administrator role. I have a demo user name Darren who has been assigned the User Administrator Role in PIM. Darren is able to elevate/request for the role and the role is automatically removed after a number of hours.

3. From the left pane, click roles. Search and click User Administrator

Image13

4. From the left pane, click Role settings

Image14

5. Click Edit to access the default settings.

Image15

6. Click the option Microsoft Entra Conditional Access Authentication Context. The Authentication Context I created earlier is visible, which is attached to the Conditional Access Policy which forces the admin to reauthenticate every time.

Image16


7. Click update

Image20


Task 4: Test the Reauthentication Policy


I’ll be logging in to Azure Portal with a demo user named Darren. I have already assigned Darren’s account to the User Administrator through PIM. Therefore, Darren is eligible to activate this role when needed. Darren is also included within the Conditional Access Policy scope.

  1. I login as Darren and go through MFA

    Note: we’ll see the Authentication Context and policy trigger later
Image17

2. Whilst logged in as Darren, I search for PIM and click my roles from the left pane.

Image18

Click activate

Image19

3. Darren is presented with a message requesting for additional verification.

Image21

4. Click the message: A Conditional Access policy is enabled and may require additional verification. Click to continue

5. Darren is prompted to login again (reauthenticate)

Image22

Image23


6. and after reauthenticating, Darren can continue to active the role.

Image24


I hope you found this post useful

Thanks for reading and see you at the next one.

Obtain Free Let’s Encrypt Certificates and Store Them in Azure Key Vault: A Step by Step Guide

Posted on by Imran Rashid
Reading Time: 12 minutes


When providing training, I demonstrate how to obtain free automated Let’s Encrypt certificates and store them in Azure Key Vault using an ACME Bot. I’ve been asked a few times to put together a step-by-step guide, so here it is.

IMPORTANT: I am implementing this solution in a demo environment with a domain name I have registered, which is not used in production. Please be careful when implementing any new solution in production. Ensure you thoroughly research and understand what you’re deploying first.

In this post I will go through a step by step guide on how to deploy a low cost solution in Azure to obtain free TLS certs from Let’s Encrypt and store them in Azure Key Vault. Furthermore, we can automatically renew these certificates and request for additional TLS certificates as needed.

Free Managed Certificates provided by the Azure platform
Depending on which services you use in Azure, there are free certificates available for use, for example, with Azure App Services and Azure Front Door. These certs are free, managed by the Azure platform and automatically renewed. However, free managed certs are limited to some services in Azure, so can not be used for all solutions.

What is Let’s Encrypt?
Let’s Encrypt is a Certificate Authority that provides free TLS certificates, making it easy for websites to enable HTTPS encryption and create a more secure Internet for everyone. Let’s Encrypt is a project of the nonprofit Internet Security Research Group.

What is ACME?
ACME stands for Automatic Certificate Management Environment. It’s a protocol that helps automate the process of obtaining and renewing SSL/TLS certificates. This means you don’t have to manually request or update certificates; ACME does it for you, making it easier to keep your website secure. There are several ACME providers, including Let’s Encrypt, which is the provider I will be using. Other providers include Buypass Go SSL, ZeroSSL, Google Trust Services, SSL.com and more.

Let’s Encrypt is one of the well known providers, offering free certificates and supports the ACME protocol for automation. To request free TLS certs, I will deploy a client to interact with the provider Let’s Encrypt. I’ll cover further details on the client later in this post.

If you wish to follow along with this demo, I will be deploying/using the below services. If you don’t have access to an Azure subscription, not to worry, I will provide a step by step guide including screenshots whilst I go through the deployment.

  • Azure Subscription: this solution will cost a small amount so an Azure Subscription is required for billing.
  • Domain name: I’ll be using a domain I have previously registered, cloudcrazy.co.uk
  • Client: Key Vault ACME bot. I’ll be using an Azure Function to run the Key Vault ACME bot client. The ACME bot will connect to the ACME provider (Let’s Encrypt) to allow me to request FREE TLS certs. I won’t be building the ACME bot client from scratch, it already exists on GitHub at the following link, GitHub Acmebot.

  • Azure App Service Plan: an Azure App Service Plan will be deployed for the Client (Azure Function App) to run in consumption mode, so it will only cost a small amount when I trigger the function app requesting for new certs, or when the app checks for certificate expiry/renewals.

  • Storage account: A storage account will be required for the client (Azure Function App) but won’t take up to much storage.

  • Azure Key Vault: the ACME bot will also connect to Key Vault as that’s where I will be storing my TLS certs.

  • Azure DNS: The DNS zone name I will be using and requesting certificates for is cloudcrazy.co.uk. You will need your own domain name. I’ll be creating an Azure DNS zone and configuring name server records for cloudcrazy.co.uk to redirect to Azure DNS. Other domain providers are also supported, such as Amazon Route 53, Cloudflare, GoDaddy, Google Cloud DNS and more. I’ll be deploying Azure DNS. With some additional effort you can also use your own custom DNS solution.

Let’s get started

  1. Visit the ACME Bot GitHub page at the following link, GitHub ACMEbot

  2. Feel free to browse the page to understand the ACME Bot further. The page shows the following at the time of writing this post.
Image

Image

Image



3. Scrolling down to the bottom of the page, I see the option to deploy this solution into my Azure environment using an ARM (Azure Resource Manager) template. I’ll be deploying into Azure (Public). Click the Deploy to Azure button. The repository also includes the option to deploy via Terraform modules and Azure Bicep if that’s what you’re already using as part of your preferred IaC (Infrastructure as code) solution.

Image


4. You’ll be prompted to login to the Azure portal

Image


5. After I log in, the provided ARM template is automatically launched from the ACME GitHub repository into my Azure environment with some default settings enabled. I will need to complete the remaining fields before I deploy.

Image


6. After completing the additional fields, this is what my deployment will look like. Please feel free to change as per your requirements.

Resource group name: rg-KeyVaultBot
Region: UK South
Mail Address: Email address for ACME account
ACME Endpoint: I am using provider Let’s Encrypt
Create With Key Vault: true (A new Key Vault will be created. If you have an existing Key Vault, click false and enter your key vault url in the Key Vault Base Url field.

Note
The new Azure Key Vault deployment configures RBAC for permissions and not access policies.

Image



7. When ready, click Review + Create, and then create after reading the terms.

Image

Image


8. The deployment should take about 5 minutes

Image


8. Click the button Go to resource group after the deployment has completed to check what has been deployed as part of this deployment.

Image

9. Click on the Function App from inside the resource group

Image


10. Explore the function app for now. Don’t make any changes.

11. If you click on Identity from the left pane, you’ll find that the deployment configured a system managed Identity for the function app. This gives the function app an identity which has been granted permissions to access the Azure Key Vault.

Image


12. Let’s open the client app via the function app. Copy the url of your function app from the overview page, and open it in a web browser.

Image


13. I get an error, not a very useful error but this is due to an authentication failure. I need to enable authentication for the app to allow me to login and access the client. We don’t want everyone on the Internet accessing this url anonymously and issuing certs on my behalf. In the next step, I will configure Entra ID authentication.

Image


14. I’ll be using authentication via Entra ID which will allow me to use my Entra ID account. There are also other authentication methods available. Click Authentication (Under Settings) from the left pane in your function app. It is also possible to configure authentication directly from Entra ID. I’ll be using the authentication option inside the function app for this demo.

Image


15. Click the button Add identity provider

Image

16. Click Microsoft from the list of Identity providers

Image

17. This wizard will create me an Entra ID app registration which will allow me to login to the function app using my Entra ID credentials. I am going to accept the default options here.

Image

Image

18. Click Add and wait for the deployment to complete

Image


19. Let’s try the client (function app) url again

Success, Entra ID is prompting for credentials

Image


20. Login with your Entra ID credentials

21. Permissions are needed for the application to access some information. Expand to check what permissions the app is needing.

Note: Carefully review what permissions are being granted before accepting for any app.

Image
Image


21. I click Accept button to grant the needed permissions

Image


22. I successfully log in to the client (function app), but there is a further error related to DNS.

Orchestrator function ‘GetCertificates_Orchestrator’ failed: The activity function ‘GetAllCertificates’ failed: “DNS Provider is not configured. Please check the documentation and configure it.”. See the function execution logs for additional details.

Image


The function app does not have access to my domain cloudcrazy.co.uk, therefore, it can not connect. I will need to resolve this before I can request for new TLS certificates from Let’s Encrypt.

23. Back in the Azure function app, under Settings, click Environment variables.

Image


24. Click the Add button

Image



25. Type the below:

Name: Acmebot:AzureDns:SubscriptionId
Value: Enter your subscription ID

Image



26. Click Apply, and the click Apply again to save changes.

27. Click Confirm. Your app may restart.

Image
Image



Azure DNS
I’ll be creating a new Azure DNS zone in my demo environment.

28. In the Azure Portal, search for and click DNS Zones

Image


29. Click create, select a resource group and input your domain.

Click Review and Create.

Image


30. Next, I need to grant permissions for the Azure Function App (the client) to connect to my DNS zone. This will allow the app to request and perform verification when requesting TLS certs from Let’s Encrypt.

Image


31. Click Add and then Add role assignment

Image


32. Select DNS Zone Contributor and click Next

Image


33. Select Managed identity and click + Select members

Image


34. Select the function app from the list and click Select. This allows the function app access to my Azure DNS zone.

Image


35. Click the button Review + Assign

36. Finally, I’ll be configuring the name servers for my domain cloudcrazy.co.uk so they point to my Azure DNS zone. Access the Azure DNS zone again and access the overview page.

I add the DNS name servers provided on the overview page to my new domain cloudcrazy.co.uk

Note: please don’t reconfigure name servers for a domain in production without prior planning. This could lead to downtime of your critical services. The domain I am using is currently not used for any production services.

Image



37. I login to my domain registrar portal and add the 4 provided name servers from the Azure portal. This process delegates access, allowing me to control my public DNS for cloudcrazy.co.uk from within the Azure portal.

IMPORTANT: I am implementing this solution in a demo environment with a domain name I have registered, which is not used in production. Please be careful when implementing any new solution in production. Ensure you thoroughly research and understand what you’re deploying first.

I add the name servers to my domain by accessing the domain registrar portal.

Image


38. That should be it. I’ll access my Azure Function app url again. No more DNS error.

39. Click Add

Image


40. Click the DNS Zone drop down list. Great, the function app is able to view the domain from Azure DNS. Remember, I allowed permissions for the app to access my Azure DNS zone in step 30 above.

Image

41. Now, it’s time to request for a cert from Let’s Encrypt. This is where we test if the client (Azure Function App) can connect to Let’s Encrypt and issue me a certificate which should automatically be stored in Azure Key Vault.

I request for a certificate for demo.cloudcrazy.co.uk

Image

42. Click the Add button which appears next to the DNS Names field, and then click Add towards the bottom. See image below.

Image

Advanced options allows you to modify the key size and add a custom certificate name if needed. I’ll be leaving the defaults.

Image


43. Done. If successful the certificate details should appear as shown in the image below.

Image


What happened in the background
The function app connected to Let’s Encrypt requesting for a TLS cert for demo.cloudcrazy.co.uk. Let’s Encrypt responds with instructions on what needs to be done in Azure DNS to verify that I own the domain. The Azure Function App adds a temporary dns record provided by Let’s Encrypt into my Azure DNS zone to complete the verification process. The Function App then returns to Let’s Encrypt to confirm the record has been added. Let’s Encrypt completes the verification check to confirm I own the domain cloudcrazy.co.uk, and issues the free TLS cert. The temporary record is then automatically deleted by the Azure Function App. This process took about 1 minute to complete and was completed automatically after I clicked the Add button in step 42.

Image

The image above displays Unmanaged certificates and Another CA certificates.

Unmanaged Certificates: If you had certificates in your Azure Key Vault which were not created by the ACME bot, those certificates would appear under unmanaged certificates.

Another CA certificates: certificates issued by another CA (Certificate Authority) would appear here.

44. Click the details button and explore the options available.

Image
Image


As seen in the image above, I can manage the certificate from the client dashboard, including manually renewing or revoking the certificate. Also, because the function app has an API, I could automate the process without having to access the dashboard directly.

Where is the certificate stored?

45. Finally, let’s check if the certificate is visible in Azure Key Vault.

  • I’ll access my Azure Key Vault, which was created as part of the deployment earlier.
  • Inside Key Vault, click certificates from the left pane
Image


46. You may receive the error below:

Error: The operation is not allowed by RBAC. If role assignments were recently changed, please wait several minutes for role assignments to become effective. 

Image


This permissions error indicates that my user accounts does not have the permissions to access certificates in Azure Key Vault. Let’s grant permissions by accessing Access control (IAM).

Image


For the purpose of this demo, I am granting my account the role, Key Vault Administrator.
Note: there are other lower privileged Key Vault roles available.

Image


47. Now that I have assigned my account permissions, let’s try that again.

The certificate is now visible to me in Azure Key Vault

Image


48. Click the certificate and you’ll see one version. Go back to your Azure function app and click the button to renew the certificate, you’ll find another version of the certificate will automatically appear in your Azure Key Vault. Any apps connecting to your certs will automatically start to use the new version of the certificate upon renewal.

Image
Image

And the Azure Key Vault now shows the new version of the certificate.

Image


49. Go ahead and request for a new certificate from within the Azure Function App dashboard. This time, I’ll input portal.cloudcrazy.co.uk and I’ll try a wild card of *.cloudcrazy.co.uk

Image


Image
Image
Image


Two additional certificates are now visible in Azure Key Vault as shown in the image below.

Image


I hope you found this demo useful.

Azure Traffic Manager 404 Web Site not found

Posted on by Imran Rashid
Reading Time: 2 minutes


A quick post about a problem I encountered after deploying an Azure Traffic Manager with three endpoints consisting of three websites running in Azure App Services. Initially, everything worked smoothly, but a few days after deployment, I started encountering an error.

When accessing the traffic manager url, I received the message below.

Message:
404 Web Site not found. You may be seeing this error due to one of the reasons listed below:
– Custom domain has not been configured inside Azure.
– Client cache is still pointing the domain to the old IP address. Clear the cache by running the command ipconfig/flushdns.

Image


Traffic manager also showed a monitor status of Degraded as shown in the image below

Image


However, I was able to access each app service url directly without an issue and the web page would load successfully. The above error only appeared when accessing the traffic manager url.

Resolution
I was originally using standard app service plans which support custom domains. My Azure App Service Plan had the traffic manager domain configured as shown in the image below.

Image


When investigating, I found that the error was due to my app service plans being downgraded to the shared tier, which does not allow the use of custom domains.

Image


Upgrading to a plan which allows custom domains resolved the issue.

A quick post, but I hope it’s of use to you.

How to access Azure Cloud Shell locally

Posted on by Imran Rashid
Reading Time: 3 minutes

In this short post, I will cover how to access Azure Cloud Shell locally from your Windows device. This will allow you to run Cloud Shell commands locally instead of using the Cloud Shell in the Azure portal.

Image


  1. Download Windows Terminal from the Windows store if not already installed on your device.

    Note:
    The Azure Cloud Shell is integrated into Windows Terminal and can be downloaded and installed on your laptop. Windows Terminal is available in all versions of Windows 11 and versions of Windows 10 22H2 after the installation of the May 23, 2023 update, KB5026435.

    If you don’t have access to the Microsoft Store or Windows Terminal is not already installed on your device, the builds are published on the GitHub releases page. However, if you download from GitHub, Windows Terminal will not automatically update with new versions. You will have to update it yourself when there is a new release.


  2. Search for and launch PowerShell from your start menu
Image


3. Click the arrow next to the + tab and click Azure Cloud Shell, as shown in the image below.

Image


4. Open a browser on your device, access https://microsoft.com/devicelogin and enter the code to authenticate

Image


5. Enter the unique code you were provided with and click Next.

Image


6. Enter your username, click Next, and then enter your password.

Image


7. You can now close the browser

Image


8. Return to Azure Cloud Shell and follow the instructions

Image


You’re connected to Azure Cloud Shell

Image


I hope this post helped

See you at the next one 🙂