--- Sjoerd Hooft's InFormation Technology ---

User Tools

Site Tools



Would you like to sponsor this site?
Or buy me a beer?:

Recently Changed Pages:

View All Pages
View All Q Pages

View All Tags

Sign up for Q to post comments.

WIKI Disclaimer: As with most other things on the Internet, the content on this wiki is not supported. It was contributed by me and is published “as is”. It has worked for me, and might work for you.
Also note that any view or statement expressed anywhere on this site are strictly mine and not the opinions or views of my employer.

Terms And Conditions for Q users

Pages with comments

2019/03/15 16:02 1 Comment
2019/03/15 16:02 1 Comment
2019/03/15 16:02 3 Comments
2017/04/20 16:35 1 Comment
2017/04/20 15:28 1 Comment
2017/04/20 15:23 1 Comment
2017/04/19 14:44 1 Comment
2017/04/17 20:10 1 Comment
2017/04/17 20:07 1 Comment
2017/04/17 19:58 1 Comment
2017/04/17 19:52 1 Comment

View All Comments


Test Environment Setup

This page is intended to provide a standardized test environment for GetShifting. Due to budget constraints we do not have an official test network based on linked clones or comparable technologies. However, we need a solution for all test environment request. We need to solve both our and business demands in this matter. These demands include (but are not limited to):

  • A test environment that resembles the acceptance or production environment
  • Ability to access the test environment from standard GetShifting desktop
  • Ability to work with elevated privileges inside the test environment
  • Ability to move data from and to the test environment
  • Ability to load ISOs inside the test servers
  • Ability to reboot the test servers if needed
  • Ability to have multiple test environment that can easily be distinguished from each other
  • Ability to monitor the number of test environments
  • Ability to cleanup (remove) test environments without interrupting other test environments

Overview of required information and pre-work:

Required Remarks
Datastore Create a datastore in the development cluster with TST as shortname, for example TestDatastore01. Make sure this one is big enough for all VMs.
Datastore Size dcserver01: 45 GB<br>rna-PXX-XXX: 45 GB<br>Note: make sure all VMs and the datastore are thin provisioned
IP addresses rna-PXX-XXX: * Development network IP address: 10.33.x.x, add this IP address in the TCPIP database * Test network IP address: 10.10.x.x (For example, this IP address should NOT be added to the TCPIP database * dcserver01: (use this address as the DNS server on all servers in the test setup)
VM Folder Create a VM Folder called after the project in the vSphere VMs and Templates view
usr accounts You need the usr accounts of the users who will access the environment.
Admin accounts The admin accounts that will be used in the test. They will get domain and DBA admin permissions in the cloned production domain.

Overview of Test Environments

Overview Explanation

A test environment always exists of a RNA server (Remote Network Administration), a standalone virtual switch and cloned virtual servers. The RNA server can be cloned from an existing one and is not member of an Active Directory domain. It is connected to the development network and to the standalone virtual switch, which, in its turn is connected to the cloned virtual servers.

Note that all VMs for a single test environment need to be on one vSphere host. This is because the vSwitch is only available on one host at the same time.

Creating the Test Environment

To create a test environment you need to have the following information available:

  • Projectcode: This should be a P or a L code, for example P14-001 or L14-001.
  • Which admin accounts need access

Creating the RNA Server

The RNA server can be cloned from an existing one. If there is a requirement that more than 2 colleagues would be able to work at the test environment at the same time remote desktop services should be installed. This is a standard role in Windows Server 2012 and can be installed and used without license for 120 days. If a longer period is required licenses should be purchased. The server and the VM name should be as displayed above:

  • RNA-ProjectCode (For example RNA-P14-001) Also, you should modify the following settings:
  • Workgroup: ProjectCode
  • Add the computer and the local administrator password to keepass
  • Enable Remote Desktop on the server
  • Set the NIC in the Development network in the correct virtual port group: SFT0-VLAN33

Creating the Standalone Virtual Switch

In vCenter go to a host in the Development cluster and proceed to the Configuration tab. Click on the Networking option and click on “Add Networking…” to create a new virtual switch. Follow the “Add Network Wizard”:

  • Connection Type: Virtual Machine
  • Select the “Create a vSphere standard switch” option but deselect any network adapter. The switch should have no physical adapters in its configuration.
  • Network Label: Projectcode (For example P14-001)
  • Leave the VLAN ID at it's default (0)
  • Check the settings and close the wizard.

> Note that the vSwitch is automatically named. This cannot be changed.

Cloning the Virtual Servers

There are three ways to clone the servers you need. The first way is the most convenient for all parties involved but is not always possible for all servers you need. You can use it always for the domain controller dcserver01 which is included in the first Recovery Plan. The idea is to do a test failover for the Virtual Servers you need and clone them from the recovery site. This requires no down time and since the recovery site is also in The Hague you don't need to copy the Virtual Servers over the WAN connection.

The second and third way are in case you need to add servers to the test environment that are not part of the protected VMs in Site Recovery Manager. In case you need servers that can be turned off for a few hours you can export them to an OVF template. If that's not possible you'll need to clone them first.

From Site Recovery Manager

In vCenter, go to Home, Solutions and then Site Recovery. Logon with your admin account and go to Recovery Plans. Select the recovery plan your required VMs are part of and click on “Test” to start a failover test. In case you only need the dcserver01 you'll notice there is a Prompt right after the domain controllers. You don't need to proceed after here. Simply navigate to the recovered VM in the BCP cluster and clone the VM to the development cluster while renaming the VM:

  • Projectcode-VMname (For example P14-001-dcserver01)

> NOte: Don't forget to cancel and cleanup the recovery plans you tested.

Without Downtime

If you cannot turn the required VMs in acceptance or production off you can first clone them. That can be done while the VMs are still online. To clone a VM select it, rightclick and select “Clone…” from the menu. Now follow the wizard while renaming the VM. Because you need to clean the clone up anyway the name is not that important. After cloning you can proceed with the procedure below.

With Downtime

After cloning or turning off the VMs you can export them to an OVF template. To do this select the VM and go to File → Export → Export OVF Template. Now you only need to think of where to place the OVF template. If you turned the VMs off and time is important, export them to a location in CyberCenter, so copying over the WAN connection can be done later. You can also export them to WAN connection immediately, this will take more time which means more downtime.

After exporting them to an OVF Template you can import them again at the The Hague vCenter site. In vCenter, go to File → Deploy OVF Template. Now a wizard starts, and you can import the VMs in the Development cluster while renaming the VM:

  • Projectcode-VMname (For example P14-001-dbserver01)
  • Place them in the appropriate folder
  • Place them in the Development resource pool
  • Make sure the VM is thin provisioned
  • If you already created the virtual network you can map the network right away to the one you created.

Network Configuration

Now make sure all VMs (including the RNA server) are connected to the standalone vSwitch you created. To do so, select the VM and click on Edit Settings. Go to the Network Adapter in the hardware tab and select the created Network label.

Now you should be able to log on through the console on the dcserver01 with your Domain Admin account and ping all servers in the testnetwork you created.

Configuring Access

Use RNA Server as File Share

In the vSphere client add an extra disk to the RNA server. Then logon the RNA Server and create an anonymous share that allows for writing on the disk. Writing to and from the RNA servers from your workplace can then be done using the RDP client, and the share can be used from the test environment.

Access the RNA Server

Now you need to create local accounts on the RNA server. Note that without Remote Desktop Services it's not possible to logon with more than 2 at the same time, so create two users, give them an easy password which is allowed to change but not required. Make sure you write down the password so it can be sent to the users.

Configuring Elevated Privileges

Add the admin accounts to the Domain Admins group and to the DBA-Admins on the cloned P12-013-dcserver01 server. Make sure you're on the cloned server, this should never be done on production.

Setting Up Access Through vCenter

If the admins working with the environment need special privileges like mounting ISOs and rebooting the VMs in case of freezes (so through the vSphere console) they need access to the vSphere client. That's two steps, first they need access to the client, and then they need access to the environment.

Accessing the vSphere Client

The vSphere Client can be installed on the users desktop or on a different management server. You should instruct inexperienced users on to which vCenter they should connect.

Access the Virtual Servers

To allow access to only the virtual servers in the created test environment, go to the “VMs and Templates” view in the vSphere client. Select the Folder you created for the project and click on the “Permissions” tab. You can rightclick anywhere on the whitespace and select “Add Permissions”. You can add the admin accounts from the PRD domain and assign them the default “Virtual Machine user (sample)” role.


Even though it's a testenvironment you need to make sure the servers are listed in:

  • CMDB
  • TCPIP database for the RNA server

Communicating How It Works


I configured the Application test environment for the Application project. It is an exact copy of acceptance/production and is therefore in an isolated network. The following servers are part of this test environment:

	* dcserver01 (domain controller)
	* dbserver01
	* appserver01
	* appserver02

These servers are only accessible by a gateway server with the IP address, which can be accessed using the "Remote Desktop Test server" application in your start menu. You can logon on this server using these two accounts:

	* usrtst01 - Welkom01!
	* usrtst02 - Welkom01!

If required, more users can be created but there can be only two simultaneous logons. From this server a RDP connection can be started to the servers mentioned above. 

The following accounts haven been added to the domain admins and the DBA administrators group in the test environment:

	* adminsjoerd
	* adminjelmer

Note that these accounts have their originals passwords set as they were about two weeks ago. 

To copy data to this environment please use the share on the RNA server. You can use Remote Desktop to copy data from the gateway server to the servers mentioned above. 

If you have any question, please let me know. 
You could leave a comment if you were logged in.
testenvironmentsetup.txt · Last modified: 2014/09/22 21:50 by sjoerd