Archive for the 'Tech Support' Category

Upgrading to VirtualCenter 2.5

Joe throttles

Just got through a rough few hours upgrading to the latest version of the VMWare Virtual Center server product (that was just released yesterday!). I know, right? I’m a glutton for punishment.

Anyway, just wanted to throw some notes up there in case there was anyone else out there who could benefit from the experience I just had.

We have two VCenter servers, both connecting to the same SQL 2005 Database server. With that setup in mind, here’s where I ran into trouble.

Started the upgrade to the first VirtualCenter server, with a full install of all the components including the VMWare Update Manager and the Converter Enterprise Edition.

The database connectivity step failed right away because the SQL Login I was using didn’t have “db_owner” privileges in the MSDB database. This is documented as a necessary permission for SQL Server in the VMWare Installation Guide, but I discovered the requirement in a roundabout way by looking at a SQL Profiler trace of the traffic being sent to the DB from the installer program.

I didn’t realize it needed that permission from a previous installation because we had initially installed VCenter using a local MSDE database.

NOTE: According to the documentation, the MSDB database permission is only needed during installation/upgrade, and can be removed after setup completes.

The next wackiness I encountered was installing the VMWare Update Manager component. It kept failing on install with a cryptic error message. I ran through the setup a few times and realized that the VMUM product has a TCP port conflict with the VirtualCenter Web Access components! We ordinarily don’t install the WebAccess components, but the “suite” installer program apparently automatically installs the Web Access business, silently.

So, Add/Remove programs, and modify the VirtualCenter Server setup to remove the Web Access components, and I was able to successfully install the VMUM components.

After my experience with the first upgrade, I foolishly thought upgrading the next server would be a breeze! The previous dot-revision upgrades for VC 2.0 were completely painless, so I had high expectations.

Little did I know that because of the SQL jobs that are created by the installation process (can anyone confirm that those jobs are part of the database install in 2.0?), there would be a naming collision and it would cause the database upgrade to fail.

Quickly reading through the DB upgrade log (found in c:\documents and settings\<username>\Local Settings\Temp) revealed the problem.

Luckily, we have two SQL 2005 databases in production (and remember, I had backed up the VC 2.0 databases before performing the upgrades). Restored to the second SQL 2005 database server, re-ran the installation routines (skipping the VMUM install!), and everything ran without a hitch.

Anyone else having some troubles upgrading? Next steps for the environment are to plan the ESX Server upgrades to v3.5! Hopefully those won’t be as painful.


Secure your servers without patching?

I ran into this article on InfoWorld (via BladeWatch), a product from Blue Lane Technologies that is described as a “patch proxy”. Basically it is a device (or software if installed in the VMWare Hypervisor), that intercepts and cleans/repairs or discards malicious traffic on the wire, protecting your precious computer without having to actually patch your servers.

I don’t think this is something I would exactly trust, but I can see in which environments it would have merit. For example, if we had very stringent uptime requirements, including planned downtimes, or if the change management process were so tightly regulated as to make it arduous or ponderous to deploy patches on the almost-continuous cycle they are currently being released.

The fact that it works within the VMWare Hypervisor to protect all the VMs hosted on that server, is of course, enticing. I will have to read more about this, and keep my ear to ground about any further developments.

Anyone out there heard of or used this product?

Adding a Data Recovery Agent to Group Policy in Windows

Barry (aka Fishbreakfast) came to me with an issue last week when I exclaimed:

I’m bored!

First off, don’t say you’re bored in the vicinity of the people who either a) are your boss or b) have more stuff to do than you do because you invariably come away with more stuff on your plate.

Anyway, the issue he had was that he had used Windows’ built-in Encrypting File System function to encrypt a few sensitive files. He got a new laptop, but didn’t either decrypt the files before transferring to the new laptop.

I can’t really blame him for that, though. Our assumption was that a Data Recovery Agent (RA) was enabled on our domain. Upon further investigation, we discovered that an RA, in fact, was *not* setup on the domain.

So, because I was bored, and because it is an interesting issue to look up, I hacked away at the problem until I could say definitively that Barry’s files could be decrypted.  Or the files were toast.

We have an Enterprise Certificate Authority installed into our Domain, so EFS/Recovery certificates are very easy to come by. What isn’t quite so obvious is how to include the RA certificate into the Group Policy that applies to particular domain computers. (You can read more about the whole process here.)

Okay, so the Group Policy setting that effects EFS Data Recovery can be found here: Computer Configuration -> Windows Settings -> Public Key Policies -> Encrypting File System. Right-click on that “folder” and choose Create Data Recovery Agent. This uses the automatic enrollment methods to request an EFS Recovery Certificate, and then apply it to the Personal Certificate store on the local computer, as well as upload it into the definition of the Group Policy Object.

Easy peasy, eh? A couple of caveats.

The only place the private key is stored (the private key being the part of the PKI cert that is required to actually recover any data) is on the computer where you requested the certificate. So be sure to export the newly created EFS Recovery certificate (including the private key) to a safe and secure backup location so that you can perform data recovery from somewhere else.

Also, the RA certificate is useful only if the group policy is applied *before* you encrypt any files. It’s worth noting, too that this only applies to Active Directory member computers. The process for setting up an RA is quite different for standalone machines.

So, back to Barry’s files? Given the above, they are definitely toast. Unless he’s got an army of PlayStation 3 consoles he could use to brute-force decrypt the files.

We now return you to your regularly-scheduled, non-geeky programming.

Shrink a Windows System Partition using VMWare Converter

As part of our license for VMWare’s Virtual Center Management Server, we get a copy of the VMWare Converter, Enterprise Edition, which allows trivial migration of any Windows physical host to virtual hardware. Additionally, the Converter can…well…convert from other virtual machine formats, including other VMWare products.

An interesting side-effect of this is that you can re-size your VMDKs (virtual disk image “files”). SAN space is expensive, so when we were looking to deploy some new VMs in our test environment, and noting that they only took up maybe 15% of the allocated disk space for them, it occurred to me that we could “clone” them by using the Converter, and simultaneously shrink them.

Normally this is something that you could do with ESX’s vmkfstools command-line utility, which allows you to shrink or grow these virtual disks. Unfortunately, Windows will sometimes complain when you try to resize the system/boot partition.

Here’s what it looks like:


Notice the “New Disk Space” drop-down; a 20GB VMDK, after conversion, will now be only 10GB! By choosing the same Virtual Center installation as the source and destination, you can effectively and conveniently resize your system partition. Don’t forget to remove the “old” VM (the source in this case), otherwise you’re not really saving any disk space!

Clone your Active Directory in 12 minutes using VMWare

Anyone out there who runs a successful Microsoft Windows Active Directory, knows that it is pre-eminently useful to have a test environment that very nearly represents your production environment…to do…you know…testing!

I went to a VMWare Disaster Recovery seminar and one of the presenters described how easy it was for them to use and create a test environment by simply taking one of their existing, virtualized Domain Controllers, cloning it, attaching it to a private network, and off you go.

I thought I would give that a try, and here’s what I came up with.

  1. Shutdown and clone a Virtual Domain Controller with a 20GB disk drive, 4.5 minutes.
  2. Power-on and attach the virtual DC to a totally private network, visible only to other virtual machines on the same box, 15 seconds.
  3. Install DNS on the Domain Controller to allow for dynamic updates within the private network, 3 minutes.
  4. Seizing FSMO roles from Domain Controllers that aren’t in this private network, 3 minutes.
  5. Sit back in wonder, 45 seconds.

These simple steps aren’t completely error free. Because the DC I chose was a replication partner with a bunch of other DCs and Active Directory Sites, it was necessary to do some tweaking to remove the “defunct” Domain Controller properties from the Active Directory. That process is documented well, here: Remove old Domain Controller Settings from FRS and the Domain.

Also, step 4 isn’t immediately obvious since most Domain Administrators would be familiar with the GUI-mode way of transferring FSMO ownership. That transfer, though, requires that the current FSMO owner be online to accede the role. Which brings us to this article: How to forcibly transfer (or seize) FSMO Roles from one DC to another from Daniel Petri (a really great resource for Windows administrators, IMO).

There you have it, folks. How to clone your Microsoft Active Directory Domain Services using VMWare in less than 12 minutes!

Virtual PC 2007 on Vista … a test!

Microsoft just released a new version of their hosted virtualization product called Virtual PC 2007. One of the big bullet points is that it is designed to perform best on Windows Vista. Luckily, I have Windows Vista installed on my laptop at work, and I figured I would try to prove just how well it does perform.

Initially, I was going to perform a head-to-head comparison with VPC 2007 and VMWare Server on Vista, but alas, VMS is not compatible with Vista. I’ve read that one should expect Vista-compatibility in the next version of VMS.

First off, here’s where you can download Virtual PC 2007.

Now, I’m running VPC on my Windows Vista laptop, which is a Dell Latitude D820, with a 2.16GHz Intel Core Duo, dual-core processor, with 2GB of RAM, a 7200-RPM 100GB Hard Drive, and an on-board Intel 945 Graphics chipset. I freshly defragmented my laptop’s hard drive, before installing VPC, just to make sure the HDD would perform as fast as possible.

Installing VPC was a snap. Simply launch the setup.exe as an administrator (in order to avoid the annoying User Account Control prompts). Less than five minutes later, it’s up and running, without requiring a restart.

Setting up a Virtual Machine (VM) couldn’t be easier. Click on New… follow the wizard through creating a virtual machine, choosing the “guest” OS. You can choose nearly every flavor of Windows Desktop and Server Operating Systems, OS/2, and the invariably enigmatic “Other” OS (which probably means some variant of Linux).

One cool thing is that the wizard chooses the minimum recommended RAM for the OS you chose. One odd thing is that the default size for the Virtual Hard Drive (VHD) that you attach to the VM is 100% of the free space left on your local hard drive; be careful to change this! Filling up your hard drive is a good way to force you to rebuild your computer.

Once you’ve configured your VM, click Start on the VPC Console dialog, and the VM powers on and begins to boot. There isn’t actually an OS installed on the VM, so you’ll need to attach a bootable CD or image file to the VM and go through the full OS installation steps, easy enough via the CD… menu option.

VPC Console

I went with Windows XP for my initial VM, with 256MB of RAM, and a 4GB Virtual Hard Drive. I figured that going through an installation of XP along with all 80 or so of the critical and optional updates that are required for a fresh build, would put VPC through its paces.

I have to say, I was pleasantly surprised at just how well it performed! Installing and patching XP didn’t take perceptibly any longer than when I’ve installed XP on full-physical hardware in the past (even on this same laptop). I was doing everything I would normally do on my laptop, while the XP VM was installing and patching, without any perceptible loss in performance. Launching Outlook 2007 and reading my email, browsing the web, working in Excel, all seemed as zippy as ever. In fact, I was able to rip (ahem…backup) two audio CD’s to Windows Media Audio Lossless format without a hiccup! That last is remarkable since a lossless compression of an audio file is extremely calculation-heavy.

Startup and Shutdown of the VM, too, didn’t seem to affect my normal activities. Also, these operations executed very quickly.

I did a little digging into the task manager and performance monitor on my laptop while running this VM. At startup, the CPU Utilization rarely rose higher than 50%, similarly at Shutdown. If the VM was just sitting there on the login screen, the CPU usage base-lined around 5-10%, which means there is a slight overhead for running the VM, but not terrible. The memory utilization on my laptop expanded to include the 256MB VM, but didn’t go beyond that, which is what I expected.

Overall, I’m really impressed with the ease of use and performance of Virtual PC 2007 on Windows Vista. And best of all, it’s completely free!

When a Vista-compatible version of VMWare Server is released, I’m looking forward to comparing this experience with that platform. Stay tuned!

VPC Running while I'm blogging about VPC

Cisco is on my short list…of enemies!

We’re investing (heavily) into IBM Blade Servers and VMWare at the office, and we got a brand-spanking new BladeCenter … (the chassis that holds each of those Blade Servers…think laptop docking station but for databases and email servers) … just before the winter break.

One of the first things Scott and I tried to configure networking modules, also known as the “Cisco Intelligent Gigabit Ethernet Switch Modules” or CIGESMs for short. Really, they should be called CYHTBMITSHESMs … as in “Cisco’s You-have-to-be-more-intelligent-than-Stephen-Hawking-ESMs” … The learning curve is so steep on these switches that it almost completely negates the usability features built into the rest of the IBM equipment that surrounds it.

It’s like putting a DOS prompt on an iPod; it just doesn’t make any sense!

The documentation doesn’t help. A couple of those PDFs are over 500 pages long, and filled with so much networking jargon and tech-speak, it might as well be a different language.

But, CIGESM, I have conquered you! I wanted to modify the VLAN configuration for particular ports attached to particular blades, and through many hours of sifting through technical support forums, gleaning small hints here and there on what exactly to do, and a little bit of trial and error, I am now a CIGESM VLAN master. Behold; the words below will open the doors to VLAN-nirvana.

configure terminal
vlan 3
name Firewall
vlan 400
name DummyVLAN
interface gi0/1
switchport mode trunk
switchport access vlan 3
no switchport trunk native vlan
switchport trunk allowed vlan 2,3
spanning-tree enablebpdufilter
spanning-tree portfast enable

It’s the “no switchport trunk native vlan” spell that’s the key.

Na’maste. <bow>

Change a Lightbulb, change the world!

It only takes 18 seconds to change a bulb. If every American home replaced just one light bulb with an energy-efficient bulb, together we could save enough energy to light more than 2.6 million homes for a year. Find out how you can save energy and cash by making the switch to energy-efficient light bulbs... and check out how many have already sold in your area.

CFL lightbulb

Coconut Trees

Coral Reefs

July 2018
« Sep