Archive

Posts Tagged ‘ESXi’

We still need floppies? Seriously, Microsoft?!

March 7th, 2012 No comments
Only one installation issue The end of a long marathon, migrating to SBS 2008

Running SBS 2008 migration on a virtual server takes us on a detour down memory lane

Working on a migration of Windows Small Business Server (SBS) 2003 to SBS 2008, I had jumped thru the previous 283 migration hoops (I exaggerate, but just a little) and was ready to boot the 2008 installer DVD with my handy SBSAnswerFile which Microsoft wants me to put on “…the root of a USB drive, floppy disk or a partition on the destination server.” Hmmm….

– USB drive is a no-go on the ESX server.
– Let’s put it on a 2nd virtual hard disk. No, the migration installer didn’t “see” it.
– OK, let’s put it on a virtual CD drive. No. It didn’t see it again.
– Finally, I went to the extra hassle of putting it on a virtual floppy. Success!

The blow by blow follows:

In order to create a floppy on my 64 bit Windows 7 VM, I downloaded the excellent WinImage tool. I “injected” (their term) the SBSAnswerFile.xml into the floppy and saved it as answer.vfd.

WinImage makes short work of creating a virtual floppy

I then uploaded it to the datastore into a folder I named ISO using the datastore browser, upload facility.

VMware wants it’s floppy images to have the extension “.flp”, so I simply renamed it using the datastore browser to answer.flp.

The floppy image shown in the datastore browser.

I then added the floppy image in the virtual machine settings so that it connects at startup.

Now, after seeing it NOT work many times, when the installation DOES see the answer file, you see the following:

A pleasant site to seeOjala! The answer file was found and migration can begin!

On the other hand, if it DOESN’T see the answer file, you will see the dialog requesting information about the time zone. And the information input in the answer file for the time zone is, of course, not there.

If you see this BEFORE the “Start the migration…” dialog, the answer file was not found by the installer. Here, the screen follows the migration start dialog and the time zone is as entered in the answer file.

So, the SBS 2008 migration continues to be one of the champs in huge projects to be avoided. David Neale (Nerds On Site, London, England) prefers to bypass the migration approach and just install fresh and convert, saying, “I like the old fashioned approach.”

The following sites provided help on tools for this. Another case of “standing on the shoulders of giants.” THANKS!

– Scott Ledyard

The 2nd 99% – tracking VMware snapshot removal progress

March 7th, 2012 1 comment

“The first 99% of the project flies by. But the 2nd 99%! Sheesh…” – anonymous

If you ever removed a snapshot in VMware ESX / ESXi, you’re presented with the ubiquitous progress meter. It chunks right along, increasing by 5% every so often. Encouraging.

And then it gets to the dreaded 99%. You’d think you’re almost home.

This would make you think you’re almost done. Wrong!

But you’re probably nowhere close.

This is really kind of dangerous. I’ve been tempted to assume that something is hung up. And that leads to thinking a hard reset of the host is required.

How CAN you see the progress? What follows is not an elegant solution, but you’ll at least be able to see what’s going on.

First, you’ll need to go to the ESXi command line (see other posts on the internet for accessing ESXi via SSH.) In this case, I used PuTTY ( http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html ) to get to the host IP and command line.

Go to the storage directory of the host, usually /vmfs/volumes, then the LUN directory and finally the VM directory.

Use the following linux command to list the files in time order, latest files last:

ls -ltr

This will show you what files have been most recently processed. Repeat this command over time (remember up-arrow to repeat bash commands) and you should notice a progression, disk files progress from lowest to highest, and within a disk, the delta files progress highest to lowes.

For example, if you have a VM called Server with 3 disks, they would be called

Server-flat.vmdk
Server_1-flat.vmdk
Server_2.flat.vmdk

And you’d see that they’d progress (latest file change time) in that order.  The delta files, created by snapshots, have 6 digit sequence numbers in their names that would progress in reverse order.

Server_1-000005-delta.vmdk
Server_1-000004-delta.vmdk
Server_1-000003-delta.vmdk
Server_1-000002-delta.vmdk
etc.

Not very exciting, true. But at least you can see some progress. I recently removed a snapshot that took 2:40 hrs. It was up to 99% in about :15 of that.

Level Platforms install does it all, but must add MWService to admin groups

March 7th, 2012 No comments

Summary:
While installing Level Platforms (LPI) Onsite Manager onto a Windows Server 2003 (a member server running on as and ESXi guest and added to a SBS 2003 domain) all went well, but one service would not start. Final, solution was that the MWService account did not have sufficient permissions. LPI tech support said to add that account to Administrators, Domain Administrators and Enterprise Administrators. This solved the problem.

Details:
After installation and during the registrationI entered my VAR domain and clicked Register, I received the message, “Unable to start Windows Service OMNetworkService.” When I ran services.msc and tried to start the OMNetworkService service, it attempted to, but then reported: “Could not start the OMNetworkService service on Local Computer. Error 1053 The service did not respond to start in a timely fashion.

Located the other LPI service, MWExpertSystem.  That service was running, but I restarted it and the started OMNetworkService. I still received the same error that it could not be started.

I consulted the LPI forums and found some suggestions that I make sure the MWService account be flagged as “Password never expires.” It already was.

I also checked the Local Security Policy and found that the MWService account WAS listed under the “Log on as a service” right.

I rebooted the Onsite Manager as a test and it came up with the message you’ve seen at server rebooting saying that some serices could not be started.

I attempted to use the OMTools – Stop OM Services + Start OM Services. Didn’t work.

I attempted stopping MWExpertSystem and starting OMNetworkService first. Didn’t work.

When I checked the Application log I found a .net error:

Event Type:    Error
Event Source:    .NET Runtime 2.0 Error Reporting
Event Category:    None
Event ID:    5000
Date:        12/17/2008
Time:        8:15:36 AM
User:        N/A
Computer:    MEMBER1
Description:
EventType clr20r3, P1 omnetworkservice.exe, P2 6.0.4.492, P3 48ca784e, P4 mscorlib, P5 2.0.0.0, P6 471ebc5b, P7 e4, P8 10, P9 system.security.security, P10 NIL.

An issue with .net. Considered working down that line, but eNerd Chris Polis, contacted LPI support.
LPI support tech Paul Savoie wrote:

Event ID 5000 is usually indicative of a rights issue with the account used for the services. Can you please have your tech confirm that the MWSERVICE account is a member of Domain Admin, Enterprise Admin, and Administrators groups.
A quick test to confirm this is the use the domain admin account for the service and see if it starts up correctly.

I did not try the latter, but made changes to the MWService account. Rebooted the server for good measure and the services fired right up.

Other comments from LPI (Jocelyn Sirois) regarding SBS setup:

Make sure the MWService account is added to the SBS group that is allowed access to the Internet. The LPI installation cannot do this. This is a default group created by the SBS default installation.
Verify that the logon credentials for the OMNetworkService  are the correct one.
If using ISA there are other considerations for some of the protocols.
The File and Print services on the SBS server must be enabled.