Microsoft: Terminal Services Load Balancing in LH Beta 3

After announcing TS Easy Print, Microsoft made an even bigger announcement at BriForum Chicago: Longhorn will have Load Balancing! It goes to show, that Microsoft thinks really highly of BriForum A big compliment to Brian as far as I'm concerned! The Load Balancing capabilities will be included in Longhorn Beta 3 for the first time.

Read the article on Thincomputing here

VMware: TSX Nice 2007 presentations now available

The presentations from TSX Nice are available here

Microsoft: Longhorn Beta 3 and the UPD "Easy Print"

Longhorn (Terminal) Server will have its own "universal printer" functionality. It should be available (I have not checked it) in the Beta 3 Longhorn Server version (released & available for download NOW).

Microsoft calls it: Easy Print. It's based on the Microsoft XPS document standard (which is similar to PDF). The "Easy Print" feature of Longhorn server is quite comprehensive though and is more than just a universal print driver in that it:

• Supports (nearly) every printer 
• Compresses the data stream send to the TS Client 
• Enables you to use the properties (UI) of the native printer driver 
• Allow you to specify which printer gets redirected into your Longhorn TS Session

Tnx to bink.nu for the info

VMware: definitive guide to ... VMware

Check out this post on VMTN forums! It has all the links/references/... you would ever dream of! Tnx to Arne for the info.

VMware: PAM Password Aging in ESX 3.0.1

As you know, the service console for ESX 3.0 is a modified version of Red Hat Enterprise Linux 3 Update 6.0. By default, a password aging & complexity policy is active. Password aging policies are set:

• Maximum days = 90 days by default
• Minimum days = 0 days (you can change your password whenever you want)
• Warning time defaults to 7

Normally, the root and vpxuser have no password aging by default (value is –1).

You can disable the password aging policy as follows:

• For all newly created users (disable globally):
  esxcfg-auth --passmaxdays=0 (or –1)
• For existing users:
  chage -M -1 (or 0) <username>

VMware: VCB(mounter) "Error: Host unreachable"

Today I discovered that there is an issue with VCB(mounter) and .vmx/.vmdk placement.

For some reason, our P2V tool had placed all config files (.vmx, log files, etc.) on /vmfs/volumes/datastore 1/<Servername> and our .vmdk files on /vmfs/volumes/datastore 2/<Servername>. In a normal environment, config files and vmdk files are kept together.

As you can see in the screenshot, the initial snapshot gets created but no operations can be performed and a timeout occurs after 45 minutes.

vcbMounter created a snapshot, and placed the snapshot files by default in the /vmfs/volumes/datastore 1/<Servername> folder where our .vmx resides. For some reason, VCB(mounter) is not able to “find” our original .vmdk files.

You have 2 options in this scenario:

1. If you don’t want to have your .vmx and your .vmdk files togheter: change the Virtual Machine Working Location from the location where the .vmx file resides to the datastore location where the .vmdk files reside and (re)add to the VirtualCenter inventory.
   
   This can be done by editing the .vmx file and adding the following parameter:
   workingDir = "/vmfs/volumes/454b27d2-f2172987-4798-0017085ce0dd/<ServerName>/"
   
   Note the UID notation, and not the linked name
   
2. If you want your .vmx and .vmdk files together: migrate your VM using a “cold" migration and relocate your .vmx (configuration files) to the datastore where your .vmdk files reside (see also my previous article here). This is the easiest & fastest approach.
   

VMware: Handy trick to rename a Virtual Machine

Just a quick trick. As you all know, you can rename a Virtual Machine in VirtualCenter. However, the name changes but the files (.vmdk, .vmx, etc.) still have their previous name. Renaming all filenames/references manually is a daunting & error prone task.

Just shut down your VM and migrate it to a different datastore. All relevant files/folders will be renamed! Isn’t that easy or what?

Microsoft: Multiple Password "Policies" in Longhorn Server

Geert Baeke has posted an interesting article on how to deploy multiple password "policies" with Longhorn April CTP build. Check it out here

VMware: bundled patch ESX-6431040

Be aware of the fact that patch ESX-6431040 is a bundled tgz, so it will not work with the ESX autopatching scripts you can find in the community. The following patches are contained within this bundle:

• ESX-1161870
• ESX-3416571
• ESX-5011126
• ESX-7737432
• ESX-7780490
• ESX-8174018
• ESX-8852210
• ESX-9617902

I personally unpacked the main patch, repackaged all extracted patches (they have a normal patch structure and are extracted in subdirectories) and added them to my patches list.

VMware: Running VirtualCenter in a VM

VMware has released a technical note on running VC in a VM. I personally don't like running VC in a VM, for the reasons covered in the technote. I do like the concept to P2V your existing physical VC (connected to an external SQL/Oracle DB) and use it in a DR scenario.

Some things to note when deploying VC in a VM:

• You need to obtain a host-based license & an initial standalone ESX host, as you cannot boot your VC without a (host- or server-based) license :)
• Shutting down/maintenance on your Virtual VirtualCenter can be tricky: you need to locate VC & connect to an ESX host to power on VC or change your hardware config for your VC.

Download it here

VMware: configuring a static MAC address in a VM

Sometimes it can be necessary to configure a static MAC address in a VM. A typical issue during P2V is an application that has its licensing based on the MAC address.

VMware has defined that VirtualCenter does not use the following range: 00:50:56:00:00:00 to 00:50:56:3F:FF:FF where 00:50:56 is the OUI.

The steps:

1. Power off & remove the server from the VirtualCenter inventory. This is a necessary step, because VC will overwrite your settings during Power On!
2. Edit the .vmx file and locate the following generated MAC address:
   Ethernet0.addressType =
   and
   Ethernet0.generatedAddress =
3. Change the value for ethernet0.addressType from “vpx” to “static”
4. Change ethernet0.GeneratedAddress to ethernet0.Address
5. Change the current MAC to a MAC address in the following range:
   00:50:56:00:00:00-00:50:56:3F:FF:FF
6. In VirtualCenter, select an ESX host and go to storage
7. Browse the data store & locate your VM
8. Right-click on the .vmx file, and select Add to inventory
9. Power On the server. Issue the command ipconfig /all and locate the VMware NIC. Your manually assigned MAC address should be there.

I know you can set your MAC address inside Windows, but I would avoid this.

VMware: autopatching ESX with an FTP repository

Dominic Rivera from vmprofessional has posted a more advanced Perl script for patching different versions of ESX. He uses an FTP repository & does an MD5SUM check before installing the downloaded patch. Check it out here!

Sources are available:

Script:
http://www.vmprofessional.com/material/esx-autopatch.pl

Pre-compiled patchlist.txt
http://www.vmprofessional.com/material/3.0.1/patchlist.txt
http://www.vmprofessional.com/material/3.0.0/patchlist.txt

VizionCore: ESXReplicator beta 2.0 Update

I got a lot of reaction on my latest post. I said the following:

As does Double-Take for VMware Infrastructure, ESXReplicator makes use of VM snapshots on the source VM during replication

It is very important to note that there is a huge difference in the snapshot techniques used by Double-Take for VMware Infrastructure and VizionCore ESXReplicator.

Vizioncore only leverages snapshots during the replication cycle to free up the VMDK as they scan it. Replicator has it's own engine for the differential (cool huh?). This is very different to Double-Take that relies on a snapshot always being open.

VMware: New patches released

VMware released some new patches for ESX 3.0.1. Especially the ESX-1541239 is an interesting one, as it addresses a critical issue with Emulex HBA drivers.

ESX-1541239 Patch 03/29/07 Critical Patch
ESX-2257739 Patch 03/29/07 Critical Patch
ESX-2559638 Patch 03/29/07 Security Patch
ESX-6431040 Patch 03/29/07 Security Patch
ESX-9916286 Patch 03/29/07 Security Patch

VizionCore: ESXReplicator 2.0 Beta 8 preview

EsxReplicator is a real-time replication solution for the VMware ESX Server environment. A beta is now available to the public with support for VI3. I must admit that I was fairly impressed by this beta version. VizionCore has done a great job. We had just 1 small problem after setup (a Next->Next->Finish install BTW).

OK, let’s check the necessary steps (besides installing the .msi):

The first step is to configure your SMTP settings, and fill out the recipient and from mail address. Also, you can set your VC Tree Expand Level (tree level expansion).



Then, next steps include adding, configuring and connecting to your VirtualCenter and/or ESX hosts.



Ok, now comes the fun part: replication. Just add a replication job via the GUI by selecting the appropriate VM and selecting Add Replication job or Assign a New Job.
A Replication Job Wizard is displayed. Note the intervals: a minimum of 15 minutes in between replication steps:



You can specify to disable quiescing, the target host and datastore. That’s about it!



You can see a nice progress summary when a job is executed. This is useful to quickly determine when & where a job failed.



Job details are shown after a replication process. Check out the giant clock! BTW, all replication job details are saved under C:\Program Files\vizioncore\esxReplicator\Logs folder.

Some remarks:

• As you can see, this is a very simple and straightforward product
• As does Double-Take for VMware Infrastructure, ESXReplicator makes use of VM snapshots on the source VM during replication
• ESXReplicator did not detect that my VM was already on the same LUN as the to-be- copied replication, so my replication job failed.
• Also, a 2nd server with the name SR-LIC01 was added to the inventory. So effectively, we had 2 SR-LIC01’s in our VC inventory! Not a good thing and something that Double-Take for VMware Infrastructure does not allow to happen (it registers the VM for a brief period and then removes it from the inventory).
• We saw a rather high impact on the service console (CPU0 and vmnic0), but this is normal considering it is an ESX to ESX host action.
• It looks like ESXReplicator is VMotion aware, nice!

Conclusion: VizionCore ESXReplicator 2.0 for VI3 looks like a very promising product. It is simple & easy to use.

HP: Data Protector VCB integration packet for VI3

For those using HP Data Protector as a backup solution: HP finally released a VCB/script toolkit for use with VI3

This package contains the scripts and the document describing the integration of VMware Consolidated Backup 3.0.1 snapshot capabilities with HP Storage Data Protector 5.5 and 6.0.

Download it here

VMware: SAN System Design & Deployment Guide

I just noticed that VMware has released a new guide on designing & deploying ESX on a SAN. It's a fine read.
Download it here

VMware: Beware patch 2

Some installation remarks on patch 2 for VirtualCenter. These are the experiences of the guys on the VMware forums and myself :)

• Make sure to disable HA and DRS when patching your VirtualCenter. Otherwise, some ESX host may become disconnected from VirtualCenter.
• Make sure to upgrade your VI Client! The new VI Client (build 40644) is NOT backwards compatible. I saw weird stuff happening when using the new VI Client on the patch 1 VirtualCenter release!!
• Check your VPXA agent version after the installation (issue vpxa –v). The new version should be VMware VirtualCenter Agent Daemon 2.0.1 build-40644 (was 33643). If not and your ESX host shows a disconnected state in VC, start to panic :). Or just install it manually by running 'service mgmt-vmware restart' at the console. Reconnect the ESX host.
• License location has changed from C:\Program Files\VMware\VMware License Server\vmware.lic to C:\Program Files\VMware\VMware License Server\Licenses\vmware.lic. I had to reboot the license server.
• Last but not least: Don’t click Yes when asked to overwrite the data. It will wipe out your DB!
  

VMware: (Auto)patching your ESX host

As you all know, patching an ESX host is not exactly fun. VMware has promised to deliver a better patching system in their new version (ESX 3.1 and VC 2.1). In the meantime, we have to make sure that our ESX hosts are patched. In this post, I will use an IIS repository to deploy ESX patches from a central server (well, its not a push but rather a pull technology).

A special thanks goes out to Arne who wrote an article (in Dutch) on his excellent ictfreak blog on configuring IIS for ESX patches. I decided to use it and add a Perl script and a patchList to make the process more manageable.

First part: installing & configuring IIS

1. Create a folder called VIPatches
2. Download all patches from the VMware site
3. Extract them to the VIPatches folder. It should look something like this:
   
   
4. In the VIPatches, create a file called patchesList.txt with the relevant patch numbers IN THE CORRECT ORDER. Make sure no additional carriage returns are available after the final patch (in our case 3199476).
   
5. Install IIS
6. Go to IIS manager and create a new website. Call it VIPatches (or something similar)
7. Change the port number to a free port (example: port 8082)
8. Make sure to browse to the correct folder (in our case E:\VIPatches) and to activate Directory browsing
   
   
9. On the directory security tab: make sure Anonymous logon is selected.
10. On the HTTP Headers tab, MIME Types button: add .* and ‘application/octet-stream’
    
11. Browse with your preferred internet browser to http://<servername>:8082/VI3Patches. You should be able to see all patches.

Second part: configuring & patching your ESX host

1. Use the Service Console
2. Open the appropriate firewall port by issuing the following command (depending on your configured port in IIS):
   esxcfg-firewall -o 8082,tcp,out,httpClient
3. Create (touch) a script under /tmp called patchESX.pl (or create it on a central location so you can copy it to all your ESX hosts with WinSCP or FastSCP).
4. Open with nano (or vim) and add the following content:
   #!/usr/bin/perl
   # patchESX.pl -- auto update esx perl script
   # by Vincent Vlieghe
   # Version 6/03/2007
   
   use LWP::Simple;
   
   $patchlist = get 'http://<yourservername>:8082/patchesList.txt';
   @array = split(/\n/, $patchlist);
   foreach $item (@array)
   {
   print $item;
   $item = trim($item);
   $cmdQuery = "esxupdate query | grep ESX-$item";
   if(system($cmdQuery) == 0)
   {
   print "\n$item is already installed - skipping\n";
   }
   else
   {
   print "\n$item is not yet installed - installing\n";
   $cmdUpdate = "esxupdate -n -r http://<yourservername>:8082/ESX-$item update";
   system($cmdUpdate);
   }
   }
   sub trim($)
   {
   my $string = shift;
   $string =~ s/^\s+//;
   $string =~ s/\s+$//;
   return $string;
   }
5. Replace <yourservername> with the IIS servername. Make sure the ESX host can contact it (check your DNS!).
6. Make sure your ESX host is running in maintenance mode.
7. Run the script by issuing perl patchESX.pl. Watch and enjoy!
8. Reboot your ESX host when all updates are installed.

VMware: new patches available for ESX 3.0.1

Some new ESX 3.0.1 patches are available. Update ESX-3199476 adds support for using Microsoft Clustering Server (MSCS) with Windows 2003 Service Pack 1 (SP 1) and R2 Guest Operating Systems.

There are now a total of 20 patches available for download. BTW: High on my ESX agenda is: creating some general (Perl) script and a (virtual) update server for easier maintenance. Why? Because installing 20 updates for every existing/new server introduced in the environment is a pain in the ***. Download them here