Mark Minasi's Windows 2000/NT Newsletter
Issue #18 October 2001

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.  

What's Inside

News

Hello all --

Oh, cuss, another record-breaker:  this is the longest newsletter I've shipped yet.

Well, the world has changed quite a bit since my last newsletter, which I sent out in the first week of September.  I know that many of you get the monthly e-mail commentary that I do for Windows 2000 magazine, so I won't repeat my observations (find it at http://www.win2000mag.net/email/index.cfm?Action=Archive&EmailNewsLetterID=1 and choose the 28 September if you've not seen it) except to say that I hope that the 11th touched all of you as lightly as is possible.  (Man, remember when the viruses that we worried about most were IIS viruses?  And yes, I know anthrax is a bacterium.)

Closer to home, much more happened this month.  Not only did Microsoft decide not to decertify the NT MCSEs, but they made getting a 2000 MCSE easier by allowing some of the older NT electives to count as electives towards a 2000 MCSE.  Finally, they created a kind of "MCSE junior" certification, an MCSA.  While I have always strongly questioned the validity of a certification controlled by a vendor, the fact is that many private and public firms are lazy and use the MCSE as a measure of competence.  So Microsoft's modification of their certification policy makes things all the easier for those of you who need those letters after your name to get or keep a job.  And by the way, if you haven't yet done it, November 1st is your deadline to request the voucher for the free all-in-one four hour test that lets you skip the four core MCSE 2000 tests.  You have to be a current NT 4.0 MCSE to qualify, but if you do, you'll save yourself $400 in testing fees and having to sit through nearly 10 hours of tests. Details at http://www.microsoft.com/trainingandservices/exams/examasearch.asp?PageID=70-240.

In other news, Microsoft shipped the next version of NT for the desktop this month... so I've got a book on it.

The New York City Seminar Returns December 3-4, Philadelphia January 14-15, Columbus January 16-17

The bad guys made us postpone the NYC and Pasadena classes, but New York is rescheduled for December 3/4 at the LaGuardia Crowne Plaza.  If you've been interested in attending my Windows 2000 Server seminar, then there's still time to sign up.  We've also announced the first two seminars for 2002:  we're back to Philadelphia on January 14/15 and making our first foray into Columbus, Ohio on the 16/17th.  I am told that Columbus is the town with the best proximity to the most towns on the Eastern Seaboard, so we'l see if that makes it a good seminar town!  I'm finding that I need more time to write so I will not be doing as many seminars in 2002 as I did in 2001 -- sorry! -- so I won't be able to visit as many cities as I did in the past 12 months.  I hope, then, that if you'd like to attend one of my seminars, that you'll please consider joining me in NYC, Philly, or Columbus.  More cities on the way, but we're still figuring out which ones -- see the next item in this issue.

Our two-day Windows 2000 seminars have been a lot of fun and the attendees have been great.  Built atop the Third Edition, we add coverage of things even more up-to-date than the Third; I've already added coverage of Windows .NET Server enhancements, a big section on troubleshooting group policies and some major enhancements to the Active Directory replication info, stuff too new to have made it into the Third -- and there's more coming.  Visit www.minasi.com/pubsems.htm to see specific session dates and locations, seminar outline, and how to sign up.  

Please Vote To Help Us Choose Cities For Our Seminars

The polls are open again and no, I don't mean the ones with the butterfly ballots.  We've been doing polls to help us determine which cities (we've added Salt Lake) to hold our Windows 2000/.NET Server seminars for over a year now, but many votes are at this point pretty old, so we figured that if they've not taken a seminar from us by now, then they're not likely to soon for one reason or another.  So to make sure that we're coming to the cities that you're currently interested in, we've reset the ballots and kept only the ones from September 1 onwards.

If you would be interested in attending one of my two-day, US$1000 seminars, then please consider voting for your city at www.minasi.com/pickcity.htm; there are almost 40 cities in the US and Canada to choose from, as well as London, UK.

Recommended Seminar:  Windows Internals December 11-13, 2001 in Austin With David Solomon and Mark Russinovich

This isn't one of my seminars, nor am I making any money from this note.  But if you want to know how Windows 2000 (and XP and .NET Server) work under the hood, there really is only one source:  the team of Dave Solomon and Mark Russinovich.  Their three-day class explains exactly how all of the pieces of Windows 2000 fit together, how they work, and how they can NOT work.  Ever wondered exactly what NT and 2000 do with all your memory?  These guys can show you.  Would you like to be able to understand a blue screen, and make use of it to figure out what went wrong?  These guys can show you.  Dave has been in the NT seminar business as long as I have and comes to his encyclopedic knowledge of NT internals because he worked at Digital back in the days that Digital was building VMS, the operating system that is in many ways NT and 2000's precursor.  When I ask Dave a "how does this work?" question, he whips out the actual SOURCE CODE and looks it up!  In contrast, Mark knows NT and 2000 so well because he's a master at reverse-engineering the operating system, and has found more OS bugs than Microsoft likes to admit.  You probably know him because he's one of the two founders of Winternals (www.winternals.com), a site that sells some essential NT and 2000 repair and admin tools.  Mark also runs www.sysinternals.com, which features a bunch of nifty free NT and 2000 utilities.  In addition, he writes a regular column for Windows 2000 Magazine.  I've known Mark and Dave for years, and can highly recommend both their talks and their book, Inside Windows 2000, 3rd Ed, from Microsoft Press.

Both speak on Windows internals on a regular basis, but it isn't often that the two of them have the time to join forces to teach an intensive, three-day class on internals.  This kind of event just doesn't happen often, so if internals are of interest to you -- and they should be, if you're an NT/2000 troubleshooter -- then this is not a class to miss.  (I certainly plan to attend.)  It's in Austin at the airport Hilton from December 11 to 13 and costs $1750 if you register four weeks in advance, or $1950 afterward.  Find out more info at Mark's site at www.sysinternals.com/seminar.shtml.  

New Book:  Mastering Windows XP Professional

As you almost certainly know, October 25 is/was the ship date for Windows NT 5.1 Workstation or, as Microsoft insists on calling it, Windows XP Professional.  Despite the new name, XP Pro is nothing to be scared of -- it's really nothing more than a 1.1 version of Windows 2000 Professional.  But it's got a bunch of new features.  It's true that most of those features fall in the "nice to have" rather than "need to have" category, but it's still worth looking at... if you're large enough to buy Open, Select, or Enterprise licenses.  People buying retail versions will have to deal with the incredibly obnoxious and insulting "Windows Product Activation," so they may think twice about that upgrade.

If, however, you'll be working with and supporting XP Pro, then you may find this book useful.  As with Mastering Workstation 4.0 and Mastering 2000 Pro, the book covers a lot of topics and is pointed at a wide range of skill levels, from the beginner to the support person.  Let me stress that: the first ten or so chapters are aimed at beginners.  It then kicks into the techier stuff, but some readers seem to get really incensed that there are chapters in the beginning about how to navigate the desktop, run Paint and the like.  Then we cover the geeky stuff.  You can buy it at http://www.amazon.com/exec/obidos/ASIN/0782129811/markminasi.  And if you like it, please consider posting a review -- I'm just holding my breath waiting for the same four guys to post negative reviews because of the first few chapters.  (Sorry if I sound a mite cranky, but I do SO wish these guys would read the online table of contents BEFORE buying a book and complaining about it.) 

Tech Section

This month, I did a fair amount of work with IPSec.  I know that some of you have been eager for information about what it is, what it does, and why you care, so I thought I'd include this introduction, which will appear in some modified form in the Fourth Edition when it arrives next Spring.  But before that, a few smaller items.

Reviews:  NEC MultiSync 1830 LCD Display and Dell's PowerEdge 500SC Servers

I needed some more servers for my testing lab and, as they're not production machines, was willing to forgo SCSI, but I wanted a decent processor speed and absolutely insist on ECC memory -- why any vendor sells computers without ECC any more is beyond me.  Mostly, though, I was looking for cheap systems -- as cheap a system as I could find with a 1 GHz processor, three 20+ GB EIDE drives (you need 'em to play with Microsoft's software RAID), and an integrated NIC that could support PXE booting so I could use RIS.  It even has the unexpected bonuses of a couple of 64-bit PCI slots and ATA-100 support.

While I could have found some clone boxes in that price range, I found that PXE booting was a real stumbling block for clones and that 512 MB of ECC RAM jacked the price up on a number of systems, so I looked to the "big name" boxes and was pleasantly surprised to find that Dell had a server that fit my needs for about $1200, the PowerEdge 500c.  The corresponding IBM models were the closest in price, and they were almost $400 more.  I got a couple of them, have been running them through their paces and have found them in general to be pretty good systems -- 2000 went on without a hitch.  I was extremely impressed to see that while Dell released a BIOS upgrade on 17 October that two servers delivered on the 22nd of October already had the BIOS update installed.  While this may not sound like a very big deal, it is, as I'm used to buying laptops from big names and finding that BIOS upgrades that had existed for three months prior to my purchase were invariably not installed before being shipped to me.

I do have a few quibbles with the systems, but they're not big ones.  First, the fans are noisy; running the two servers significantly increases the background noise level in my office.  Of course, as these are servers, that probably wouldn't be the case for "real" users -- they'd probably put real production servers in a separate, physically secured room.  Second, even though the system supports PXE, it's flaky, and often claims that it can't find DHCP even though booting from the RIS boot floppy finds DHCP every time.  But I'm not sure that's Dell's fault, as I've run into this before.  The boot ROM that many people use for PXE is the Intel Boot Agent, and it's given me trouble with other systems -- for example, my ThinkPad has an Intel-based NIC and I could not get it to PXE boot from my RIS server until I replaced the RIS server's NIC, even though literally dozens of other systems had PXE booted already without trouble from that NIC.  Network Monitor shows that the PXE client does a DHCP "Discover" and that my DHCP server makes an offer, but the PXE client never moves to "Request," so, again, the bug is clearly in the Intel PXE ROM.  I'll just bug Dell about it until they get an updated agent.  Third, I have to wonder about Dell's price on one of it's add-ons.  They've got a kit that lets you rack-mount the server, and that's kind of interesting-sounding.  I've been desperate to find a reasonably priced 1U rack mountable server and while the 500 SC isn't 1U -- it looks more like about 6U -- it'd be nice to start buying all mountable stuff.  But the rack mounting kit is $350 -- about a quarter of the price of the server!  Titanium rack-mounts, perhaps?  Overall, I like the servers and I'm actually thinking of buying one as a workstation.  All I'd have to do is add a sound card and replace the CD with a DVD/CD burner.  I've said a lot of negative things about Dell in print in the past, but so far I have to say that they're changing my mind with this server.  (Once they fix the Intel Boot Agent.)

About a week ago, I turned 44.  And what birthday present did I get from my network?  My monitor blew out.  As I have 12 systems running off a single monitor via a KVM switch (the Avocent SwitchView, highly recommended for small labs), I really needed to get a new monitor.  Yes, I had a spare, but it was... sigh... a mere 17" Viewsonic.  No 1280x1024 for me on THAT baby.  I'd been wanting an LCD monitor, but I wanted one that gave me a screen size about the same as the 21" that blew up.  Found one in the NEC 1830, which calls itself an 18" display but basically has the same viewable area as many 21 inchers.

I was concerned about brightness and image contrast, as well as autosizing.  Autosizing particularly concerned me because I play old DOS games now and then (Star Control mainly) and some LCD screens show 640x480 as a tiny box in the middle of the screen, with a lot of wasted pixels.  Other screens enlarge the image to fill the screen, but use an enlargement algorithm that makes the screen look truly terrible.  Here's what I found.

Bad news:  cost.  It was $929.  But I'm always willing to spend money for a good monitor.  My philosophy has always been that (1) I don't buy new monitors all that often -- every three or four years and (2) while a good monitor is expensive, I spend a lot of time in front of my monitor... and have you priced new EYES recently?  And heck, I just saved all that money on those servers.<g>

Good news:  as I use this one monitor for a dozen systems, all of which use different graphics cards, resolutions and frequencies, I worried about the monitor's switching time.  Would it take 20 seconds to re-sync every time I switched?  The answer is no.  The monitor DOES take a few seconds the first time that it sees each system, but then remembers that system.  Switching is clean.  The screen is incredibly sharp.  Once I get ClearType running on the XP boxes, it'll probably be stunning.  And the monitor offers several resizing options, which are then specific to the system that the monitor is working with.  In other words, if you want System 1 to use one method of resizing and System 2 to use a different one, then no problem, the 1830 remembers.

In sum:  if you're looking for an LCD monitor because it'll use one third the electricity and take one half the space of a CRT but have been waiting for one that's as good and as flexible as a CRT, then this is it -- if the price doesn't scare you away.

Mirroring Details:  Making Win2K Boot Disks And The Truth About EIDE ARC Paths

In early September, I attended 101 Communications' TechMentor conference.  One of its unexpected benefits was that Vue offered the MCSE tests at half-price, and so I thought I'd give the four core tests a whirl.  I was struck by the fact that Microsoft honestly thinks that we all use their software RAID system, as fully nine of the 51 questions that I got on the Server test were about mirroring.  The Professional test also asked a fair amount about mirroring, and when I took the new geeky "Supporting and Maintaining a Microsoft Windows NT Server 4.0 Network" elective test, that also had a bunch of mirroring questions.  (In case you're wondering, I passed them all and am now recertified.  So in answer to the question "is the book all you need to pass the tests?" I can answer "well, I took the core four cold and passed them all, and everything I know is in the book, so if you know the book, you'll pass the tests, I guess.")

I hadn't messed with mirrored drives since NT 4.0, when I found that they weren't all that useful.  They're good for one and only one thing:  a physical failure on the boot disk. A co-author did the mirroring write-up for the Mastering 2000 book, so I'd not had to really focus on making mirroring work on 2000.  Of course there's nothing like actually doing something to learn it, so I spent a Sunday and Monday building mirrored systems, blowing them up and recovering from them.  Creating a mirrored system is simple:  first upgrade the drive that you boot from to a dynamic disk (in Disk Administrator, right-click the icon for "Disk 0" and choose "Upgrade to Dynamic Disk...," then click OK and Upgrade, as well as answer the two remaining "are you sure?" dialogs), reboot, and then right-click the boot drive and choose "Add Mirror...," and then a physical drive to mirror your data onto.  After mirror set regenerates, then the basic approach to recovering from a drive 0 failure is fairly simple:  when the mirror on drive 0 stops working, then you need to just make your computer boot from a different drive, the mirrored one.  But that's not straightforward on most EIDE-using systems.

The answer is a Windows 2000 boot floppy.  Your job is to figure out (1) how do you create a Windows 2000 boot floppy and (2) how do you tell that boot floppy to use a particular partition on a particular physical drive?

Making a Windows 2000 Boot Floppy

We covered this in detail in the Mastering NT Server 4.0 book, but it kind of slipped through the cracks in the 2000 book.

Many people are surprised to hear that it's possible to make a Win2K boot floppy.  After all, the OS is waaay too big a system to fit on a floppy, right?  Right.  But you can use a floppy to help a wounded system START the boot process.  For example, take the case we're looking at here, a mirrored drive in a system of all EIDE drives.  99 percent of what you need to boot 2000 can sit on any drive.  But you need a few files to get things moving.  The exact files that you need vary depending on how your system accesses its boot disk -- what you'll soon come to know as the MULTI() versus SCSI() issue.  Let's first build a boot floppy that will work for EIDE-based systems, and take up SCSI in a bit:

That's it.  What's that, you don't believe me?  Try it with a working system; it'll work for any system that boots from an EIDE drive, and in fact will work for most systems that boot from a SCSI drive.  And by the way, those three files are hidden on the root of the "system" drive, which is probably drive C: on most systems.  And BOOT.INI is usually read-only, but we'll want to edit it, so un-check the read-only attribute.  If the GUI doesn't let you do it, type this from a command line:

attrib -s -h -r c:\boot.ini
attrib -s -h c:\ntdetect.com
attrib -s -h c:\ntldr

Format the floppy, copy the files, and boot from it.  You'll see that you get the normal boot picker and the system boots.  But this boot floppy only knows how to make the drive 0 partition boot.  To teach Windows 2000 how to boot from the mirrored drive, you'll need to mess with ... ugh ... ARC definitions.

Understanding ARC Paths

As you probably know, BOOT.INI files look like this:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Server" /fastdetect
BOOT.INI Syntax

The section [operating systems] is a menu pointing to various places to load the operating system, and with different options.  (You might have more than one copy of the operating system on a given computer, recall.)  Or it might point to a copy of Windows 9x, or perhaps an installed copy of the Recovery Console.  (Which, by the way, you can install even on  NT 4.0 servers -- not a bad plan.)  

That gobbledygook with the multi, disk, rdisk and partitions is a way of describing where a disk partition is.  It's called an ARC path and while I know that you're supposed to define acronyms the first time that you use them, I didn't bother because ARC means "Advanced Research Computer" -- not terribly illuminating.  Anyway, an ARC path is a way of describing a particular disk partition on a particular physical drive -- in multi(0)disk(0)rdisk(0)partition(1)\WINNT, the "multi(0)disk(0)rdisk(0)partition(1)" part identifies the partition (drive C:), and the "\WINNT" just says that the system's files are (not surprisingly) in the directory named \WINNT.  So it's ARC geek-ese for "C:\WINNT."  ARC paths either look like

multi(W)disk(X)rdisk(Y)partition(Z)

or

scsi(W)disk(X)rdisk(Y)partition(Z)

Where W, X, Y and Z are numbers.  But there's something very important that you should understand early on -- these are essentially two completely different numbering schemes.  Some systems use multi() and others use scsi(), and those two define rdisk() and disk() differently.  So it's time for a short digression into disk hardware.

MULTI() Versus SCSI():  INT 13 Bootability Versus On-Disk Drivers

Virtually every modern motherboard has connections to support four EIDE drives.  It distinguishes between the four physical drives by grouping them into two channels, 0 and 1, and requiring that the installer configure one drive on each channel to be the "master" and the other the "slave."  Thus, your systems' motherboards almost certainly support four EIDE drives designated as channel 0 master, channel 0 slave, channel 1 master, and channel 1 slave.  But those hard drives are no good unless you can get to it, so you need some system software to read and write those drives.  The first thing that any system asks of its hard disks, of course, is to boot from one or more of them.

Booting a computer from a hard disk presents something of a chicken-and-egg problem.  You need to load some software into the computer's RAM in order to teach the CPU how to command the disk controller to read data from the hard disk.  But, as we store software on our hard disks, we would need to read that software off of the hard disk.  But in order to read from the hard disk, we need to load some software into the computer's RAM in order to teach the CPU how to command the disk controller and, well, you see the problem.  For years, we've gotten around this vicious circle by pre-loading some software into a memory whose contents survive a power-off situation called a ROM.  As you probably know, that software loaded into the ROM is called a BIOS and part of the BIOS is a program called INT 13 which knows how to access the first X bytes on any or all of the up-to-four EIDE drives.  "X" depends on the BIOS age; originally BIOSes could only see the first 500 MB of an EIDE drive, then a next generation of INT 13s recognized 2 GB, then 8 GB, and newer ones have an even greater limit.

Windows NT in its various incarnations has taken advantage of INT 13's convenience with the MULTI() syntax.  When BOOT.INI tells NT, 2000, XP, .NET Server or whatever that it is to boot from a MULTI() drive, then NT just lets the built-in INT 13 get the basic OS loaded and, as part of the "takeoff process," finds the 32-bit NT driver that supports EIDEs, a file named atapi.sys.  NT then leaves shifts its disk activity to atapi.sys, stops using INT 13, never using it again until the next boot.

SCSI, in contrast, is a quite different story.  The software to manipulate a SCSI disk read or write is more complex, and that software doesn't exist in most computers' BIOSes.  I recall that in the mid-80s in order to make SCSI hard disks work on PCs, you had to create a special boot floppy that contained SCSI disk drivers.  Once booted from the floppy, the drivers let you access the SCSI drives... but it was irritating to need the floppy.

Fortunately, however, SCSI host adapters nowadays contain a BIOS of their own which hides the details of SCSI from the computer, allowing the PC to issue garden-variety INT 13 commands to read and write data.  In such a system, NT is very happy, as the SCSI wolf in EIDE sheep's clothing just looks like a regular old EIDE drive -- MULTI() works fine.  Again, it uses INT 13 to get the boot process started, and then switches over to the particular SCSI host adapter's driver as soon as possible, and at that point NT can see all of the SCSI drives.  But SCSI host adapters can't use MULTI() work all the time:

In that case, your system must do all of its booting from the specific driver for your particular SCSI host adapter -- for example, one of my systems has an Adaptec SCSI host adapter whose driver is named AIC78U2.SYS.  NT/2000 makes it easy for itself by copying that SCSI driver into the root of the drive that it first boots from, and renames the driver to NTBOOTDD.SYS.  (That way, it doesn't have to poke around the Registry looking for the driver -- always knows where it is and what it's called.)  In addition to that, any system whose SCSI host adapter isn't MULTI()-able must use the SCSI() syntax in BOOT.INI.  You will also find that the root directory on the drive that your system first boots from -- probably C: -- contains one more file, NTBOOTDD.SYS -- the driver, recall.  You must copy that file to any bootable Win2K floppies that you make.  To reiterate, the contents of a Win2K boot floppy would be a floppy formatted with Windows 2000 and containing

All NTLDRs and NTDETECT.COMs are the same for all systems, MULTI() or SCSI().  But NTBOOTDD.SYS varies from system to system, of course, depending on those system's SCSI host adapters.

ARC Terminology for EIDE

Armed with that information, you're now ready to write your own MULTI() ARC paths.  Read a multi(W)disk(X)rdisk(y)partition(z) like so:

So here are a few examples from what we know so far.

Suppose you have a computer with one hard disk (set on channel 0 as master, of course -- all one-drive systems must work that way) divided into three logical drives, lettered C:, E: and F:.  The CD-ROM is drive D:.  You've put Windows 2000 on drive E:\WINNT.  The ARC path looks like:

multi(0)disk(0)rdisk(0)partition(2)\WINNT

Multi() is always zero for the motherboard-attached drives.  disk() is always zero when using multi().  rdisk(0) is 0 because it's the first physical hard disk. Partition(2) is 2 because in this case E: is the second partition on the drive.  In my earlier example, E: was the third -- there wasn't any CD-ROM stealing drive letter D: -- and so it was partition(3).  The "\WINNT" means that the name of the partition on E: is WINNT.

If Win2K were on drive F: on that computer, the ARC path would be multi(0)disk(0)rdisk(0)partition(3)\WINNT.

If Win2K were on drive F:, but you'd put it in a directory called WINDOWS, the ARC path would be multi(0)disk(0)rdisk(0)partition(3)\WINDOWS.

Of course, if Win2K is on drive C: then the ARC path is multi(0)disk(0)rdisk(0)partition(1)\WINNT.  (Unless there's a hidden "configuration" partition on the first drive created by the system.  I'll cover that at the end of this article.)

Ugly EIDE ARC Paths And How To Defeat Them

Now comes the strange part.  You have a standard motherboard which can support four EIDE devices.  Each is either configured as channel 0 master, channel 0 slave, channel 1 master, or channel 1 slave.  The path always looks like multi(0)disk(0)rdisk(SOMETHING)partition(partition-number) and you now know about partition numbers -- so what's the value of SOMETHING?  What would the drive configured as channel 1 slave be -- 2, 3, or 4?  Well, it seems to depend.  I've configured a number of systems with different amounts of EIDE drives, and this is what I think rdisk() is doing when it numbers drives.

First, the boot drive must be configured as the channel 0 master on most systems.  (I'm weaseling with "most" because some motherboards have very flexible BIOSes and let you mess with this in CMOS.  But most seem not to.)  That is always rdisk(0).

Next, the system -- NTDETECT.COM, I suppose -- looks on channel 1 for any hard disk, master or slave.  That is rdisk(1).

Then it returns to channel 0 and looks for a second hard disk, ignoring any other kinds of drives -- a CD-ROM, burner, DVD, tape or the like will be skipped.  That will get the next rdisk value -- if it found a drive on channel 1, then this second channel 0 drive will be rdisk(2).  But if it found no hard disks at all on channel 1, then the second drive on channel 0 will be rdisk(1).

Finally, if there is a second drive on channel 1, then it gets the next rdisk() value.  Summarized, you can figure out which rdisk() value applies to each physical drive by noting which channels each drive is on, noting only hard disks.  Then use this:

WAIT, don't run away... if that sounds too bloody hard (and it is), I've got a great workaround.  Just be lazy and build a BOOT.INI on your Windows 2000 boot floppy that covers all of your bases.  Here's how.  First, get your system set up and running with the mirror.  Then create the boot floppy.  Edit the copy of boot.ini on the floppy.  The BOOT.INI on a Dell server looked like this:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Server" /fastdetect

It's in sections -- [boot loader] defines how long to wait for the user to pick an OS, and default tells it which to load if the user does nothing.  In Notepad, copy that last line three times, so the file looks like this:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Server" /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Server" /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Server" /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Server" /fastdetect

Next, change the rdisk values on the three copied lines, making a line for rdisk(1), rdisk(2), and rdisk(3).  Also, change the quoted text next to the options to make clear which each option does.  You'll end up with a BOOT.INI that looks like this:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Rdisk 0" /fastdetect
multi(0)disk(0)rdisk(1)partition(2)\WINNT="Rdisk 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(2)\WINNT="Rdisk 2" /fastdetect
multi(0)disk(0)rdisk(3)partition(2)\WINNT="Rdisk 3" /fastdetect

Now you've covered your bases.  When you've got to boot from the mirror drive, just pop in the floppy and boot from it.  You'll get a menu offering your options "Rdisk 0," "Rdisk 1," "Rdisk 2," or "Rdisk 3."  If you've got a dead drive on the channel 0 master, then don't bother with Rdisk 0; try Rdisk 1.  If you get some kind of "I couldn't boot" error from Win2K, then boot again and try Rdisk 2, and if that doesn't work, then try Rdisk 3.  (If that doesn't work then you probably have a larger problem.  You DO keep regular system backups, right?)

One more thought on EIDE ARC paths:  did you notice that the Dell seemed to boot from partition(2)?  I didn't plan that.  As far as I know, I'm booting the system from drive C:.  But why is drive C: the second partition?  Because the Dell steals a few megs up front for a "configuration" partition.  Most big-name systems do something like that.  It's nothing to worry about -- I just wanted to explain why it's there.  I never had to worry about it, though, as I just copied that first line and changed only rdisk().   

SCSI ARC Paths

In case you have a system that must boot from a SCSI hard disk, and for some reason you can't fit that SCSI drive/controller into the MULTI() syntax, here's how to build SCSI ARCs.  They are considerably more logical.  Read a scsi(w)disk(x)rdisk(y)partition(z) like so:

I hope you don't have to mess with this much.  But let me give you a very important piece of advice:  make the floppy as soon as you mirror the drive, and test it out.  It won't take but a few minutes now, and you'll be able to do it while you've got a clear head, instead of when 15 people are yelling at you to get that darned server up NOW!

Understanding IPSec

Basic garden-variety IP lacks security, and that’s fine in most cases – if you’re just visiting my Web page, then you really don’t care much if anyone were to snoop on you, unless of course your boss had issued an edict against visiting my site.  And it’s possible but very unlikely that someone on the Internet, sitting on a computer between you and me, would take the time to somehow intercept the data that my Web site were sending your browser, modifying it before sending it to you so as to produce a falsified page.

But many communications do need security.  If you were to visit my Web site to buy something online, then you’d want that communication secured.  SSL solves that problem, but it’s pretty much restricted to a Web-only protocol.  If a company had two offices across the country from one another but used the Internet to connect a server in one site to a server in the other site, then the company would probably want to ensure that any communications between those two servers both couldn’t be snooped upon, and couldn’t be modified along the way by evildoers.  SSL wouldn’t really be the answer for that.

Instead, another set of protocols called IP Security or IPSec seek to provide a generic answer for securing IP-based networks.  IPSec operates at the same layer as IP, rather than SSL, which, again, is an application-layer protocol.  IPSec is also a necessary part of using the Virtual Private Network (VPN) protocol L2TP – you can’t run L2TP without IPSec.

Basically, IPSec lets you take any two computers and secure the conversation between them to varying degrees.  To understand how, you need to understand IPSec "actions," "filters," and "rules."

IPSec Action Types

IPSec lets you choose how secure a communication between two computers will be.  Basically, it offers four levels of security, four of what is called in IPSec-ese "actions":

Let’s examine those in a bit more detail.

Block Transmission

This does just what it sounds like:  it blocks transmissions.  When you tell IPSec to “block” traffic from machine X to machine Y, then the IPSec code on machine Y just simply discards any traffic coming in from machine X.

While this might seem at first blush to be kind of useless, if you think about it then you’ll see that it isn’t at all.  In some senses, blocking traffic is the most extreme option for security, right?  For example, my firm might have a competitor whose systems run on subnet 200.200.100.0, and I don’t want them to be able to send me mail, visit my Web site, or communicate with my network in any way.  (Granted, these would have to be pretty truly hated competitors -- Vaders to my Kenobi -- but I needed an example.)  I could set up IPSec on my systems to block that subnet, just discarding any packets that arrive from them.

Encrypt Transmission: ESP

Here, I want to allow traffic to pass from machine X to machine Y, but I’m worried that someone will eavesdrop on the network connection between X and Y.  So I tell IPSec to use a protocol called the Encapsulating Security Payload – and I’ll bet you didn’t need to be precognitive to guess that its acronym is ESP – to encrypt the traffic before putting it on the network.   Snoopers will only see an unreadable, random-looking stream of bytes.

Notice how convenient it is that IPSec works way down at the network protocol layer – it can encrypt anything.  Do you like the convenience of Telnet but hate that it sends its information in cleartext?   Just tell IPSec that whenever machine X and machine Y are using Telnet to communicate that IPSec should use ESP to encrypt the communication.  No modification required at all to the Telnet server or client.

When would encryption be useful?  Perhaps you have a few machines inside your intranet that handle very sensitive information – payroll info, or perhaps customer credit cards.  The data might be kept on a machine named SQL1, and it might be entered and edited only from workstations WS1, WS2, and WS3.  You might fear that an insider might set up a sniffer on the network to trap this traffic as it goes by, collecting privileged information.  You can keep people from accessing SQL1’s database in the first place with permissions, as you already know.  But you can keep people from listening on the wire by creating IPSec policies on SQL1 that force it to encrypt any communications to and from WS1, WS2, or WS3, and you can create similar policies on those workstations.

Or, in another instance, suppose you had a server in Chicago and offices all around the country, containing workstations that need to access data on that server.  Suppose also that the only way that the offices connect to Chicago is over the public Internet, and you’re (rightly) concerned that running company data over the public Internet might not be the best idea, security-wise.   You could create an IPSec policy on the Chicago server so that it will only accept encrypted traffic – it never accepts cleartext communications.  You would then create IPSec policies on the workstations so that they only communicate with the Chicago server via ESP.

Sign Transmission: AH

In certain kinds of network attacks, the bad guys fool your computer into thinking that transmissions from them are transmissions from someone that you trust.  Or other attacks involve grabbing transmission packets somewhere between you and the trusted person, modifying the packets and sending them along to you – what is called a “man in the middle” attack.  IPSec lets you guard against this with a protocol called Authentication Header or AH.  AH is a method for digitally signing communications.  If your computer and mine are performing signed communications, then we’re not encrypting our data, and anyone listening on the wire could overhear our communications.  Instead, digital signing adds a bit of data to the end of our network packets which we can use to verify that the data wasn’t changed in transit.

Permit Transmission

“Permit” is IPSec’s phrase for “no security at all.”  It just tells IPSec to let the traffic pass without any changes to it and no checks on its integrity.  This is basically what happens in a TCP/IP-based network that doesn’t include any IPSec.   Why, then, have a “permit” action at all?  So that you can create rules that restrict some things but not others, like a rule (which you’ll see us build later) that says “block all incoming traffic except for traffic on ports 80 and 443 – permit only traffic on those ports.”

IPSec Filters

Now that you know what IPSec can do, lets examine an important flexibility about IPSec – its filters.  In my examples so far, I’ve said that you can direct IPSec to encrypt traffic between two particular systems.  In another example, I said that you could tell IPSec not only to encrypt transmissions between two particular systems, but that you could further refine IPSec’s mission by saying that it should encrypt transmissions between those two systems only when running Telnet.  In the section on blocking traffic altogether, I suggested that you might want to tell your Web server to block any traffic at all from subnet 200.200.100.0.

More specifically, you can use filters to restrict IPSec to securing communications

All of this makes for a very nice amount of flexibility in IPSec-ing.

IPSec Rules = IPSec Actions + IPSec Filters

Blocking, encrypting, signing, or permitting traffic is said to be an IPSec action.  You’ve just met IPSec filters.  But to use IPSec, you combine a filter and an action to produce a rule.  For example, suppose you want to tell the IPSec system on a given computer, “encrypt all Telnet traffic from the computer at 10.10.11.3.”  That’s a rule.  It has a filter part and an action part:

If you spend some time working with Windows 2000's (or XP's or .NET Server's) implementation of IPSec, then you'll see that you control IPSec by building policies, and that policies are built up of one or more rules.  As you've just seen, rules are built of a filter ("should I do it?") and an action ("what do I do?").

Signing And Encrypting Need One More Piece:  Authentication

In order to make either digital signatures or encryption work, you need a set of agreed-upon “keys” – passwords, basically.  So whenever you create an IPSec rule, then you’ll have to tell IPSec how to authenticate.

Microsoft’s IPSec supports three methods of authenticating:  Kerberos, certificates, or an agreed-upon key.  The “Kerberos” option only works between computers that are either in an Active Directory domain, or in AD domains that trust one another.  Simply having two computers that have Kerberos clients won’t be sufficient and, insofar as I can see, even having two Windows systems that are members of the same Unix-based Kerberos version 5 realm (the Kerberos version of what we call a domain in the Microsoft world) can’t use IPSec to communicate while authenticating with Kerberos.  Perhaps Microsoft should have called this options “Active Directory” rather than “Kerberos.”

The “certificates” option allows you to use Public Key Infrastructure (PKI) certificates to identify a machine.  The “preshared key” option lets you use a regular cleartext string as the key.  Not very secure, but as Microsoft is always very careful to say, “hey, it was in the RFC, so we had to include it.”  I love the preshared key option, myself, as it’s great for experimentation.  No need to set up a certificate or an AD domain – just tell both machines to use a preshared key and they type in some text, like “this is a secret” on both machines.  I wouldn’t use it in a production environment, but for teaching and testing purposes, it’s great.

Microsoft’s IPSec implementation of authentication has a sort of annoying habit:  it demands an authentication method whether IPSec needs it or not.  You see, simply permitting traffic through without changing it, or blocking it altogether, do not require any agreed-upon keys, so in theory any rule that only includes permitting and blocking should not require choosing an authentication method – it’d be like the Department of Motor Vehicles refusing to let you register your electric car unless you tell them whether you put regular or high-test gas in the car.  But, again, Microsoft’s IPSec asks you for an authentication method anyway, even though it’ll never use it.  So if you’re building an IPSec rule that only permits and/or blocks, then go ahead and choose any authentication method; it doesn’t matter.

And when would you use only permitting and blocking?  When you set up IPSec to do one of it's most interesting (but largely unmentioned by the literature) abilities -- building very flexible packet filters, for example.

I'm just about out of space, but let me provide a pointer to what will, I hope, be the next question in your mind:  how do I play with this stuff?  Well, IPSec is driven by policies, either local or domain-based.  You can create IPSec rules from the Local Security Policy program (secpol.msc) or via Group Policies.  Policies contain one or more rules.  The best strategy for creating rules is, oddly enough, to first define the filters and actions in one place, and then glue them together into rules.  To get started, open up Local Security Policy (Start/Programs/Administrative Tools/Local Security Policy) and look for the folder labeled "IP Security Policies on Local Machine."  Right-click that folder and choose "Manage IP filter lists and filter actions," and create the desired filters and actions.  Then close the dialogs and once again right-click the folder and choose "Create IP Security Policy" to create a policy.  Once you've got the policy the way that you want it, right-click it and choose Assign.  You will see that Microsoft has pre-created three policies.  Only one can be in effect at any moment, so unless you assign the policy, you won't see its effects.

I'm out of space, but if you'd like to read a step-by-step example of one use of IPSec -- encrypting the communications between two specific computers -- look at Microsoft's Q article Q301284.  And yes, I'll definitely have more examples in the Fourth Edition, but the MS example will do pretty well until then.  I hope this intro helps you get your feet wet with this potentially quite useful tool.

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:

Comdex Vegas November 13-15

Yes, it's crowded, insane, and messy... but Fall Comdex is too much fun to pass up.  For the third year running, George Spalding hosts Comdex's Windows 2000/2002/XP "X-treme Knowledge" (God, I can't wait for that "X-treme" stuff to die out) sessions.  Sign up and you'll hear not just George and me but also my co-authors Christa Anderson and Doug Toombs, as well as Cisco God Todd Lamme.  I'm not only doing my 2000/2002 talks, I've also been asked to do my Software Conspiracy talk:  "Why Software Firms Produce Faulty Products, How They Can Harm You, And What You Can Do About It."   The site with the specifics on the program is at http://www.key3media.com/comdex/fall2001/education/extreme/.  

TechMentor San Francisco April 3-7

Another reliably good show, and one gaining in popularity, as it seems that every one that I attend is larger than the one before.  It's got great sessions and is back in San Francisco.  Info at www.techmentorevents.com.   Last time, they had a very cool feature in that you could 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 will be doing a general session on Windows XP and .NET Server, as well as a breakout session on Troubleshooting Group Policies and a really geeky (but hopefully clear and entertaining) session on Active Directory replication. I'll also be doing a book signing at the Sybex booth. If you can make it then I surely hope to see you there!

WinConnections in Palm Springs May 5-8

The same folks that put on that Windows 2000/Exchange 2000 Connections conference in Scottsdale are coming to Palm Springs in early May of next year.  I get to keynote this conference and to do a talk that I do a little less frequently than my others -- my Software Conspiracy talk. If you'd like to hear my views on why software is so buggy and what we can do about it then don't miss the keynote.

I'm also doing some breakouts; my "AD classic" talk (an overview of Active Directory with Whistler updates), an explanation of what Windows XP and 2002 will do for (or to) you, and then you can see the World Opening of my new 2000 security talk, "12 Things You Can Do To Secure Your Windows 2000 Network".  I've also been asked to host a "Reader To Reader" session, where you can bring your most puzzling stumpers.  These sessions worked out fantastically in Scottsdale, so don't miss this show.

Find out more at www.winconnections.com.

Windows Decisions 2002 in Chicago May 8-10

The searchwin2k.com folks (who run a great portal offering tons of Windows 2000 information as well as jumping-off points to other great resources) have put together an interesting conference in The Windy City early this November, but world events have prompted them to move it to May.  (Better time for good weather in Chicago anyway.) John Enck, one of my former co-workers at Windows NT (now 2000) magazine, will be offering his unique perspectives, as will Laura DiDio -- Laura's been an NT industry watcher for as long as I can remember. They'll also have geek talks, including my look ahead at .NET Server (and what will be by then a look BEHIND to XP) as well as an AD/migration talk.

Interestingly enough, the conference is free. Free, that is, if you meet their criteria and no, I don't know what those criteria are -- but it only takes a minute or two to apply. Give it a shot and perhaps I'll see you at the Chicago Hilton!

Find out more at http://www.windowsdecisions2002.com/.

Bring Mark to your site to teach

I'm keeping busy doing Windows 2000/.NET Server seminars and writing the Fourth Edition, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2000/2002 techies.  To join the large 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 Jennifer Williams at jennifer@minasi.com, or call her at (757) 426-1431 (between 1 and 5 Eastern time, weekdays, please).

Until Next Month...

Have a quiet and safe month!  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 seventeen thousand subscribers and I hope to use this to get information to every single Mastering NT and 2000 Server reader. Thanks for letting me visit with you, and take care -- may we all weather this current industry slowdown and this not-by-the-usual-rules war!  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.  (Note the new URL; it's a FAQ for people mailing me questions.  Take a peek and let me know what you think!)

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 2001 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.