Ideally, every IT department would have a dedicated environment for testing new software versions. In reality, not everyone can afford to set aside test systems, though few IT pros relish the idea of installing beta software on production machines. But thanks to Microsoft's release of Virtual Server 2005 Release 2 (R2) as a free download (at http://www.microsoft.com/windowsserversystem/virtualserver/software/default.mspx), you can easily and economically set up an isolated test bed and run beta or brand-new software versions in a virtual machine (VM) environment. I recently created such an environment to test Exchange Server 2007 Beta 1 and the new version of Outlook Web Access (OWA), and I'll walk you through the basic steps I followed to do so.

In the Web-exclusive sidebar " Creating the Basic Virtual Environment" (http://www.windowsitpro.com, InstantDoc ID 53900), I explain the processes I followed to create the VMs and virtual hard disks in Virtual Server and install the Windows OSs in the VMs. Figure 1 shows the layout of my test environment. Before you undertake your virtualization project, be sure to check with management about your company's policies for installing beta software and running test systems connected to the production network.

Collecting the Hardware
An advantage of testing under Virtual Server 2005 is that you probably won't need to go out and buy any new hardware. Take a brief inventory of any spare hardware you have available and see what you can put together.

You'll want to assemble a machine that has as much RAM as possible, and you'll also need enough disk space to hold all the virtual hard disks you'll create. The more—and faster—processors you have, the better your machine's performance, although that isn't your chief concern in a test environment.

I used a retired HP NetServer LH6000, a quad P3 550MHz Xenon server that had dutifully served up several Microsoft SQL Server 2000 databases for four years. I removed some RAM from another retired Net-Server to give my test machine a total of 4GB of memory. For storage, I chose an 8GB SCSI hardware RAID 1 array, which provides storage for the OS and program files, and a 170GB SCSI hardware RAID 5 array, which provides storage for the virtual hard disks. Why use RAID for a test system? To provide redundancy: You don't want to spend all day setting up your VMs only to have a disk fail overnight and destroy all your work. Also, a RAID array is likely to provide better I/O performance for the VMs than a single large disk can.

I recommend that you completely isolate your VMs from both your production network and the Internet. Doing so removes the risk of the beta software affecting production and also avoids the need to install antivirus software on your VMs (one less application to run means better performance). The downside to this approach is that you'll need to install everything on your VMs from CDROM or DVD. Therefore, you'll definitely want to add a DVD-ROM drive to your test machine. A DVDROM/CD-RW drive is better; in fact, two drives—one CD/DVD reader and one CD/DVD burner—are ideal. After you've gathered all the components for your test machine, install the necessary RAM, processors, drives, and other hardware and set up your RAID hardware.

Isolate or Connect?
Make sure you have copies of all the applications you want to install on the test system before you start. The sidebar, "Applications Installed on the Test System," lists the software I installed on my test machine.

Now you're at a decision point. You can either connect the test machine to your production network and possibly the Internet or leave it completely isolated. Earlier, I advised you to isolate your VMs from the production network and the Internet. However, I recommend you connect the physical test machine to your production network and give the test system access to the Internet. Doing so offers some key benefits:

• You can install the Virtual Machine Remote Control client (VMRC)—a Virtual Server 2005 component that lets a client access VMs on a virtual server—on any number of management workstations in your network, letting you control the VMs from your office PC, your home PC over a VPN connection, or another location.
• You can access your test machine via Remote Desktop.
• If you're sitting at the console of the test machine, you can download software from the Internet and, if you installed a CD/DVD burner, use it to burn copies of whatever you need. You can then mount the newly burned CD/DVD on your VMs. Doing so can save you a lot of trips back and forth to your test machine.
• You can use your current backup solution to back up your virtual hard disks over the network.

The downside to this approach is that it makes your test machine a first-class citizen on your production network. If you do put your test system on the production network, you'll want to treat it like any other production machine and keep it up to date (e.g., by staying current on OS hotfixes and anitvirus updates).

Whatever you decide, your next steps are to do a clean install of Windows Server 2003 Service Pack 1 (SP1) on your test machine, then install Virtual Server 2005 R2, also on the test system. (See "Creating the Basic Virtual Environment" for more information about performing these installations.) If the test machine is on your production network, now's the time to install the VMRC on any management workstations you want. Likewise, you'll want to make the Virtual Server Administration Web site one of your Microsoft Internet Explorer (IE) Favorites because you'll be accessing it often as part of the Virtual Server setup process. The Administration Web site URL is typically http://servername:1024/, where servername is the NetBIOS name of your test machine.

Installing Exchange 2007
Assuming you've already created the VMs and virtual hard disks you'll need and installed the OSs you'll be using, you're ready to install Exchange 2007 Beta 1. To do so, insert the Exchange 2007 Beta 1 DVD into your test machine's CD/DVD drive and start the setup process. You'll also need to install Microsoft .NET Framework 2.0, which is included on the Exchange 2007 Beta 1 DVD.

The installer will tell you that you need to have Microsoft Management Console (MMC) 3.0 installed. Initially I elected not to install MMC 3.0 because it's included with Windows 2003 R2, which I'd already installed— but the installer wouldn't proceed without it.

After a bit of Google searching, I located the solution to this problem on the Microsoft Exchange Team Blog (http://www.msexchangeteam.com). The installer is looking for a Release Candidate 1 (RC1) Refresh pre-release build of MMC 3.0. You can solve the problem by either installing that build or adding a new registry subkey. I used the registry subkey workaround; after exiting the installer, I created an empty subkey called HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\ MMC30Core. After I created this subkey, the installer proceeded. I elected to install the Bridgehead Server, Mailbox Server, and Client Access Server Exchange roles. (I didn't test the Unified Messaging role because I didn't have a test PBX or the Gateway Server role because it wasn't applicable to my test environment.)

After you select the roles, the installation pre-checks begin. Mine failed initially on the Bridgehead Server, Mailbox Server, and Client Access roles because the domain was in Windows 2000 mixed mode, since I hadn't upgraded my Active Directory (AD) domain from Windows 2000 mixed to Windows 2003 native. I exited the installer and upgraded the domain. (I explain the procedure for doing so in "Creating the Basic Virtual Environment".)

The installation pre-check also complained that Microsoft IIS wasn't installed. After again exiting the installer, I fixed this problem by running the Add or Remove Programs applet's Add/Remove Windows Components option and selecting Application Server (IIS) to install IIS with defaults. After I did so, all my prechecks passed and installation began.

The installer's next step, called Organization Preparation, was to add the Exchange Attributes to AD. This step took slightly longer than one hour for me (your results might differ). Once Organization Preparation is complete, the actual Exchange 2007 installation starts.

The installation proceeded smoothly until the Mailbox Server role was installed, when I got this error: An error occurred while performing operations on atom from exsetdata.dll: Error HRESULT E_FAIL has been returned from a call to a COM component.... Back at the Exchange Team Blog, I found that others had experienced this problem. A couple of suggested solutions were to reinstall Windows 2003 SP1 and to uninstall and reinstall Exchange 2007. I opted for the uninstall/reinstall method. After removing Exchange 2007 and rebooting my EXCH VM (the VM I created earlier, as described in "Creating the Basic Virtual Environment," which contains the Exchange application and data), I reran the installation procedure and got no errors this time around. Note that uninstalling and then reinstalling Exchange 2007 will create an additional Universal Security Group (USG) in AD, called Exchange Server Administrators(servername)#, where servername is your test machine's NetBIOS name and # is likely to increment based on how many times you uninstall and reinstall.

Testing Exchange 2007
Of course, Exchange isn't much use without mailboxes, so my next step after installing Exchange 2007 in the VM was to create some. Being an Exchange administrator since the Exchange Server 5.5 days, my natural impulse was to log on as an Administrator to XP1, the VM I'd created for Microsoft Office Outlook 2007 and OWA, and attempt to access the OWA site at http://exch.incubator.local/ exchange. No dice. I thought the Administrator account might not be mailbox-enabled, so I checked the account via Exchange Management Console (EMC)—Exchange 2007's new version of Exchange System Manager (ESM)—and it was indeed mailbox-enabled. Searching Google and checking the Exchange Team Blog turned up no helpful information. I reread the release notes. Nothing. I thought OWA might be disabled for this user, but the ability to enable/ disable access to OWA on a per-user basis isn't available in EMC in Beta 1. I suspected that you could probably enable/disable OWA for a particular user in the Exchange Management Shell (EMS), but I wasn't ready to tackle EMS yet. I finally decided to create a new user and try logging on by using that account.

I created a user, TestUser1, on DC, the VM that's the domain controller (DC) and includes AD. While I was in DC, I created a file share called ExDoc Access so that I could test OWA Document Access, a new feature that lets you access files stored on file shares on your internal network without requiring you to establish a VPN connection or connect via Terminal Services. I also created a text file and placed it in that share. Then, on EXCH, I mailbox-enabled the new user without any trouble and was able to log on to OWA. After clicking the Documents button in OWA, as Figure 2 shows, I could open my file share and text file. Cool! I'd love to have this feature available in production today.

I deleted TestUser1 on DC, and Exchange 2007 automatically deleted the user's mailbox. I then created two new users, John Smith and Jenny Jones. On EXCH, I mailbox-enabled both users, as Figure 3 shows. I logged on to XP1 as John Smith and XP2 (the VM I'd created for OWA and Microsoft Office Outlook 2003) as Jenny Jones and was able to send messages back and forth by using OWA and Outlook 2003, as Figure 4 shows.

Configuring Outlook 2007 went smoothly, via a wizard that runs the first time you launch Outlook after installing it. All I needed to do to create an Outlook profile was to select Microsoft Exchange Server as the account I wanted to connect to; Outlook 2007 automatically created the profile. As Figure 5 shows, Outlook resolved my username (John Smith) and Exchange server and connected right away. This feature, called Auto Account Setup—which is new to Exchange 2007 and Outlook 2007 and requires both products—will be another great addition to the production versions because it simplifies the somewhat tricky process of profile creation.

What's Next?
If you ever want to (or have to) revert to an earlier version of Exchange, simply shut down your VMs and restore from the backups of your virtual hard disk—and optionally, your shared virtual networks and shared VMs— which you should have made after you set up the VMs and installed Windows on them (see "Creating the Basic Virtual Environment"). Other than that, the sky's the limit. One of my coworkers equipped his test machine with Exchange Server 2003 and Exchange 5.5 so that he could practice migration scenarios. You might want to hold on to those Exchange 5.5 CDROMs for a similar occasion.

As for me, my test machine will soon be hosting Exchange 2007 Beta 2, SQL Server 2005, System Center Configuration Manager 2007 (formerly code-named SMS v4) Beta 1, Windows Vista Beta 2, and Windows Server Longhorn Beta 2. Good luck with your test system, and don't be afraid to experiment!