Mark Minasi's Windows 2000/NT/XP Newsletter
Issue #25 July 2002

To subscribe, visit http://www.minasi.com/nwsreg.htm. To unsubscribe, link to http://www.minasi.com/unsubs.htm. To change e-mail address, switch between HTML or text format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.  Visit the Archives at http://www.minasi.com/archive.htm.  Please do NOT reply to this mail; for comments, please link to www.minasi.com/gethelp.  Document copyright 2002 Mark Minasi.

What's Inside

News

Hello all --

This month, I continued work on the Linux book update and put the finishing touches on the new XP Support class that we're running in Boston and Atlanta this September so as the song goes, I hope that "I'll see you in September."  (Okay, so it's a DATED song reference.)  The audio seminars are selling briskly despite the best efforts of Verizon (see "Sorry We've Been Down" below) and I'm looking into setting up a discussion board on my Web site -- more on that later.  

XP Support Seminars in Boston and Atlanta in September, New Orleans and Denver in November At $895/Seat

If your company is making the move from Wintendo (Win 9x), NT 4.0 or Windows 2000 Pro to XP Professional, then we've got the seminar for you!  "XP Professional for Support Professionals" shows your desktop support techies how to deploy, network, manage, support and troubleshoot XP Professional, in just two days.  This seminar is packed with demonstrations and a course guide filled with step by step procedures.  As always, I try my best to make explaining entertaining so come join us if you can either in September in Atlanta or Boston, or November in either New Orleans or Denver.  Visit www.minasi.com/pubsems.htm for schedule specifics or www.minasi.com/xpsupport.htm for the course outline.

Windows 2000 Server Seminars in New York/New Jersey, Washington DC, and Tampa 

Our two-day Windows 2000 seminars have been a lot of fun and the attendees have been great.  Built atop the Fourth Edition, we add coverage of things even more up-to-date than that edition.  Visit www.minasi.com/pubsems.htm to see specific session dates and locations, seminar outline, and how to sign up.  We're coming to New York/New Jersey (Mahwah) and DC in September, and Tampa in November.  Those will be our only Server seminars for the rest of the year, and I hope you'll join me for a seminar that will fill your brain with knowledge and share a few laughs in the process.

NOTE that every attendee to the seminar receives a copy of the new Fourth Edition of Mastering Windows 2000 Server!

Pick Up A Copy of our Windows 2000/.NET Audio Seminar and Software Quality Book 

Want to attend the Server class but haven't the time or money?  $225 gets you the audio version of the seminar complete with over 10 hours of lecture accompanied by illustrative PowerPoints, all nicely cross-indexed for future reference.  Pick up a copy today at www.minasi.com/audiosales.

Do computer bugs bug you?  Find out why they're so prevalent and what you can do about them by grabbing a copy of my 1999 McGraw-Hill book The Software Conspiracy:  Why Software Vendors Produce Faulty Products, How They Can Harm You, And What You Can Do About It.  It's just five bucks in e-book (PDF) format.  If you've read my other books then you know my technical writing -- but this book is aimed at both techies and non-techies.  The much-respected Kirkus Reviews said of that it was "A lucidly written, eminently practical guide to fighting back against the modern scourge of software 'bugs' ... An absorbing, easily understandable, and inspiring book..."  Get your copy at www.softwareconspiracy.com.

Sorry We've Been Down, We're Working On It

I know that a lot of you have tried to get onto my site this month but were unsuccessful, and I'm awfully sorry about that.  You see, I run my servers (DNS, mail, Web) from my house in a rural part of Virginia, connecting to the Internet with a 256/384 kbps frame relay to my ISP.  When we go down, there are of course several possible reasons: power at my location might go down, my router might fail, the ISP might have some kind of trouble, or the frame relay that connects me to the ISP might fail.

On my side I have an identically configured router ready to pop into the network, should something befall my Cisco; that system is plugged into a isolation transformer/battery backup unit, and on top of my propane-driven generator would power the network for six days if necessary.  The ISP does suffer router or power troubles, but they're infrequent and usually addressed quickly.  The weak link has been the frame relay between my house and the ISP.

Unfortunately I don't have much in the way of choices for frame relay providers; Verizon is about all I've got available to me.  Their network has proven by far the weakest link in my connection to the outside world, disconnecting me nine days out of the past thirty.  It's sad that any firm can charge me $600/month for a quarter-megabit of connectivity and then not deliver a significant part of that month, but then that's the beauty of a monopoly I suppose.  While I cannot control Verizon's lack of quality, I DO want to apologize for the inconvenience that it's presented to you.  And to explain what I'm working on to get around it.

Recently my cable provider (Cox) has put cable modem into my neighborhood.  They're offering business Internet services (static IPs) over cable modem.  Now, I've got enough friends who have cable modem to know that shifting my network over to a cable provider probably would not net me any greater reliability.  But I've ordered business cable services from Cox with this intention:  I'll give my servers two IP addresses apiece -- one on the Verizon network, and one on the Cox network.  Then I'll rig DNS to show BOTH IP addresses:  when visiting, for example, www.minasi.com, then your system will query my DNS server, and my DNS server will return two IP addresses, the Verizon-based network address and the Cox-based network address.  If one doesn't work, then your system (assuming it's using a standard TCP/IP stack) will automatically try the other.  I'll take a bit of jiggery-pokery on my network, but I believe that I can shake out the bugs and end up with a fairly fault-tolerant connection to the Internet ... and ultimately to you.

Thanks for your patience. 

We've Got A Discussion Forum Up, Come Visit

I find that I can't answer many reader questions because they concern specific circumstances that I've not run into.  Often, however, some other reader can help out.  I hate to have to say "I'm sorry, but I don' t know," but I often have to.  So I've set up a Web-based discussion board where people can post problems and, with hope, solutions.

I'll use it as another way to pass along information and answer questions, of course.  And the search feature will let people quickly see if someone else has asked a similar question in the past.  But, again, the fact is that I just plain don't know the answer to many questions ... but I'll bet that many of YOU have run across the problems before, and will oftimes have an answer.

Whether to pose a question or offer help, stop by and say hi -- or just chat in the "general" forums.  See you there!

Tech Section

This month, four articles:  one on a tool that will save you big time on your test labs, an answer to a VFAQ (very frequently asked question), a note on FireWire and laptops, and a tip on modifying group policies on systems without an Active Directory.

Tricks To Let You Learn, Prototype and Experiment With Networking Cheaply With VMWare

In the past couple of months I've been doing a lot of work with a great tool called VMWare Workstation 3.1 from a company called VMWare.  In this article, I will start out by introducing you to what it can do and why you'd want it, and then I want to tell you about some tricks that I've figured out to make building an entire Active Directory on it possible.  (These are all things that I found fairly difficult to accomplish and no amount of Google searching pointed me to Web pages that could help, so I believe you'll find this article useful.)

Now, I usually don't talk much about third-party tools, as I'm inherently cheap and prefer to spend my time trying to squeeze the most functionality out of the free stuff that I've already paid for.  But I think you'll see that this tool is a must-buy.

The Good News

First of all, what is VMWare?  It is one of a class of programs that let you take one PC and essentially cut it up into several "virtual" PCs.  For example, as you know I recently started doing my XP Support seminar.  Now, to do the seminar right I really needed at least four machines -- one to run the PowerPoints, one to be a Windows 2000 Active Directory domain controller, one to be an XP Professional system joined to the domain, and one to be an XP Pro box not joined to the domain.  Sure, I could have collapsed this a bit, putting the PowerPoints on either the Server or one of the Professional boxes, but even then I'd need three computers.  Or I could have cut out a few demonstrations and gotten by with just one XP box, but I preferred not to.  I wasn't thrilled by the idea of dragging four laptops (or even two!) with me, so I looked into VMWare -- I'd seen it when it first came out years ago -- and was pleasantly surprised by its power.  (Its documentation could use some work, but we'll get to that.)  It's at www.wmware.com.  Or, if you don't do demonstrations, consider those times that you need a test lab.  For example, you want to play around with Active Directory, and so you decide that you'll build a small version of your network with couple of domain controllers, a member server, and a workstation.  That'd mean that you'd need four computers as well as room for four computers, a mare's nest of cables, and so on.  With VMWare, in contrast, you'd just get one computer and use it to create four virtual PCs, and then you'd install Server or Professional on each one.  VMWare includes, as you'll see, a virtual network, so all of these computers can communicate with one another, saving you having to find three extra computers and a bunch of cables.  In my case, I currently have a test lab that consists of a couple of tables upon which I've stacked seven to nine (two are laptops and so they're occasionally elsewhere) machines.  I intend to replace them with just two systems with a bunch of RAM and as many hard disks as I can fit in them (VMWare virtual machines are significantly faster if they run on separate physical hard disks.)  I can't recommend VMWare highly enough. 

VMWare runs on your PC, atop NT 4, Windows 2000, XP or Linux.  Your "real" computer, the one that runs VMWare, is called the "host" operating system.  VMWare then lets you create imaginary PCs called "guests" that live in windows, or you can run them in full screen mode.  All VMs are connected to one another, and to the host, with a "virtual network" that you can configure.  To install an operating system, just drop an installation CD-ROM into your CD-ROM drive and click the button on the VMWare window to start up the PC.  It's pretty cool that you even see a BIOS screen and a regular power-up sequence, and then you install the OS as always.  

In actual fact the virtual PC lives on your hard disk in a directory -- and that's VERY neat.  Why?  First of all, it's simple to back up and restore virtual machines.  You could create prototype Linux, 2000 Pro, 2000 Server, and XP VMs and back them up somewhere, saving you the trouble in the future of having to re-run the Setup routines -- a kind of super-fast Ghost.  Even better, you can run Sysprep on the 2000 or XP VMs before backing up the VMs; the resultant image is then as flexible as any Sysprepped image.

That would be very useful for someone teaching a class like the ones that I do.  After teaching a demonstration-driven class, I've normally got after-class cleanup to handle.  After two days of demonstrations, I've messed up the computers, so I've got to go rebuild the domain controller, delete files, policies etc. so that I'm back in a "virgin" setting for the next class.  With VMware, however, I get the virtual PC just the way I like it, and then I back up the directory.  Result?  Restoring a system to "virgin" state is no harder than copying from the backed-up directory to the VMWare virtual machine directory.  Or I could restore my classroom demo virtual machines with another neat feature of VMWare -- "un-doable" disks.  Basically you get a system the way you want it and then change its drive to "undoable" mode.  From that point on, whenever you power down or start up the virtual machine, you get a dialog box asking if you want VMWare to reset the disk to the initial state, or to keep collecting new information.  You could, for example, run the thing in undoable mode for a month and install new packages and data files, all of which would accumulate on the virtual PC's hard disk.  A package that you'd installed a week ago would still be there today.  But if you downed the virtual PC tomorrow and told it to "discard," then your system would go back in time to that point a month ago when you set the drive to undoable.  Quite nice.

Here are a few other ideas for things that you might find useful in VMWare:

The Bad News

So all in all there's a lot to like in VMWare's "Workstation 3.1" product.  A few things may be annoying, however.  You can't create a really virtual PC, with multiple processors.  And each VM's RAM is limited by the physical -- not the virtual -- RAM in the host PC.  It'd be nice to say "I don't care how slow the VMs are" and run as many VMs as your virtual memory allows.  The way that VMWare multitasks between virtual machines isn't very well exposed and offers very little configurability; there's no way to say that VM1 should get five percent of the CPU time, VM2 should get four times that, and so on.  And while it's a small thing, the virtual PCs are a sort of almost APM-based system, rather than ACPI systems.  A small difference, but a difference that might matter -- it might be nice to be able to experiment with RIS and Ghost on APM versus ACPI systems.  And it'd also be nice to just click the "power off" button for the virtual machine to bring it down gracefully. 

How the VMWare Virtual Network Works

So far, all I've done is tell you why you might want it and what you might do with it... what's the value of this as a TECH article?  One little detail:  VMWare's documentation on its internal virtual network.  The virtual network is absolutely essential, as you want all of your VMs to talk to one another.  The documentation explains some, but not all, of how the VMWare virtual network is set up.  In the rest of this article, I want to offer some step-by-step help on getting a VMWare virtual network to work and in particular to make it work in an Active Directory world.

Simplified, VMWare actually has not one but nine virtual networks called VMnet0 through VMnet8.  By default, they behave as if they were eight completely separate, disconnected Ethernet hubs.  Put one VM onto one virtual network and another VM onto another network, and they cannot see each other at all.  (You can, however, add multiple virtual NICs to any VM and connect those NICs to whatever virtual network that you'd like.  So you could, if you wanted, set up a few VMs on VMnet3 and a few VMs on VMnet6, and then build a VM that has two NICs, one in VMnet3 and one in VMnet6, and then turn on RRAS to make that VM a router.  A cheap and simple way to play with using Windows 2000 or .NET as an IP router.  But not the topic of this article.)

Clearly, then, you'll usually want to put all of your VMs on the same virtual network.  (Too bad it doesn't include a "virtual WAN" wherein you could specify that VMnet3 connected to VMnet5 via dial-up, VMnet3 to VMnet6 via a Cisco router, etc.  Man, would that make writing the RRAS chapter simple.)  In its simplest form, then, you can't even communicate between a VMnet and your host computer's actual network -- virtual PCs and your real PC can't communicate.

But you probably will want more than that; in particular, you'll probably want to connect

VMWare has a prebuilt solution for those needs.  Two of the virtual networks have an extra bit of virtual network hardware on them -- VMnet1 and VMnet8, and VMnet0 has a built-in feature called bridged networking.  Let's take that one up first.

Bridged Networks

Every VM has a virtual NIC that looks like an Ethernet adapter.  (An "AMD PCNET" adapter, to be exact, whatever that is.)  You control a VM's networking options by doing this:

  1. Start the "VM Workstation" program.
  2. Choose the VM whose networking you want to configure in the left-hand panel by left-clicking it once.
  3. Choose Settings/Configuration Editor.
  4. In the resulting window, you will see a list of items describing the virtual machine -- how much memory it has, what kinds of drives it contains, and its network adapter.  Click the network adapter and to the right of the network adapter's icon, you'll see four options:

As you'd imagine, you opt for bridging by choosing "Bridged."  You cannot do this if your network card is a wireless card.  You won't get an error message if you try to bridge to a wireless card, but nothing will work in the way that I'm about to describe.  (If your only NIC is wireless but you want your VMs to be able to access the public Internet, then don't despair; you can use NAT, which I'll cover later.) If you choose to bridge a virtual NIC, then that NIC appears to your local network -- the real one, that is, the one that your host computer is on -- as if it were an actual NIC on the network.  If you've enabled DHCP on the operating system running in the virtual machine, then it will seek out a real-live DHCP server to try to get an IP address.  This virtual machine is then as visible to your corporate intranet or to the public Internet as is your actual host computer.  Think of it as if every VM were able to poke its nose out of the "virtual" world to the "real" world, if we can consider the Internet the "real world."  (I know, a scary thought.)

For example, suppose you're running VMWare on a home network that is connected to the Internet via a wired cable modem/DSL router, either a dedicated device that does that (D-link, Linksys, those kinds of guys) or a PC running Windows 98 second edition or later running Internet Connection Sharing. As a result, all of the computers in your home network get assigned some non-routable address in the 10.x.x.x or 192.168.0.x ranges, and they can use those addresses to access the Internet via a network address translation routing facility in your cable modem/DSL router, ICS or whatever.  Suppose for the sake of example that your host PC gets IP address 10.1.1.27 from the DHCP server built into the cable modem/DSL router, which hands out addresses in the range 10.1.1.2-10.1.1.254.  (Your cable modem/DSL router may not use that range; it may use another range, like 192.168.0.x; there's nothing wrong with that.  I'm just using 10.1.1.x as an example.  Of course, if you're using a Windows machine to do this via ICS then the range is 192.168.0.x.)

You set up two VMs and configure their virtual NICs to be bridged.  You put XP on VM1 and Windows 2000 Server on VM2.  Boot the virtual machines up and VMWare fools your cable modem/DSL router into thinking that you've just put two more actual real-life Ethernet cards on your network.  The DHCP server built in the router hands them IP addresses; for the sake of example, let's say that they are 10.1.1.31 and 10.1.1.32.

You can now walk to another computer inside your home network and PING 10.1.1.32 and get a response.  A network sniffer would even show that the network adapter associated with 10.1.1.31 has a different MAC address than the network adapter associated with 10.1.1.32, which in turn is different from the MAC address on the actual NIC in the host PC.  

Digression:  Addresses and Active Directory's DNS Needs

Remember from the book and other newsletters (newsletter 23 in particular) that you probably want to set up the DNS that supports your Active Directory using split-brain DNS.  Without re-hashing the specifics of it, let me just simplify and say that you'll probably want to build your network so that

  1. You have a DNS server set up on your first Windows 2000 Server that contains a zone with the same name as your proposed Active Directory -- if you wanted to set up a domain named bigfirm.biz then your 2K server would have a bigfirm.biz zone on it.
  2. That zone must be set up to be dynamic, to allow dynamic updates.
  3. You have all of the computers that are to be members of your domain, including the DNS server itself, pointing to that first 2K server as their preferred DNS server.  In the "preferred DNS server" field of every server and workstation, you fill in the IP address of the DNS server.

This is straightforward except for one thing:  it means that you must know the IP address of that first 2K server so that you can tell DHCP to tell all of the clients to refer to that IP address for their DNS needs.  You need, then, to be able to (1) assign a fixed IP address to your first 2K server and (2) assign the preferred DNS server value for all of your other VMs to equal that fixed IP address.

That turned out to be the tough part.  How you'll do it, or if you can do it at all, depends on your network configuration.  How would you accomplish this if you bridged your NICs?  In one of two ways.

First, you could forgo DHCP altogether and simply assign a static IP address to your 2K server; then assign that IP address to the preferred DNS server field of every VM by hand.  Or, second, you could configure whatever DHCP server serves your internal network to (1) reserve a particular IP address for your virtual 2K server and (2) give that IP address to every computer as a preferred DNS server.  In order to make a DHCP server reserve a particular IP address for a particular NIC, then you need the physical address of that NIC.  You can find the physical address of your virtual 2K server's NIC by just opening up a command prompt and typing "ipconfig/all" -- one of the things reported is the physical address.  Either works, although you might not want to tell your internal DHCP server to point every single computer on your intranet to a virtual machine for their DNS needs.  If you're running a Windows 2000 DHCP server then you could use a DHCP user class ID, although that's a fair amount of work also.

Host-Only Network

The next option is a "host-only" network.  This virtual network lets your VMs communicate with your host computer, but does not let other real computers see your VMs -- the VMs don't present addresses to the actual network.  The host-only network also introduces another VMWare virtual network feature:  a virtual DHCP server.

The virtual DHCP server doesn't appear as one of the virtual machines.  It's just a process running as part of VMWare, actually an implementation of the same ISC.ORG DHCP server as you see on Linux and Unix boxes.  When you install VMWare, its setup program looks around, trying to find a subnet that no one's using, and then configures the VMWare virtual DHCP server to hand out addresses in that subnet.  Unless you configure it otherwise, the VMWare virtual DHCP server will use a subnet in 192.168.x; for example, the one that I'm looking at now leases out addresses in the range 192.168.192.x.  Another time I set up VMWare, the DHCP server settled on the 192.168.4.x range.  (You can fix the range if you like; the VMWare documentation takes you through the process.)  The VMWare virtual DHCP server itself takes the "254" address in its chosen range.  So, again in the example of the computer that I'm working with, the virtual DHCP server claims to exist at 192.168.192.254 and, again, there's really no way to "talk" to it -- you can't telnet to that address or PING it, for example.   

So we've seen that in a host-only network there is a VMWare virtual DHCP server that hands out IP addresses to all of the VMs that have chosen to put their virtual NICs in the "Host-only" network option.  That DHCP server hands out IP addresses that are all in some specific C network (subnet mask 255.255.255.0) range that the VMWare Setup program created.  Clearly then all of the VMs that have chosen "Host-only" can PING each another, as they've all got addresses in that sameC network.  But what about your host computer?  How can it talk to the VMs, given that your host PC probably only has one Ethernet card, and that NIC has  probably got an address on some different subnet, an address given it by a cable modem/DSL router or perhaps statically assigned?

Simple:  run an IPCONFIG /ALL on your host computer and you may see the answer immediately.  You see, VMWare gives your host PC an imaginary new NIC, and the VMWare virtual DHCP server gives that NIC an address in the C network range used by the "host-only" internal network.  You can even see this imaginary NIC -- just open up Device Manager and look under "Network Adapters" and you'll see that you've got a NIC called "VMWare Virtual Ethernet (basic host-only support for VMnet1)."  Notice that there's another as well called "VMWare Virtual Ethernet Adapter (Network Address Translation (NAT) for VMnet8);" we'll discuss that one in a minute.  As I just suggested, if you do an ipconfig /all on your host computer then you should see that both virtual NICs exist and that the host-only one has an IP address in the same C network range as the virtual machines' NICs do.

What's the benefit of host-only?  First, it allows all of the VMs to communicate with each other simply, as they're all in the same subnet.  Second, it allows the VMs to communicate with the host.  Third, host-only provides a DHCP server so that the IP addresses get set automatically.  Finally, computers in a host-only network do  NOT  get access to "real" network, whether a corporate intranet or the public Internet.  The overall benefits are then simple plug-and-play IP address assigning and security for the VMs.

How would we make this work in our standard test Active Directory, with one or more servers and a few workstations, all virtual?  Again, we need to be able to the first 2K server (which, again, is both the DNS server and the first AD domain controller) with a fixed IP address, and to set all of the VMs to use that IP address as their preferred DNS server.  The two tasks that will accomplish that are to (1) figure out how to make the VMWare DHCP server give the VM running the 2K server the same IP address all the time and (2) figure out how to make the VMWare DHCP server tell all other systems in the host-only network to look to that 2K server for their DNS server needs.  And while we're at it, it'd be nice to pre-assign the DNS suffix "bigfirm.biz" to all of our systems, as that will be the name of our Active Directory.

Now, you and I know how to do that kind of thing with a Windows 2000 or NT 4-based DHCP server... but that's not the DHCP server that we've got here.  Nope, friends, we are in Unix/Linux configuration territory.  But it's not too bad.  Here are the steps.

Step 1:  back up the DHCP server's configuration file so that if we screw up then we can still get things back to their original state.  The file is an ASCII text file in system32 named vmnetdhcp.conf.  Stuff a copy of it away somewhere just in case.

Step 2: set up the VMs so that their network adapters are set to "host-only."  You MUST do this step before the next step, as changing a VM's NIC from one network setting to another (e.g., from "bridged" to "host-only") changes the NIC's physical address.

Step 3: get the MAC address of the virtual NIC in the 2K virtual machine.  Again, just run IPCONFIG on the 2K virtual machine and get its "physical address," which is the same as the MAC address.  For example, suppose you ran IPCONFIG /ALL on your 2K server and got this result:

Ethernet adapter Local Area Connection:
...
Physical Address. . . . . . . . . : 00-50-EB-02-2B-32 ...

Step 4: tell the DHCP server to give a particular IP address to the 2K server, using the 2K server's MAC address.  

For example, suppose that your VMWare DHCP server is using the 192.168.22.x subnet.  Let's just set the 2K server's IP address to 192.168.22.10.  We'd do that by editing the vmnetdhcp.conf file to add this text:

host W2kSv {
hardware ethernet 00:50:EB:02:2B:32;
fixed-address 192.168.22.10;
option domain-name-servers 192.168.22.10;
option domain-name "bigfirm.biz";
}

This is Linux-ese for "give the system with this physical address the IP address 192.168.22.10, tell it to use that address for its preferred DNS, and give it the domain suffix 'bigfirm.biz.'"  Notice that you express the MAC address by replacing the dashes with colons.  Stop and start the "VMWare DHCP Service" and the changes will take effect.  Restart the VMs or ipconfig /renew them.  

Step 5:  tell the other systems to look to 192.168.22.10 for their DNS.  This is another edit to the vmnetdhcp.conf file.  Look for the section that starts "# Virtual ethernet segment 1;" before I made any changes to it, mine looked like 

# Virtual ethernet segment 1
# Added at 06/29/02 09:14:51
subnet 192.168.22.0 netmask 255.255.255.0 {
range 192.168.22.128 192.168.22.254; # up to 126 VM's
option broadcast-address 192.168.22.255;
option domain-name-servers 192.168.22.1;
option domain-name "localdomain";
}

Hosts-only uses segment 1.  Most of it's decipherable but irrelevant; all we want to do is to ensure that everyone on this subnet uses the .10 system as their DNS server.  That's the "option domain-name-servers" line.  But while we're at it, we may as well change the "domain-name" option, so the section looks like this after changing the last two lines:

# Virtual ethernet segment 1
# Added at 06/29/02 09:14:51
subnet 192.168.22.0 netmask 255.255.255.0 {
range 192.168.192.128 192.168.22.254; # up to 126 VM's
option broadcast-address 192.168.22.255;
option domain-name-servers 192.168.22.10;
option domain-name "bigfirm.biz";
}

Again, save and restart the VM DHCP service.  And when this works as you like it, back up the vmnetdhcp.conf file; reconfiguring some things on VMWare causes VMWare to overwrite the file.  

Step 6: check in Device Manager on your host PC to ensure that the "VMWare Virtual Ethernet Adapter (basic host-only support for VMnet1) is enabled.

Step 7: Configure the operating systems in the VMs to get their IP information from DHCP and restart them.  Do an IPCONFIG /all on all of them and you will see that the 2K server has the right IP address and that every machine points to that server, as well as has the bigfirm.biz DNS suffix.

NAT Configuration

Finally, there's the NAT option.  It's basically an enhancement of host-only networking.  It is similar to host-only in that it

But NAT adds two things.

If you don't care about fixing particular systems with particular IP addresses, then setting up a bunch of VMs that can NAT out to the Internet is simple.

1.  Set the networking option for all of your VMs to "NAT."

2. Look in Device Manager on your host PC to ensure that the virtual NIC for NAT ("NIC for NAT," doesn't that have a catchy little ring?) is enabled.

3. Ensure that all of the OSes running in the VMs are set to use DHCP to configure their TCP/IP addresses.

That's it; all of your VMs will talk to each other and to the outside world, as they're all configured to use an imaginary system at the .2 address, which is the NAT router.  But to make our AD work, again we'll have to do a bit of modification.  As before, the goal is to (1) give the first 2K server, which will be the DNS server and the first AD domain controller, a fixed IP address and (2) to tell all of the virtual machines, including the 2K server itself, to point to that fixed address as their preferred DNS server.  Secondarily, we can also use the DHCP server to set all system's DNS suffix to whatever our domain's name is.

Let's just arbitrarily set the 2K server's address to .10 in whatever 192.168.x.y network VMWare is using.  Whenever you're going to assign an IP address to a particular system with VMWare's DHCP server, use an address in the .3-.127 range, as .1 and .2 are used for other things and the DHCP server gives out addresses in the .128-.254 range.  We'll use the DNS suffix bigfirm.biz, as before.  Here's how to get a VMWare NAT network to accommodate our split-brain DNS setup.  (You'll note how similar this is to the host-only setup, but I wanted to make this as clear as possible, so forgive any repetition.)

Step 1:  back up the DHCP server's configuration file so that if we screw up then we can still get things back to their original state.  The file is an ASCII text file in system32 named vmnetdhcp.conf.  Stuff a copy of it away somewhere just in case.

Step 2: check in Device Manager on your host PC to ensure that the "VMWare Virtual Ethernet Adapter (Network Address Translating (NAT) for VMnet8)" is enabled.

Step 3: set up the VMs so that their network adapters are set to "NAT."  You MUST do this step before the next step, as changing a VM's NIC from one network setting to another changes the NIC's physical address.

Step 4: Boot the VM that your 2K server is running in to get the MAC address of its virtual NIC.  Again, just run IPCONFIG on the 2K virtual machine and get its "physical address," which is the same as the MAC address.  (Make sure the 2K system is using DHCP or clearly this won't work.)  IPCONFIG will also tell you what network your DHCP server is using for the NAT subnet.  For example, on my system I see that DHCP gave my 2K server the address 192.168.71.132 -- so I know that NAT on my system is running in the 192.168.71.x range.  So now I know that I want my 2K server to end up with IP address 192.168.71.10.

Step 5: tell the DHCP server to give a particular IP address to the 2K server.  Let's assume that an excerpt of the IPCONFIG /ALL command looks like this:

Ethernet adapter Local Area Connection:
...
Physical Address. . . . . . . . . : 00-50-EB-02-2B-32 ...

We've already seen that VMnet8 is running on 192.168.71.x and that therefore we're going to give our 2K server the address 192.168.71.10.  I can tell the DHCP server to do that by editing vmnetdhcp.conf, like so:

host W2kSv {
hardware ethernet 00:50:EB:02:2B:32;
fixed-address 192.168.71.10;
option domain-name-servers 192.168.71.10;
option domain-name "bigfirm.biz";
}

This is Linux-ese for "give the system with this physical address the IP address 192.168.71.10, tell it to use that address for its preferred DNS, and give it the domain suffix 'bigfirm.biz.'"  Notice that you express the MAC address by replacing the dashes with colons.  Stop and start the "VMWare DHCP Service" and the changes will take effect.  Restart the VMs or ipconfig /renew them.  

Step 6:  tell the other systems to look to 192.168.71.10 for their DNS.  This is another edit to the vmnetdhcp.conf file.  Look for the section that starts "# Virtual ethernet segment 8;" mine looks like 

# Virtual ethernet segment 8
# Added at 06/29/02 09:15:01
subnet 192.168.71.0 netmask 255.255.255.0 {
range 192.168.71.128 192.168.71.254; # up to 126 VM's
option broadcast-address 192.168.71.255;
option domain-name-servers 192.168.71.2;
option domain-name "localdomain";
option netbios-name-servers 192.168.71.2;
option routers 192.168.71.2;
}

NAT uses segment 8.  Most of it's decipherable but irrelevant; all we want to do is to ensure that everyone on this subnet uses the .10 system as their DNS server.  That's the "option domain-name-servers" line.  But while we're at it, we may as well change the "domain-name" option, so the section looks like this:

# Virtual ethernet segment 8
# Added at 06/29/02 09:15:01
subnet 192.168.71.0 netmask 255.255.255.0 {
range 192.168.71.128 192.168.71.254; # up to 126 VM's
option broadcast-address 192.168.71.255;
option domain-name-servers 192.168.71.10;
option domain-name "bigfirm.biz";
option netbios-name-servers 192.168.71.2;
option routers 192.168.71.2;
}

Again, save and restart the VM DHCP service.  And when this works as you like it, back up the vmnetdhcp.conf file; reconfiguring some things on VMWare causes VMWare to overwrite the file.  

Step 7: Configure the operating systems in the VMs to get their IP information from DHCP and restart them.  Do an IPCONFIG /all on all of them and you will see that the 2K server has the right IP address and that every machine points to that server, as well as has the bigfirm.biz DNS suffix.

That should do it; you can now bend VMWare to your will no matter how you set up your network.

In case you're wondering, I don't own stock or have any financial interest in the product.  And yes, I know that there is a competing product called Virtual PC from Connectix (http://www.connectix.com) that is $100 cheaper, sounds like it does pretty much what VMWare does and runs on a Mac on top of all that... but Virtual PC is different from VMWare in one very important way, and that makes the difference.  Virtual PC creates REALLY virtual PCs, down to the processor:  it really emulates a Pentium processor in software.  The net effect is that while on the one hand Virtual PC will end up more flexible -- it runs on a Mac, for example, and can emulate PCs on a Mac's processor -- it's slower than VMWare.  Still, it's a good product.

You Cannot Use A Windows 2000 Server As An NT 4.0 Domain Controller

This is in the book but I'm getting the question almost daily these days, so I thought I'd clarify this with a brief note.

You can add Windows 2000 systems, both servers and workstations (Professional), to NT 4.0 domains.  Windows 2000 makes a fine workstation or member server in an NT 4.0-based domain.  Windows 2000 cannot, however, act as a backup domain controller in an NT 4.0 domain.  Cannot.  Can't.  It's not possible.  Honest!

By the way, NT 4.0 workstations and servers can function perfectly as members of a Windows 2000-based Active Directory domain.  They can even be domain controllers in an AD, provided that the AD is still in mixed mode.

FireWire and Laptops:  Four Pins Are Less Than Six

It was time for a new laptop, as I wanted something with the horsepower to run VMWare and a bunch of virtual machines.  My "must-have" requirements were that the computer have a Pentium 4 and at least a gigabyte of RAM  and one of those Accupoint/StressPoint/TrackPoint mice, the ones that look like a pencil eraser between the G and H keys.  (I hate touchpads.)  Close on those requirements were a need for built-in wireless Ethernet, built-in wired 10/100 Ethernet, and more than one USB port.  And while it wasn't necessary I really wanted to end up with integrated FireWire.  

I got all of those in the WinBook J4 -- 2GHz, 1 GB RAM, FOUR USB ports, wired and wireless Ethernet, DVD/CDRW and FireWire.  You can buy some very small FireWire drives (two would fit in a pack of cards) that don't even require power plugs, as they draw their power from the FireWire connector itself.   Aha, I thought, I'll just bring along a few tiny FireWire drives and have a truly powerful portable system that'll run VMWare like a charm.

There was only one problem:  those nifty little drives didn't work.

You see, there are two kinds of FireWire connectors.  There's a six-pin connector shaped a bit like a flattened capital "D" (sized at about 10mm by 5mm) and a smaller four-pin connector sized at about 5 mm x 3 mm.  The two varieties of FireWire connectors are compatible and you can find three kinds of FireWire cables -- six pin to six pin, four pin to four pin, and four pin to six pin.  The difference between the six and four pin connectors is power -- those two extra pins let the FireWire interface deliver power. (See http://www.computer.org/multimedia/articles/firewire.htm for a writeup on FireWire strategies and standards.)  That's how those nifty little fit-in-your-shirt-pocket FireWire hard disks work; they include a six-pin FireWire connector and run off its power. 

The WinBook, like most every other FireWire-equipped laptop that I've seen, is only equipped with a four-wire connector.  (Jeremy Moskowitz tells me that Dell's got a laptop with a six-pin FireWire attachment, but I've not seen it.)  Sure, you can buy a four pin to six pin cable and then connect the WinBook to the little hard disk, but if there's only four wires coming out of the laptop then there's nothing to deliver the juice to that six-pin connector on the hard disk.  I've also looked into several CardBus or PCMCIA add-on cards that let you add FireWire compatibility to your laptop and while some of them offer six-pin FireWire connectors, I have not found any that actually POWER the two extra pins.

What's the answer?  Something called a FireWire hub.  Like a USB hub, a FireWire hub lets you expand a single FireWire connection into two or more connections, allowing you to connect up to 63 devices on a single FireWire link.  Why that's interesting is that there are several FireWire hubs available that come with a little power adapter.   One that I bought, the IOGear G-FH300 comes with a socket for a power adapter but does not ship with a power adapter.  Once I located an adapter that delivered the right juice, however, I was able to get my small FireWire drive to connect to the WinBook with no trouble.  (Whether I feel like dragging around the hub and its power brick just to accommodate the small drive is another story.)

One more thought before I close this -- be prepared to try a FEW FireWire hubs, and be prepared to send one or two back.  One of the hubs that I tried, a FireXpress, came with five attractive colored snap-on shells so that presumably I could make it match my Ibook or Imac no matter what the computer's color.  Despite that attempt at being aesthetically pleasing, it didn't work not matter WHAT color shell I chose.  The IOGear was less aesthetically designed and only came in one color, but it worked. 

Using GPEDIT.MSC To Edit Local Policies On Remote Computers

If you don't have an Active Directory running but want to use group policies then all is not lost.

Sure, the Local Security Policy tool is nice, but it only gives access to a subset of what group policies can do. Did you know that you can use the standard GPEDIT.MSC snap-in locally and remotely?

You can control the local set of group policies on any given workstation or server; just click Start/Run and type in "gpedit.msc," then press Enter. You then have the full access to all of group policy's power (well, actually some of it... some things don't make sense without a domain and you don't see those things). You can even use GPEDIT.MSC to control policies on a remote system with the /gpcomputer: option from a command line, like so:

gpedit /gpcomputer:"computername.acme.com"

Where you can replace "computername.acme.com" with either a DNS name or an IP address. In any case, however, it's got to be surrounded by double quotes. And by the way, this works on systems that are members of an AD as well, but remember that domain-based group policies always override any local group policies.

Conferences

I hope you'll join me for a seminar but if you can't attend a class then please consider attending one of these conferences:

TechMentor San Diego September 3-7

A terrific show that I'd attend even if they didn't pay me to be there.  It's got great sessions and is in San Diego this September.  Info at www.techmentorevents.com.   For the past two conferences that have offered you the opportunity to take any Microsoft cert test for half price, so on the off-chance that you didn't see any sessions that you wanted to sit in on (an unlikely event!), then you could take a test.  They even ran tests until about 9 at night.

I'm doing "Securing Your Network -- A Dozen Tips," "Troubleshooting Group Policies," and "Tuning Windows 2000/XP/.NET Computers" as well as a general session.  If you can make it then I surely hope to see you there!

Frontlines Orlando Returns October 28-29

They said it was dead but they were wrong.  George Spalding's Frontlines, the premier conference for technical support folks, is back (yay!) in Orlando (boo!) this October.  In case you've never been to a Frontlines, it's a conference for help desk and support people -- on the "front lines" -- and offers two very full days of sessions aiming to build and refresh both the "soft" and "hard" skills that you need in order to get your job done.  In the process, you of course meet others in our industry so at worst you have someone with whom to bitch about tech support life and at best you may find someone who's already solved a problem that you're struggling with right now.  George and I will do our ever-popular Networking 101, where we explain every single networking concept known to Man in just three hours; I will do my talk about the best and worst of XP and .NET Server, and George and I will run Tech Support Jeopardy, where geeks vie for fabulous prizes and merchandise.  Info at www.front-lines.com.  

Windows and .NET Magazine Live! October 30-November 2 Orlando

What was once the "WinConnections" conference is now "Windows and .NET Magazine Live!" and this fall it goes to Orlando.  In addition to the great content (which keeps getting better, thanks to conference chairs Don Jones and Jeremy Moskowitz), the magazine has now brought together all of the Connections conferences -- not only is there stuff for administrators, but developers as well.  If you sign up for the entire week then you end up getting access to conferences focusing on 2000/.NET/XP administration, Exchange, SQL Server, XML, Web Services. ASP.NET, and Visual Studio.NET.  It's a kind of "superconference" that ends up being quite a good value for your conference dollar.  The speakers are an all-star line-up, including my co-author Christa Anderson as well as a long list of top-of-the-line experts.  I'm keynoting as well as doing several sessions, including a new one on tuning systems.  www.winconnections.com for more info.

Fall Comdex November 18-21 Las Vegas

George Spalding and I team up yet again for Fall Comdex's "Extreme Knowledge" (doesn't that sound painful, "extreme" knowledge?) seminar sessions on Microsoft Windows technologies.  If you're going to Vegas this November then consider dropping by to hear me, Christa Anderson, Todd Lammle, Doug Toombs, Jeremy Moskowitz and others deliver the goods on running Windows without pane!  The general Comdex site is www.comdex.com but they seem not to have anything specific on the site yet.

Bring Mark to your site to teach

I'm keeping busy doing Windows 2000/.NET Server seminars and writing, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2000/.NET techies.  To join the large educational, pharmaceutical, agricultural, aerospace, banking, government, transportation, and other organizations that I've assisted, either take a peek at the course outline at www.minasi.com/w2koutln.htm, mail our assistant at Assistant@Minasi.com, or call her at (757) 426-1431 (only between 9-5 Eastern time, weekdays, please).

Until Next Month...

Have a quiet and safe month.  I'll be finishing the update of the Linux book, I'll report on that next time.  I don't often get a chance to say it, but many thanks to the many of you who've bought a book, audio seminar, attended a conference or a live seminar.

Please share this newsletter; I'd like very much to expand this newsletter into a useful source of NT/2000/.NET Server/XP information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at over 21,000 subscribers and I hope to use this to get information to every single Mastering XP, NT and 2000 Server reader. Thanks for letting me visit with you, and take care -- I'm still predicting that the economy will roar back by September, so polish up those resumes!  Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at http://www.minasi.com/gethelp

To subscribe, visit http://www.minasi.com/nwsreg.asp. To change e-mail, format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.  To unsubscribe, link to http://www.minasi.com/unsubs.asp. Visit the Archives at http://www.minasi.com/archive.htm. Please do NOT reply to this mail; for comments, please link to http://www.minasi.com/gethelp.

All contents copyright 2002 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.