If you run the VMware Converter against a GPT based disk, you’ll receive an error about EFI firmware not being supported. Here’s how to P2V a GPT based Windows server (for free!). What we’re doing is taking a cold image based backup of the physical server and restoring it into a VM. To do this, we’ll use a free and open source tool called Clonezilla. While you could power up the physical server while you get the VM built, it’s best to keep the physical server offline until you bring the VM up. This will prevent data changes between when you take the image and when you restore it.

1. Run Clonezilla against the physical box and image the server to an ISO
2. Create a VM with the production name of the server
   1. Make sure the VM’s disk is the same size or bigger as the physical server’s disk
3. Boot the VM from the ISO
4. Restore the image from the samba_server option
5. The following steps came from Andrew Cohon at Andrew’s Cheap Thrills
   1. If you get a STOP 0x0000007B error, follow these steps:
      1. Mount the Server 2008 R2 DVD to the VM and boot to it.
      2. At the first screen (Language Selection), hit Shift-F10 for a command prompt.
      3. Run Regedit.
      4. Load the system hive from the VM’s disk:
         1. Highlight HKEY_LOCAL_MACHINE
         2. File > Load Hive
         3. Select < c: > \Windows\System32\config\system
         4. Name it something like “asdf”
1. Expand HKEY_LOCAL_MACHINE\asdf\ControlSet1\Services\LSI_SAS
2. Change the data for value “Start” from “3″ to “0″.
3. File > Unload Hive.
4. Exit regedit.
5. Reboot the VM.
6. Install the VMware tools.
7. Remove the old network adapter
   1. Open a command prompt and type the following
      1. set devmgr_show_nonpresent_devices=1 (hit enter)
      2. start devmgmt.msc (hit enter)
   2. Go to the View menu and click “Show Hidden Devices”
   3. Go into Network Adapters and remove the greyed out adapters
8. Put the production IP on the VM’s NIC.

Hope this helps someone out!

I stopped, pondered and then Googled.

Documentation? Limited.

Forums? Informative.

I found the following post on the EMC Community forums on how to tell if an enabler requires a reboot. I call it the “peek behind the curtain” check. The enabler file (.ena) is really a ZIP file (.zip). Change the extension, open the file, and then open the TOC.txt file. In there, you’ll see the following:

That INSTALL_REBOOT_REQUIRED line will tell you whether or not a reboot is required.

It turns out that specific enabler did require a reboot. Saved my biscuits.

This could also be useful to set a temporary password during the install and then be changed later after the install is complete.

Before you go through the process of installing UCS Central, make sure all UCS clusters that you plan on adding to UCS Central are on the 2.1 firmware. Older firmware is not supported with UCS Central. From a deployment standpoint, there are two options. One is a clean build from an ISO, the other (and my preference) is a pre-built virtual appliance. Deploy the OVA into your virtual host and power it up. If you’ve ever configured a brand new fabric interconnect, the setup prompt will look very familiar. The only difference is the addition of the shared secret. The shared secret is the password you’ll use to register UCS domains (clusters) with UCS Central. It cannot be a dictionary word, and you’d be surprised what’s in the dictionary. I recommend doing a letter/number replacement. 0 for o, 4 for a, etc. After you apply the configuration, you’ll have successfully deployed UCS Central.

There are some things you’ll need to do before you register a UCS domain with UCS Central. First, configure NTP on UCS Central. This is located on the Operations Management tab under Domain Groups, Domain Group root, Operational Policies, Time Zone.

Next, configure NTP on the UCS domain. This is under the Admin tab, Time Zone Management:

Time synchronization is very important. If the time is off, a UCS domain will fail to register.

Wait for the System Time in the bottom right corner to match up. The hour may not match up, but that’s OK. If it doesn’t match, it’s the time zone difference between where you are and UTC. In my screenshots, that’s 6 hours (Eastern Daylight Savings Time). Once the time sync is complete, it’s time to register with UCS Central. Under the Admin tab, go to Communication Management, UCS Central.

Click “Register With UCS Central”. A new window will appear. Enter the IP or hostname of UCS Central in the Hostname/IP Address field and the Shared Secret you configured in the initial deployment of UCS Central.

The options in the window are to determine what has control, the local configuration or the global configuration in UCS Central. This can be changed later, so you can register it with everything on the local configuration being left alone. This could be used as a configuration tool for a new install if you had a standard build to use with it.

Click OK to kick off the Registration. If you want to see the progress (which isn’t much), click the FSM tab. When it’s done, you’ll see the following in UCS Central:

At this point, UCS Central is able to manage that UCS domain. At this point, UCS Central is limited to mostly view-only things. It can see service profiles, templates, pools, etc. but can only make limited changes to them. In later versions, you’ll be able to create global service profiles and templates. This will allow you to move service profiles between domains, which is an amazing idea.

Here’s Cisco’s data sheet on all of the features of UCS Central. You can build this in your home lab (like I did), using the UCS Platform Emulator. It’s a fantastic tool for playing around with UCS and testing out the features of new products like UCS Central.

Get in there and dig around. Let me know what you think in the comments.

After reading it, I started thinking about where I (and my family) came from. My dad loves to tell this story, so I figured I’ll tell it here. My dad grew up in the Hawkins Village projects of Rankin, PA, just outside of Pittsburgh. It wasn’t a nice place then, it certainly isn’t a nice place now. Growing up in the Steel City, it was almost a guarantee that you got a job in one of the mills. Rankin happens to be next door to Braddock, the home of U.S. Steel’s Edgar Thomson Works. After high school, he went across the street (literally) into the employment office of the mill. After doing some random maintenance jobs, he decided enlisting in the military was a better idea (it was 1969, he was sent immediately to Vietnam).  After coming back, he went back to the mill for a few years before using the GI Bill to go to college. He knew he wanted to get out of Pittsburgh and raise a family that wouldn’t have to work in the mill. He became a lawyer and gave us every opportunity to succeed. Fast forward to my senior year of college. A professor mentioned that I should take the internship test for the U.S. Steel. At the time, they had a math test for IT positions. I almost didn’t go because it meant getting up at 8 AM on a Saturday. No, I’m not kidding. I took the test and passed. Got through the interview process and into a well paying internship for a large company that generally hired its interns upon graduation. My dad was proud of me and thought it was great that I was going to work in the office instead of the mill. Before I started, I got a phone call asking if I would mind changing locations and working in the mill. Not just any mill though, the Edgar Thomson Works in Braddock, PA. I accepted. I told my dad and his first words were, “I worked my tail off to make sure you kids didn’t end up in the mill. What’s your first job out of college? A job in the mill…” I could hear the smile on his face. He recognized the hilarity of the situation and thought it was fantastic that I was working in the mill. He thought I should move into Hawkins Village and wondered if his old building was still there (it wasn’t and had burned down 15 years ago). 

I look back on that story and realize the phone call to go work in the mill was a complete blessing in disguise. Headquarters was siloed. I would have been stuck in desktop support effectively forever. In the mill, I did desktop, network, server and application support. I got a far wider experience in the field compared to the interns at headquarters. I worked so hard that they felt forced to hire me because they couldn’t lose the effort I put in. I was on call 24/7/365 from the second year of my internship (I did a 5 year program in school, so I had an extra year of internship) through the last day of work 3.5 years later. I learned more in that job both professionally and technically than I learned in 5 years of school. The people there took chances on me and I feel it paid off. I’m forever grateful to them for giving me an amazing start to my career. Hard work makes the dream work. 

Changing the IP of vCenter in the past wasn’t a terribly hard thing to do. Change the IP, modify the proxy.xml file (if needed), restart services, done. You may run into an issue on the DB side (See my previous post on changing the IP of vCenter here), but other than that it’s easy peasy. Enter Single Sign On (SSO). It’s a crucial piece of the puzzle that gets overlooked when you’ve changed IPs on a vCenter box.

I made the normal changes, including changing the IP that SQL Server (also running on the vCenter VM) was using. I start the VirtualCenter Server service……no bueno.

Let’s start with the logs. Tracing the vpxd log under C:\ProgramData\VMware\VirtualCenter Server\Logs finds the following error:

It was failing making the connection to Single Sign On for the STS Root certificates. Here’s the fun part: SSO starts regardless of what IP it has. I’m staring at the VMware Single Sign On service and seeing it’s started and wondering why nothing can connect to it. Checking the logs at C:\Program Files\VMware\Infrastructure\SSOServer\logs shows the following:

SSO had the wrong IP for the database server (all on the same box, it’s a lab) and couldn’t connect to LDAP for AD authentication. That’s not cool. Enter this VMware KB (2033516): http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2033516

Performed the changes, ta-da vCenter started.

There are two ways to go about this. The installer gives you the option of SQL Express or using a supported database (MS SQL, Oracle, DB2, or Postgres). In this post, I’ll show you how to install SSO with an existing SQL Server instance. The easiest way to install SSO is to use the SQL Express as the installer handles the DB creation and connectivity. From a backup perspective, an existing SQL Server instance is far better.

For this, you’ll need an existing SQL Server instance. This can run on either the vCenter itself or as a separate server. I won’t bog through installing SQL Server, we’ll just assume you’ve installed it and have it running.

Step 1: Create the database.

Inside [vSphere 5.1 Install Media]\Single Sign On\DBScripts\SSOServer\schema\mssql is a set of scripts that will build or change the Single Sign On database. Open SQL Server Management Studio, connect to your SQL Server instance and drag rsaIMSLiteMSSQLSetupTablespaces.sql into Management Studio.

This will open a new query window in SQL Server Management Studio. We need to change the file locations for the database.

Change this to the location you wish to save the file into. Do this for the other two file location lines. These should all stay together unless you specifically (and in production, should) separate log files from data files. In this case, this is in my lab so I kept them in the same location.

Execute the procedure and a new database called RSA will be created.

We will also need to enable Mixed Authentication. The installer uses a built in user to the database (RSA_DBA) to connect to the database. Right click on the SQL Server in the left pane and click Properties. Click Security in the left pane of the new window and select SQL Server and Windows Authentication mode.

You can close SQL Server Management Studio now.

Step 2: Install Single Sign On

Run the installer from the install media. This can be done via the “Simple Install” (which installs SSO, vCenter Inventory Service and vCenter Server) or by installing just SSO.

Create a new primary node for a vCenter Single Sign On Installation

In this instance, we’ll create a primary node for a new installation. Because we’re doing this, you could add another node later for high availability. Without this, you’re stuck with one node. If that node fails, so does vCenter. If you set up basic, I would suggest running it on the same machine as vCenter as it eliminates a point of failure. The only failure points are the service  failing or the backend database not being available.

Create a password. Make it a good one and save it somewhere safe (like KeePass or LastPass).

Because we’ve already run the SQL script to create the database, we’ll select the Use an existing supported database option. The SQL Express option is far easier, but doesn’t scale up as well and backups are a bit trickier.

Here’s where the fun begins. Set the database type to Mssql, insert the database name of RSA (which is the database the script creates), enter the IP or hostname of the SQL server, and check Use Windows Authentication. Make sure you’re an admin on the SQL server or you’ll get an authentication failure. If you knew a SQL user that had admin rights, you could enter those credentials here.

Click Next on the Fully Qualified Domain Name or IP Address of the host. If it can’t resolve the hostname, that’s OK.

Next, select a user account to run the Security Support Provider Interface server as. I took the default in my lab. If you have an application-only user you prefer to use, here’s where to enter it. I would make sure it has rights to the Single Sign On database. In my case, I was running it on the same machine as Single Sign On so the default was sufficient.

Select the location you wish to install the Single Sign On service to

Select the port you wish to use for the service. Taking the default is preferred here.

Click Install. If you get any errors, run them through the VMware KB. The documentation is well done on common errors. I got a “Error 29115: Cannot authenticate to DB” error, which was resolved by setting up SQL and Windows authentication on the database server.

That’s it! Install the Inventory Service and vCenter Server and you’ll have an up and running vCenter 5.1 install.

If you’re upgrading your existing vCenter and will run SSO with it, I would HIGHLY recommend adding memory to the VM or machine running vCenter. It works with 4 GB but is much more responsive with 6 GB at a minimum, 8 GB if you can spare it. The other option is to split SSO off onto its own VM or machine. You could build a multi-node install for availability this way.

Leave comments below and I’ll try to answer your questions!

I got to check out an iPhone 5 the other day. It’s stunningly light in comparison to the 4S or even my Galaxy Nexus. It feels smaller than a 4S, even with the larger screen. The bigger screen is cool, but by keeping the width of the phone the same I could easily reach the top and bottom corners with my thumb without fear of dropping the phone. That’s something I can’t do with my Nexus.

The Nexus dwarfs the iPhone 5 in size, even with the increase in height. The front facing camera has been centered at the top of the device and the quality is worlds better, and will make Facetime/Skype calls look better. The back of the case is brushed aluminum that matches the ring around the phone. It looks and feels fantastic. In very short terms, it’s a fantastic piece of hardware.

We’ve now reached the tipping point where the hardware is outpacing the software. iOS 6 feels like a minor instead of a major revision. Android has surpassed iOS in a number of categories, and being entirely honest, Jelly Bean is on par with iOS 6 in terms of general smoothness and responsiveness. iOS 7 (yes I’m already looking forward) will be a HUGE release for Apple. It has to be. The phone hardware is there. The OS needs to play its part now. Going feature for feature with Android is not the way to go about it. Google has done a fantastic job in the last 2 versions of taking the gap away from Apple on features and smoothness. They’ve also had the lead and extended it on notification handling. Jelly Bean’s notification system is hands down the best in the mobile game. The ability to handle events from the notification panel without changing app focus is fantastic, and you don’t realize how nice that is until you have it. I’d love iOS 7 to add the ability to drop a tiny icon in the status bar instead of the full banner. Just something to let me know that I have a new mail, text, etc. Jelly Bean drops a tiny icon in the status bar and allows me to clear individual notifications with a swipe. Seems simple, but it’s amazingly effective. I still miss icon badging though. The big red dot in the top right corner of an icon is a great way to get my attention, and Android doesn’t have that at all.

The only difference right now between phones is developer usage. Developers are still making innovative and awesome apps for iOS, with an Android port later on. A perfect example: Instagram. They built a following on having a clean, easy interface for people to take and share pictures with their friends. It was an iOS exclusive app for 18 months before an Android version finally appeared. Tweetbot for iOS comes to mind as an app I wish Android had. The Twitter clients for Android aren’t very good. The best one, in fact, is the official one. Mostly because it has actual push notifications instead of running in the background and polling for new mentions/messages. On the iOS side, Echofon and Tweetbot are great, well laid out apps for using Twitter. Even the official version on iOS isn’t so bad.

Apple finally has legitimate competition for users. Android and iOS effectively encompass 90% of the smartphone market and would love to grab that last 10% (Windows Phone, Blackberry). Android has made up significant ground in the feature and function gap and made it tougher to say “Get an iPhone”.

Switched from Android to iPhone or vice versa? What’s your take?

Descriptive, right?

A quick Google found this KB article from VMware that explained the issue. When your backup program runs, it sets this flag in the vCenter database that prevents migrations from happening so it can take a clean backup. If it isn’t able to remove the flag, migrations fail with this error. This affects the entire VM, not just the individual disks.

Run through the KB article and you’ll be all set!

When it runs, it starts a Tomcat server instance that runs the Health Analyzer web application. It’s a fantastic tool, but has a default setup that may not play well with other installed web servers (say, your vCenter box). When the application starts, it tries to run the application on port 80. If you already have something running on port 80 (like vCenter), the Tomcat instance will fail. This was an issue for me, but I figured out how to change the port it uses to start on so it can run without disabling services that need to use port 80.

1. Start the ThinApp and let it fail. We need to do this as it creates a folder structure for the Tomcat instance.

2. Go to C:\users\*the user you ran the ThinApp under*\AppData\Roaming\Thinstall\*random identification string*\%drive_c%\usr\share\vha\tomcat\conf

3. Edit server.xml

4. Find ConnectorPort=”80″

5. Change 80 to whatever port number you know is free. 

6. Save the changes and start the ThinApp. 

7. You should see Initializing Coyote HTTP/1.1 on http-(port number you chose)

8. Access the interface from http://localhost:port

Now you should be able to access VMware Health Analyzer from a different port than port 80. Remember to let the ThinApp remain running while you’re working in the Health Analyzer. If you close it, your session will end.