After passing the VCDX Enterprise Admin Exam in July, I have booked the design exam for 20 September in the hope that if I pass the design exam, I will only have to sit the VCDX 4 design exam in order to qualify for the VCDX defence session. However, I received a notification from Pearson that VMware has asked to retire the VCDX 3 exams on 30 August 2010.

I therefore had to either reschedule the design exam to an earlier date or cancel the exam. As there are now no appointments available prior to 30 August I had to cancel the exam. This is slightly annoying as it means that rather than just having to pass the vSphere 4 design exam, I will now have to go and sit the VCDX Admin exam for vSphere 4 as well. And for those who don’t yet know, you DON’T want to sit that Admin exam twice!

When an ESX/ESXi host has been added to vCenter and the vpxa agent has been installed on the host, the vpxa agent will not allow any virtual machines state changes to be made directly from the host itself. You will still be able to use the vSphere client to connect directly to the ESX/ESXi host, but you will not be permitted to power on VMs directly on the ESX host. You will also be denied access to power on VM’s using the CLI. Only through vCenter will you now be able to power on a VM. What makes this awkward is this: The error message that is returned when the vpxa agent denies power on operations does not state the reason why your VM has failed to power on.

I got caught out by this after my vCenter Server (that was running as a VM) was powered down. I then connected directly to the ESX host where the vCenter VM was registered, but I was unable to power on the vCenter VM as vpxa was denying the power on operation. The way to get around this is to stop the vmware-vpxa daemon on the host “service vmware-vpxa stop). Only then will you be able to power on VMs directly.

I also have to state that I have not tried the GA build of vSphere 4.1, so the only experience I have with vSphere 4.1 is the beta. It would be interesting to see if it's still the same. Feel free to test it out and leave comments.

Large organisations, such as banks, will have quite a few very large data centres that are sometimes located all over the world. These organisations don't fool around when it comes to infrastructures. They don't have one data centre with maybe one or possibly two vCenter Servers. No, as I said, these guys have many data centres, each filled with thousands of physical servers. They could have 5 vCenter servers in each data centre, and each one of those vCenter servers will manage say 10 HA/DRS clusters with 8 ESX host each running thousands of Virtual Machines. To top this, each vCenter server will have its own stand-alone VMware Update Manager Server. To make managing these vCenter Servers easier, they will use vCenter a linked-mode configuration. This allows them to managed all of their vCenter and VUM Servers from a single vSphere Client instance.

Now here is where the SSL certificate story makes sense. For simplicity, I'm going to scale down the numbers a bit. Let's say they have two data centres. Each data centre has two vCenter Servers and two VUM servers. These vCenter Servers are configured with linked-mode. This means that when logging into one vCenter Server, one will be able to manage four vCenter Servers and four VUM Servers from the same console. Each one of these vCenter and VUM servers will have a self generated and signed SSL Certificate that was generated and installed during the vCenter and VUM installation. So when a user logs into one of the vCenter Servers for the first time using the vSphere client, that poor user will have to click the "Ignore" button on a security warning similar to the one below a whopping eight times!!! Yes, that's right, one for every vCenter Server and one for every VUM server in linked-mode.

Replacing the original SSL certificates on the vCenter and VUM servers with SSL certificates that have been generated by a CA that has a CA certificate in the client computer's Root Certificate Authority store will prevent the message from being displayed.

 When I originally set out to write a post on SSL Certificate Replacement for VMware vSphere vCenter Server and VMware vSphere Update Manager Server, I had planned to write a single blog article to cover the whole topic. However, as I started to document the procedure for replacing SSL Certificates earlier in May 2010, I realised that when all the screen captures are included (which is what I had planned for) the article was simply way too long for a single blog post. For this reason I have decided to cover SSL Certificate Replacement in separate articles all linked together to form a "tutorial" like post. I hope it works!

Anyway, I have decided to break the SSL Certificate Replacement topic down into the following "Steps":

1. Prepare the Certificate Authority Server with IIS, OpenSSL and Microsoft Certificate Services
2. Create a Certificate Request using OpenSSL on Windows
3. Submit the Certificate Request to the Microsoft Certificate Services CA
4. Create a new PFX-Formatted Certificate
5. Replace the vCenter Server SSL Certificates
6. Replace the VMware Update Manager SSL Certificates. (Article is yet to be published)
   

To create this article and screen shots, I made use of a lab that was especally prepared for this exercise. This lab contained the following components:

Our meeting will be held at the Thames Suite, London Chamber of Commerce and Industry, 33 Queen Street, London EC4R 1AP, +44 (0)20 7248 4444. The nearest tube station is Mansion House, location information is available here. Reception is from 1230 for a prompt 1pm start, to finish around 5pm. Our agenda looks something like this:

1100 – 1200 (Optional) Interactive PowerCLI / Powershell workshop – Alan Renouf
Note: If you would like to participate in Alan’s workshop, please bring a laptop, preferably with the most current PowerCLI and PowerShell binaries installed.

12:30 – 13:00 Arrive & Refreshments
13:00 – 13:20 Welcome & News – Alaric Davies
13:20 – 14:00 Sponsor Presentation, Why EMC for VMware? – Alan Renouf, Simon Seagrave

• Thin Storage in a Virtual World – Chris Evans, ‘The Storage Architect’
• Towards a Virtual Desktop – Stuart McHugh, Withers Worldwide
• Experiences with Hyper-V – Mike Laverick, RTFM Education

15:00 – 15:20 Refreshment break

• Preparation steps towards the VCDX – Simon Gallagher, Ioko
• ESX in the DMZ – Steve Bruck, Associated News and Matt Northam, VMware
• vSphere 4.1 new features – James Smith, VMware

16:45 – 17:00 Close
17:00 – Pub

To register your interest in attending, please send an email to londonvmug at yahoo dot com with up to two named attendees from your organisation. If you do not receive a confirmation mail, please don’t just turn up since we will not be able to admit you to the meeting. Please separately mention if you intend attending Alan’s PowerCLI workshop at 1100. Content from the meetings will continue to be uploaded to www.box.net/londonug, NDA permitting.

Sincerely, and with regards,

The UKLVMUG Steering Committee

So, yesterday I had to go and sit the VMware VCDX Enterprise Admin Exam (VCE310). Although, a few weeks after I had booked my seat for the VCE310 exam, the good people at VMware had come up with the new certification tracks that includes the new VCDX4 certification. I then for a moment was contemplating cancelling my booking for the VCE310 exam, but after thinking it through for a bit and also taking into account the fact that I had to wait for quite some time to get a VCE310 booking from VMware, I decided to go ahead and site the VCE310 anyway.

As I mentioned earlier in the post, things have been very busy the last few months and I hardly had any time to prepare for the exam. For that reason, I arrived at the testing centre yesterday, prepared to take a kicking from the exam. I knew that in the case of me failing the exam, I would at least know what to expect from future attempts.

I'm sure you have seen may posts form gurus that have taken the exam before, so I'm not going to go into too much detail on the exam. To state the obvious, as I'm also under NDA, I will not be able to discuss any questions that were asked either.

The VCE310 exam is split into two parts, each accounting for 50% of your final score. The first part of the exam is the same format as the VCP exam based on questions with multiple choice answers. As I started to work my way through these questions, I realised that it's not actually as hard as I'd first anticipated. However, towards the middle of the first section, I noticed that the exam was starting to get more and more tricky as it was focusing the questions based on a particular technology that I don't know all that much about. I'm not sure if the exam system adapts to your weaknesses or strengths, but I did notice that the system kept on asking me questions around this same technology. Almost as if it knew that I sucked at it! However, towards the end of the first section, I felt as if I was getting back on top of the fight and that the questions asked were fair and reasonable, whatever that might mean.

The second half of the exam is a live LAB. Unlike most exams with LAB environments that basically only emulate a small part of the software that the question is based around, this was actually a live lab running on live servers with real IP addresses user accounts, RDP sessions, remote console sessions, Putty SSH sessions and DNS entries. Every keystroke and mouse movement is tracked and recorded for whomever that will score your efforts to interrogate.

Now, at first I thought "I work with this stuff in large enterprise data centres every day of my life, so this should be easy as." I was wrong. First of all, because you know that your every move is recorded, it adds extra pressure. Also, the remote console session to the live LAB environment wasn't the best. It was “glitchy” and had poor response times. One example is that I had difficulty seeing the navigation tabs in the VI client. But that's the easy part. What I did find very hard was the fact that if you don't know how to do something that can only be done from the CLI using Putty, you basically couldn't perform the tasks asked in the lab question. It's as simple as that. If you don't know how to enable or disable root access for SSH (and this is just an easy example, the real lab questions are much more complicated and harder that this), you simply don't know and you won't be able to answer that question.

In regards to my efforts in the LAB environment, there were two questions that I genuinely didn't have a clue on. Whether that will be enough left out for me to fail? We'll I'll know within 12 days from now. All I know is that when I got home last night, I jumped straight onto my lab to try and find the answers to the two question that I couldn't do in the lab, and to say the least I was kicking myself within 10 minutes of logging onto my lab! As Homer Simpson would say... Doh!

All in all I think the exam is composed to be very failr and reasonable. If I do fail the exam, it won't be because the exam was too hard, but it would be because I did not study. It's as simple as that.

Anyway, up an onwards. If I pass, it would be a bonus. If I fail, then oh well, you win some and you lose some. At least I know now what is expected in the exam, something that even the exam blueprint can't give 100% clarity on.

ID: ESX400-201006201-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the VMware ESX 4.0 Core and CIM components

ID: ESX400-201006202-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the VMware ESX 4.0 mpt2sas device driver

ID: ESX400-201006203-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the VMware ESX 4.0 mptsas, mptspi device drivers

ID: ESX400-201006204-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the VMware ESX 4.0 fnic device driver

ID: ESX400-201006205-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the ESX 4.0 SCSI/iSCSI driver

ID: ESX400-201006206-UG  Impact: HostGeneral  Release date: 2010-06-10  Products: esx 4.0.0
Updates the VMware ESX 4.0 ixgbe device driver

ID: ESX400-201006207-UG  Impact: HostGeneral  Release date: 2010-06-10  Products: esx 4.0.0
Updates the ESX 4.0 Intel igb driver

ID: ESX400-201006208-UG  Impact: HostGeneral  Release date: 2010-06-10  Products: esx 4.0.0
Updates the ESX 4.0 USB storage component

ID: ESX400-201006209-UG  Impact: HostGeneral  Release date: 2010-06-10  Products: esx 4.0.0
Updates the ESX 4.0 qlogic SCSI driver

ID: ESX400-201006211-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the VMware ESX 4.0 nx-nic device driver

ID: ESX400-201006212-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the VMware ESX 4.0 bnx2x device driver

ID: ESX400-201006214-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the VMware ESX 4.0 cciss device driver

ID: ESX400-201006215-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates Driver for VMware ESX 4.0 HP SAS Controllers

ID: ESX400-201006217-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the ESX 4.0 python component

ID: ESX400-201006218-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the VMware ESX 4.0  SCSI lpfc820 device driver

ID: ESX400-201006219-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the VMware ESX 4.0  ATA libata device driver

ID: ESX400-201006220-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the ESX 4.0 Megaraid SAS device driver

ID: ESX400-201006221-UG  Impact: HostGeneral  Release date: 2010-06-10  Products: esx 4.0.0
Updates tzdata

ID: ESX400-201006222-UG  Impact: HostGeneral  Release date: 2010-06-10  Products: esx 4.0.0
Updates the ESX 4.0 pam_passwdqc rpm

ID: ESX400-201006224-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the ESX 4.0 initscripts rpm

ID: ESX400-201006225-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the ESX 4.0 Web Access components

ID: ESX400-201006226-UG  Impact: Critical  Release date: 2010-06-10  Products: esx 4.0.0
Updates the VMware ESX 4.0 EHCI HCD device driver

ID: ESX400-Update02  Impact: HostGeneral  Release date: 2010-06-10  Products: esx 4.0.0
VMware ESX 4.0 Complete Update 2

ID: ESXi400-201006201-UG  Impact: Critical  Release date: 2010-06-10  Products: embeddedEsx 4.0.0
Firmware update for 4.0 U2  release

ID: ESXi400-201006202-UG  Impact: Critical  Release date: 2010-06-10  Products: embeddedEsx 4.0.0
Tools update for 4.0 U2 release

ID: ESXi400-201006203-UG  Impact: Critical  Release date: 2010-06-10  Products: embeddedEsx 4.0.0
VI Client update for 4.0 U2 release

ID: ESXi400-Update02  Impact: Critical  Release date: 2010-06-10  Products: embeddedEsx 4.0.0
VMware ESXi 4.0 Update 2

ID: VEM400-201006011-BG  Impact: HostGeneral  Release date: 2010-06-10  Products: embeddedEsx 4.0.0, esx 4.0.0
Cisco Nexus 1000V VEM

ID: VEM400-201006021-BG  Impact: HostGeneral  Release date: 2010-06-10  Products: embeddedEsx 4.0.0, esx 4.0.0
Cisco Nexus 1000V VEM

Before continuing with the steps in this article, please ensure that you have followed the following steps required to generate and sign a new SSL Certificate for vCenter Server:

1. Prepare the Certificate Authority Server with IIS, OpenSSL and Microsoft Certificate Services
2. Create a Certificate Request using OpenSSL on Windows
3. Submit the Certificate Request to the Microsoft Certificate Services CA
4. Create a new PFX-Formatted Certificate

Ok, so we have now self signed our own SSL Certificate for the vCenter Server. Let's first look at the steps that we need to take in order to replace the SSL Certificate for the vCenter Server.

The procedure for replacing the SSL Certificates for VMware vCenter Server involves:

1. Disconnect all ESH hosts that are being managed by the vCenter Server
2. Stop the vCenter Server services
3. Create a backup of the existing SSL Certificate files
4. Replace the Existing SSL Certificate files with the new SSL Certificate files
5. Reset the VMware vCenter Database Password
6. Start the VMware vCenter Services
7. Reconnect all ESX hosts managed by the vCenter Server

Ok, let's begin:

Disconnect all ESX hosts managed by the vCenter Server

In order to replace the SSL Certificates for a vCenter Server, all ESX hosts that are managed by that vCenter Server need to be disconnected from the vCenter Server.

Important: If multiple vCenter Servers are configured as Linked-Mode, it is only necessary to disconnect the ESX hosts that are being managed by the vCenter Server that is currently having its SSL Certificates replaced. There is no need to disconnect ESX hosts that are managed by other vCenter Servers in the Link-Mode configuration. There is also no need to break the Linked-Mode configuration between the vCenter Servers. I have also seen posts on the community forums that suggest that you shut down all VMs running on all ESX hosts managed by the vCenter Server. This statement is not correct. There is no need to evacuate VMs from any ESX hosts.

Stop the vCenter Server Services

Before we can replace the SSL Certificates we need to first stop the vCenter Server Serivices.

Open the Services Management Console (Start -> Run -> services.msc -> OK

The Services Management Console Opens. Scroll down and locate the following two services:

• VMware VirtualCenter Management Webservices
• VMware VirtualCenter Server
  

Right-click on the "VMware VirtualCenter Server " service and click "Stop"

A message will appear stating that when the VMware VirtualCenter Server stops, the VMware VirtualCenter Webservices service will also be stopped. Acknowledge the message by clicking “Yes”

Create a backup of the existing SSL Certificate files

Using Windows Explorer, browse to the following location on the vCenter Server:

C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\

The directory will contain the following three files:

• rui.crt
• rui.key
• rui.pfx

Create a new folder called "Backup". Once the folder has been created, move the rui.crt, rui.key, rui.pfx files into the Backup folder.

Copy the new SSL files from the OpenSSL-Win32\Bin folder on the Certificate Authority Server to C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\

As the VMware vCenter database password has been encrypted using the original SSL Certificate when vCenter was installed, the vCenter Server Service will not be able to use the new SSL Certificate in order to decrypt the stored password. We therefore need to reset the vCenter database password and encrypt the password using the new SSL Certificate.

Open a new command prompt window and browse to the Program Files directory where VMware vCenter Server is installed. In the example below, vCenter Server is installed  on a 64-bit operating system and is therefore installed at “D:\Program Files (x86)\VMware\Infrastructure\VirtualCenter Server\”, however the default installation path for vCenter Server when installed on a 32-bit operating system is “C:\Program Files\VMware\Infrastructure\VirtualCenter Server\”

To reset the password, type: “vpxd.exe –p” and press <Enter>. When prompted to enter a new DB password, enter a new password for the vCenter Database and press <Enter>. Enter the password again to verify the entry and press <Enter>. Confirm that “Reset DB password succeeded” is displayed.

Go back to the Services Management Console and find the following two services:

• VMware VirtualCenter Management Webservices
• VMware VirtualCenter Server

Right-click on the "VMware VirtualCenter Server" service and click "Start"

Once the VMware VirtualCenter Server service has started, right-click on the VMware VirtualCenter Management Webservices and click "Start".

Once the steps above have been followed, the VMware vCenter Server will be using the new SSL certificates. Please bear in mind that the SSL certificate was signed for a specific host based on the host's FQDN. Therfore in order to avoid being presented with a  SSL certificate warning, the FQDN of the vCenter server should now be used when loggin into vCenter with the vSphere client.

Before continuing with the steps ioutlined in this article, be sure to have completed Step 3: Submit the new Certificate Request to a Certificate Authority

The rui.key and rui.crt files will be used by VMware products as replacement SSL Certificate files. However in addition to these two files a PFX-formatted certificate file called “rui.pfx” specific for Windows must be created. The “rui.pfx” file is a concatenation of the system’s certificate and private key, exported in PFX format.

To create this file, open a new command prompt and change directory to C:\OpenSSL-Win32\bin\ and type the following command:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword –out rui.pfx

IMPORTANT: Do not change testpassword to anything else. The export password has to remain as testpassword as the VMware vCenter Server depends on this password to function correctly.

Now that the SSL Certificate files have been created, they need to be installed on the vCenter or Update Manager Server.

• Click here to replace VMware  vCenter Server SSL Certificates
• Click here to replace VMware Update Manager Server SSL Certificates
  

Before continuing with the steps in this article, be sure that you have completed Step 2: Generate a new SSL Certificate Request

Now that we have used OpenSSL to generate a new SSL certificate request, we need to submit the request to a Certificate Authority in order to sign a new SSL Certificate based on the request. OpenSSL has now generated the request and saved the request in rui.csr. We now need to open the rui.csr file using Wordpad. Once the file has been opened in Wordpad, we will copy the entire contents of the file to the clipboard.

After opening Windows Wordpad, open the rui.csr file that was generated by OpenSSL.

When the "rui.csr" file is opened in WordPad, a block of text that begins with "-----BEGIN CERTIFICATE REQUEST-----" and ends with "-----END CERTIFICATE REQUEST-----" is displayed. From the File Menu, click "Edit -> Select All" to select the entire content of the "rui.csr" file.

Copy the contents of the rui.csr file to the clipboard by clicking on Edit -> Copy (or simply press CTRL+C).

In the examples referenced in this article, Microsoft Certificate Services is installed on the same Windows Server as OpenSSL. Our server is called LABSSL01.uk.labs.virtualvcp.com. However it is not a requirement that Microsoft Certificate Services and OpenSSL is installed on the same server.

Open a new browser window and navigate to the Microsoft Certificate Services URL. As Microsoft Certificate Services is installed on the same host as where the browser is running, the URL referenced is http://localhost/certsrv. However, if the Microsoft Certificate Services server is not on the same host, the URL should contain: http://<ca-hostname-or-ip-address>/certsrv

 The Microsoft Certificate Services Welcome page is displayed. Under Select a task click on "Request a certificate".

At the next page, click “advanced certificate request”

Click "Submit a certificate request by using a base-64-encoded CMC or PKCS#10 file, or submit a renewal request by using a base-64-encoded PKCS#7 file."

At the next page, right click in the Saved Request field and click “Paste”. This will paste the Certificate Request text that was copied to the clipboard, into the Saved Request field

To submit the new SSL Certificate Request to the Certificate Authority, click the "Submit" button.

The next page will confirm that the certificate request has been received.

Now that the new certificate request has been submitted to the CA, we need to sign the certificate.

To issue and sign the new certificate request, open the Microsoft Certification Authority Management Console: Start -> Run -> certsrv.msc -> OK

The Certification Management Console opens. From the left pane, click “Pending Requests”. The new certificate request is displayed in the right pane

To issue the new SSL certificate, right click on the pending certificate request, select “All Tasks” and click on “Issue”.

Open a new browser window and again navigate to the Microsoft Certificate Services URL. At the Welcome page, click “View the status of a pending certificate request”

Select the Saved Request Certificate from the list

At the Certificate Issues page, select “Base 64 Encoded” then click “Download certificate”

The File Download Dialog opens. Click “Save”

Using the Save As dialog, navigate to the “C:\OpenSSL-Win32\bin” folder. Under the “Save as type” drop down menu, select “All files”. At the “File name” field, enter “rui.crt”. Click Save

Now that we have a new SSL Certificate, continue to Step 4: Create a new PFX-Formatted Certificate

This has been going on for a while now (more than 20 minutes I think). Is it just me or is anyone else suffering?

According to the vEXPERT Landing Page  "The VMware vExpert Award is given to individuals who have significantly contributed to the community of VMware users over the past year. vExperts are book authors, bloggers, VMUG leaders, tool builders, and other IT professionals who share their knowledge and passion with others. These vExperts have gone above and beyond their day jobs to share their technical expertise and communicate the value of VMware and virtualization to their colleagues and community."

I am glad to report that BT Openreach has fixed the problem with the ADSL line that supports virtualvcp.com. The site is back online now!

Before you continue with the following procedure, ensure that you have completed Step 1: Prepare OpenSSL and Microsoft CS

We will be using OpenSSL to generate a new RSA key. We will then use this key to generate a new SSL Certificate Request that we can submit to the Microsoft Certificate Authority that we have created in Step 1.

On the SSL Server that we have prepared in Step 1, Open a new command prompt window and change directory to the “C:\OpenSSL-Win32\bin” directory. 

The "C:\OpenSSL-Win32\bin" directory holds all the files necessary to generate new SSL certificate requests. Openssl.exe should be used to generate the following two files:

• rui.key  - A 1024-bit RSA key that we will use to generate a new SSL Certificate request file
• rui.csr   - The .csr file contains the certificate request information that can be submitted to a SSL Certificate Authority in order to issue a new SSL Certificate.

First, lets' create a new key file. At the command prompt, type "openssl genrsa 1024 > rui.key" and press enter.

A new file called “rui.key” has now been created under “C:\OpenSSL-Win32\bin”. This file can now be used to generate a new certificate request file.

Now that the rui.key file has been created by OpenSSL, issue the following command at the prompt in order to generate a new certificate request file: “openssl req –new –key rui.key > rui.csr”

OpenSSL will now request the following information that will be package into the certificate request file. This information will be used by the Certificate Authority to issue and sign a new SSL Certificate. 

 OpenSSL has now created a file called “rui.csr”. This file contains the request that needs to be submitted to a Certificate Authority in order to issue and sign a new SSL Certificate based on the information entered into the request.

Continue to Step 3: Submit the new Certificate Request to a Certificate Authority 

In order to request and self sign new SSL certificates for VMware vCenter Server 4.x and VMware Update Manager we will need to get a certificate authority up and running. For this lab, we will use a Microsoft Windows 2003 Server running Microsoft Certificate Services as our Certificate Authority. Although we will be using Microsoft Certificate Services to sign the new SSL Certificates, OpenSSL will be used to generate the SSL Certificate Requests that will be submitted to the Microsoft Certificate Authority.

To build the SSL CA Server we will need to have the following software components:

• A Windows 2003 Server
• Microsoft Internet Information Services (IIS) enabled
• Microsoft Certificate Services Installed
• Visual C++ Redistibutable (Download this from here )
• Win32 OpenSSL V1.0.0 Lite (Download this from here) 

For this example I have prepared a Windows 2003 Server called LABSSL01 and I've also added the server to the LABS.UK.VIRTUALVCP.COM domain. So, the FQDN of our SSL Certificate Authority server for this example will be: labssl01.labs.uk.virtualvcp.com.

Preparing the server for Microsoft Certificate Services

The first thing that we will need to get in place is IIS. We will use IIS to access the Microsoft Certificate Services Web Portal. The web portal will be handy to:

• Submit new SSL Certificate Requests to the Microsoft CA
• Download the signed SSL Certificates
• Download the CA Root Certificate to client machines

We will be installing the IIS and Certificate Services components at the same time.

Using Add or Remove Programs from the Windows Control Panel, Click the Add/Remove Windows Components Button:

Select "Application Server" and click "Details". Then select the following components under "Application Server"

• Application Server Console
• Enable network COM+ access
• Internet Information Services

Once the components have been selected, Click OK.

With the IIS components now selected, we can go ahead and select the Certificate Services components as well.

Select "Certificate Services", then click "Details"

The Certificate Services components dialog opens. Select the following components before clicking "OK":

• Certificate Services CA
• Certificate Services Web Enrollment Support

When Certificate Services CA is selected, the following message will appear. Click "Yes" to continue

Now that both IIS and Certificate Services components have been selected, click "Next".

As we are installing a new Certificate Authority, we need to provide some information for the new Certificate Authority.

For the CA type, select "Stand-alone root CA" and click "Next" 

Now it's time to supply information that will identify the new Certificate Authority. The information provided here will also be included in each SSL certificate that the new CA will sign in the future.

At least the "Common Name for this CA" field should be completed as well as the "Validity period" field.

At the Certificate Database Settings dialog, keep the default settings and click "Next"

A message will appear stating that in order to complete the installation, Internet Information Services must be restarted. Click "Yes" to acknowledge this message.

You may also be presented with a message requesting that ASP be enabled. Click "Yes" to enable ASP now.

During the installation, you may be prompted for the Windows 2003 Installation CD. Please make sure that you have this handy in order to complete the installation of IIS and Certificate Services.

When the above steps have been completed, your server will be an ASP Web Server as well as a Certificate Authority capable of signing new SSL Certificates. However we will still need to install OpenSSL for Windows. OpenSSL is used to generate new SSL Certificate requests that will be submitted to the new Microsoft Certificate Authority. In this example, our Certificate Authority is called "VirtualVCP SelfSign Certificate Authority"

 In order for your client machines to verify the authenticity of any certificates signed by your new CA, you will have to download and install the CA root certificate on each client machine. The new CA root certificate can be downloaded from http://<your-ca-server>/certserv

Installing Win32 OpenSSL V1.0.0 Lite

NOTE: Before installing Win32 OpenSSL V1.0.0 Lite, please download and install Visual C++ Redistibutable from the Microsoft Website.

Download Win32 OpenSSL V1.0.0 Lite from here

Run the Win32 OpenSSL Light installer. At the Welcome dialog, click “Next”

Select “I accept the agreement” and click “Next”

Keep the default Destination Location as “C:\OpenSSL-Win32” and click “Next”

Select "The OpenSSL binaries (/bin) directory" and click "Next"

Click "Finish" to complete the installation

This then completes the SSL Server preparation. However, as we will be issuing new SSL certificates using the SSL Certificate Authority installed on this server, we will have to import the CA's root certificate into the Trusted Root Certification Authorities store of each of the client computers that will be using the vSphere client to connect to vCenter and VUM.

Continue to the next step: Generate a new SSL Certificate Request

ID: ESX400-201005401-SG  Impact: HostSecurity  Release date: 2010-05-27  Products: esx 4.0.0 Updates vmkernel64, scripts, tools etc

ID: ESX400-201005402-SG  Impact: HostSecurity  Release date: 2010-05-27  Products: esx 4.0.0 Updates VMware-webCenter-esx

ID: ESX400-201005403-SG  Impact: HostSecurity  Release date: 2010-05-27  Products: esx 4.0.0 Updates Expat

ID: ESX400-201005404-SG  Impact: HostSecurity  Release date: 2010-05-27  Products: esx 4.0.0 Updates NTP

ID: ESX400-201005405-SG  Impact: HostSecurity  Release date: 2010-05-27  Products: esx 4.0.0 Updates gzip

ID: ESX400-201005406-SG  Impact: HostSecurity  Release date: 2010-05-27  Products: esx 4.0.0 Updates krb5 and pam_krb5

ID: ESX400-201005407-SG  Impact: HostSecurity  Release date: 2010-05-27  Products: esx 4.0.0 Updates gcc packages

ID: ESX400-201005408-SG  Impact: HostSecurity  Release date: 2010-05-27  Products: esx 4.0.0 Updates bind-libs and bind-utils

ID: ESX400-201005409-SG  Impact: HostSecurity  Release date: 2010-05-27  Products: esx 4.0.0 Updates sudo

ID: ESXi400-201005401-SG  Impact: HostSecurity  Release date: 2010-05-27  Products: embeddedEsx 4.0.0 Updates Firmware

ID: ESXi400-201005402-BG  Impact: Critical  Release date: 2010-05-27  Products: embeddedEsx 4.0.0 Updates VMware Tools

ID: VEM400-201005001-BG  Impact: HostGeneral  Release date: 2010-05-27  Products: embeddedEsx 4.0.0, esx 4.0.0 Cisco Nexus 1000V VEM

ID: VEM400-201005011-BG  Impact: HostGeneral  Release date: 2010-05-27  Products: embeddedEsx 4.0.0, esx 4.0.0 Cisco Nexus 1000V VEM

ID: VEM400-201005021-BG  Impact: HostGeneral  Release date: 2010-05-27  Products: embeddedEsx 4.0.0, esx 4.0.0 Cisco Nexus 1000V VEM

PHD Virtual continues to extend our product family to meet the expanding needs of the virtualization community. On May 6th, we announced PHD Virtual Backup for Citrix XenServer.  We are also happy to tell you that as of September, 2010 we will also offer support for VMware ESXI.

Learn more about how we  can support your current VMware backup and recovery as well as your future requirements by contacting a PHD Representative today at 1.866.710.1882!

As we continue to build on robust legacy of the award-winning esXpress 4.0, PHD Virtual’s products meet enterprise requirements for flexibility and scalability by using the virtual appliance itself to perform backups, in less time, more reliably, and at a lower cost. We are the only enterprise data protection solutions that operate independent of the hypervisor offering greater stability and more security.

PHD Virtual also provides a collaborative path to integrate with all major physical backup solutions (including products from Data Domain, Quantum, Symantec, EMC, HP, IBM, etc.) for end-to-end data protection throughout the enterprise.  Today, thousands of customers worldwide trust their mission critical data to PHD Virtual’s solutions.

Learn more about our currents products, as well as our new offering for Citrix by attending a webinar on May 19 at 2 pm EST

This bug does not affect the stability of virtual machines during normal business operations and it only affects ESX/i 4.0 Update 1 environments. Update 2 will include a fix for this issue.

In the meantime, use one of the following workarounds:

VMware yesterday released a KB article about this issue. The KB article can be found at: http://kb.vmware.com/kb/1020158 (Opens in new Window).

Why do they sterilize the needle for lethal injections?
 
 
Why they don't make the whole plane out of the material used for the indestructible black box?

Why sheep don't shrink when it rains?
 
Why they are called apartments when
they are all stuck together?
 
If con is the opposite of pro, is Congress the opposite of progress?
 
Why they call the airport "the terminal"
if flying is so safe? 
 

Read more...

Learn about HP Virtual Connect technology directly from the HP's experts, as they take a deep dive into the technology and innovations. See first-hand how Virtual Connect technology can simplify and converge your server edge connections, integrate into any standards based networking infrastructure and reduce complexity, while cutting your costs.

The webinars in this series will be:

• March 30, 2010
  Virtual Connect Flex-10 Management of Connections and Bandwidth
  • HP Virtual Connect Flex-10 technology is a foundation for the virtualization capabilities offered by HP. These capabilities enable HP to provide a Converged Infrastructure without compromises. In this session, we will discuss how VC enables Insight Dynamics for ProLiant and HP/IO, how to manage the connections and bandwidth to quickly respond to change in workload. We will also discuss the economics of HP Virtual Connect Flex-10.
• April 15, 2010
  Server Edge Virtualization
  • The evolution of the data center architecture has seen shifts towards consolidation and virtualization. HP's Converged Infrastructure vision includes a view that all infrastructure resources should be virtualized. Server edge virtualization is a key technology that can help customers simplify the way servers connect to external networks.
• May 18, 2010
  Squashing the Myths
  • Virtual Connect is loved by customers and feared by competitors. So, let's talk about the best way to answer objections inspired by competitors.
• June 8, 2010
  HP Virtual Connect for FlexFabric
  • In this session, you will learn how to build a Converged Infrastructure with Virtual Connect to simplify your connection environment and reduce equipment, power, cooling and management costs. Find out how Virtual Connect for HP FlexFabric uniquely converges the BladeSystem server edge using Flex-10 technology with industry standard Ethernet and Fibre Channel, without compromising your existing infrastructure and operations.
• June 22, 2010
  Converging fabrics and reducing costs at the server edge
  • From its introduction, HP BladeSystem has delivered unprecedented innovation in the areas of data center infrastructure simplification and reduced TCO. In this session, you will hear how HP FlexFabric and Flex-10 technology enhancements will allow you to dramatically reduce the complexity, power and cost of connecting server blade enclosures to data center networks.
• July 13, 2010
  Managing data center connections and workloads with Virtual Connect Enterprise Manager (VCEM)
  • This month's webinar will examine how Virtual Connect Enterprise Manager (VCEM) helps to streamline IT operations and improve response times by centrally managing network connections, server workloads and Virtual Connect configurations for up to thousands of servers across the datacenter. The session will include live demonstrations of core VCEM functionality.
• August 10, 2010
  VC in small to mid-sized environments: Remote Branch, Remote office how to's
  • Virtual Connect isn't just for big data centers! It solves lots of problems for shops where the lone guy wears three hats. Or, the channel partner providing IT support for small customers. We'll show how it fits wherever you need servers connected.
• September 14, 2010
  Server I/O virtualization in your environment
  • With millions of ports shipped, HP Virtual Connect has demonstrated unique value in simplifying the way servers are connected to networks. In this session, you will hear about the latest innovations to server I/O virtualization and how they can improve operations of server, network and storage teams with blade and rack-mount server infrastructure environments across your data center.
• September 28, 2010
  Implementing Virtual Connect in your environment
  • Virtual Connect is the simplest way to connect servers to networks. Come learn how to deploy a converged Virtual Connect infrastructure with minimal disruption to existing data and storage networks. You will hear how to transition to a converged server edge so that you can dramatically improve the way you connect and manage servers across your data center.

If you are interested, you may go and register for the series at www.hp.com/go/VirtualConnectWebinars. Registration is free.

Last week when trying to reinstall Novell Platespin Portability Suite 8, I ran into the following error during the installation.

"Cannot connect to  IIS with http or https". As I was sure that my IIS and ASP.NET installation was correct, I couldn't for the life of my work out as to why I was getting the error. After turning to the search engines, I found that the problem was covered on several sites, including that of Novell. However, even Novell only seemed to point out that the problem is due to ASP.NET not being registered  with IIS properly. They also provided instructions on how to "fix" the issue by reinstalling IIS as well as re-registering ASP.NET with IIS. None of the remedies they offered worked in my case.

So, I decided to go with what I had in log files and to simply try and work out for myself what the problem could be. I then turned my attention to the IIS Manager. I noticed that whenever the installer tried to access the PortabilitySuiteAppPoll, the pool's state would changed from "Running" to "Stopped - Unknown Error". That would then explain the reason for the Portability Suite not being able to connect to IIS then. The question then was: "Why would the application pool shut down whenever the installer tried to connect?"

I then turned my attention to the logs. It turns out that in the Windows System Event log (Start -> Run -> eventvwr.msc) was logging the following error quite often.

"Warning, Event ID: 1021, Description: " The identity of application pool "PortabilitySuiteAppPool" is invalid. If it remains invalid when the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number."

Well, that just spells out exactly what was happening. Whenever the Portability Suite installer tried to access IIS, it would disable the PortabilitySuiteAppPool.

How I went about solving the issue:

I turned my attention to the IIS manager (Start -> Run -> iis.msc) again. Under Application Pools, I selected PortabilitySuiteAppPool. From the file menu, click "Action -> Properties". Under the "Identity" tab, I noticed that "Configurable" was selected and the User Name field contained "Portability Suite".

I then went on to inspect the "Portability Suite" user's properties using Computer Manager (Start -> Run -> compmgmt.msc). A closer look at the user's properties, revealed that the user was "Locked Out". Unlocking the user account solved the problem and the installation of Portability Suite went without issues.

I guess that when you uninstall Portability Suite, the user account is locked out, probably fopr security reasons. However, when installing Portability suite, the installer will try to create a new account, but as the account already exists, it just opts to use it as is, without making sure that the account is indeed active.

What a way to waste two hours of my already packed day!