I found a function used to set RemoteDisplay.maxConnections here. By changing the RemoteDisplay.maxConnections it could be used to also change the other options so I modified the function to accept another parameter for the setting you want to add or change.

Here is the function:

Function Set-ExtraOptions{
param(
    [string[]]$vmName,
    [string[]]$KeyName,
    $KeyValue
)
    $vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

    $extra = New-Object VMware.Vim.optionvalue
    $extra.Key="$KeyName"
    $extra.Value="$KeyValue"
    $vmConfigSpec.extraconfig += $extra

        $vm = Get-VM $vmName | Get-View
        $vm.ReconfigVM($vmConfigSpec)
}

And here is how you call it:

Set-ExtraOptions -vmName VM_NAME -KeyName KEY_NAME -KeyValue KEY_VALUE

To set isolation.device.connectable.disable to FALSE for LabVM-A just call the function like this:

Set-ExtraOptions -vmName “LabVM-A” -KeyName isolation.device.connectable.disable -KeyValue FALSE

The process is pretty simple and detailed instructions can be found in the VMware KB here which includes this video:

I am not going to walk through the steps, the video does a great job of that. The video shows updating from 3.5 to 4.1, the only difference in the 4.0 to 4.1 upgrade process is the upgrade bundle that is used.

I had originally planned to do half my hosts on one morning and the second half the next but the upgrade was quick, it did not take more than 10 minutes for each host, so I went ahead and updated all of them.

Here is the the warning message:

Active Directory Web Services encountered an error while reading the settings for the specified Active Directory Lightweight Directory Services instance. Active Directory Web Services will retry this operation periodically. In the mean time, this instance will be ignored. Instance name: ADAM_VMwareVCMSDS

This message was being repeated once every minute.

After a bit of research I found a post in the VMware Community which lead me to the fix that is here.

The registry value for \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ADAM_VMwareVCMSDS\Parameters\Port SSL was set to type REG_SZ and the data for the value was empty. I deleted the Port SSL value, re-added the value as a REG_DWORD with the data set to a decimal value of 636, restarted the VMwareVCMSDS service, and all is well.

Thanks to TheSaffaGeek for this fix.

Currently our vCenter is on a separate physical box running Windows 2003 with 4 GB RAM and a single 2.66 Ghz dual core processor. The vCenter database is on Microsoft SQL 2005 also running on the same physical box. The hardware we have in place would support running vCenter 4.1 but since 4.1 requires a 64 bit OS, and ours is currently running on 32bit, I am going to upgrade/migrate vCenter to a new guest VM running Windows 2008 R2 64. I am also going move the vCenter database to the new VM (I know it is not necessarily best practice to run the DB on the same box as vCenter but my environment is small and it should work out ok – if not I will move the database to another server at a later date) which is running Microsoft SQL 2005 x64.

The vSphere 4.1 Upgrade Guide available from VMware provides a detailed step-by-step process. This VMware KB article (5850444) also gives an overview of the process of moving vCenter and the SQL database from one host to another.

Here is my basic walk-through of upgrading to vCenter 4.0 to 4.1 while moving to a new server that happens to be a VM.

1. The new guest hardware is configured with 2 vCPUs, 4 GB RAM, and 2x20GB hard drives (1 for OS and 1 for data). I have installed Windows 2008 R2 and installed all the “important” updates from Microsoft. Microsoft SQL 2005 has been installed and Service Pack 3 has been applied to it. Microsoft .NET Framework 3.5.1 Features has also been installed using Server Manager.
    
2. Using the SQL Server Management Studio two new databases are created on the new server, one for vCenter and one for VMware Update Manager (VUM).
    
3. Set up a 64bit ODBC connection to the vCenter database and a 32 bit ODBC connection to the VUM database. Both connections are set up as System DSNs and use the SQL Native Client. To create the 32 bit ODBC connection use the application C:\Windows\SysWOW64\odbcad32.exe
    
4. Note what ESXi host the new 4.1 vCenter VM is running on so you can connect directly with the vSphere client if a console is needed. Stop the vCenter Server service in services.msc on the 4.0 vCenter server. (I also disabled the service).
    
5. Use SQL Server Management Studio to create backups of the 4.0 vCenter and VUM databases. Then restore the databases to the newly created databases on the new vCenter 4.1 server.
    
6. On both the 4.0 and 4.1 server copy the datamigration folder from the vCenter iso to C:\datamigration and unzip the datamigration.zip file within the folder. On the 4.0 server run the backup.bat script. This script will create a data directory in the C:\datamigration. Copy this directory (and its contents) to C:\datamigration on the 4.1 server. Note: If you are using the SQL 2005 Express database for vCenter the datamigration backup script will also backup the vCenter and VUM databases.
    
7. Since we wanted the new vCenter 4.1 server to have the same IP address as the old server, this is the point where we changed the IP addresses of both the 4.0 and 4.1 servers and verified DNS was resolving everything correctly.
    
8. Connect the CD on the new 4.1 server to the vCenter iso (you will need to connect to the host with the vSphere client to connect the CD to VM unless you did this before you stopped the vCenter Server service – live and learn). Run the install.bat file located in C:\datamigration on the 4.1 server to start the vCenter installation.
    
9. The VMware vCenter Server installation wizard will run. Follow the installation and make the necessary choices. When prompted for the database select the use existing supported database option and choose the ODBC/DSN (64bit) that was set up for vCenter. Select upgrade the database to 4.1.
    
10. Once the vCenter Server installation completes the VUM installation wizard will launch. Follow the same process for the VUM installation. When prompted for the database select the use existing supported database option and choose the ODBC/DSN (32bit) that was set up for the VUM database.
     
11. Once installation completes log in to the new vCenter Server using the vSphere Client install the updated VUM plugin. Check each host for a task – Upgrade vCenter Agent.
     
12. Test, test, and then test. – I checked the following: DRS/HA configurations for the cluster, perform a vMotion of a VM, Scan a Host for Updates, Check any scheduled tasks, Check logs for any errors, etc.
     

The update went without issue and our vCenter is now 4.1 on a Windows 2008 R2 64bit virtual machine. Will be upgrading the ESXi 4.0 hosts to 4.1 next week.

@jirahcox had sent me the following tweet the night before “@herseyc I had to uninstall Update Manager 4.0 then reinstall 4.1 with a clean db. UM 4.1 over 4.0 installed fine, but wouldn’t scan hosts.”

I did have to reattach my update manager baselines before I could scan hosts. Not sure why the baseline attachments did not carry over in the datamigration/database restore??? But after reattaching them all worked well without having to reinstall VUM. Thanks to @jirahcox for the heads up on a potential issue.

Here is a list of resources I used to research and prepare for the migration:

• vSphere 4.1 Upgrade Guide
   
• VMware KB: Migrating vCenter Server to a different host machine
   
• VMware KB: vSphere 4.1 upgrade pre-installation requirements and considerations
   
• VMware Migrate vCenter 4.0 Database to New vCenter 4.1 Server
   
• Virtualizing vCenter With vDS Catch-22
   
• Design Challenges Of Virtualized vCenter With A vNetwork Distributed Switch

@ChildRoland67 tweeted: My @VMware environment has been so stable for so long, I’m not sure I’d know what to do anymore if it broke.

Our VMware environment is also very stable and the issues that we do have from time to time are usually self-induced

Version info (Changelog) can be found here and you can download it from right here.

Most of the book was written while vSphere was still in beta so the book covers ESX/ESXi 3.5 and Virtual Center 2.5.

I have only thumbed through it so far but it looks like there is a lot of good information. There are some pretty good tables with the configuration differences between 3.5 and 4 in Chapter 1. The command line reference in Chapter 5 should be useful to both versions, as well as the Security stuff in Chapter 6.

Looking forward to reading the book cover to cover.

Use the Stage wizard to download the patches before using remediation. This downloads and prepares the patches while the host is still online. This decrease the amount of time the host is off line (in maintenance mode) will applying patches.

Stage and Remediate in Upate Manager

You can stage at the cluster and Data Center level to prepare all hosts in the cluster for remediation.

Update Manager Stage Wizard

Shortcuts in Home-Inventory-Hosts and Clusters

Stage and Remediate Host - Cluster and Data Center

Just updated to ESX 4.0.0 build 175625. Staging took about 3 1/2 minutes total and remediation took about 12 minutes per host (this include Entering maintenance mode, VM migration, patch installation, reboot, exit maintenance mode). Three and a half minutes of savings may not seem like much, and across three hosts it really isn’t that big of a deal, but across 20 hosts that would make a huge difference.

Awesome new vSphere feature!

To enable it ssh to the service console and log in as root.

[root@vmware]# chkconfig –level 345 vmware-webAccess on

Verify it has been enabled for run level 3, 4, and 5

[root@vmware]# chkconfig –list vmware-webAccess
vmware-webAccess 0:off 1:off 2:off 3:on 4:on 5:on 6:off

Start the service

[root@vmware]# service vmware-webAccess start
Starting VMware Virtual Infrastructure Web Access:
VMware Virtual Infrastructure Web Access [ OK ]

You can now log in a root at https://vmwareESXhostname/ui/

Does anyone know why VMware disabled this by default?

Awesome resource for anyone looking into deploying or upgrading to vSphere 4.0