Mark Minasi's Windows 2000/NT Newsletter
Issue #16 August 2001

To subscribe, visit To unsubscribe, link to To change e-mail address, switch between HTML or text format, etc., link to  Visit the Archives at  Please do NOT reply to this mail; for comments, please mail to  

What's Inside


This month, some post-Code Red advice, some Terminal Services nuggets, using an NT 4.0 DNS server in an Active Directory environment, and an oddity -- a circumstance where a Registry glitch in the Windows Time Service causes machines to be unable to log into the AD.  Also, our final seminars of the year are running this upcoming month -- if you've been thinking about joining us for a seminar, now's the time.

The Software Conspiracy Is On Sale (Twelve Bucks!) At Amazon

Amazon's not normally known for its great deals on books (he said, wryly) but I noticed the other day that my commentary on software quality, The Software Conspiracy: Why Companies Put Out Faulty Software, How They Can Hurt You and What You Can Do About It, is now selling for just under $12 on Amazon. Considering that Barnes and Noble want almost $23, that's not bad and, at least in my opinion, is finally just about the right price for it. You can find it at The Software Conspiracy: Why Companies Put Out Faulty Software, How They Can Hurt You and What You Can Do About It. The book is a bit of a departure from my other books in that it's written for a broader audience -- non-techie radio and TV people who've interviewed me about the book all said that they were surprised that they understood it -- but if you've ever wondered why the software companies get away with defect levels that would put a restaurant, automaker, or home builder out of business, then please consider picking up a copy.

Note, by the way, that Amazon's still charging their usual shipping rates, so either buy it in combination with some other books, or go for the we'll-ship-it-to-you-sometime-this-year cheapest rates. If you'd like more info about the book then please visit its Web site,

More on the URL-Only Version Of The Newsletter

I guess I gave the wrong impression last month when I asked about a URL-only newsletter. I never intended, as many of you thought, to say that I would stop e-mailing newsletters. Instead, I meant that currently you have a choice: I either e-mail you a text version of the newsletter, or I e-mail you an HTML version of the newsletter. They're basically the same piece -- I don't send graphics; the HTML version's just a little better-looking, as I can use fonts and text formatting. What I meant was that I was considering offering a third option, where I would just send an e-mail containing just a URL. You'd click the URL and read the newsletter on-line at my Web site. I'd still e-mail the full text of the newsletter to anyone who wanted it, fear not.

You already have a password!

Many of you said that you didn't want to have yet another username and password, and as I indicated that you'd log onto the Web server to read the newsletter, you told me "no! Don't make me remember register and remember a username and password!" But you already have one: you got it when you registered for the newsletter. Your username is just the e-mail address that you want the newsletter sent to, and you chose a password when you signed up. If you've lost it, then the system will e-mail your password to you if you just visit

You can already read back issues

Some of you said that you'd only recently joined and wanted to read the back issues. That's no problem -- just visit, supply your e-mail address and password, and you can read all the old (and current) issues.

What about a search engine?

Many of you said that if I'm going to let people read the newsletters on-line that I really need to put together a search engine so that it's easy to find a particular topic.

I can't argue with that. So I'm working on it but have found that Index Server under Windows 2000 is a bit more challenging than I originally suspected. I'm cracking it, but slowly. (And of course the fact that the recent Code Red worm is based on a bug in Index Server has hampered finding any help on the Internet -- any search on "Index Server" yields mostly Code Red advice.) I've got a new search engine up at, give it a shot and let me know what you think. 

Our September Classes (DC, NYC, Pasadena, San Francisco, and Chicago) Are The Last For The Year!

To ensure that I've got the time that I need to get the Fourth Edition of Mastering Windows 2000 Server done, we've closed the book on public seminars for 2001. If you've been meaning to get to one of my seminars, then there are just a few left -- and they're in DC (Crystal City), New York (outside LaGuardia), Southern California (Pasadena), San Francisco (Embarcadero), and Chicago (Itasca).

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 to see specific session dates and locations, seminar outline, and how to sign up.  

Tech Section

Thoughts On Code Red

A few weeks ago, I found that my IIS server started mysteriously crashing every twenty minutes or so.  The Event Log was characteristically unhelpful -- "an unknown error" was the cause.  After experiencing nothing but good things with IIS 5.0, I was mystified.  I tried a bunch of things and finally surrendered, determining to spend the $245 to call Microsoft.

No sooner had I said "IIS," when the obviously-harried Microsoft support guy pointed me to two URLs.  They were patches for the worm now known as "Code Red."  Apparently it takes control of an IIS server by sneaking past its security via a bug that Microsoft patched back in May... but that I'd not noticed the patch for, and so I'd not patched my server.  A later version, Code Red 2, does some nastier stuff -- copies CMD.EXE into your Scripts directory and renames it ROOT.EXE, so that it can pretty much do anything that it likes, copies EXPLORER.EXE into the root directories of your drives, and disables Windows File Protection with the FFFFFF9D entry that I covered in a previous newsletter.

Now, normally Code Red doesn't crash Web servers; instead, it destroys their home pages, rewriting them with a message along the lines of "You have been hacked by Chinese!"  But that didn't happen; instead, my server crashed.  Why?  Because of my approach to Web security.

Like other small business people, I threw my Web server together quickly and told myself that I'd secure it later.  Of course, "later" never comes.  But a client, Jim Forkner of Penn State, e-mailed me, telling me that my Web site was, in Jim's words, "wide open."  That motivated me to get off my duff and fix it.

Now, Microsoft has a couple of papers on securing IIS, and the one specific to IIS 5.0 is at  But even before that came out, I'd reasoned in this way:

I don't have the time to check Microsoft's security updates every day, and I'm not yet a super-developer-guru kind of guy on IIS; I'm stronger on the administration side than the development side.  So I need a quick and dirty way to feel relatively secure about my Web server.  So when I'm analyzing a security problem, I always ask myself:  what user account is running when this potential security risk is occurring?  How can I protect myself from that user account?

In the case of IIS, the answer is the IUSR account.  When you install IIS on a computer, the computer creates a user account called IUSR_machinename, so for example if I were to put IIS on a computer named PC34 then I'd have a user account called IUSR_PC34.  Now, let's take this a bit further.  Whether you realize it or not, when you visit an IIS-based Web site, you are logged onto that Web server as the IUSR account.  Whenever you try to do something, like view a page or run a script, then NT or 2000 checks your permissions to do that, as always.  IIS itself has some built-in security, so you've got to get its OK to do anything, but, as we've seen, there are bugs in IIS security.

So I've always put my trust in NTFS as a fallback.  Here's what I mean.

Suppose you want to visit my home page,  The machine that runs the Web server is called \\DUN, so it's got an account called IUSR_DUN on it.  You point your browser to and find my Web server.  It logs you on as IUSR_DUN.  Next, it says "hmmm... IUSR_DUN wants to see default.asp, our home page.  Let's check IUSR_DUN's credentials... OK, fine with me, I'll just load up that page."  But when IIS goes to get default.asp, then it must of course fetch it from the hard disk.  At that point, NTFS wakes up, assuming that you've got your wwwroot on an NTFS drive.  (Please tell me you do!)  NTFS then steps up and says, "hey who wants that file?"  And IIS responds, "IUSR_DUN does."  NTFS then looks at the file and directory permissions that IUSR_DUN has for default.asp and, assuming that the IUSR_DUN account has read permissions, then you see the page.

But suppose you run some script that exploits some hole in IIS security that lets you, say, erase or replace files on the hard disk of the Web server?  What stops you?  Well, with hope IIS would, but let's suppose that there's a bug in there like Code Red, so IIS just falls over.  What does NTFS say?

Well, NTFS would be of some help, except for one little problem:  the default permissions on just about everything are Everyone/Full Control.  That's the key to a simplistic step that you can take to secure your Web server.  I went to the root directories of my disks and specifically denied IUSR_DUN access to everything on the hard disk.  Then I gave it read access to wwwroot.  I found that didn't work, and that I needed to loosen things up a bit more, letting it write to a directory where scripts write data, and apparently it needs to be able to read WINNT.  But other than that, no access.  The result?  When Code Red tried to overwrite my home page, apparently it wasn't ready for a "no writes allowed" response from NTFS, and so apparently a bug in Code Red made it crash, taking IIS with it.

Now, I'd rather that it not affect me at all, but I was happy to see that it hadn't harmed my data.  And Microsoft even refunded me the $245.  The moral of the story is:  know who the relevant account is when something's happening... and take a little time to tweak that account's NTFS permissions.

Now, if you'll excuse me, I have to go apply two patches to about two dozen servers...

One Web Server Can Provide Remote Access For Many Win2K Servers Via Terminal Services

While teaching at the University of Georgia (Athens) this month, Buz Dale (one of the attendees) asked me about Internet Information Server and TSAC, the Terminal Server Advanced Client.

In case you don't know, TSAC is a piece of free code that you can add onto a Windows 2000 Server running Terminal Services. It lets you use Internet Explorer as a Terminal Server client. A nice tool, but I've always felt a bit queasy about having to make every computer that I want remote access to into a Web server. Turns out it's not necessary.

For those who don't know what I'm talking about, let me ask, "how would using Internet Explorer into a remote control tool be useful?"  Well, let's suppose that you set up a Windows 2000 server and want to be able to administer it remotely. You could install PCAnywhere or something like that, but you'd have to pay for that, and here's a free solution. First, turn on Terminal Services in the Control Panel (there's a whole chapter in the Mastering book about this, in case you're wondering). Now the server side is ready. On the client side, you need a program that will let you connect to the server and originally that was a specific Terminal Services client program that you had to install on any computer that you wanted to control the server from. But I found that inconvenient, as my need for remote control often happens when I'm away from home and may not have a Terminal Services client handy.

Terminal Server Advanced Client (TSAC) or, as it's sometimes called, Tsweb, solves that problem. You install it on an Internet Information Server once and from that point on, you can use that IIS server as a jumping-off point for control of any server running Terminal Services. So, for example, suppose I have three domain controllers called DC1, DC2, and DC3, and a Web server named WEBBER (, all on my network. I've put Tsweb on WEBBER and enabled Terminal Services on DC1, DC2, and DC3.

Now suppose I need to do some remote administration on DC2. I just open up Internet Explorer and point my browser to -- you've got to add that "/tsweb" part. I then get a "Welcome to Terminal Services" screen which prompts me for the name of the server (so I fill in DC2) and then opens up a page showing the logon screen for that server. I log in, get my work done, and log off, again requiring nothing more than IE on my desktop.

Anyway, here's where Buz helped: I've always said that you needed a copy of IIS on every server that you wanted to do remote administration on. Buz pointed out that I was completely wrong -- you need only have one IIS server to do that. That's a comfort, given the recent security problems with IIS. Thanks, Buz!

Letting Non-Domain Admins connect to a Win2K Server via Terminal Services in Remote Admin mode

I really like Terminal Services for Windows 2000 in the "Remote Administration" mode; it lets up to two people use Terminal Services to remotely control a Windows 2000 Server, and doesn't require me to buy any Terminal Server client licenses. But when you select "Remote Administration" mode for Terminal Services, then Terminal Services only lets members of the Domain Admins group log into Terminal Services. I wanted to let regular old users log in, but didn't know how. While teaching a class for a large communications company this month, I found out how.

  1. Open Terminal Services Configuration (it's in Administrative Tools)
  2. In the command pane (the left-hand pane of the MMC console), click on "Connections."
  3. In the right-hand pane, you'll see an icon representing a connection (a hard disk atop a network connection) and the words "RDP-Tcp," "tcp," and "Microsoft RDP 5.0." Double-click the icon to bring up its Properties dialog, or just right-click the icon and choose "Properties." You'll see a property page labeled "RDP-Tcp Properties."
  4. Click the "Permissions" tab.
  5. Note that right now, the tab shows only the System account and the local Administrators group. Add any person or group that you like, and they'll be able to log onto the server via Terminal Services.

You Can Use NT 4.0 As A Secondary DNS Server for Active Directory

Once more, the Athenians helped me out.

While at University of Georgia, we talked a lot about DNS, as it's often the biggest stumbling block for organizations getting ready to roll out 2000. And, as always, part of my lecture explains that surprisingly you can use an NT 4.0 server running NT's DNS to support the DNS needs of Active Directory. NT's DNS server will, with Service Pack 6a, support both underscores and SRV records. It doesn't, however, support dynamic DNS, which is why I usually only mention it in passing.

But someone in class (I forget who, or I'd thank him/her) then pointed out that its lack of dynamic DNS abilities doesn't really take it out of the running for AD usefulness. You could, the attendee pointed out, probably use an NT DNS server as a secondary DNS server on an Active Directory. It sounded like a good idea and a good insight, so I tried it out -- and it works great in that role. Now there's a way to let those old 100 MHz Pentiums play a role in your brand-new Active Directory!

Fixing Login Failures Due To Using A Non-Microsoft Time Server For Time Synchronization In Windows 2000

A reader wrote to say that he was having trouble making time synchronization work on his Windows 2000 machines.  What he did that was a bit unusual was to choose to override the standard time synchronization procedure, choosing not to let the 2000 boxes find their own time server (which will be a domain controller normally) but instead to force the machines to use a Unix-based SNTP server.

So the reader told the workstations to synchronize their clocks with a Unix time server with the NET TIME /SETSNTP command.  For example, if they'd wanted to set their machine's time from the US Naval Observatory's time server, they'd have typed

net time /

Now, that should have worked.  But it didn't, unknown to the reader.  The 2000 box couldn't synchronize with the desired time server, and so that 2000 box's time drifted so far from the actual time that Active Directory couldn't log the computer (or its user) on.  (Recall that AD needs good time synchronization because Kerberos, its authentication protocol, needs fairly consistent time between a machine and its domain controller.)

What happened?  Windows 2000 got its Registry entries mixed up.

In order to synchronize its time, a 2000 box obviously needs a time server to synchronize with.  But Microsoft knew that administrators wouldn't want to have to punch a time server's name or address into every single workstation, member server and domain controller, so Windows Time Service offers you an option:  either you tell it what time server to use, or it will go find one of its own.  By default, 2000 boxes will find time servers of their own -- member servers and workstations synchronize with the domain controller that authenticated them, the DCs synchronize with the PDC emulation operations master in their domain, and the PDC emulators all synchronize with the PDC emulator in the forest root, as I explained in chapter 8 of the Third Edition.  So for most of us, Windows Time Service is a don't-think-about-it thing:  it just works.

But under the hood, here's how Windows Time Service knows whether to go find a time server, or to use one that you specified -- with a Registry entry.  Two, in fact.  They both live in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters.  One parameter, "Type," tells Windows Time Service whether to find a time server or to use a user-specified time server.  The other, "NTPServer," tells Windows Time Service what time server to use, if Windows Time Service isn't already configured to find a server of its own, as you'll see in a minute.  But first, here are the possible values for Type:

So consider two scenarios:  a standard "go find your own time server" situation, and a "use the time server that I'm telling you to use" situation.  In the standard situation for a Windows 2000 system that's part of an Active Directory domain, the 2000 system goes and finds its own time server, usually its domain controller.  In that case:


NTPServer=(doesn't matter)

The NTPServer entry can be empty or filled, it doesn't matter -- if Windows Time Service is in "Nt5DS" mode, it doesn't look in NTPServer.  If, on the other hand, you've told your workstation to use a particular time server, perhaps (again), then the entries look like this:


For some reason, when the reader set his time server with NET TIME /SETSNTP, Windows 2000 put the time server's name into NTPServer, as it should, but it did not change the value in Type.  As a result, Type still contained "Nt5DS," and so the computer ignored the reader's directive to use the Unix time server.  The machine's time drifted too much and the Kerberos problem eventually surfaced.  The answer, of course, was to change the value in Type from "Nt5DS" to "NTP."

Now, there's more to this than I'm telling you apparently, as I've found while experimenting that Windows Time Service that it's smart enough to sometimes fix itself.  But in some cases it can't -- so take a peek in your System event log now and then, and if your system tells you that you've got an "Event ID 54" on the Windows Time Service, then take a peek at Type and NTPServer.

The short version of his problem was this.  If a workstation's time gets seriously out of whack from a domain controller's, then the DC won't be able to log the machine (or its user) on, as Active Directory relies upon Kerberos for authentication, and Kerberos needs good time synchronization between server and client, or it won't work.  


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 Francisco September 4-8

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

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 Phoenix October 1-4

The same folks that put on that Windows 2000/Exchange 2000 Connections conference in Monterey are coming to Phoenix (well, really Scottsdale) in early October.  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), 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.

Find out more at

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.  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  

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, mail Jennifer Williams at, or call her at (757) 426-1431 (between 1 and 5 Eastern time, weekdays, please).

Until Next Month...

Have a great 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 fifteen 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 in peace!  Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at

To subscribe, visit To change e-mail, format, etc., link to  To unsubscribe, link to Visit the Archives at Please do NOT reply to this mail; for comments, please mail to

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