Building a Microsoft BackOffice Server Solution on AWS with AWS CloudFormation

Last month, AWS released the AWS Enterprise Accelerator: Microsoft Servers on the AWS Cloud along with a deployment guide and CloudFormation template. This blog post will explain how to deploy complex Windows workloads and how AWS CloudFormation solves the problems related to server dependencies.

This AWS Enterprise Accelerator solution deploys the four most requested Microsoft servers ─ SQL Server, Exchange Server, Lync Server, and SharePoint Server ─ in a highly available, multi-AZ architecture on AWS. It includes Active Directory Domain Services as the foundation. By following the steps in the solution, you can take advantage of the email, collaboration, communications, and directory features provided by these servers on the AWS IaaS platform.  

There are a number of dependencies between the servers in this solution, including:

• Active Directory
• Internet access
• Dependencies within server clusters, such as needing to create the first server instance before adding additional servers to the cluster.
• Dependencies on AWS infrastructure, such as sharing a common VPC, NAT gateway, Internet gateway, DNS, routes, and so on.

The infrastructure and servers are built in three logical layers. The Master template orchestrates the stack builds with one stack per Microsoft server and manages inter-stack dependencies. Each of the CloudFormation stacks uses PowerShell to stand up the Microsoft servers at the OS level. Before it configures the OS, CloudFormation configures the AWS infrastructure required by each Windows server. Together, CloudFormation and PowerShell create a quick, repeatable deployment pattern for the servers. The solution supports 10,000 users. Its modularity at both the infrastructure and application level enables larger user counts.

Managing Stack Dependencies

To explain how we enabled the dependencies between the stacks, the SQLStack is dependent on ADStack since SQL Server is dependent on Active Directory; and, similarly, SharePointStack is dependent on SQLStack, both as required by Microsoft. Lync is dependendent on Exchange since both servers must extend the AD schema independently. In Master, these server dependencies are coded in CloudFormation as follows:

“Resources“: {
       “ADStack“: …AWS::CloudFormation::Stack…
       “SQLStack“: {
             “Type“: “AWS::CloudFormation::Stack“,
             “DependsOn“: “ADStack“,
             “Properties“: …
       }
and
“Resources“: {
       “ADStack“: …AWS::CloudFormation::Stack…
       “SQLStack“: {
             “Type“: “AWS::CloudFormation::Stack“,
             “DependsOn“: “ADStack“,
             “Properties“: …
       },
       “SharePointStack“: {
            “Type“: “AWS::CloudFormation::Stack“,
            “DependsOn“: “SQLStack“,
            “Properties“: …
       }

The “DependsOn” statements in the stack definitions forces the order of stack execution to match the diagram. Lower layers are executed and successfully completed before the upper layers. If you do not use “DependsOn”, CloudFormation will execute your stacks in parallel. An example of parallel execution is what happens after ADStack returns SUCCESS. The two higher-level stacks, SQLStack and ExchangeStack, are executed in parallel at the next level (layer 2).  SharePoint and Lync are executed in parallel at layer 3. The arrows in the diagram indicate stack dependencies.

Passing Parameters Between Stacks

If you have concerns about how to pass infrastructure parameters between the stack layers, let’s use an example in which we want to pass the same VPCCIDR to all of the stacks in the solution. VPCCIDR is defined as a parameter in Master as follows:

“VPCCIDR“: {
            “AllowedPattern“: “[a-zA-Z0-9]+\..+“,
            “Default“: “10.0.0.0/16“,
            “Description“: “CIDR Block for the VPC“,
            “Type“: “String“
           }

By defining VPCCIDR in Master and soliciting user input for this value, this value is then passed to ADStack by the use of an identically named and typed parameter between Master and the stack being called.

“VPCCIDR“: {
            “Description“: “CIDR Block for the VPC“,
            “Type“: “String“,
            “Default“: “10.0.0.0/16“,
            “AllowedPattern“: “[a-zA-Z0-9]+\..+“
           }

After Master defines VPCCIDR, ADStack can use “Ref”: “VPCCIDR” in any resource (such as the security group, DomainController1SG) that needs the VPC CIDR range of the first domain controller. Instead of passing commonly-named parameters between stacks, another option is to pass outputs from one stack as inputs to the next. For example, if you want to pass VPCID between two stacks, you could accomplish this as follows. Create an output like VPCID in the first stack:

“Outputs”  : {
               “VPCID” : {
                          “Value” : “ {“Ref” : “VPC”},
                          “Description” : “VPC ID”
               }, …
}

In the second stack, create a parameter with the same name and type:

“Parameters” : {
               “VPCID” : {
                          “Type” : “AWS::EC2::VPC::Id”,
               }, …
}

When the first template calls the second template, VPCID is passed as an output of the first template to become an input (parameter) to the second.

Managing Dependencies Between Resources Inside a Stack

All of the dependencies so far have been between stacks. Another type of dependency is one between resources within a stack. In the Microsoft servers case, an example of an intra-stack dependency is the need to create the first domain controller, DC1, before creating the second domain controller, DC2.

DC1, like many cluster servers, must be fully created first so that it can replicate common state (domain objects) to DC2.  In the case of the Microsoft servers in this solution, all of the servers require that a single server (such as DC1 or Exch1) must be fully created to define the cluster or farm configuration used on subsequent servers.

Here’s another intra-stack dependency example: The Microsoft servers must fully configure the Microsoft software on the Amazon EC2 instances before those instances can be used. So there is a dependency on software completion within the stack after successful creation of the instance, before the rest of stack execution (such as deploying subsequent servers) can continue. These intra-stack dependencies like “software is fully installed” are managed through the use of wait conditions. Wait conditions are CloudFormation resources just like EC2 instances and allow the “DependsOn” attribute mentioned earlier to manage dependencies inside a stack. For example, to pause the creation of DC2 until DC1 is complete, we configured the following “DependsOn” attribute using a wait condition. See (1) in the following diagram:

“DomainController1“: {
            “Type“: “AWS::EC2::Instance”,
            “DependsOn“: “NATGateway1”,
            “Metadata“: {
                “AWS::CloudFormation::Init”: {
                    “configSets“: {
                        “config“: [
                            “setup“,
                            “rename“,
                            “installADDS“,
                            “configureSites“,
                            “installADCS“,
                            “finalize“
                        ]
                    }, …
             },
             “Properties” : …
},
“DomainController2“: {
             “Type“: “AWS::EC2::Instance“,
[1]          “DependsOn“: “DomainController1WaitCondition“,
             “Metadata“: …,
             “Properties” : …
},

The WaitCondition (2) uses on a CloudFormation resource called a WaitConditionHandle (3), which receives a SUCCESS or FAILURE signal from the creation of the first domain controller:

“DomainController1WaitCondition“: {
            “Type“: “AWS::CloudFormation::WaitCondition“,
            “DependsOn“: “DomainController1“,
            “Properties“: {
                “Handle“: {
[2]                    “Ref“: “DomainController1WaitHandle“
                },
                “Timeout“: “3600“
            }
     },
     “DomainController1WaitHandle“: {
[3]            “Type“: “AWS::CloudFormation::WaitConditionHandle“
     }

SUCCESS is signaled in (4) by cfn-signal.exe –exit-code 0 during the “finalize” step of DC1, which enables CloudFormation to execute DC2 as an EC2 resource via the wait condition.

                “finalize“: {
                       “commands“: {
                           “a-signal-success“: {
                               “command“: {
                                   “Fn::Join“: [
                                       “”,
                                       [
[4]                                            “cfn-signal.exe -e 0 “”,
                                           {
                                               “Ref“: “DomainController1WaitHandle“

                                            },
                                           “””
                                       ]
                                   ]
                               }
                           }
                       }
                   }
               }

If the timeout had been reached in step (2), this would have automatically signaled a FAILURE and stopped stack execution of ADStack and the Master stack.

As we have seen in this blog post, you can create both nested stacks and nested dependencies and can pass parameters between stacks by passing standard parameters or by passing outputs. Inside a stack, you can configure resources that are dependent on other resources through the use of wait conditions and the cfn-signal infrastructure. The AWS Enterprise Accelerator solution uses both techniques to deploy multiple Microsoft servers in a single VPC for a Microsoft BackOffice solution on AWS.  

In a future blog post, we will illustrate how PowerShell can be used to bootstrap and configure Windows instances with downloaded cmdlets, all integrated into CloudFormation stacks.