Mark Minasi's Windows 2000/NT Newsletter

Issue #13 April 2001

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

What's Inside


You Can Now Update Your Subscription Info On-Line

You folks asked for it, so now it's here.  If you want to change anything about your newsletter subscription -- shift from text mail to HTML mail, change your password, update your email address -- you can now do it on-line.  There's a link from the home page, or go to  I hope you find it useful.

Seminars Coming To San Jose & St. Louis (May), Toronto, Montreal & Seattle (June), Raleigh & Dallas (July)

Our two-day Windows 2000 seminars have been a lot of fun and the attendees have been great.  We've finally gotten in our copies of the Third Edition so every attendee gets a copy of the Third.  But the useful information doesn't just stop there:  I've already added 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.  Here are just a few recent attendee comments:

"Kept me interested the whole time!! Even until 5 PM on Friday.  Didn't know what to expect, especially as it wasn't a hands-on class.  I was pleasantly surprised.  Thanks!"

"Magnificent.  Finally a teacher who starts with the premise that his students are skilled.  Entertaining, and he tells it like it is."

"Greatly enjoyed it, learned more in two days than I learned from all of the Microsoft books I've bought."

San Jose's just around the corner.  If you've been thinking about signing up, now's the time.  

Now There Are More Seminars Available, Thanks To Windows 2000 Magazine: Long Beach, Boston, San Francisco

Many of you know that I write for Windows 2000 Magazine.  I've written for them for nearly six years and stayed with them because I like their unique editorial style -- first of all, as a matter of policy they maintain a ratio of one ad page for every page of useful text, where most pubs feed you TWO pages of ads for every page of text, and, second, they insist that the majority of their articles be practical, nuts-and-bolts stuff.  Unlike most magazines, their editorial staff is chock-full of techies and so they're always keeping us on the leading edge.

They've decided to branch out from just written publications to in-person events, and the first bunch are a trio of seminars that they're running in Long Beach, Boston, and San Francisco for their first round.  Kalen Delany shows you how to tune SQL queries and Steve Milroy shows you how to "go wireless," each in a one-day seminar format.  At the same time, I'll be running the very same Windows 2000 Server seminar that I've been doing publicly for the past year -- same Powerpoints, same outline, same presentation.  Attendees don't get a copy of the Third, but the registration fee is a bit cheaper, so it all evens out.  And it lets me increase the number of cities that I'm covering.  The first session is the Long Beach session coming up at the beginning of May (1/2), then Boston the end of May (30/31), and then San Francisco in the beginning of June (7/8).  Visit their site at to sign up, hope to see you there!

We Also Do NT 4.0 Administration Seminars

A few people have called asking if we also do seminars on planning, installing, and managing networks based on NT 4.0 rather than Windows 2000.  The answer is yes -- and in fact we've been doing NT seminars since 1993!  If you're interested, you can find a seminar outline (it's a two-day class, like the 2000 class) at  They're only offered as in-house seminars, though, unlike the 2000 seminars.

Tech Section

Forcing Active Directory to Require Complex Passwords (With a Lesson In Group Policy Conflicts)

You may recall that an early NT 4.0 service pack (either 2 or 3, I forget) included a file called passfilt.dll which, if installed on your domain controllers, would force users to select "strong" passwords, where Microsoft's definition of "strong" ("complex" seems more appropriate to me) is that a password must:

Under NT 4.0, you just installed passfilt.dll on all of your DCs.  To make your Windows 2000 Active Directory domain require complex passwords, however, you use a different process.

First of all, you needn't install passfilt.dll and in fact you won't find it anywhere on the 2000 CD; its functionality is built into Windows 2000.  You need only turn that functionality on, with a group policy.  The short version of how to do that is to enable the policy called "Passwords must meet complexity requirements of installed password filter."  Here are some more step by step details.

  1. Open up Active Directory Users and Computers.
  2. In the left-hand pane (the "command pane,") you'll see a three-computer icon representing your directory.  Right-click it and choose "Properties," then click the tab labeled "Group Policies" in the resulting property page.
  3. This policy is a machine policy, not a user policy.  (This surprised me, as it seemed as if it should be a user policy -- after all, we're controlling how users set policies, no?  But I guess this is a policy that affects any action on this particular machine -- i.e. the domain controller.)  Therefore, open up the computer icon, "Computer Configuration."
  4. Within that, open Windows Settings, then Security Settings -- there may be a bit of a pause here, but don't worry, just give it a few seconds -- then Account Policies, then finally the folder labeled Password Policy.
  5. Inside that folder, you'll see a policy "Passwords must meet complexity requirements of installed password filter."  Doubleclick it.
  6. Check the box "Define this policy setting."
  7. Click the radio button labeled "Enable."
  8. Close the GP Editor.

But you're not done yet -- don't expect this to take effect immediately.  Domain controllers re-apply policies every five minutes, but they can only apply a policy that they know about, so you've also got to wait for the policy information to replicate to other domain controllers.  (Obviously if you have only one DC then replication isn't a problem.)

Now, I DID all that, and then created a user account and tried to give it a short one-character password, expecting to get an error message.  But I didn't; 2000 accepted the short password despite the new policy.  I even opened a command line and typed "secedit /refreshpolicy machine_policy," hoping that would push the system into seeing the policy.  But it still didn't work.

Here's what I forgot.  Domains automatically get a policy called "Default Domain Policy."  When I created my new policy, "Complex password policy," then the Group Policies user interface placed it below the Default Domain Policy, as the UI does by default -- reading top to bottom, you can see the order in which policies were created and/or linked to the domain.  I hadn't realized it before, but the Default Domain Policy object DISABLES strong passwords!

So there's a conflict in policies here -- my "Complex password policy" said to use complex passwords, and the "Default Domain Policy" said not to.  Who wins?  Well, by default, a system pays attention to the LAST command that it heard, and the system executes policies from the one at the bottom of the list in the user interface to the top.  (It's true, believe it or not.)  So the system first got the command to force strong passwords, and then as it worked its way up the UI it came across the Default Domain Policy, which said to NOT force strong passwords.  So no strong passwords.

The answer?  I could have simply set my "Complex password policy" object to "No Override."  Instead, I just moved it above "Default Domain Policy" in the UI.  Result:  strong passwords.

And one more note, embarrassing as it may be:  I thought originally to just try this strong password policy out on an organizational unit, but the policy didn't work.  Then I remembered -- duh -- that account policies don't apply to OUs; you've got to make account policies to domains.

Some NET Commands DO Work Without NetBIOS

You may know that on a network with only Windows 2000 systems and an Active Directory, you can turn off NetBIOS-over-TCP support altogether.  As that's not a possibility for most of us -- if you've got any Windows 9x or NT boxes around, or if you're still running any pre-Win2K server-based apps then you still need NetBIOS -- most of us haven't done much experimentation in a NetBIOS-free environment.  I'd always assumed that the NET.EXE commands -- net view, net use, and the like -- relied upon NetBIOS and would stop working without it.

For the past week I've been running without NetBIOS and I've learned a few things.  Many of the NET commands still work.  NET USE works just as it did before, for example.  Even NET VIEW works, IF you point it at a particular machine, as in "net view \\markspc."  You can't use it to get a list of servers on your domain.  And shutting off NetBIOS greatly decreased the "chatter" on my network -- all of those "browser announcements" went away.  The troublesome part is that now you find your shared volumes by looking in Active Directory -- but AD doesn't know about any of those shares unless you explicitly "publish" them.  A bit more work, but if you can get away with turning off NetBIOS, it's worth looking into.  I cover this in greater detail in the July issue of Windows 2000 Magazine, but I wanted to drop this quick comment to encourage you all to do some experimentation.

Letting Non-Administrators Log On Locally To A Domain Controller Under Windows 2000

It's an old story:  you're playing around with NT or 2000 on just one machine, so you make that machine a domain controller.  You'd like to try out some things with a regular old no-powers user account, but regular old users aren't allowed to log on locally to a domain controller.  What to do?  Under NT, you just fired up User Manager and adjusted a right.  But how to do it in 2000?  Well, the short answer is that the user rights that you modified with User Mangler under NT you now modify using group policies.  The longer answer is that I should have included this in the book, so here's the step-by-steps on how to let people in the Users group log on locally to a domain controller.

  1. Open Active Directory Users and Computers
  2. Open the icon in the left-hand pane with the domain's name.
  3. Right-click the icon that will appear below it labeled "Domain Controllers" and choose "Properties."
  4. On the resulting property page, click the tab labeled "Group Policy."
  5. Double-click the object labeled "Default Domain Controller Policy."
  6. In the Group Policy window that opens, choose Computer Configuration / Windows Settings / Security Settings / Local Policies / User Rights Assignment.
  7. Double-click the line "Log on locally."
  8. Add whatever group you want in the resulting dialog box and click OK.  Close the Group Policy snap-in and close Active Directory Users and Computers, as well as Active Directory Users and Computers.
  9. Open a command line and type "secedit /refreshpolicy machine_policy"

You'll now be able to log off and log back as a non-administrator user and 2000 won't complain.

You Can't "Map Root" With Windows 9x, Sadly (But You CAN from NT)

A reader wrote to asks how he can use Dfs's "map root"-like feature on a Windows 9x client.  For those who don't know what that means, here's the background.  Suppose you have a share where you keep the home directories named USERS on a server named SRV1.  You could map someone to that share by typing

net use x: \\srv1\users

But you typically don't want to connect a user to the top level of the home directories; instead, each user has a directory so that a user named Byron would probably have a home directory named users\byron.  You'd like to attach Byron to the \byron directory inside the \Users share without letting him see the other directories in \Users -- in effect, you'd like to "trap" him in \Users\byron and, even if he were to type "cd .." to try to back up the directory tree to \Users, the system would simply say "there IS no directory above this one," keeping him out of the top-level \Users directory.  In the Novell world, such a thing was called doing a "map root."  In NT and 2000-ese, we call it doing a "deep net use."  And if the \Users directory is hosted on an NT 4.0 server with the Distributed File System (Dfs) installed, or on a Windows 2000 server, then you can tell an NT 4.0 or 2000-based client computer to "map root," like so:

net use h: \\srv1\users\byron

That would work, and if you have those client types then I strongly recommend that you look into using it.  And because Windows 9x has a downloadable Dfs client, you'd think -- certainly the documentation indicates that you can -- that you could do deep NET USEs from Windows 9x.  But, as Microsoft's Knowledge Base sort of says in article Q178631, you can't expect to be able to "map root" unless you're running NT 4.0 SP3 or later on both your workstation and server.   

Why Does My 2000 Box Constantly Dial the Internet?  An Early Answer 

I don't have the whole story on this yet, but I wanted to pass along a Q article number to those who've asked me "why does my Windows 2000 server insist on dialing up the Internet periodically?"  Microsoft published a Knowledge Base article, Q265395, that discusses some Registry entries to adjust.  I know that this is an issue for many of you and I'm looking into it as time permits -- but I wanted to pass along that link for those who might find that useful.

Feedback On My Loopback

Some of you wrote in to tell me that there's another way to tell 2000 to keep an Ethernet card "awake" even if there's no cable attached to it.  I'd offered the pin-outs to build your own "Ethernet loopback." Several of you wrote to tell me that there's a Registry zap that'll do that as well.  Mike Dunn was the first reader to offer this:

"Hi Mark! -- Although your 'Fooling An Ethernet Adapter With a Loopback Cable' solution does work, there is a KB article that describes how to disable this behavior. Refer to KB article Q239924, How to Disable Media Sense for TCP/IP in Windows 2000. We ran across the undesirable side effect of being disconnected and resorted to this registry 'fix'. Great newsletter!
Regards, Mike Dunn"

Thanks to Mike and the others that offered this advice.  Glad I've got you guys to keep me honest.

ECC Memory:  Buy It!

When buying new computers for server or workstation purposes, there are a number of things to look for.  I like built-in NICs and support for the Preboot Execution Sequence (PXE) protocol so that I can stuff new images on new computers without the need of a boot floppy.  Higher CPU speed is great, and of course 2000 is no different from its NT predecessor in its insatiable demand for RAM, so the more memory, the better.

But when you're buying all of that memory, consider what you're buying: more and more bit storage capacity stuffed into smaller and smaller packages.  Random environmental events cause bits to flip sometimes, no matter how good your hardware is -- believe it or not, the actual chip package itself is slightly radioactive (VERY slightly -- don't worry about getting irradiated!) and so once in a while, the chip package itself will emit a particle which can then flip a bit in the chip's electronics.  Power sags, surges and spikes can do the same thing.

This has been an issue ever since the dawn of PCs, but it's a bigger problem for two reasons.  First, PCs used to all ship with some extra memory, a ninth bit for every eight, that could detect such errors, a bit called a "parity" bit.  Systems used that parity bit to check every memory access to ensure that the data in the memory was undamaged.  If the systems found that the memory WAS damaged, however, their response wasn't a very satisfactory one:  the system would simply lock up, leaving a "parity error" message on the screen.  It protected you, the thought was, from saving damaged data.  Nowadays, most systems have done away with the ninth bit, so parity errors have "gone away."  But in reality, of course, memory errors haven't gone away; they've just gone underground.  Now when RAM errors pop up, they can manifest themselves as data damage or mysterious system lockups.  So it'd be nice to be able to restore some of the old parity testing protection.  Furthermore -- and here's the second reason -- you've got a lot more memory in your system then PCs had back in the old days.  Every bit position is, in theory, one more possible location for data failure.  That's not entirely true, as RAM chips are far more reliable than they were in the mid-80s, but overall there is a logic to the point of view that "the more targets, the more hits."

There is an answer that's been around for years but that people don't make enough use of:  ECC memory.  One of the great side-effects of the Pentium II and later chips is an ability to utilize that ninth memory bit, if it's installed, to do something that's somewhat LIKE parity, but better.  ECC -- which stands for "Error Correcting Code" -- can not only detect a bad bit, it'll CORRECT it.  This cool feature basically offers you this trade-off:  buy slightly more expensive memory modules (with that ninth bit for every eight) and then turn on the ECC feature of the computer -- it's in the BIOS setup routine -- and you are assured that when your system mysteriously locks up that you can lay the blame at the feet of the software.

Identify ECC-compatible memory by the "ECC" that the manufacturer usually includes in its name.  Old-style SDRAMs come in a 64-bit and 72-bit configuration; the 72-bit is ECC.  Unfortunately, some manufacturers build cheap motherboards that won't support those extra bits, so don't try this unless you check your BIOS setup routine first.  And unfortunately I've not run across any laptops that offer the ability to do ECC.  But if you can buy it, definitely do!

Amazon Reviews:  A Request

If you've got a copy of the Third Edition and are enjoying it, may I ask a favor?  Now that the Third Edition's out, the Amazon guys have once again set up a review page BEFORE they're shipping books.  The result is that the only people who do reviews are those who have complaints about the previous editions (like the guy who complains that there's no CD -- which clearly refers to the Second), or that it's not an exam cram guide (which I've never said that it is) or the like.  Even if you didn't buy the book from Amazon, that's sort of become Review Central on the Internet and so any comments posted there are extremely influential.  So if you liked the book and would consider taking a moment to post a few words, I'd very much appreciate it, and thanks.


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:

WinConnections in Monterey May 8-11

The same folks that brought WinConnections 2000 twice in Arizona last year are returning but this time in Monterey.  I'm doing a general session as well as a variety of other topics.  Find out more at

InterWorks 2001 in San Francisco May 6

The Interex guys, the people who put on HP World, have hired me to do an all-day pre-conference tutorial in San Francisco on Sunday, May 6 on the topic of Active Directory at their InterWorks 2001 conference.  Information at

Canada Comdex Toronto July 11

My buddy George Spalding and I  visit Our Neighbor To The North to do a one-day soup-to-nuts program as part of the Toronto Comdex show.  Just one day, just George and Mark, and for once I get to go to Canada in the SUMMER!  (For some reason the vast majority of my Canadian clients hire me in the Winter.  I've always just assumed that it was just part of The Universe's Dire Plan To Get Me.)  Find out more at  (More about Canada Comdex, not about The Universe's Dire Plan.)

Bring Mark to your site to teach

I'm keeping busy doing Windows 2000 seminars, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2000 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 information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at more than twelve thousand subscribers (at least until I clean out the "dead addresses" file) 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!  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.