Monday, 26 April 2010

Windows Server 2003 Active Directory Domain Rename

Scenario: I have a single Windows Server 2003 Domain Controller with a domain DCTEST.PRIV, and I want to rename this DC.PRIV. I have a Windows Server 2003 Member Server that I can use as the control station for performing the domain rename process.


1: Google “Windows Server 2003 Active Directory Domain Rename Tools” and download domainrename.exe onto your member server. Double-click the exe → Run → Welcome to the Domain Rename Tools Version 1.4 Setup Wizard – Next > → I Agree → Finish

2: In Active Directory Domains and Trusts (domain.msc,) Raise Domain Functional Level to Windows Server 2003 (if not already,) Raise Forest Functional Level to Windows Server 2003 (if not already.)

3: On the control station, switch to the RenameTools directory ( C:\Program Files\Microsoft Domain Rename Tools ,) and type the following command: rendom /list

4: Enter copy domainlist.xml domainlist-save.xml to save the forest description file

5: Modify domainlist.xml changing entries for the existing domain name to the new domain name, and save the changes

6: Type the following command: rendom /upload

7: Type the following command: rendom /prepare

8: Type the following command: rendom /execute

After you run the execute command, your domain controllers, member servers, client computers, will all automatically reboot and when they are back up they will be on the changed domain name << very cool >>

9: Reboot the control station twice

10: On the control station, switch to the RenameTools directory, and type the following command: rendom /end

11: (Update courtesy of HaPi) Run "gpfixup.exe /olddns:DCTEST.PRIV /newdns:DC.PRIV" to update Group Policy Objects.

And that is it!


Author: V. Cosonok


My walkthrough is very simplistic – from simple beginnings complex things are built. For much more detail I would highly recommend reading . Below are a few essential notes:

The Requirements and Consequences of Domain Renaming

Before you can use Rendom.exe to perform any domain renaming tasks, you have to ensure the following:

The domain controllers must be running Windows Server 2003
The forest functional level must be raised to the Windows Server 2003 forest functional level.
You need Enterprise Administrator privileges to perform any domain renaming tasks.
You have to use a member server to carry out domain renaming tasks - you cannot use a domain controller. The member server becomes your control station for performing the domain rename process.
Domain DFS root servers must be running Windows 2000 - SP3 or above
Exchange 2000 must not be installed in the domain.

A few factors on the domain rename process should be kept in mind.

These are noted below:

The entire forest is unavailable during the domain rename process.
If a domain controller(s) cannot be reached, or does not participate in, or finish the domain rename process, you have to remove the domain controller from the forest in order for the process to be finalized.
Because some changes are not replicated, and external trust relationships no longer exists, you would have to examine each one of your domain controllers.
The DNS host names of the domain controllers are not automatically changed by the Active Directory domain rename feature. This creates the need for you to carry out the domain controller rename process on your domain controllers individually.
Although the DNS suffix of your member servers and client workstations will be updated, it might not be instantaneously.
Once the domain controllers are rebooted, each client workstation running Windows 2000 or Windows XP has to be rebooted twice.

Sunday, 18 April 2010

Migrating a virtual machine from one standalone ESX host's local storage to another standalone ESX host's local storage


Two standalone ESX Hosts – say ESX1 and ESX2
Both hosts use local storage and there is no shared storage and no option for this provision
There is network connectivity between the hosts

Question: How to move a VM from ESX1 to ESX2 other?

Some possible solutions:

1: Download from local datastore of ESX1 using WinSCP (or similar,) or the VI/vSphere Client, and upload to ESX2 using the same method
2: Use VMware converter to V2V the virtual machine
3: Linux route – via the service console, configure the local storage on ESX2 to allow mounting to ESX1, configure the ESX firewall on both ESX1 and ESX2 to allow local datastore to local datastore transfer, mount ESX2's local datastore to ESX1 and do a mv (move)

The above were put in order of most simple to most difficult to achieve. The problem with option 1 is that there is a download process followed by an upload process, so the move would take at least twice as long as doing a straight move. So onto solution 2 as the preferred solution, and this is pretty simple to achive too. Below is a walkthrough of how to do this.
I choose a cold clone as being the better option since no need to install extra software on the VM to be moved.

Walkthrough – Using VMware converter to V2V from one standalone ESX host local storage to another ESX host local storage

1: Download the VMware-convertercd from VMware
2: Mount coldclone.iso in the virtual CD drive of the VM to be moved
3: Configure the Boot Options of the VM to 'Boot to BIOS' so it can be configured to boot from CD-ROM
4: Reboot the VM, configure the BIOS to boot from CD-ROM, and boot into coldclone.iso (will prompt for press any key to boot from CD)
5: VMware vCenter Converter will run through 4 actions, wait for these to complete, then accept the License Agreement and click OK

6: Would you like to update network parameters at this time? No

7: When the VMware vCenter Converter window loads, select 'Import Machine'

Import Wizard

8: Welcome to vCenter Converter Import Wizard > Click Next
9: Step 1: Choose a source for import > Click Next
     Choose the disks to import and specify their size > Click Next

10: Step 2: Choose a destination for the new virtual machine > Click Next
     Select the destination type: vSphere Virtual Machine > Click Next

     ESX or vCenter Server Login – enter relevant details > Click Next

     Virtual Machine name: <> > Click Next
     Select host or resource pool > Click Next
     Choose a datastore > Click Next
     Choose number of NICs and the network > Click Next

11: Step 3: Customization – leave checkboxes unticked > Click Next

12: Ready to Complete > Click Finish

And wait for the job to complete

Note: VMware Converter requires at least 264MB Memory in order to run

Author: V. Cosonok

Sunday, 11 April 2010

Microsoft Hyper-V R2 – why use it over VMware?

Answer = perceived cost savings (see below for pricing comparison and caveats)

Below is a brief article on why one would use Hyper-V over VMware. The general consensus in the IT industry (even from Microsoft themselves) is that VMware’s vSphere is the superior product over Hyper-V. Microsoft are playing catch up. The only reason to go for a Hyper-V solution is cost savings (also, the hope that in three or four years Microsoft may have a comparable product.)

Note: From now on I will just write Hyper-V meaning Hyper-V R2.


To start off; I'd highly recommend reading 9 Reasons Enterprises Shouldn’t Switch To Hyper-V by Elias Khnaser

Elias lists – poor breadth of OS support (just Windows and SuSE Linux,) no memory overcommit (something Microsoft are now working on, without it you can forget implementing VDI in a Hyper-V environment,) reduced security, can only live migrate one machine at a time, no VM priority restart in the event of a host failover, no fault tolerance, hot adds (hot addition of disks is possible in Hyper-V,) lack of support for 3rd party tools, and immaturity of the product.

And I'll add three more:

1: Snapshots

Snapshots in Hyper-V can only be committed by shutting down the VM.

Yes, you read that correctly. One of the best features of virtualization (at least VMware virtualization,) is the ability to take a snapshot, make a change, and if it works then delete the snapshot, or if not then roll back. A big failing with Hyper-V is that when you create a snapshot, the only way to subsequently delete it is by shutting down the VM and thus incurring downtime whilst the data on the differencing disks are written back into the original vhd file (you can delete the snapshot from the console, but the differencing disks remain, and are still being written to.) Also, this raises issues of having Hyper-V administrators who are not aware of this, happily taking snapshots, and then all of a sudden people start complaining about the performance of the VM, and investigation discovers that the VM is running off a chain of differencing disks, and the only solution is to shutdown the VM incurring downtime whilst the snapshots are committed back into the original vhd (there could be hours of downtime depending on how many and how big the differencing disks are.)

2: More Administration

To quote Einstein “keep things as simple as they can be but no simpler.” A problem with managing a Hyper-V environment is that the tools are a mess. For the same functionality you get out of one console in VMware (the VI Client,) you'll be using 3+ different consoles (Hyper-V console, SCVMM, Failover manager for clustering....) to do the same. And whereas doing something say like enabling HA on a cluster in VMware is just a case of ticking a box; to achieve the same in Hyper-V, there is much more to do in the way of configuring failover manager, creating cluster shared volumes....

3: Hyper-V is not as efficient a hypervisor as VMware vSphere/ESXi

This comes down to the architecture; even if you use Hyper-V standalone, it is still a Windows 2008 operating system just stripped down. An install of ESXi weighs in at around 100MB in size, Hyper-V standalone and you're looking at around 1.2GB, if you go for Windows 2008 full with the Hyper-V role enabled, 3GB. Also, VMware ESX is purely designed for virtualization, Windows 2008 is designed for a lot more besides and hence the added complexity (more things to go wrong too.)

So, if Hyper-V has these failings, why would anyone use it?

The answer is price.

If you have Windows 2008 licenses you have most likely already got Hyper-V.

Caveat 1: You must remember when comparing pricing that you will need to invest in more physical hardware if you use Hyper-V (no memory overcommit hence the VM guest density per physical host is a lot lower.) A very rough calculation is that you'll need to buy twice the amount of memory, or twice the number of servers (and twice the rackspace, power consumption, and cooling costs) as you would in a vSphere enivornment with same number of VM guests.

Caveat 2: VMware environment administration is a doddle, your Hyper-V environment administrators will have much more work to do.

Pricing (from Microsoft & VMware websites from April 2010):

(X-large format below - click to view complete table)

Author V. Cosonok

Friday, 2 April 2010

Setting up VMware Capacity Planner ( Walkthrough guide )

Part A: Setting a New Assessment

1: Go to and login with your credentials

2: From the Home page, select ‘Start new assessment’

3: Enter the company details, we shall select Consolidation Analysis (CA), and click ‘Next >’

4: Grant Access to users who can view and manage the assessment , and click ‘Next >’

5: We’ll skip the Select Notifications bit for this one – click ‘Next >’

6: We’ll skip the Select Subscriptions bit for this one – click ‘Finish’

Part B: Downloading and installing the collector

1: Log on to a server where the assessment is to be run,

login to , click on 'Portal' in the top right corner
under Resources → Product Downloads, download the VMware Capacity Planner Collector

2: Run the exe
3: Click 'Next >' on the initial screen

4: Accept the License Agreement → Click 'Next >'
5: Choose a Destination Folder to install to → Click 'Next >'
6: Configure Collector Service Account credentials → Click 'Next >'

7: Click 'Install'
8: Click 'Finish'

Part C: Configuring the VMware Capacity Planner Data Manager

1: Double-click on the 'VMware Capacity Planner Data Manager' icon on the desktop, or access via Programs.

You will be presented with a screen like the below
Configuring is just a case of running through the 7 steps

1: Setup Wizard

2: Click Import Systems or Discover Domain Discover Systems
(If not run automatically when finished Task 1)

3: Click Test Collection View Test Collection Results
4: Click Collect Inventory Data
5: Click Collect Performance Data
6: Click Register Collector

A Register Collector window (see below) will pop-up
Instructions for 'if you are doing a full assessment'
i: Choose Administration → Collector → Register Database Ids

ii: On the Administration – Database ID Registration screen, click Add
iii: Paste the ID in the field provided and click OK

Click Verify Collector

7: Click Synchronize Data

To ensure data is regularly synchronized, from the VMware Capacity Planner Data Manager, go
Admin → Options → 'Jobs' tab → untick 'Suspend Scheduler'

And then wait....

Author V. Cosonok