Home / server / Questions / 766644
Accepted
emmdee
Asked: 2016-03-29 21:54:31 +0800 CST

AWS EC2 - Clone Windows Server Machines That Are Domain Joined

  • 772

Firstly, I am using these as a base guide: http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ami-create-standard.html http://reduktor.net/2014/09/autoscale-ec2-instances-ad-aws/

Secondly, our region doesn't support the AWS directory service

Scenario

I am looking to create a "base AMI" for a set of application servers we have. I may need to deploy 1 or more new servers based off of this image.

The instances are originially created from EC2 Windows Server 2008 R2 Datacenter base AMI (Created by Amazon)

The applications themselves are static, licensing is completely redistributable, and the config doesn't need to change on one machine vs another.

The ONLY thing that is different from one machine to the other is the hostname and network config. Network config is handled by EC2, so the hostname is really the only thing that needs to change from once instance to another

The machines are part of Active Directory, and have specific OU Group Policy rules applied to the machines. They will all join the same OU.

Goal:

My goal is to have a base AMI. When this AMI is launched it auto-joins the domain OR is already joined to the domain.

The applications that are ran from the machine REQUIRE domain accounts to run the Windows Services. So I can't have an image that's not joined to the domain.

An idea I had (Will test this tomorrow):

  • Create a default/generic hostname "server-xy", join the domain and create my AMI. Power down the source VM then deploy from AMI. Once it boots, rename it to its final hostname "server-02". Then deploy another from AMI, rename it, rinse and repeat -- sound viable? EDIT: this didn't work since renaming it invalidates the original hostname at the domain level. Seems like what I would like to do might not be feasible.
active-directory

2 Answers

  1. I'm a noob at AWS, but in lieu of any other answer, this is what I'd try.

    1. Set up your Instance as a golden image using a modest instance size.
    2. Give it a hostname of server-image in workgroup images or something obvious.
    3. Install all the applications you need, patch it, install whatever utils you like (treesize, VNC, notepad++, winVI, wingrep, etc) and create any drive shares. Specifically do NOT join the AD domain.

    4. Shut down this machine and create an AMI from it.

    5. Then create instances from that AMI. You could look at a reserved instance which is cheaper, or if your workload is such that servers can happily come and go you might want to explore spot instances.

    6. (this is the bit I'm vague on the windows front) It is possible to do "stuff" automatically when creating a new instance from an AMI. We use a CLI command run on a linux "controller" instance which is always on. For Example:

    ./instance-new.py -a "ami-abc123xyz" -c "servers" -n "server-42" -t "t3.16xlarge"

    • -a is the AMI name you want to source from
    • -c is the billing category
    • -n is the hostname of the new machine
    • -t is the instance size
    • there are heaps more command line options.

    I can't share our customised version here, but the original came from http://docs.aws.amazon.com/cli/latest/reference/opsworks/create-instance.html

    Ours has additional stanzas like this for linux machines to get salt and then update from the salt-master:

    userdata = """#!/bin/bash /usr/bin/yum install -y https://repo.saltstack.com/yum/redhat/salt-repo-latest-2.el7.noarch.rpm /usr/bin/yum install -y salt-minion hostnamectl set-hostname %s hostname > /etc/salt/minion_id systemctl start salt-minion sleep 5 /bin/salt-call state.highstate /bin/salt-call state.highstate /usr/bin/yum update -y """ % args.hostname

    There's got to be some windowsy/AD way to join a domain from a script.

    This script also sets up monitoring and other things.

    Separately if you use automated tear-down then you will need some kind of script to run to leave the AD and clean up the old account before deleting the instance.

    When your servers are getting a bit old, or there are critical windows patches, then boot your golden image and apply all the updates/upgrades. Then stop it and create a new AMI. Point your creation script at the new AMI and once you're happy it works, delete the old AMI to save storage costs. There's good reason to keep at least one previous golden image AMI floating about as a known good backup - we keep two.

    • 0
  2. Best Answer

    As a general rule for a domain joined Windows machine, you shouldn't clone it as is. You should remove it from the domain and use sysprep. Then you can use this as a template/base AMI. Each new clone will be joined using a new SID, name, IP to the domain, making a new computer account in the AD.

    • 0