Recently, I downloaded and tried VMware Converter Beta. It is VMware's new P2V (and V2V) product. This publicly available download is the Starter Edition and is free to use. There is also an Enterprise edition with additional features. When compared to their previous P2V product, P2V Assistant, VMware Converter has the following extra features that jump out:

Online P2V
The source machine (physical or virtual) keeps running during the P2V process. This is similar to what vendors like Leostream and PlateSpin offer. Obviously, this is not a good method for all your servers but might be for some. Note that the Starter Edition only supports this method. Another limitation of the Starter Edition is the fact that you cannot initiate P2V conversions of remote servers. In other words, you have to install the full package (agent and management tool) on the source machine to convert it. The Enterprise edition supports installing the management tool on a separate machine to push agents to remote machines to convert them. In that case, multiple P2V conversions can be initiated at the same time and followed from the management tool.

Offline P2V with a WinPE boot cd
The source machine is turned off and booted with a WinPE boot cd. A tool is provided to inject new Windows drivers into the cd image. The P2V Assistant boot cd was based on Knoppix and thus required Linux drivers. The boot cd is only for the Enterprise Edition and is the method of choice to create a consistent image of the source server.

No need for a helper virtual machine
With ESX as the destination, the P2V Assistant required a helper virtual machine. This is not the case for VMware Converter. When you configure a conversion, you just specify the target ESX server or VirtualCenter and VMware Converter takes care of creating the destination virtual machine, the disks, etc… This makes it much simpler and easier to use.

VMware Tools and reconfiguration
When you configure a conversion, you can specify that the VMware Tools have to be installed automatically. You can also reconfigure the virtual machine and give it a new name, new IP, etc… The reconfiguring is done with sysprep.

I tried a few conversions and had a couple of issues. First of all, make sure you have name resolution correctly configured so that the name of your target ESX server can be resolved to an IP address. That should not be an issue in a production environment but in a test environment, that is easily overlooked (as I did). I also had an issue with the imaging process itself. Apparently, VMware Converter uses Volume Shadow Copy services on operating systems that support it. On my test source machine, these services were disabled and naturally, the imaging process failed. After starting the Volume Shadow Copy service and the MS Software Shadow Copy Provider services everything worked like a charm.

VMware Converter looks promising but VMware should make the enterprise flavour free as well and this for several reasons. The first reason is that P2V in itself is not what matters most. Granted, it is an important process in a virtualization project but in the end, it is the virtualization itself and the management of the virtualized environment that counts. Secondly, the product only makes P2V just a bit easier. With some 3^rd party imaging tools and VMware's Virtual Machine Importer 2.0, you can also achieve the same end result.

At work, we have implemented Live Communication Server 2005 (LCS). I recently got a new smartphone (HTC MteoR) and decided to check out the mobile client for LCS, Communicator Mobile. It is a free download from the Microsoft site and can be found here. I downloaded the client for Windows Mobile 5.0 for SmartPhones.

The installation is like any other application you install on a SmartPhone but because the msi package checks the version of ActiveSync, installation fails on Windows Vista. I am running Windows Vista RC2 with Windows Mobile Device Center so I needed to install Office Communicator Mobile from an XP box with ActiveSync 4.1.

At present, LCS is only reachable on our internal network so I needed a VPN connection to get to the server. I configured a VPN connection that connects from "The Internet" to "Work". Because you cannot tell Office Communicator Mobile to connect using the VPN connection, you need to configure the LCS server name by using the short NetBIOS name and not the FQDN. In that case, the SmartPhone will use the VPN connection automatically because a short name requires a connection to the "Work" network.

After installation of the client, a different homescreen is installed that includes your Office Communicator status. If you use software like Facade, you will have to reconfigure it for the new homescreen. Below you see a screenshot of the new homescreen with a section for Office Communicator at the bottom and Facade at the top (launch bar and calendar/tasks).

The Office Communicator mobile client looks like this:

Of course, unless you like to chat using the telephone keys, I don't think it is very useful to have an LCS client on a mobile phone. Obviously, a device like the HTC TyTN is better suited. In the past, we have had customers asking us for such a solution. In the days of LCS 2003, something like a mobile version of Windows Messenger was not available. With LCS 2005 however, you can connect from all Windows-based devices.

Integrating ESX 3.0 with Active Directory is often requested by customers where we implement ESX. At the moment, I am doing an ESX implementation at one of our larger customers and of course, AD integration is part of the project. Naturally, they will use VirtualCenter 2.0 most of the time, but at times they will need to connect to individual ESX servers using VI Client, ssh or web access. In that case, they want to use their AD account and password.

VMware recently published a small whitepaper about Active Directory integration. With ESX 3.0, the process is very straightforward and only requires one command:

esxcfg-auth --enablead --addomain=domain.com --addc=domain.com

The VMware document uses the FQDN of a domain controller for the --addc parameter, but you can use the FQDN of the domain. That way, DNS is used to find domain controllers and use one of those. The command above modifies a few files like /etc/krb5.conf and also the system-auth file in /etc/pam.d. The ESX firewall is also automatically configured to open the needed ports for AD authentication.

Before you can logon with an AD account, you need to create a console user on the ESX box that has the same name as your AD account. For example, if you have an AD account domain\esxadmin, you need to add a user to the ESX console called esxadmin. The command to use is useradd esxadmin. You can also use VI Client to create the user. You can now logon with the account and use the AD password. I tested this with ESX 3.0.1 servers against Windows 2000 and Windows 2003 domains and it worked as advertised.

A couple of other things to think of:

• If you create a user in AD with account name root, you can logon as root with its AD password.
  
• If you don't want AD authentication for root, you can edit /etc/pam.d/system-auth. On the line that starts with auth and also includes pam_krb5.so, add this to the end: minimum_uid=1. Authentication for root (uid=0) will now be done locally only.
  
• If you want the AD user to have the same rights as root, you can set the user's UID to 0 (usermod -u 0 -c username). Of course, if you have used minimum_uid, that won't work.
  
• Alternatively, use sudoers to allow users to use sudo to execute specific tasks as root.
  

If you want administrators to use their AD account to connect to ESX with the VI Client or web access, you need to configure that with VI Client first. Start VI Client and connect to the ESX server as root. Use CTRL-P to add a permission at the server level. For example, to grant the user all rights, give the user the Administrator role (see below). That user will then be able to logon with his/her AD account and password in both VI Client and web access.

There are some issues with AD integration when done this way:

• When you configure the AD account to change its password the next logon, you will get a warning in the ESX console but you can still logon. That should not happen.
  
• If you do change your password with the passwd command, you change it locally only.
  

To get around some of these issues, you can use a product such as Centrify DirectControl for ESX. DirectControl has deeper integration with Active Directory and many more features:

• An AD computer account is created for your ESX servers.
  
• Active Directory Group Policies can be used to push down policies to ESX computer objects.
  
• When you create a new user in AD, you can directly create a user account on your ESX machines and set properties such as the home directory.
  
• Active Directory Group Policies can be applied to users that logon to ESX. For example, you can push down sudo configuration using a group policy.
  
• When a password expires or you set the change at next logon flag, you need to change the password in the ESX console. When you change your password, it is the AD password that you change, not the local password.
  
• When a user uses passwd, the AD password is modified and not the local password.
  
• Using group policies, you can configure logon banners.
  
• You can install a modified SSH daemon that is "kerberized". With Centrify's modified putty client, you can use ssh to logon without retyping your AD password.
  

We are in the process of evaluating DirectControl and it is very easy to deploy and work with. Pricing is reasonable and the product supports ESX 3.0.x.

Normally, I make ssh connections to ESX using an ssh client such as Putty or Bitvise Tunnelier. Out of the box, ESX enables ssh access but disallows login as root. To perform tasks as root, you have to logon with a regular user account and then get root privileges with su. This means you have to type two passwords each time, which is annoying. Using passwords is also a less secure way of connecting and with ESX, security is a top concern.

So, instead of using passwords, you can authenticate by using key pairs. The full process is explained in a very well written tutorial you can find here. In short, the steps are as follows:

• Generate a public/private key pair
• Put the public key on the server (ESX)
• Configure your client (e.g. Putty) to use the private key to authenticate
• (optionally) Use Pageant to avoid having to type the pass phrase to the private key each time you logon

On my system, all I have to do is to click an icon on my desktop that connects to the target ESX server. Then Putty opens and logs me on automatically to the ESX server:

If you want, you can also disable the use of passwords and require that everyone use a private key to authenticate. Less flexible, but more secure!

Implementing Live Communication Server 2005 is an easy way to improve internal communications. When a lot of your employees are "road warriors" or working at customer sites, it might be a good idea to implement Microsoft Office Communicator Web Access as well. It provides access to Live Communication Server using a web interface. A secured HTTP connection (SSL) is all you need to chat with the rest of your colleagues.

This post gives a quick overview of the installation process and shows a bit of the user interface as well.

Lab environment

• Domain: newtech.local with a domain controller called newtech-dc
  
• SQL Server: SQL Server 2005 SP1 running on newtech-sql
  
• Live Communication Server 2005 SP1: enterprise version installed on newtech-lcs
  

All servers are virtual machines on ESX 3.0.1.

Installation of LCS 2005 with SP1

Follow the normal installation procedure as described in the documentation. I had some issues with creating the SQL databases but that was purely because of the lack of space on the database and log disk. The error messages are quite cryptic, as always.

I installed the enterprise version so you have to create what is called an enterprise pool. It is just a bunch of servers that provide the core services. An enterprise pool needs a name. I used the name newtech so the FQDN of the LCS enterprise pool is newtech.newtech.local. You also need a DNS A record for this FQDN that points, in this case, to the ip address of newtech-lcs, the only front-end server in the pool.

Enable users for LCS

This is done using the Active Directory Users and Computers (ADUC) snap-in on newtech-lcs, the server where I installed LCS 2005.

For example:

You just need to select Enable users for Live Communications... Then you follow the wizard and assign the user to a server or pool (in this case, a pool). You should see that the user has been enabled.

Communicator Web Access

Download the package from Microsoft here.

I installed the package on the same server as LCS (newtech-lcs) but that is not necessary. Before installing the package, install the following components:

• IIS 6.0
  
• .NET Framework 2.0
  

If you installed .NET Framework 2.0 before IIS 6, you need to run "aspnet_regiis –i". That file is normally in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727.

Configuring certificates

You need several certificates to get things to work:

• SSL certificate on the Communicator Web Access (CWA) virtual server in IIS
  
• Certificates for MTLS on Live Communication Server AND Communicator Web Access
  

In my test setup, I used a mix of methods to generate certificates: selfssl.exe and Certificate Server.

To generate the SSL certificate for the CWA virtual server or web site, I used selfssl.exe. Selfssl.exe is part of the IIS6 Resource Kit tools. I used the following command line on the server where Communicator Web Access was installed:

Selfssl /N:CN=lcs.newtech.local /V:1000 /T

This creates a certificate for common name lcs.newtech.local. Users will use https://lcs.newtech.local to connect to Communicator Web Access. Of course, you can choose any name you wish. Just create a corresponding A record in DNS to get to the server. The certificate is valid for 1000 days (/V) and the certificate is added to the trusted roots on the web server (/T). You will be asked to attach this certificate to the first virtual server (Default Web Site). You can do that and copy it from there to the CWA virtual server or you can add an extra parameter to selfssl and attach the certificate directly to the CWA virtual server. In the end, you should have something like:

Above you see the Communicator Web Access virtual server with the properties of the server certificate that is attached to it.

Next, you need certificates for MTLS because CWA communicates with LCS using a certificate. When LCS responds, it uses its own connection to CWA. To achieve this, two certificates are needed:

• A certificate for LCS with, as common name, the FQDN of the enterprise pool (newtech.newtech.local)
  
• A certificate for CWA with, as common name, the FQDN of the server where web access is installed (newtech-lcs.newtech.local)
  

You can also use one certificate but then you need to configure subject alternate names.

To create the certificate for newtech.newtech.local, I used selfssl.exe again. After the certificate is in the certificate store, you need to configure LCS to use it. In the management console, open the properties of the front-end server in the pool. In my case, that's newtech-lcs.newtech.local.

In the properties, use the Add... button to add a connection. In transport type, select TLS and then select the certificate for newtech.newtech.local. As a result, you should see something like below:

LCS 2005 is now configured to accept TLS connections on port 5061 using the correct certificate.

Now, you need a certificate for Communicator Web Access. You can use selfssl.exe again. This time, however, I used the Enterprise CA installed on newtech-dc. In IIS, I generated a new request for newtech-lcs.newtech.local and submitted it directly to the Enterprise CA. The CA will issue the certificate directly so it will be in the certificate store right away. Since it is an enterprise CA, the certificate is also trusted.

Now you can configure Communicator Web Access with a certificate. In the management console of Communicator Web Access, open the properties of the server object. Use the Select Certificate... button to select the correct certificate.

Using Communicator Web Access (CWA)

I configured CWA so that users connect to it using https://lcs.newtech.local. When a user does that, the following UI is shown:

The user will be warned about pop-up blocking. Pop-up blocking should be turned off for this website. The user can now logon using the web form. The user gets the web form because I configured CWA for external access. It is also possible to switch it to internal use and use NTLM/Kerberos.

One thing to do is to allow the users to have remote access. Without it, they cannot use CWA. This is done using Active Directory Users and Computers on LCS. Just right click a user and select Configure Live Communication Users. Then configure remote access as shown below:

The user can now logon and will see the following interface.

The web interface is very similar to the full-blown 32-bit version and also comes with message pop-ups at the right bottom corner of your screen. It is sufficient if you only need instant messaging and is ideal for remote users connecting from computers outside the domain (kiosk, internet café, home computers, ...)

Of course, when you implement this in a production environment, you need to put this server in the DMZ. Or put it on your internal network and use a reverse proxy to provide access to it.

Conclusion

Microsoft Office Communicator Web Access is a great solution to extend the reach of Live Communication Server 2005 beyond the internal network. It is easy to implement once you know about the required certificates.

I just installed Windows Vista RC2 on my HP nw8000 laptop. It was needed because my DVD drive was not accessible anymore in RC1. It was ok after installation but a few days later, the thing just stopped working. I hope that won't happen on RC2.

Trend Micro's PC-cillin doesn't work well with this release so I switched to avast!, which is now compatible with Windows Vista.

Another piece of software that now works on Vista is Daemon Tools 4.06. I work a lot with ISO files so a tool like that is really needed.

Vista RC2 runs well on the nw8000 but the Windows Experience index is not that great. The problem is the graphics card, as you can see below.

ESX 3.0.1 and VirtualCenter 2.0.1 can now be downloaded. The release comes with a few things such as support for some newer hardware like the Intel Tulsa processor, full support for some 64-bit operating systems and critical bugfixes. I hope that display (GUI) issues in VirtualCenter have been addressed as well.

Also in the package is improved upgrade support. See the updated guide.

UPDATE: some info about the upgrade process can be found here.