Avoiding performance issues with Linked Clone VMware View Desktop through fully deployed (thick) desktop

              Optimal design of a VMware View environment must take several factors into consideration. One of the most important factor is the Storage design. When proper storage design planning is not done, it invariably leads to performance issues in the environment. The most prominent example would be having linked clones in an environment in multiple SATA drives with very little cache space. There is a solution for avoiding such performance issues and that is to have fully deployed (thick disk) desktop. Having fully deployed desktops means spreading the I/O over many spindles instead of crowding all requests to one spindle.

This can be done in two methods:

  • Cloning the Desktop VM
  • Storage VMotion the Desktop VM

Cloning the Desktop VM

Steps:

  1. From VCenter, right click on desktop VM. Select ‘Clone’

  2. Keeping continuing with the wizard till the point of selecting what to do with the disk

  3. Now select ‘Same Format as Source’

These steps can be done when the desktop is on or off (hot or cold). In a nutshell, the linked clone is read (the latest snapshot of vmdk file that includes all changes down to base disk) and  stand-alone disks are created which are independent of the linked clone storage structure. Thus the file created from the cloning is the thick vmdk file which can now be used as base.

The advantage with this method is that one can verify that the cloning is complete before removing the linked clone VM in the View Manager. The new one can be manually added after verification.

Storage VMotion the Desktop VM

Steps:

  1. From VCenter, right click on Desktop VM. Select ‘Migrate’

  2. Select ‘Change Datastore’

  3. Follow the next steps and select ‘Same Format as Source’ in disk section

The VMs are converted just in the same way as the first method with the only benefit that this can be done without any downtime for the desktop.

This method also has the disadvantage of having no verification mechanism and the necessity of free space to be available on another datastore.


Tips for strong password in server hardening

The need for a highly secure Strong Password is felt more these days due to increased hacking and phishing. With Microsoft integrating windows logon to many online transactions, the need is further more important.

The password policy setting is one of the most important steps in server hardening procedure. This is usually done in 99% of the environments. But if in any environment it was overlooked, there are methods how one can enforce the strong password policy there.

The steps to enable password security policy in Windows 2003 Domain server is presented in this post:

Step#1: Start—> Program –> Administrative Tools –> Domain Security Policy

step1

Step#2: From the Domain Security Policy Window, enable the “Password must meet complexity requirements” under Password policy in Account Policies

step2

Once these steps are done, the password policy will be enforced when the users do a password reset.

 

Microsoft has some suggestion on how to make your password strong. I find the following tips useful:

  1. The length of password is very important – make it at least 14 characters or more.
  2. Make your password strong with special characters (symbol) in it.
  3. Mix upper and lower case letters to increase complexity.
  4. Remember to use the entire keyboard instead of using common words.
  5. Increase the length by using numbers between the letters.
  6. More complex the better – add punctuation at the beginning.

You might also want to refer to the Microsoft Documentation for detailed examples and Password checker tool


Restoring corrupted windows OS files without affecting the existing configuration files

Many a times we have the difficulty of having to restore some corrupted OS files. But this is always scary as there is a high chance of the other existing configuration files getting corrupted as well.

Well, in one of my tight situations I found that Microsoft was a life saver yet again! Microsoft provides a command line tool System File Checker “SFC” which can be used to recover the corrupted windows operating system files.

Since the discovery of this tool, I have used SFC in many production windows server environment successfully and the problem got fixed every time!

When you are not really sure that all the OS files are good and you doubt that system files have been somehow corrupted, do use SFC. This tool will validate the digital signatures of all the Windows system files and if there are any incorrect files, they are restored.

During the recovery process if possible it will use the on-disk cache files. But in some cases, this tool may request the original installation CD. This is because; the SFC tool will replace a damaged file from CD if it is not available in the on-disk cache.

So before start the system files recovery process using the SFC utility tool we should have original OS CD.

To run the System File Checker utility

  • Step1: Go to Start menu and select Run
  • Step2: Enter the command SFC /Scannow - Press enter button

This command will take few minutes to trigger the System Scan process. If any of the system files are replaced by the SFC, a reboot is required. This will not affect any previous configuration settings.

Check this Microsoft link for Microsoft documentation on SFC


Solving technical issues for large memory support in Windows 2003 server

Recently I faced issues when I setup the IBM HS20 blade server. I had installed 8 GB physical memory on the blade and I installed the window 2003 32 bit Enterprise operating system. After the OS installation I verified the physical memory availability by using the “systeminfo” command and found that the operating system showed only 4GB RAM present on the server. I was wondering what had happened to the other 4 GB!!

This is because of the hardware limitation. In any 32-bit Operating System, one only has access to 4GB of address space by default. The 32-bit Operating System can actually handle 4GB of memory. Using the /PAE switch allows the OS to handle memory above its maximum range as long as the application can handle it.

Any OS can only handle whatever resources are shown to it by the hardware BIOS.  If the hardware does not support a large enough addressing range, then it won’t report anything above that.  If the hardware supporting 36-bit PAE Intel Extensions or the AMD equivalent is used with an OS that supports PAE, we can enable both and see the entire RAM.

The procedure that I followed to enable the PAE switch in windows 2003 operating system is as below:

Step1:

Open the My Computer Window from the OS and select the menu Tools from the top of the menu bar

Step2:

Under the Tools menu select the menu “Folder Options” and select the sub menu “View”

step2

Step3:

Inside the View menu select the option “Show hidden files and folders” and uncheck the option “Hide protected operating system files (recommended)”

step3

Select the Apply button and press OK button to close this window

Step4:

Open the primary boot partition (default boot partition is C: Drive). Now we can see the hidden file “boot.ini”.

step4

Step5:

Open the boot.ini file in notepad and update the /PAE switch on the file. The below screen shot shows the correct format after enter the /PAE switch. Once update the switch we need to save the file and close the file.

step5

Step6:

Go to My Computer menu on the Desktop and select properties of the My Computer. Now we can see the 8 GB RAM available in the system.

step6


How to change the Service console IP in VMware ESX 4 Server?

Changing the IP for the Service Console must be done from the physical console or through a remote console session (ILO or DRAC). If you make changes through a network connection such as SSH, network connectivity to the Service Console disconnects because the Service Console's network interface changes.

  1. Run the following command to set the IP address:
    root@frank root# esxcfg-vswif -i 192.xxx-xx-xx -n 255.255.255.0 vswif0
    (Note
    : In this example, v swif0 is the Service Console adapter that is the interface to which you are applying the IP address change.)
  2. Open the /etc/hosts file with a text editor and modify it so that it reflects the correct IP address and hostname.
  3. To change the default gateway address and the hostname, edit the /etc/sysconfig/network file and change the GATEWAY and HOSTNAME parameters to the proper values.
  4. For the changes to take place, reboot the host or restart the network service with the command:
    root@frank root# service network restart

Note: This command breaks any current network connections to the Service Console.


How to Change the hostname, domain, DNS servers, and default gateway in VMware vSphere or Infrastructure (VI) Client?

  1. Highlight the ESX host and click the Configuration tab.
  2. Click DNS and Routing.
  3. Click Properties.
  4. To change the hostname, domain, and DNS servers, click the DNS Configuration tab and enter the appropriate values.
    (Note: Disable VMware High Availability if you do not want virtual machines to failover during the hostname IP change.)
  5. To change the default gateway, click the Routing tab and enter the appropriate value.
  6. Update the etc/opt/vmware/vpxa/vpxa.cfg file to reflect the new settings.
  7. Reboot the ESX host for the changes to take place.