Your Active Directory Pre-production environment: Restore from Backup or Deploy as Code?

Active Directory

Active Directory Domain Services act as the cornerstone of every on-premises Microsoft-oriented networking infrastructure. It is important to get things right when it comes to your Domain Controllers, user objects and access controls.

An obvious solution to getting things right the first time is offering one or more pre-production environments to develop and test scripts,

I see two main strategies to creating pre-production environments for Active Directory Domain Services:

  1. Create an environment from backup
  2. Deploy an environment following the Infrastructure as Code (IaC) principles

Each strategy has its own strengths and weaknesses (in the short term). They also face vastly different opportunities and threats (in the long term).

Choosing the right strategy is important to reach the goals set out for the pre-production environment. Below, I provide an overview of each strategy. I also analyse the strengths, weaknesses, opportunities and threats through SWOT analyses.

Restore from Backup

In this strategy, you create a pre-production environment for Development, Test and/or Acceptance (OTA) purposes by restoring a backup of all relevant systems, services and applications in a separate networking environment.

When you’re using VMware vSphere and Veeam Backup & Replication, you can easily achieve this through the SureBackup feature in Veeam. Veeam and other backup vendors also offers solutions for environments using other hypervisors and for physical servers, but these solutions aren’t as streamlined as SureBackup.

Strengths

This strategy possesses the following strengths (in the short term):

  • The pre-production 100% represents the production environment.
  • The pre-production environment can be used to test and/or automate administrative actions and scripts before implementation in production.
  • Creating the on-premises components of an Active Directory implementation is completely automatable with solutions like Veeam’s SureBackup.

Weaknesses

This strategy exhibits the following weaknesses (in the short term):

  • The pre-production environment is 100% identical to the production environment in terms of DNS domain name, etc. This could lead to confusion around changes; people might think they are making changes in pre-production, but actually making them in production as the two environments cannot be adequately distinguished.
  • The pre-production may not be GDPR/CPAA compliant when working with an outside vendor, as all the production data for employees is available in the pre-production environment.
  • All changes in the production environment need to be repeated in the pre-production environment to keep both environments in sync and keep the pre-production environment 100% representative.
  • Pre-production environments need to absolutely be separated from the production environment.

Opportunities

This strategy offers the following opportunities (in the long term):

  • Every time a pre-production environment is created, restore from backups is tested.

Threats

This strategy faces the following threats (in the long term):

  • The period of time in which a pre-production environment needs to be available after creation dictates the cost level of the pre-production environment. Complexity, administrative repeat actions all add up.

Infrastructure as Code

In this strategy, you create a pre-production environment for Development, Test and/or Acceptance (OTA) purposes by deploying a relevant networking infrastructure from scratch, defining each aspect of the environment through code.

As every aspect, including the DNS domain name for the Active Directory forest can be defined, you need not separate the pro-production environment from the production environment. It helps, but is not necessary.

When you’re using Azure Infrastructure as a Service (IaaS) to host your pre-production environment(s), you can use ARM templates and Azure DevOps pipelines to set things up, so that when there’s a need for a pre-production environment, you can deploy one with a single click.

Strengths

This strategy possesses the following strengths (in the short term):

  • A pre-production Active Directory environment with multiple Domain Controllers and member servers can be deployed in as little as 45 minutes.
  • Pre-production environments can be deployed using test-specific values, including the DNS domain name to test all sorts of scenarios.
  • Pre-production environments can be deployed with a test-specific population. This way, pre-production environments can be GDPR/CPAA compliant. Temporary insecure settings for the pre-production environment would not necessarily lead to a data leak that is traceable to the organization or affect the people in the organization.
  • Pre-production environments don’t lead to running costs. A pre-production environment can be torn down when it is no longer needed and redeployed when it’s needed again.

Weaknesses

This strategy exhibits the following weaknesses (in the short term):

  • Pre-production environments are not identical or representative for production environments.
  • Not all Hybrid Identity components can be deployed as code. Azure AD Connect and GPOs are notorious components to automate.

Opportunities

This strategy offers the following opportunities (in the long term):

  • Using the right Infrastructure as Code solution means you can deploy wherever you want to deploy. Solutions like Terraform allow you to deploy to Microsoft Azure, Amazon AWS and VMware vSphere platforms.
  • Active Directory pre-production environments can be set up per vendor. This way, an organization can provide an environment to correspond with the vendor’s release process, whether its staging/production or develop/test/accept/production.

Threats

This strategy faces the following threats (in the long term):

  • The Infrastructure as Code pipeline requires maintenance.

Concluding

Restore from Backup and  Infrastructure as Code are both valid strategies to create Active Directory pre-production environments. However, depending on the goal of the pre-production environment, following one strategy works better than following the other.

Infrastructure as Code is typically the better strategy for development and test goals, where restoring from backup is typically better to meet Acceptance goals.

Whichever strategy you choose is OK. It’s better than having only a production test environment…

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.