virtualization Archives - Page 2 of 2

Backing up the vCenter 4.x AD LDS Instance

Posted on August 18, 2010February 11, 2019 by admin

vCenter is one of the most important components of your vSphere 4.x virtual infrastructure. Many advanced capabilities of vSphere 4 (vMotion, DRS, etc.) are not available without vCenter. Prior to vSphere 4.x, it was sufficient to backup the vCenter database and restore vCenter by building a new vCenter server, restoring the database, and reinstalling vCenter to attach to the restored database.

With the introduction of vSphere 4.x, vCenter 4.x started using Active Directory Application Mode (ADAM) on Windows Server 2003 and Active Directory Lightweight Directory Services (AD LDS) on Windows Server 2008 to accommodate Linked Mode for vCenter. The roles and permissions are stored in the ADAM or AD LDS database. In order to restore the roles and permissions, the ADAM or AD LDS database must be backed up.

VMware KB1023985 tells you that you need to back up the SSL certificates, vCenter Database, and the ADAM/AD LDS database. There are many well-known ways to back up a SQL database. However, backing up an AD LDS instance is a lesser known procedure. The following PowerShell script will back up the the AD LDS VMware Instance on Server 2008 and the SSL folder. As always, test it thoroughly before using it.
[powershell]#
# Name: VC_ADAM_SSL_Backup.ps1
# Author: Harley Stagner
# Version: 1.0
# Date: 08/17/2010
# Comment: PowerShell script to backup AD LDS
# and SSL folder for vCenter
#
# Thanks to Tony Murray for the AD LDS portion of the
# script.
#
#
#########################################################

# Declare variables
$BackupDir = “C:backupVMwareBackup”
$SSLDir = $env:AllUsersProfile + “VMwareVMware VirtualCenterSSL”
$IFMName = “adamntds.dit”
$cmd = $env:SystemRoot + “system32dsdbutil.exe”
$flags = “`”activate instance VMwareVCMSDS`” ifm `”create full C:backupVMwareBackup`” quit quit”
$date = Get-Date -f “yyyymmdd”
$backupfile = $date + “_adamntds.bak”
$DumpIFM = “{0} {1}” -f $cmd,$Flags
$ServiceVCWeb = “vctomcat”
$ServiceVCServer = “vpxd”

# Main
Stop-Service $ServiceVCWeb
Stop-Service $ServiceVCServer -force
# Create the folder if it doesn’t exist
if(Test-Path -path $BackupDir)
{Write-Host “The folder” $BackupDir “already exists”}
else
{New-Item $BackupDir -type directory}
# Clear the IFM folder (Dsdbutil needs folder to be empty before writing to it)
Remove-Item $BackupDir* -recurse

# Run Dsdbutil.exe to create the IFM dump file
Invoke-Expression $DumpIFM
# Rename the dump file to give the backup a unique name

Rename-Item $BackupDir””$IFMName -newname $backupfile
Copy-Item $SSLDir $BackupDir -recurse
Start-Service $ServiceVCWeb
Start-Service $ServiceVCServer

# End Main[/powershell]
This script utilizes the dsdbutil.exe utility on Windows Server 2008 to backup the AD LDS instance and SSL folder after it stops the vCenter services. By default it backs these items to “C:backupVMwareBackup”. Change it to your liking.

Now to restore the AD LDS instance data, follow the directions at Technet.

References

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023985

http://technet.microsoft.com/en-us/library/cc725665%28WS.10%29.aspx

http://www.open-a-socket.com/index.php/category/ad-lds-adam/

Active Directory Authentication – Accountability in ESX / ESXi 4.1

Posted on August 3, 2010February 11, 2019 by admin

As a part of TBL professional services datacenter practice, I perform many health and security checks on virtual infrastructures for clients. One of the common issues that I run into is the use of the default “root” account for administering ESX servers. This is an issue for two reasons:

The “root” account has a tremendous amount of power and the password for it is typically the same shared password on each ESX host.
If all administration is done with the “root” account there is no audit trail for accountability. It could have been Joe, Bob, or Sue that logged into the ESX host. You just don’t know.

Of course, most administration should be done through vCenter, but you still occasionally need to log into an ESX host directly. The solution to this that I have recommended in the past has been to create local user accounts coinciding with the Active Directory user name on each ESX host. Then do not use root unless absolutely necessary when performing administrative tasks directly on the host. However, this meant that the IT Administrators would need to manage user accounts in Active Directory and the local accounts on the ESX / ESXi hosts.

There has been a “less than ideal” solution to Active Directory authentication for quite a while (see Scott Lowe’s article). However, this solution was very laborious, involves the command line, and only worked on ESX Classic. Not ESXi.

With the release of vSphere 4.1, native Active Directory authentication is one of the many new features. Here’s how easy it is to implement once you have ESX installed.

Connect to your ESX/ESXi server with the vSphere Client.
Click on “Inventory” and highlight your ESX/ESXi server.
Click on the “Configuration” tab.
Navigate to “Software –> Authentication Services”
Click on “Properties” on the right hand side.
Change the “Directory Service Type” from “Local Authentication” to “Active Directory”
Once you do that and enter in your Domain, click “Join Domain” and you will be prompted for appropriate credentials to join the domain.
Click “OK” when you are done.

That’s it! Now you can have accountability controlled through Active Directory Authentication. Joe, Bob, and Sue can all use their respective Active Directory accounts for authentication. Accountability!

Permissions can now be added for Active Directory users and groups as well.

You can even use it with the vSphere CLI and the Direct Console User Interface (DCUI) on ESXi.

Should you still need the local “root” account for emergencies, it will still be available to you. Otherwise, do your company a favor and maintain an audit trail for administrative actions on your infrastructure.

This Kind of Leverage Does Not Come Around Very Often

Posted on July 19, 2010February 11, 2019 by admin

The exciting and also the maddening thing about working in the technology business is the frenetic pace of change and the rapidity with which new technology is introduced and then delivered to market. What technology is impactful for my business and what is merely interesting? I think a lot technology “innovation” falls in the latter category and may be nice to have in the organization some day…when I get around to it. However over the course of technology-time, there are a few product introductions that impel a business executive or technology leader to stop and consider whether this new technology represents an inflection in the market and/or a potential point of differentiation for my business. The CIUS introduced by Cisco may be one of those potential points of differentiation. http://www.cisco.com/en/US/products/ps11156/index.html?POSITION=SEM&COUNTRY_SITE=us&CAMPAIGN=HN&CREATIVE=Cius&REFERRING_SITE=Google&KEYWORD=cisco+cius

I don’t think the CIUS by itself is the point of differentiation for business. Rather, I think that it ties together multiple, strategic yet disparate technology initiatives into a rare “ah-ha!” moment for businesses is what makes the CIUS more than worth a look. While we are just getting the specs on CIUS (and we at TBL are scrambling to get one into our lab) on paper and through demonstrations, it looks like the glue that may bind several I/T investments together. The CIUS can be your desktop, your office, your phone, and your telepresence essentially in a device of similar size and demensions of an iPad. Designed for business, the CIUS will connect via any wireless protocol and also via carrier 3G and 4G networks. If I have a mobile workforce, if I have Cisco Unified Communications, if I am thinking about virtual desktops, if I am considering private cloud as means for service delivery for my business, then I just found a device that can serve as the “catcher” for most any technology I care to pitch to my end user community. One other cool thought about this device as a “desktop” of choice for the truly productive worker in 2011 and beyond – through VMware, I can provide secure, encrypted connectivity for the CIUS user without stressing or without having to use current remote access infrastructure. I can certainly leverage my current VPN infrastructure, but what if I want to get out of the remote access business and leverage the VMware tools instead? That might be cool. What if I was looking to have to refresh 500 laptops for salesman who log hundreds if not thousands of calls into my PC help desk for access, virus, and application issues? What if their “laptop” was a virtual image presented to a CIUS instead of a costly, support-heavy traditional device? And what if the CIUS could also give them high definition video capability? What is this device could “dock” and also be their desk phone? What if there were apps and connections I could write that delivered secure connections into my customized salesforce.com protal? This is starting to get pretty interesting. And the really cool part is that all the investments I made in Cisco UC, VMware, and Cloud Computing just got more valuable through a better access device.

I think this is where I am supposed to come up with an analogy to illustrate the fact that the CIUS leverages up most any investment you have made to your communications and applications infrastructure over the past 5 years…but one escapes me right now, so I will post a good one when it pops in my head, probably over the weekend cutting the grass.