Monthly Archives: July 2014

For the most part I love SRM for providing a relatively simple way to back up and recover our  VMware environment.  The problem that I have with SRM is that when it comes to testing failover, what do you do with your domain controllers?  According to VMware’s documentation found here, you should never use SRM to backup your domain controllers because you should already be using Active Directory replication to handle recovery situations.

When testing in the past I have added the DCs to my test recovery plan.  The problem was that most of the time the cloned DCs (in a test bubble) took forever to come up, and because of this, testing would take way longer than it should.  What is the solution?

The solution I have developed is to use scheduled powercli task that will clone my primary DC on a daily basis, change the network port group to a test bubble, and then power it on.  Doing this gives me a domain controller in my test bubble that should be ready to use whenever I want to test SRM.  I am still deciding whether or not I need to power down the primary DC first before cloning.  For now, I am cloning live.  I have a feeling I will hear from you guys on this one…:)

Preparation:

1.  The first thing I have is an old physical desktop to run my scripts.  You could run your scripts through a VM, however, I will be running my UPS Emergency shutdown script through this machine as well.

2.  I created a service account in AD that has very specific rights within vCenter.  Give this AD account admin rights on the physical machine that you will run your scripts from.

3.  Install PowerCLI on the machine using the AD account you created earlier.  Some good installation instructions can be found here.  Make sure that your set the execution policy to remotesigned.  While you still have PowerCLI open, add the credentials of the AD account to the PowerCLI credential store.  Information on this can be found here.  In our example in PowerCLI you would type New-VICredentialStoreItem -Host <vcenter server name/ip> -User <AD Script Account> -Password <Password for the script account>.  This will store the credentials within the user profile directory and it is encrypted!  This way there is no username and password in clear text going over the wire.  Note that if you try to test the script right now it will not work because there are no rights for the account in vCenter.

4.  I am going to be good and use the Web VIC to configure the permissions, sometimes I feel like this though…

Now that I have gotten that out of my system, log into the Web VIC as an administrator and click Administration –> Roles.  Click  to create a new role.  Name this role something like “clone” or cloneandchangenetwork”.  Check the following boxes:

Datastore –> Allocate Space
Network –> Assign Network
Network –> Configure
Resource –> Assign Virtual Machine to Resource Pool
Virtual Machine –> Configuration –> Add New Disk
Virtual Machine –> Configuration –> Add or Remove Device
Virtual Machine –> Configuration –> Modify Device Settings
Virtual Machine –> Interaction –> Power On
Virtual Machine –> Interaction –> Power Off
Virtual Machine –> Inventory –> Create from existing
Virtual Machine –> Inventory –> Create New
Virtual Machine –> Inventory –> Register
Virtual Machine –> Inventory –> Remove
Virtual Machine –> Provisioning –> Clone Virtual Machine

Now that our role was created, we need to assign it to the locations that we want this role to have rights.  To keep this simple, but not very secure, you could assign the role to the vCenter Server level.  The rights will propagate down the entire tree across any datacenters that you might set up.  Most people don’t want this because it would allow the cloning of any server, so we are going to assign rights exactly where they need to go.  But first we need to create a new folder where our cloned VM will eventually live.

Folder Rights
Click Home –> VMs and Templates.  Using the arrows, expand the list on the left pane.  Right click Discovered virtual machine –> New Folder and then name your new folder something like DCClone.  Click Manage –> Permissions.  Click  and then from the drop down menu select the role that you created earlier and then click Add.  Choose your domain from the Domain drop down and then find the user that we created earlier in the list.  Click OK.  You should now see the AD user and the assigned role.  Now uncheck the Propagate to children box and then Click OK.

Cluster Rights
Click Home –>  Hosts and Clusters.  Then click on the Cluster where the DC resides that you will be cloning.  Click Manage –> Permissions.  Click  and then from the drop down menu select the role that you created earlier and then click Add.  Choose your domain from the Domain drop down and then find the user that we created earlier in the list.  Click OK.  You should now see the AD user and the assigned role.  Now uncheck the Propagate to children box and then Click OK.  This keeps the script account from having rights down the tree.

DC Rights
Click Home –>  Hosts and Clusters.  Then click on the DC that needs to be cloned.  Click Manage –> Permissions.  Click  and then from the drop down menu select the role that you created earlier and then click Add.  Choose your domain from the Domain drop down and then find the user that we created earlier in the list.  Click OK.  You should now see the AD user and the assigned role.  Click OK.

Datastore Rights
Now we need to set the role for the host that will house the cloned VM.  Click Home –> Storage, and then on the left hand side click the datastore that the will be home to the clone.  Click the Manage –> Permissions.  Click  and then from the drop down menu select the role that you created earlier and then click Add.  Choose your domain from the Domain drop down and then find the user that we created earlier in the list.  Click OK.  You should now see the AD user and the assigned role.  Click OK.

Host Rights
Now we need to set the role for the host that we are going to clone to.  Click the Home –>  Hosts and Clusters, and then on the left hand pane click the host  that the will be home to the clone.  Click the Manage –> Permissions.  Click  and then from the drop down menu select the role that you created earlier and then click Add.  Choose your domain from the Domain drop down and then find the user that we created earlier in the list.  Click OK.  You should now see the AD user and the assigned role.  Now uncheck the Propagate to children box and then Click OK.  This keeps the script account from having rights down the host.

Network Rights
Finally, we are going to set the role for the network.  Click Home –> Networking.  On the left pane select the test network that  you have in your environment.  Mine is called Test Bubble.  Click the Manage –> Permissions.  Click  and then from the drop down menu select the role that you created earlier and then click Add.  Choose your domain from the Domain drop down and then find the user that we created earlier in the list.  Click OK.  You should now see the AD user and the assigned role.  Click OK.

By the time you are done, your script service account should have rights in vCenter for the Cluster (no propagate), host where the clone will live (no propagate), the Datastore, Network, Folder, and DC that will be cloned.

WAY TO GO!!  Are you ready for part 2?