So far, our Physical-to-Virtual migrations of Exchange 2003 on x86 Server 2003 Enterprise boxes have gone mostly smoothly – until this evening, that is. In the past, a failure soon after the P2V process started was resolved with a reboot or by disabling the TCP Offload Engine on the Broadcom NICs (this was easily accomplished with the cmd.exe command netsh int ip set chimney DISABLED).
This evening’s P2Vs were a bit more challenging.
A highly secured Windows installation can make your SQL installation fail
There are some highly modified default installations of both Windows desktops and servers that certain institutions use to increase the security of their networks. These versions of Windows are focused on security and are locked down from the ground up, which is a good thing. But all these security settings can give an IT guy headaches if you’re trying to get things accomplished. One such feature can make your SQL install fail. I happened to come across this recently in a test lab.
If you’re driving along with a standard SQL install, everything will be going fine until, towards the end of the installation process, you see the gem below. And SQL installs take a little time to complete. Having to reinstall can be a real pain.
It’s no fun doing research all day on your only day off, so I took a minute to read Mike D’s VMware blog over at http://www.mikedipetrillo.com/ where I came across some interesting and fun stuff. The “stuff” is actually just an embedded YouTube video but one that should send you back in time for a few minutes to reminisce about simpler days. The video shows the upgrade of every major version of Microsoft Windows since — get this — Windows 1.0! He actually started with MS-DOS 5.0 because the earliest Windows versions required it. One interesting tid-bit is that the launch of Windows 1.0 predates that of the VGA standard and its numerous analog extensions we’ve all come to know and love. Instead, it uses EGA.