Server Operating Systems:

At this time, I see little reason to upgrade to Windows 2008. For what most servers do, Windows 2003 does the job just fine, and is still being supported (with hot-fixes, but not Service Packs) by Microsoft. The software you run on it likes 2003 just fine. Before long, new hardware will be built with Windows 2008 in mind, and Windows 2003 drivers for your hardware might get harder to find. However, I recommend moving to virtual servers at that time, and it will then not be necessary to have Windows drivers for your new server. The virtualization layer (hypervisor) will handle that, and the “virtual hardware” assigned to your server will work fine with Windows 2003 for many years to come.

Exchange 2007? Let’s just not talk about that right now. This is an OS discussion, and I will just say that I intend to resist that one as long as possible too, until Microsoft remembers that if we wanted to manage everything with command lines and scripts, we’d be using Linux with Sendmail or some open-source, command-line driven equivalent.

Terminal Servers, however, could benefit from a Windows 2008 upgrade. Terminal Services (now called Remote Desktop Services) functions have been greatly improved in 2008, specifically in the area of publishing applications seamlessly without giving the users access to the entire desktop – and in the area of remote printing. Remote printing has been a major thorn in your side, and Windows 2008 can help you with that. I believe the new Terminal Services is web-accessible, making it very easy to set up new workstations to use it.

Here is another, more detailed discussion of those improvements.

Is it worth the cost to upgrade? Your customer will have to decide.
Workstation Operating Systems:

I am happy to say that most of my customers have managed to skip right over Windows Vista.

I have not had much experience yet with Windows 7, but my limited experience suggests that Microsoft learned a lot from their Vista flop, and worked to smooth out the rough edges that made people despise Vista. My limited experience also suggests that Windows 7 is still too new for widespread adoption, with pitfalls lurking due to software applications and drivers not being fully compatible with Windows 7 yet.

That being said, we are entering a more sophisticated age of malware and viruses, and it may be time to leave behind the less intrusive security measures we have been enjoying with Windows XP, which is now allowing more and more PCs to become infected – just as it happened with Windows 2000. It will be a rocky time, when we try to balance having appropriate access to our own computers against making them wide open to attacks. Some software will work OK when installed with an administrative account and then used by someone else. Some will not. We’ll have to work out which software requires which installation method, and perhaps sometimes temporarily give a user administrative access to their machine to get something installed and configured, then take it away to help protect them. We can do this with Windows XP for now, and then later with Windows 7.

For the time being, I will recommend that my customers continue to purchase workstations that come with Windows 7 licenses, but have a downgrade to XP installed on them. This will continue for as long as possible, until we start seeing the rate of virus infection become too high, or other factors necessitate a change. The age-old cycle of viruses and antivirus software one-upping each other continues, and maybe we’ll see a comeback of the antivirus software.

For now, Dell is offering workstations with Windows 7 licenses, with Windows XP installed – but only in the Business section.

So, am I just being resistant to change? There is some of that, but I do not embrace change for its own sake. there has to be some benefit, other than the many hours of billable work I could get from pushing customers into unfamilair operating systems just because Microsoft wants to keep their money machine rolling. Let me just say that I was determined to be open-minded abot Vista. I gave it a solid try. When asked whether I wanted Vista or XP on my company-supplied laptop, I chose Vista. I suffered it for 6 months, before finally deciding that enough was enough. I had passed the learning curve and the pain continued. I went back to XP. So no, it is not just resistance to change. There are good reasons for me to hold back. They are related to deficiencies of the new OSes, financial reasons, and the general difficulty of being among the first to move to new technology.

Unless there are specific, compelling benefits to be gained in each scenario, then you won’t see me jumping first to new versions of the OS. Not me, not this time.

Tags: remote Desktop Services, Terminal Services, Virtualization, Windows 2003, Windows 2008, Windows 7, Windows Vista, Windows XP

Summary:
Triggered by an excessive heat wave, I used the built-in Windows Backup to do a test restore of my production virtual servers from their usual VMware ESXi host to a smaller, more portable machine that lives in an air-conditioned room. The servers will run there until the heat wave dissipates, whereupon I will reverse the procedure and move them back to their usual home.

The restore process was incredibly easy. This is a demonstration of how portable and flexible virtual servers are, and how well the built-in Windows Backup works with virtualization.

I can now say with a high level of confidence that virtual servers, backed up with a local VSS-based disk backup solution, and coupled with an offsite backup solution, is a great way to go. My scenario was a simple problem with a simple solution, but this power and flexibility can easily be applied in many different situations.

The Full Story:
If you live in the Western Washington area, you know we’re having a crazy heat wave.

Many businesses have servers tucked away in closets, kitchen areas, and other little nooks and crannies, without air conditioning. Mine is one of them. I strongly recommend air conditioning to my customers, and it is with some embarrassment that I admit that I have not implemented it myself – but I have never needed it before. My company’s servers are in a steel enclosure in a 675 square foot garage. Usually it stays quite cool, verified by the thermal monitoring unit attached to my battery backup system. If the temperature gets too high, the battery backup sends a shutdown command to the servers so they are not damaged by the heat.

Several of my customers have had thermal shutdown issues the last few days. Today it was my turn. I happened to be sitting at my workstation when the e-mail arrived, telling me that I had 3 minutes to correct the situation before things started shutting down.

I started by logging into the battery backup unit and adjusting the threshold up a few degrees to give me time to work. Next I walked down to the server rack and opened its door to allow more air flow to the servers. The thermal monitor is just inside the door, right next to the air intake holes in the front of the server. The third step I took was to shut down one of the servers in the rack – a virtual server running Windows Home Server, which backs up my workstations. Since I don’t store data on workstations, it’s OK to go a few days without backing them up.

Back in my air-conditioned office, I logged into the battery backup management web page and saw that it had gone up to 91 degrees while I was working, but was now back to 90. I watched it for a few minutes. It stayed at 90. Still too hot.

Sitting back and thinking about my options, I considered fans – but the entire room was very hot. Fans would only push the hot air around, and I’ve heard horror stories and seen pictures of server rooms which had burned down due to electrical fires starting from cheap fans that weren’t designed for a 24/7 duty cycle.

I considered moving the server to my office – but the server is very noisy, being a rack-mount server with small fans moving very quickly. However, my servers are virtual, running on VMware ESXi, so they should be very portable…        …and an idea was formed.

One of the great benefits of virtualization is that you can put your virtual machine on any hardware that is supported by the host operating system, which in my case is VMware ESXi. That makes backup and restore very simple. You don’t have to be concerned with hard disk controller drivers and other such obstacles to a smooth restore operation.

I’ve been evangelizing these virtues for over a year now, and using the technology myself. I decided to use this unfortunate heat wave as an opportunity to perform a real-world test of the technology I have been talking about. I decided to do a last-minute backup of my server, move the backup device to a smaller, quieter machine in my office, and restore the backup. I would run it in my office until temperatures reach sane levels again, and then reverse the procedure.

I warned the users that the server was going down for a while. I stopped the incoming e-mail service, and forced a “backup now” on the SBS 2008 and Windows 2008 servers that form my infrastructure. That took about 1/2 hour. I am using the built-in Windows Backup, and it is performing disk-based incremental backups. Then I shut down the “guest” operating systems, and finally shut down the host server.

Again I walked down to the server rack and disconnected the external hard disk that I store my local backups on. It was nearly hot enough to burn my fingers. I carried it up to my office and plugged it into the generic white-box server ($800) that I use to run lab experiments. This machine would also make an excellent loaner ESXi server if one of my customers experienced a server failure. It has a single quad-core 2.5GHz CPU, 8GB RAM, and 1.5 TB of disk space.

I attached the USB stick that boots VMware ESXi on that host, booted it up, and configured its networking (2 minutes).

Next step, I created two guest virtual machines with the same disk sizes as the machines I was going to restore. I had to allocate less memory, so the servers might run a little slower. Then I attached the virtual disks on the backup device to the appropriate VMs, and finally mapped the SBS2008 and Windows 2008 DVDs to the new virtual machines and configured them to boot from DVD.

I booted up the SBS2008 server first. It booted from DVD, and I used the menus on the DVD to start a Full Computer Restore, using the backups that it found automatically when it searched the attached disks. I chose the correct date/time of the backup to restore, verified that all of the volumes were present, and told it to begin.

I didn’t have to flounder around looking for hard disk controller drivers, making floppy disks or putting drivers on USB. I set to work on the second server, which is less critical to my business, and had similar results with that one. Not wanting to cause the first restore to slow down, I brought the second server to the final prompt to begin the restore, and waited for the first one to complete.

The restore was the easiest full-server restore I have ever done, with the best results. After the restore, I booted the server, and it was off and running without a backward glance.

The first server, which runs 90% of my business, was restored and running less than 2 hours of shutting down for the move. A backup queuing mail service had received and stored my e-mail while it was down, so I didn’t miss a single message. The second server, running my blog site, followed soon after.

I did have three very small hiccups:
1. Windows detected the hardware change (probably the CPU chip) and required re-activation, but it worked automatically – two mouse clicks and a few seconds took care of it.
2. Because I forgot to set the date/time properly on the destination ESXi host, my SBS2008 server’s clock got set wrong and that caused authentication problems for a few minutes until I figured out what was going on and corrected it.
3. The DHCP Server service on my SBS did not start because I was running an open-source DHCP server during the downtime to keep everything connected to the network. I just had to stop the one and start the other.

Compared with the kind of difficulties I would normally expect with this kind of full server restore to different hardware, this was a piece of cake.

I can now say with a high level of confidence that virtual servers, backed up with a local VSS-based disk backup solution, coupled with an offsite backup solution, is a great way to go. My scenario was a simple problem with a simple solution, but this power and flexibility can easily be applied in many different situations.

Tags: backup, ESXi, SBS 2008, Virtualization

Updated 11/22/2008 with new info regarding connectivity after fresh OS load.

Some of this may be old news to some readers, but it was not old news to me, and it cost me a bit of time and frustration to put it all together.

There are, of course, lots of resources available to cover these steps – but what I could not find was a reasonably simple overview in plain English that contained enough detail to send me down the right path. I found some complex details regarding some key point or other in some places, arguments about whether Hyper-V or ESXi was better, and some obvious copy/paste crap content from MS marketing materials.

Nothing I found really put it all together on a basic level, to help me get to a platform from which I could then drill down to my desired level of detail, after first feeling like I was making some progress with the product.

So, I have decided to provide for others that which I was seeking. Here is my “middle ground” overview.

Components:
Hyper-V Server Installation (Standalone)
Hyper-V Remote Management Tools Update for Vista x86
Hyper-V Remote Management Tools Update for Vista x64
Hyper-V Update for Windows 2008 x86
Hyper-V Update for Windows 2008 x64

The first piece of the puzzle I was missing was that there are multiple ways to install Hyper-V:

• As a standalone server
• As a role on Windows 2008 Core
• As a role on a full Windows 2008 Server

This document covers only the standalone Hyper-V server because it is free, and is the closest I can get to a bare-metal hypervisor product from Microsoft.

Once you have downloaded the components you need, the next step is to burn a DVD from the ISO you downloaded for the Hyper-V Server installation. Put that in the drive and install away. If you get any errors about your hardware not being supported, you’ll need to check the system requirements. Also, here is a handy quick tool for checking some basics. It will tell you instantly whether your CPU is 64-bit, and whether hardware DEP and Intel VT are supported and enabled – some basic building blocks that Hyper-V needs.

Once you’ve installed Hyper-V, you’ll log on at the console with Administrator / blank password, and then change the password. You’ll be presented with a very basic text menu. Set your IP addressing, change the computer name, and JOIN A DOMAIN. I was unable to connect to the Hyper-V server with anything (RDP, SMB, Hyper-V Manager, nuthin’!) until I joined it to a domain.

Update: After some testing, and a helpful tip from Brian East, I have new information regarding connectivity:

• Turning on RDP does create an exception in the firewall, and it works. Not sure what I did wrong the first time.

• Sharing a folder does create a firewall exception for file/printer sharing, and it works.

• Connecting to the server via the management console works through the firewall, as long as you are logged on with a username/password that matches the Hyper-V admin account, or it is joined to a domain and you are logged in with a domain account that has permission to do the job.

• The management console will NOT prompt you for a password. Either you’re in or you’re not, based on your user account.

• When connecting to a running VM, (or starting one after connecting to it) you are prompted for a password unless the Hyper-V server is joined to a domain and you are logged in with a domain account with sufficient permission.

You may need to use DISKPART at the command prompt to set up any additional hard disks in your server, if you did not do that part during setup.

Once you’ve completed all of that, you may start to wonder “How in the heck do I configure VMs and VM-related settings on this thing?“, since those things are not in that basic text menu.

The answer is: Connect to your Hyper-V server from a management console you have installed on another computer. Yes, you can manage it from inside a VM that is running on it, but you have to get there first. The links above will give you the latest management tools for Vista and 2008.

For Vista, click the appropriate management tool link above, and install it. A new icon will appear under Administrative Tools called Hyper-V Manager.

For Windows 2008, use Server Manager. In the Features section, under Remote Server Administration Tools, you’ll find Hyper-V Tools.

Once you have your Hyper-V server installed and joined to a domain, and your management tools installed, the rest is pretty straightforward, so I’ll not belabor it here.

• One nice feature about Hyper-V is that you can use Windows Explorer to copy ISO images and virtual floppy images around, as well as VHDs.

So now that you’ve gotten started with Hyper-V, you might want to know: How do I perform a P2V into a Hyper-V environment? That, my inquisitive friends, is another story. The short answer is “Microsoft System Center Virtual Machine Manager” (That’s a mouthful!).

For known issues with running SBS2008 in a Hyper-V environment, and some other miscellaneous ramblings about SBS2008, check this out.

Tags: Hyper-V, management, Virtualization, vm