Friday, January 7, 2011

Unable to add an ESX host to vCenter

While this issue has been discussed at length both in the communities and in knowledge base articles (ex. http://kb.vmware.com/kb/1003409), I cannot find a single KB article that lists every step I would perform to fix the issue and the order in which I would perform them.
There are two different kinds of ESX to vCenter connectivity problems that I would like to discuss:
  1. Initially adding an ESX host
  2. Reconnecting a disconnected ESX host
In my experience, the first problem is almost always caused by a DNS or network connectivity issue. To solve this, first try to add the ESX host by IP address instead of FQDN. If this works, ensure the ESX host and vCenter Server have the appropriate DNS servers, that they can resolve through them (i.e. nslookup) to other hosts, and most importantly that they can resolve to each other. If/When DNS is working properly, try to connect between the ESX host and vCenter server via ping and SSH.
In the case of a disconnected ESX host, the second problem listed above, simply restarting the management services fixes the issue most of the time:
# service mgmt-vmware restart
# service vmware-vpxa restart
The important thing to note is that after restarting the management services you may need to wait several minutes in order to confirm whether or not the issue is resolved (i.e. the host reconnects to vCenter). If this fails, in some rare cases closing out of the VI session and establishing a new connection resolves the issue. If the issue is still not resolved, disconnect the ESX host from vCenter and then manually remove the vmware-vpxa rpm from the host:
# rpm -e `rpm -qa | grep vpxa`
Finally, reconnect the ESX host. As a last-ditch effort, if the host is still listed as disconnected or remains "In Progress" during the "Add Host" function, restart the vCenter Server service.
While the KB articles suggest a variety of other options, the above steps have always resolved the issue for me.

Tuesday, January 4, 2011

Installing vCenter 4.1 with SQL database and ODBC DSN Connection

Creating SQL Database and ODBC Connection

Creating the service account
Before you create the database on the SQL server, create a domain account for the vCenter service. This service does not need to be a member of any group aside from the Domain Users group.
image image
Log onto the new vCenter Windows Server 2008 R2 64-bit server and open up Server Manager.
image
Navigate to Configuration –> Local Users and Groups –> Groups and open up the Administrators group. Add the service account to the local administrators group.
image
Creating the SQL Database on Microsoft SQL Server
Open up SQL Server Management Studio.
image
Once SQL Server Management Studio launches, connect to the SQL instance.
image
Once in SQL Server Management Studio, start a new query with the New Query button at the top left hand corner.
image
This will bring up a new query window.
image
Now if we refer to page 80 in the installation guide (http://www.vmware.com/pdf/vsphere4/r41/vsp_41_esx_vc_installation_guide.pdf) we see the following script:
use [master]
go
CREATE DATABASE [VCDB] ON PRIMARY
(NAME = N'vcdb', FILENAME = N'C:\VCDB.mdf', SIZE = 2000KB, FILEGROWTH = 10% )
LOG ON
(NAME = N'vcdb_log', FILENAME = N'C:\VCDB.ldf', SIZE = 1000KB, FILEGROWTH = 10%)
COLLATE SQL_Latin1_General_CP1_CI_AS
go
use VCDB
go
sp_addlogin @loginame=[vpxuser], @passwd=N'vpxuser!0', @defdb='VCDB',
@deflanguage='us_english'
go
ALTER LOGIN [vpxuser] WITH CHECK_POLICY = OFF
go
CREATE USER [vpxuser] for LOGIN [vpxuser]
go
sp_addrolemember @rolename = 'db_owner', @membername = 'vpxuser'
go
use MSDB
go
CREATE USER [vpxuser] for LOGIN [vpxuser]
go
sp_addrolemember @rolename = 'db_owner', @membername = 'vpxuser'
go
I never end up using this script because it essentially creates a new SQL authentication account for vCenter to use. What I prefer doing is to add the vCenter domain service account to the permissions instead of creating a completely new one. The following is a modified script that I use instead.
Please note that the parameters that will need to be changed accordingly to your infrastructure are Enlarged and BOLDED.

use [master]
go
CREATE DATABASE [VCDB] ON PRIMARY
(NAME = N'vcdb', FILENAME = N'D:\databases\VCDB.mdf', SIZE = 2000KB, FILEGROWTH = 10% )
LOG ON
(NAME = N'vcdb_log', FILENAME = N'D:\databases\VCDB.ldf', SIZE = 1000KB, FILEGROWTH = 10%)
COLLATE SQL_Latin1_General_CP1_CI_AS
go
use VCDB
go
sp_grantlogin @loginame=[domain\svc_vCenter]
go
sp_defaultdb @loginame=[domain\svc_vCenter], @defdb='VCDB'
go
ALTER LOGIN [domain\svc_vCenter] WITH DEFAULT_LANGUAGE = us_english;
go
CREATE USER [domain\svc_vCenter] for LOGIN [domain\svc_vCenter]
go
sp_addrolemember @rolename = 'db_owner', @membername = 'domain\svc_vCenter'
go
use MSDB
go
CREATE USER [domain\svc_vCenter] for LOGIN [domain\svc_vCenter]
go
sp_addrolemember @rolename = 'db_owner', @membername = 'domain\svc_vCenter'
go
Parameters:
D:\databases\VCDB.mdf' = The location of the database and the database filename.
D:\databases\VCDB.ldf' = The location of the log and the log filename.
domain\svc_vCenter = The vCenter service account name preceded by the domain NetBIOS name.
------------------------------------------------------------------------------------------------------------------------------------------------------------------
For those who are interested, the line:
ALTER LOGIN [vpxuser] WITH CHECK_POLICY = OFF
… was taken out because this line disables the password policy check and only applies to a SQL Authentication account.
The code essentially does the following:
  1. Create a database named VCDB.
  2. Add the domain service account we created to the SQL server.
  3. Set the default database for the service account.
  4. Set the default language for the service account.
  5. Give service account db_owner permissions to VCDB.
  6. Give service account db_owner permissions to msdb.
Once you’ve made the appropriate changes execute the code and if no syntax mistakes were made, you will see the message:
Command(s) completed successfully.
image
The new database has now been created and the vCenter service account now has the proper permissions.
image
Creating the 64-bit ODBC DSN Connection
Update: If you find that you’re missing the SQL Server Native Client 10.0 option, please see this link below.
Microsoft SQL Server 2008 Feature Pack, August 2008--
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=C6C3E9EF-BA29-4A43-8D69-A2BED18FE73C&displaylang=en

--Microsoft SQL Server 2008 Feature Pack, October 2008--
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=228DE03F-3B5A-428A-923F-58A033D316E1&displaylang=en

--Microsoft® SQL Server® 2008 R2 Feature Pack--
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ceb4346f-657f-4d28-83f5-aae0c5c83d52

Open up the Start menu and navigate to Administrative Tools –> Data Sources (ODBC).
image
Navigate to the System DSN tab and click Add.
Make sure you click on the System DSN tab before you create the DSN!
image
A common mistake I’ve come across when troubleshooting DSN creation problems is that a SQL Server driver was created instead of the SQL Server Native Client 10.0. So make sure you select the latter and click Finish.
SQL Server = WRONG
SQL Server Native Client 10.0 = RIGHT
image
Fill in the following fields:
Name: This is just a logical name and can be anything you want.
Description: Logical description.
Server: You can either put the NetBIOS or FQDN of the server name. I personally prefer the FQDN.
image
Since we’re using a domain service account, we can leave the following parameters as default.
image
Make sure you change the default database to your vCenter database that you created earlier. The name in the installation guide is VCDB.
image
Leave the following settings as default and click Finish.
image
A window is now presented that allows you to test the ODBC connection. You might wonder what credentials it’s using to test the connection and the answer to that is what you’re currently logged in as. This DSN is set up to automatically use whichever process that attempts to run it and since the process that will be using this DSN is ran under the domain service account we created, those credentials would be passed.
image
To test the service account’s permissions, make sure you’re logged into Windows with that account.
image
Once you click finish, you will now see your new ODBC DSN.
image
Hope this helps clarify the process. Remember this is for vSphere 4.1 and not 4.0 as the latter uses a 32-bit ODBC DSN.

Installing VMware vCenter 4.1

While the installation for VMware vCenter 4.1 isn’t a whole lot different than vCenter 4.0 or even Virtual Center 2.5, I figure I’ll write a post describing the process since I documented one of my installs.
Some key items that we should be aware about are:
  • Note that 4.0 uses a 32-bit ODBC driver while 4.1 uses 64-bit
image
  • If you’re using a full version of SQL, we need to create the database first 
  • Log in with the service account you want the vCenter services to be ran as.

Launch the installation and ensure that you right-click and choose Run as administrator.
image
Read the EULA.
image
Agree to the EULA.
image
Type in the information for the required fields.
image
If you created the ODBC connection correctly, you’ll be able to see it in the list.


image
I was a bit annoyed to see that I had to log in as the service account in order to set the services to run as the service account. As shown in the screenshot below, I had logged in with my own account did not have an option to change it.
image
Select the directory you want the binaries to be installed into or leave it set to the default.
image
Choose standalone or linked mode.
image
Change the ports if required.
image
Select the proper settings for your environment.
image
Kick off the install.
image
The install will proceed from this point on.
image
image
image
image



Saturday, January 1, 2011

Windows Server 2008 R2 Migration Tools

The Windows Server 2008 R2 Migration Tools are a set of tools available to simplify migration of various roles, features and other server data to a new server running Windows Server 2008 R2.
As described on the Migration Tools TechNet documentation, the following can be migrated using these tools:
Roles
Active Directory Domain Services and DNS
DHCP Server
File Services
Print Services

Features
BranchCache

Settings and Data
Data and Shares
IP Configuration
Local Users and Groups

Installation
Start by installing the Windows Server Migration Tools feature from the Add feature wizard in Server Manager on the destination server running Windows Server 2008 R2:
image
image
image
You can find the new feature on the Start-menu in Administrative tools:
image
After the “Windows Server Migration Tools” PowerShell prompt are opened, go to C:\Windows\System32\ServerMigrationTools.
Type SmigDeploy.exe /? to list the description and usage of this command.
image

Example usage
In this example we`ll migrate a DHCP Server running on a Windows Server 2003 machine. To create a deployment package for Windows Server 2003 32-bit, execute the following command:
image
When the package folder are successfully create, copy the folder to the source DHCP Server:
image
The only requirement on the source Windows Server 2003 server are Windows PowerShell (and thereby .NET Framework 2.0).
Start SmigDeploy.exe from the SMT_ws03_x86 folder to fire up Windows PowerShell with the Windows Server Migration Tools snapin.
Available cmdlets for this snapin:
image
Execute the cmdlet Get-SmigServerFeature to get the set of all Windows features that can be migrated from the local server:
image 
image
The cmdlet returns the DHCP Server as a feature available for migration:
image
Here we got the DHCP Leases on the source DHCP Server, which are to be migrated to the Windows Server 2008 R2 server:
image
To export the DHCP Server configuration and database, run the Export-SmigServerSetting cmdlet with the following parameters (you will be prompted for a password to protect the exported file):
image
The export was successful, and we can see the exported *.mig-file:
image
Copy the *.mig file to the target DHCP Server.
To import the DHCP Server configuration and database, run the Import-SmigServerSetting cmdlet with the following parameters (you will be prompted for the password  for the exported file):
image
The DHCP Server feature was not installed on the Windows Server 2008 R2 server, but the Import-SmigServerSetting takes care of this automatically:
image
The import was successful:
image
After starting the DHCP Server service we can open the DHCP Server management console and verify that the migration was successful:
image
This concludes this post regarding the new Migration Tools, and I must say I really like this new feature, especially the fact that it`s leveraging Windows PowerShell. I would recommend you to play around with this in a lab environment to get to know it`s usage.
Edit 25.08.2009: As stated in the documentation on Technet, the DHCP-service on the source server must be stopped (Stop-Service DHCPserver) prior to the export. Thanks to Max for pointing this out