Table of Contents
- Introduction to the Reference Guide
- The New Itinerary for Windows Server 2008
- The Registry
- Domain Organization
Executing the Migration Plan
- Microsoft on the Other Side of the Barrier
- Is Vista Necessary?
- The Chronicles of Migration: A Never-ending Story?
- Migrating the Company Mindset
- Sketching the Phases for a Planned Migration
- How to Serve an "Essential Business"
- Breaking It Down and Putting It Back Together for SMBs
- A Never-ending Story?
- Finding Your Place in the Performance Curve
- Transitioning the Message, or the Transition of Messaging
- Migrating the Company Mindset
- Setting Up for the Practice Session
- The Ultimate Minimum Configuration: Zero Dedicated PCs
- Microsoft vs. Virtual Microsoft
- The Virtual Server 2005 R2 Solution
- Of Virtual Servers and Semi-Virtual Clusters
- A Virtual Client Needs a Virtual Client Server, or, To Each His Own
- Building a Stable Non-existent Network
- Making Virtual Server into Virtually a Server
- The Unix Migration Plan: Peace with Honor
- Living in Two Worlds
- Coping With Two Worlds By Creating A Third
- The NetWare Migration
- Creating Server 2003 Domains
- Planning an OU Structure
- Planning a Site Structure
- Restructuring NT Domains
- The Breakdown of Setup
- Running Windows Server 2003 Setup
- Running Windows Server 2008 Setup
- Resource Management
- Networking at the Link Level
- Network Applications
- Windows Management Instrumentation
- The Dawn of Windows Server 2008
- Windows Server By Command
Making Virtual Server into Virtually a Server
Last updated Sep 26, 2003.
It may be the smallest network you could ever not really build: a virtual Windows Server 2003 and a virtual Windows XP Professional client. But you can use these two virtual machines to set up a truly virtual Active Directory domain that exploits the sole simulated connection between the two virtual machines.
Figure 5 Easily one of the hallmarks of Windows Server 2003 is the Configure Your Server Wizard, which makes itself available soon after installation. Here, I'm about to set up the basic AD services on Thunderball.
Rather than utilize the peer-to-peer style networking services available to us through Internet Connection Sharing, we want to simulate an enterprise-class networking environment. So for Thunderball, I went through the motions of installing DNS, a DHCP server (yes, another one), and most importantly, AD.
Figure 6 When setting up the remote access server for Thunderball, the wizard found both network connections, but it doesn't really know the difference between them. So it helps to see the IP Address: the 192.168 connection clearly accesses the NAT-assigned local network loop.
Having enough memory assigned to your VM is critical to this process. You really need 256 Mb, at least, allocated to a WS2K3-based VM—for Thunderball, I assigned 320 Mb. But if you only have a 512 Mb physical computer, then there's just no way to accomplish this. And when you have less than 256 Mb allocated on a physical computer that's already busy, the AD installation process time increases exponentially, from just over half an hour to as long as 40 hours.
One way you know for certain you've installed AD on your WS2K3-based VM is that its boot time easily triples. Thunderball was booting in 2:33 on my 2.2 GHz AMD system; with AD installed, that time drags way down to over seven minutes. Remember, you have to reach your logon prompt before WS2K3 has an opportunity to load Virtual Machine Extensions, which will expedite the system for the remainder of the session.
Figure 7 Don't blink—or don't just click Next—or you'll miss this important little report at the end of the Wizard, which tells you that it's given up installing DHCP, and assigned a static address instead. It's assigned to the local network, but the Wizard is not that explicit.
Although the Configure Your Server Wizard took some time to perform the steps of setting up a DHCP server to run on WS2K3, a later step in the process actually undoes that bit of magic for you. The connection between Thunderball and Moonraker was severed after AD was installed, and Thunderball was rebooted. And in the Administrative Tools menu, there was no DHCP selection from which I could determine why Thunderball's IP address on the Red Network was 192.168.0.1. It's a good thing I took screen shots of the information I ignored along the way.
At this point, without Thunderball actually recognizing an internal DHCP server, I have two options: The easiest would be to configure Thunderball to recognize the DHCP server that VS2005 already has in place. While this will probably be effective, it wouldn't adequately simulate a real-world environment; in other words, if Thunderball and Moonraker were real computers, then what physical entity in this real network would be providing this ethereal DHCP service. So my other option, for the sake of accurate simulation, is to set up the DHCP server in Thunderball, that the Wizard declined to build.
Figure 8 You install the DHCP server in WS2K3 the old-fashioned way, with the Add/Remove Programs control panel.
Installing a DHCP server in WS2K3 is like uninstalling Windows Messenger or Minesweeper from Windows XP: You actually do it from the Add/Remove Programs control panel. Click Add/Remove Windows Components, and WS2K3 brings up the Windows Components Wizard. (If the last Wizard was such a wizard, if ever a wiz there was, we wouldn't be needing this Wizard.). Click Networking Services, then click Details. You'll find DHCP as the second entry in the list; check that, then click OK. Then go through the motions of clicking Next and waiting. Planning meals, or at least snacks, around these waiting periods is a reasonable option.
Figure 9 The new DHCP console, which comes complete with instructions.
With your stomach satiated, at least for now, you'll find DHCP as one of the entries in the Administrative Tools menu. With this console, Microsoft is nice enough to give you some explicit instructions regarding configuring DHCP. Here, we have to pull another rope trick: defining the scope of the DHCP address scheme. So from the Action menu, select New Scope. In yet another Wizard, you're prompted to name the scope; I'm calling mine "Red Network."
In the IP Address Range panel, you use much the same logic as for setting up DHCP inside VS2005. Here's where I discovered that VS2005's logic actually wasn't very good: It had been reserving several blocks of addresses for DHCP distribution—more than it could possibly require. So in setting up the range of addresses which Thunderball's DHCP server should assign, I used 10.239.0.254 as the ending IP address, instead of 10.239.255.254 which VS2005 assigned its own DHCP by default.
To make this work, I have to be certain to disable the "Red Network" DHCP server that VS2005 has set up. But the trick to making things work afterwards, believe it or not (and by now, you probably can) is to get Thunderball to recognize its own DHCP server, rather than someone else's. Unfortunately, there's still quite a bit of work ahead.
- "Setting Up a DHCP Server for Your Organization," by Brien M. Posey. Article from WindowsNetworking.com.
Books and e-Books
- Bixler, Dave; Schmied, Will. MCSE 70-291 Training Guide: Implementing, Managing, and Maintaining a Windows® Server 2003 Network Infrastructure. Que Corporation, 2003. Preview Chapter 2, "Implementing, Managing, and Maintaining DHCP," on Safari.