Unable to ping Server 2008

I have blogged about this before and I will again as folks fall trap to this all of the time.

By default, ping response is disabled beginning with Server 2008 and continuing into newer revisions of Windows Server. 

FYI - With Server Core, ping is silent regardless of the state of the firewall.

Here is a great tip from Ben of the Hyper-V team:

The first thing I would do is to check the firewall configuration in your guest operating system, and make sure that it allows ICMP.

Here is a great article that steps you through how to do this:

“Nobody can ping my computer”

http://technet.microsoft.com/en-us/library/cc749323(WS.10).aspx

BOOTMGR is missing - Repairing a Windows 7 or 2008 R2 image after VM deployment

Deploying a Windows 7 image to a virtual machine is not as straightforward as you might think.
The primary issue resides in how the reference Windows 7 system is installed.
If you create a VM and insert your Windows 7 media and proceed to click Next through the entire installation wizard, you will have a working Windows 7 installation, that can be templated, it can be copied, you can do just about anything you like to it – as long as all copies involve the entire virtual disk.
Say that you want to use ImageX to image the Windows 7 installation and then deploy that Windows 7 image to other virtual systems.
If all that you did was click Next through the installation wizard or you did not customize your unattend.xml at all – you actually have a VM that has been installed with two volumes – a System Reserved volume and the volume where the actual system is installed.
The standard process is that you boot your system into the WinPE environment and you use ImageX /capture to create a WIM from a particular volume. Note the word “volume.” ImageX is a volume based tool, not a disk based tool.
The problem comes when we try to deploy this image. We boot into ImageX and /apply – then we reboot the virtual machine and we end up with the error: “BOOTMGR is missing”

The boot manager resides on the System Reserved volume, that is the extra partition that is created but was not captured by ImageX.
According to Microsoft TechNet documentation How to Perform Common Deployment Tasks with Virtual Hard Disks we need to use BCDBoot.exe to “configure the boot entry in the BCD store to be on the volume inside the VHD.” If you follow the link, the portion that we are concerned with is: “Prepare a VHD image to boot inside a virtual machine.”
To repair the VM where the image we need some type of recovery environment. We can get to a prompt to fix the applied image by any of the following ways: Boot to a WinPE 3.0 ISO, Boot to a Recovery Console using the OS installation media, attach the virtual disk to another known working Windows virtual machine.
For my example I have used the Windows Automated Installation Kit and created a WinPE 3 ISO. However, in testing I first simply attached the failing virtual disk to a working VM and performed the same commands. I also found references that booting into the Recovery Console of the installation media also works, but I did not test this. It is important to note that if you use WinPE the bit-ness of your WinPE image must match the bit-ness of the OS in the VM (32-bit to 32-bit / 64-bit to 64-bit).
The repair process:
1. Boot the virtual machine into WinPE (or attach the virtual disk to a running VM).

(An alternative to this is to boot using the installation media.  At the "Install Windows" screen (the first screen of the installer) type Shift+F10 to open a command prompt)

2. Discover the drive letter assigned to the virtual disk that is failing to boot.

3. Execute the following command (pay attention to use the correct drive letter – in my example “C:” is the letter that was assigned to the virtual disk, the WinPE system volume is “X:”).
C:\windows\system32\bcdboot C:\windows /s C:

4. Simply type “exit” to cause WinPE to shutdown and reboot into the VM. If the virtual disk was mounted in another VM, then power off the VM and detach the virtual disk before booting the imported VM.

Do you know where your VM has been?

For a tester, creating a situation that causes a piece of software to fail gives you a warm fuzzy feeling inside. Some situations are easy. Some are difficult. Others are accidental, but totally realistic as to how they happened.

I have recently been busy testing virtual disk conversion tools. You might say: "how relatively boring is that.." And I will admit that it isn't the most glamorous thing to test. However, it has lead me to the reality that virtualization of a machine workload is NOT new.

Almost 6 years ago I first began working seriously with virtualization, moving a number of physical machines and their applications into virtual machines on ESX server. Back then, this was really cool stuff. Very few companies were doing it. Microsoft did not officially support running their operating systems within virtual machines, and you could never tell an application support person that you had virtualized the server their application was running on as they would immediately declare "there is your problem."

Well, we have grown and MSFT has gotten into the hypervisor market and all of a sudden this stuff is becoming main stream.

The most important part that I want to bring up is: People are migrating between hypervisor platforms, virtual disk formats, throwing away an old platform for a different one. Why? Because they can.

This is totally relevant to testing, evaluating, understanding performance, and a number of other things with your VMs. What was the life of that virtual machine? How did it get to where it is today? Does anyone in the enterprise even know?

I recently had the pleasure of breaking a piece of software and was told by a developer that "that was a really good bug, you found a great case." Now, as a tester, there is nothing better than a developer giving you a compliment because you found a good bug.

Now, I need to get back to my point.

I had access to a VM that was built on VMware workstation, moved to ESX server, to Virtual Server, to Hyper-V, and then I converted it back to a VMDK from VHD using WinImage.
This is at least five disk format modifications, three tools modifications, and this VM was running an application.

And, during most of those conversions a 3rd party, offline, conversion tool was probably involved. Some examples you may be familiar with: WinImage, Acronis, VMDK2VHD, PlateSpin, etc.

Needless to say there was a problem introduced to the virtual disk at some point in its life. Did any of the tools report this? No. Did the VM boot and run? Most definitely. Did we have any idea that there might be a problem? Definitely not.

It just goes to show you that in this day and age we need to keep track of these things. As who knows where an error can be introduced into an environment.

It is no different than the case of converting that old NT domain controller in the back corner into a VM because there is one legacy application that runs on it that is critical and the application has never been updated... And then you realize that you have migrated between platforms, formats, and who knows what tools.

So, always be mindful of your virtual machines. Their life and lifetime. Not just from a security standpoint, but from a stability standpoint.