Mark Minasi's Windows 2000/NT Newsletter
Issue #17 September 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 link to  

What's Inside


Get ready for the biggest newsletter I've ever done!  Back to school, back to work, or back to looking for a job for those unlucky folks caught up in The Big Recession That Seems To Only Have Hit Us Techies.  This month, some good news (the search engine's working), a gift (my 1998 book on Windows 98 support is now free for downloading), info on two great new books that I didn't have to write, I just "guided," a bunch of tips and a big article on Indexing Service that includes everything you'd need to put a search engine on a Web server.  We've got just the last few classes of the year going on between now and the end of September, there are some great conferences coming up and even a free Windows 2000 conference just announced.

Note:  Please Don't Hit "Reply" To This Newsletter

In order to keep the maintenance tractable on this newsletter, I send it out from an account that I only track for names to delete -- bounced names and such.  (A fair amount of work, so please, if you move then either update your member info or unsubscribe -- links are at the top and bottom of the newsletter.)  As there are thousands of machine-generated replies ("delivery failure," "Joe Smith is on vacation," and the like), I can't pick through them to find mail from people who just hit "reply" to ask a question.  I'm always available for questions or comments at; so again please understand that replies to this newsletter probably won't be seen.  Thanks!

The Newsletter Search Engine Is Up

It's finished, at least for now; you can now log on and read either any given issue, or search on keywords using the Index Server query language at  

The Expert Guide To Windows 98 Is Now Free

My book The Expert Guide To Windows 98 is now out of print, sadly, but now you can get it in PDF form on the Web site.  Visit to view, download, or print its chapters.  Enjoy it and please tell your friends to come check it out.

New Books: Windows 2000 Scripting and Group Policies In-Depth, With Enterprise Storage On The Way!

A while back, Sybex asked me to write more books.  I told them that I'd love to, but, as they know, I'm the world's slowest writer.  So they said, "could you EDIT a few books?"  Sure, I said, grinning fiendishly -- just let me pick the best Windows 2000 topics and authors, and let me give them all of the time that they need.  AND don't make them turn out 1500 page tomes; if they can get the job done in 400 pages, that should be enough.  I sat back and expected them to tell me "thanks, but no thanks."

Well, they surprised me.  They said, "sure."

So I immediately signed a book on scripting.  Christa Anderson, who's worked with me on a number of books and who penned a great introduction to local area networks (Mastering Local Area Networks, Sybex) was just the choice for Windows 2000 Automated Deployment and Remote Administration, a book on both building scripts and doing automated rollouts.  Basically, Christa takes a simple, logical approach to scripting.  By her lights, scripting languages are little robotic hands that push buttons and pull levers for you, so she starts out with a great tutorial on VBscript.  But what then she zeroes in on those buttons and levers or, in other words, the scripting interfaces WMI (Windows Management Instrumentation) and ADSI (Active Directory Scripting Interface).  WMI is the set of scriptable commands that control hardware and local configuration on any system -- you'd use it to find out whether a system had a SCSI or ESDI disk, to shut it down, or to format a disk.  ADSI lets you manipulate Active Directory (and, if you're patient enough, even NT 4.0) domains and accounts.  Scripting is one of those things that we've all got to learn in the next few years, and Christa has done a bang-up job of showing us how!

The other immediate "must-have" topic was, I thought, group policies.  So I turned to the guy who lives and breathes it -- Jeremy Moskowitz.  Jeremy's not only smart and hardworking, he's also tenacious -- I almost grew to feel pity for the Microsoft people who initally dodged his incisive group policy questions on e-mail, thinking that perhaps he'd just go away and stop asking them why their product didn't work as advertised.  He never did go away, and as a result there's stuff in this book that I don't think exists anywhere else in print.  Jeremy shared much of the book's writing with Derek Melber, another GP genius, and enlisted the aid of... well... just about everyone that I know in putting this book together.  And the result is a book that is truly "Group Policies, A to Z."  But that's not the name; it's Windows 2000: Group Policy, Profiles, and IntelliMirror.  I have turned to this book time and time again as a reference for GP questions, even before the book was generally available  (that's the advantage of being a series editor) and I'm not just showing pride of parenthood -- well, grandparenthood -- when I say that you will really like Christa and Jeremy's books.

Nor is that the end.  There's an Enterprise Storage book by Peter Bruzzese (almost done!) and, finally, the long-awaited (Amazon's been claiming it exists for about a year now) end-all guide to Terminal Services.  We've got a Security book and a Cluster book in development as well.  But more on them when they arrive. 

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

Changing A Password From The Command Line

I got a question on this recently and I'm not sure I covered it in the book.  How can you change someone's password from the command line?  

Well, if it's a local user account, then simply net user username newpassword so,for example, to change the local admin's password to "bigsecret," you'd type

net user administrator bigsecret

But that only works for local accounts.  To change a password on a domain account, add the /domain option.  So to change the default Administrator password on the domain to reallybigsecret, type this:

net user administrator reallybigsecret /domain

And I recently found a great 2000 Resource Kit tool that will set a password to a random value -- cusrmgr.  Why would you want that?  Personally, I don't want people using the default Administrator account, but it's so hard to break them of the habit.  So I randomize the password, make people use their own Domain Admin account, turn on auditing and threaten Severe Punishment to anyone caught setting the Administrator password back to something else -- unless there's a good reason.  Cusrmgr randomizes passwords using the -u option to select the user account and the -p (lowercase!) option to randomize, like so:

cusrmgr -u Administrator -p

Use Care When Changing NT 4.0 NTFS Permissions From A 2000 Machine

Several readers told me that they saw some strange behavior when they used Windows 2000 computers to administer their NT 4.0 systems.  In particular, they had trouble when modifying NTFS permissions on a Windows NT 4.0 system from a 2000 system.  Here's what I found.

Open up an NT 4.0-hosted directory from a Windows 2000 computer; right-click it and choose Properties, then Security.  You'll see the usual Windows 2000 Security property tab, which, as you know, offers some things that NT's NTFS Security dialogs never did.  In particular, 2000 supports both the idea of allowing and denying kinds of access -- and finer-grained access at that.  Now modify that NT 4.0 directory's NTFS permissions, specifically denying someone some kind of access.

You will find that NT 4.0 understands the notion of denying access, believe it or not -- apparently NTFS was always smarter than its Security dialog boxes let on, or perhaps the NTFS upgrades that we quietly got when we installed Service Pack 5 on NT 4.0 systems added the ability.  In any case, that NT 4.0 system will now respect that "deny access" permission setting.  So far, so good -- we've discovered some hidden gold in NT 4.0.

But now go back to that NT 4.0 system and try to examine the NTFS permissions on that directory from the NT 4.0 system.  You get an interesting dialog box:

The security information for C:\ is not standard and cannot 
be displayed. Windows NT 3.x and 4.x support certain features 
such as Deny Access Control Entries but cannot edit security 
information which uses these features. The information 
may have been modified by a computer running Windows NT 5.0, 
which supports these features and can edit information which 
uses them. 
Do you want to overwrite the current security information? Y/N

Now, how you answer that dialog box is very important.  To see how, let me re-explain that dialog box, in English.  It's saying this:

"It looks like someone has added some advanced permissions to this directory -- a 'deny' permission, that I'm guessing that you assigned from a Windows 2000 or later computer.  This server knows how to handle 'deny' permissions, so there's nothing wrong here.  But you've asked to view the permissions, and now we've got a problem, as I just don't know how to display permissions of the 'deny' variety.  So you've got two choices.  First, you could just forgo trying to view the permissions on this computer.  If you do that, then everything will work fine; you'll just have to do your permission viewing and setting from a Windows 2000 computer.  Click 'No' if you want to do that.  Second, if you really want to be able to view and set permissions on this directory from this computer, I can do that -- but only if you let me reset the list of permissions (the 'ACLs') on this directory entirely, so we're starting with a clean slate.  To repeat, if you choose this option then you will lose any and all permissions on this directory; no one will have access of any kind until you add people back to the permissions list.  Click 'Yes' if you want to do that."

If you click "Yes," then you'll get a normal NT 4.0 permissions dialog, but it'll be completely empty.  If at this point you've decided that maybe this is a bad idea, and that doing NTFS permissions on this computer from a 2000 box isn't so terrible, then it's not too late -- click Cancel.  Or keep going and rebuild whatever permissions you like.  Take a minute to consider your decision, as you'd really hate to have to rebuild an entire drive's permission structure by hand.  Particularly if it's the boot drive!

Alternatively, you can enhance Win NT's ability to deal with "deny" permissions by using the version of the Security Configuration Manager which appeared at the same time as Service Pack 4 for NT 4.0.

By the way, after I figured this out I found a Knowledge Base article that discusses this; if you're interested, it's Q287024.

Telling Outlook Not To Respond to Receipt Requests

A while back, I commented in a book's introduction (I've forgotten which) that I preferred that people not send me mail that requested receipts of when I'd read the mail, as it seemed to me to be a bit rude -- "I don't trust you to admit that you got this mail, even when I'm not paying for a response, and now that I know that you've read it, you'd better respond quickly," that sort of thing.  Anyway, for some reason in the past couple of months I've gotten mail from some readers who say that they find Outlook annoying in that whenever someone requests a read receipt, then Outlook pops up a dialog asking what they want to do, and is there a way to tell it not to do that?

I had to honestly answer that I'm pretty sure that I'd found the setting to tell Outlook to just ignore the read receipt request, but that I didn't remember if that was the case.  Four readers disagreed strongly with me, saying that there was no way to keep Outlook from replying.  I poked around my notes and found how I did it.

Now, I don't use Outlook with Exchange, I just use it as an Internet mail client, so perhaps my copy (Outlook 2000) will behave differently than yours, but to tell it to ignore read receipts, just do this:

  1. Click Tools, then Options
  2. On the resulting property page (which is simply called "Options"), choose the "Preferences" tab.  It'll probably be up front anyway.
  3. In the section "E-Mail," click the button labeled "E-mail Options..."
  4. In the resulting dialog box ("E-mail Options"), click the button labeled "Tracking Options..."
  5. That will raise a dialog box labeled "Tracking Options" with a section labeled "Use this option to decide how to respond to requests for read receipts;" click the radio button next to "Never send a response."

 That'll do it.  (And to think that you four guys doubted me!)

An Innovative Way To Combat E-Mail Viruses

I recently whined aloud in the e-mail newsletter that I do for Windows 2000 Magazine (get it free at about how bloody tired I was that people are still opening attachments without looking closely at them.  Reader Brian Davis had a great idea:  redefine the VBS, Javascript, REG and similar files so that the default when you click on them is not to EXECUTE... but to OPEN them.  Brilliant and, like most great ideas, should have obvious from the beginning!  You can, of course, still run scripts -- but you must do it by right-clicking them and choosing "Execute" or "Run" instead of "Open."  Here's Brian's Regedit script to make this happen:

@="C:\\Windows\\Notepad.exe \"%1\""
@="C:\\Windows\\Notepad.exe \"%1\""
@="C:\\Windows\\Notepad.exe \"%1\""
@="C:\\Windows\\Notepad.exe \"%1\""
@="C:\\Windows\\Notepad.exe \"%1\""
@="C:\\Windows\\Notepad.exe \"%1\""

Configuring and Troubleshooting Indexing Server And Building Web-based Query Pages

Index Server has surely gotten a fair amount of press attention because it contained the security hole that the Code Red weasels used to attack Web servers around the world.  But it's harder to find useful information on making Index Server work.  Here's some of what I found while getting Index Server up and running, and making it useful.

What Indexing Service Does

First of all, let's stop calling it Index Server, as so many people (including me) still do; its newer, correct name is Indexing Service.  It was originally called Index Server because it was a separate add-on program that shipped for NT 4.0.  Windows 2000 Server and .NET Server include it as a basic system service named Indexing Service.  What it does to make searching today's huge hard disks a tractable affair.

Working in the background, Indexing Service examines and analyzes the files on your system, building and maintaining an index of the words that it finds there.  At first blush, that'd make Indexing Service sound like something that just keeps track of every word, where "word" is just defined as a bunch of letters surrounded by spaces or punctuation.  But think a bit more about it, and you'll see that Indexing Service has a harder job than that.  Extracting words is simple if your document is plain ASCII text.  But if it's an HTML file, how would Indexing Service know that <br> is or isn't a word?  How would it understand words in a Microsoft Word document?  The answer is that Indexing Service includes a bunch of filters, programs that understand particular file formats.  Indexing Service comes with filters that let it understand ASCII files, HTML files, Microsoft Office files and what Help calls "Internet mail and news documents."  (It scans my PSTs?)  Notice that there's no PDF filter; you can download it, I'm told, from Adobe's Web site at

The Annoying Thing About Indexing Service:  Little Documentation

The fact that Microsoft first documented it when it was Index Server means that unfortunately you'll find that most of the Index-related documentation that you'll find on Microsoft's Web site and in books refers to the Index Server, which sort of works like Indexing Service, but not quite.  To make things worse, the old Index Server documentation explained how to build HTML pages to query a cataloged directory and for some reason Microsoft chose not to do that in the Indexing Service documentation.  You're just supposed to know that things "kind of" work the same with Indexing Services as they did with Index Server, so I guess you're supposed to try the old code and hope it works.  It does, sometimes; but I'll give you some basic HTML pages that you can use to create a Web page that will let you search any catalog from a Web browser.  As always, once you know the magic words then you can extract the information that you need from Microsoft's Web site.  

What documentation there is about Indexing Service is in the Windows 2000 Server Help file.  Open its Table of Contents and open the "Files and Printers" link.  One of the sub-links that you'll see is called "Indexing Service."  Or just open up \winnt\help\is.chm.

How You'll Use It (Why You Care)

I've found it a great tool for building a fast, flexible Web-based search engine.  But you can also use it within your network or just on your computer without any Web interface at all.  For example, if you had a huge directory of ASCII, Office, and HTML documents, then you could catalog that and search for particular files extremely quickly.

How It Works

You tell Indexing Service that you want to create a catalog of a particular directory by telling Indexing Service two things:  what directory you want to index (catalog), and where to put that catalog -- after all, the catalog files must reside somewhere.  Indexing Services creates a folder named catalog.wci in the directory that you've told it to store the catalog in.  That leads to the following very important performance concerns -- ones that I learned the hard way.

Managing It

Indexing Service is a service that you handle much like other services -- you can start it, stop it, or restart it.  A standard 2000 install sets it up as a manual rather than automatic service, so you've either got to set it up as automatic or remember to turn it on every time you reboot.  (You do that in the usual way -- right-click My Computer, choose Manage Computer.  Under "Computer Management," open the "Services and Applications" folder and then the object under that named "Services."  In Services, you'll find "Indexing Service;" right-click that and you'll see both "Start" and "Properties" on the resulting context menu.  "Start" starts it right now, "Properties" lets you change "Startup type:" from Manual to Automatic.

Like DNS and IIS, the Indexing Service's snap-in is incorporated in Manage Computer under Services and Applications, near the Services object that you just clicked.  Open it and you'll one or more icons that look sort of like books -- those are the catalogs, and we'll get to them in a minute.  First, though, right-click the "Indexing Service" icon and choose Properties.  You'll see two tabs on the page -- "Generation" and "Tracking."

"Generation" controls how Indexing Service creates indexes. One check box says "Index files with unknown extensions;" it's not checked but if you check it then Indexing Service just says damn the torpedoes and indexes everything, even if it doesn't have a filter for it.  I don't use it, but I'm sure that someone thought it was a good idea.  The other check box, "Generate abstracts," is also unchecked by default, but might be worth checking.  When checked, Indexing Service tries to create an abstract of each file that it indexes.  It's a nice feature but isn't always that smart; for example, it seems to create abstracts of HTML files by displaying the <h1> and <h2> elements of the document, which may not correctly characterize that document.

"Tracking" just includes one check box, "Add Network Share Alias Automatically," and it's checked by default.  This ensures that if Indexing Service indexes a drive that it sees as a mapped drive letter that it remembers not only the drive letter, but the entire UNC.  For example, if you've mapped \\server01\data to X: and indexed X:, then Indexing Services would remember that those files are available at \\server01\data even if you don't have that UNC mapped back to X: when you try to retrieve the indexed documents.

Standard Catalogs

Even if you've never used Indexing Service before, you're likely to already see two catalogs: one called System and, if you're running a Web server on the computer, another catalog called Web.  As their names suggest, they index system information and whatever's on your Web server content.

Personally, the first thing I do is to delete both of them.  Having my entire Web site as well as every hard disk on my server indexed gives me the heebie-jeebies.  I mean, why not just make it easy for crackers to spy on my system once they've cracked Indexing Service?  My feeling is that I'll decide what gets indexed on my system, thanks very much.

To delete a catalog, you must stop the Indexing Service.  Then just left-click the catalog and press the Del key, or right-click the catalog -- although I've seen cases where the "Delete" option doesn't appear on the context menu, but you can still right-click and press Del to get rid of the catalog.

Creating A Catalog

You create a catalog in Indexing Service by right-clicking the Indexing Service icon and choosing New, then Catalog...  That raises a dialog box labeled "Add Catalog" that contains just two text fields:  "Name" and "Location."  In "Name," just fill in the descriptive name of your catalog.  No spaces allowed!  This name doesn't have to relate in any way to the name of the directory that you're going to index.  For example, I named the catalog for my on-line newsletters "Newsletters" even though they don't reside in a directory named "Newsletters."  "Location" is the location of the catalog files, not the files to be cataloged.  This was what I was talking about a while back:  specify a location for your catalog that is different from the actual location to be cataloged.  For example, if I were indexing newsletters in a directory named C:\Newsletters, I might put the catalog's location in, say, "C:\Newsletter Index."  But no matter where you put the catalog, remember not to put it in wwwroot or anywhere under that directory.

If Indexing Service is off when you create the catalog, you'll get a dialog to that effect: "catalog will remain offline until Indexing Service is restarted."  No surprise there.

Tell It What To Catalog, and What Not To

Now Indexing Service knows that you want to catalog something, but it doesn't know what.  So add one or more directories to its list of things to index.  Right-click the catalog's icon and choose New/Directory and you'll see a dialog box asking you to fill in the path and, if relevant, the UNC of the directory to catalog.  Next to that is an odd-looking set of radio buttons asking "Include in index?"

Is this about the dumbest question you can imagine, or what?  Here you are, adding a directory to a catalog -- whose sole function in life is to index data, and this dialog asks if you want to index the data.  What were they thinking?  Well, Indexing Service not only indexes the top level of the directory that you specify, but any subdirectories as well.  So suppose I've decided to index C:\Newsletters, as it contains my old newsletters.  But suppose that inside the C:\Newsletters directory is a C:\Newsletters\In-Progress directory, where I keep my newsletters that I'm still working on.  Well, by default Indexing Service would catalog that directory as well -- so a well-placed query would let you see my newsletters before I'm even finished writing them!  That's not what I want, so I might add C:\Newsletters as I've described, and then add C:\Newsletters\In-Progress -- and then tell Indexing Service not to include C:\Newsletters\In-Progress in the catalog.  The net effect would be to defeat Indexing Service's natural inclination to index everything in C:\Newsletters, even my work-in-progress directory.

Consider File Permissions, or Your Catalog Won't Work

Sometimes security gets in the way of Indexing Service.  So take a minute and consider the file and directory permissions on the things that you want to index.

When I first used Indexing Service, it drove me absolutely crazy.  It could index many files... but not the ones that I wanted, not the ones on my Web server.  I set up a pristine new computer, built a catalog on it with copies of the exact same data files that I wanted to index, and it worked... but not on my Web server.  Then it dawned on me:  I'd monkeyed with the directory permissions on my server.

My original plan had been to adjust the permissions so that the IUSR account didn't have access to parts of the disk that it had no need to have.  But in the process of disconnecting some directory permissions from inheriting permissions from their parent directory, I cleared all previous permissions.  Including the System account.

But, as you've probably already thought, the Indexing Service runs under the System account.  And therein lay the problem.  I'd set up the catalog right; I'd just denied Indexing Service the ability to actually read the files that I wanted it to index.  Now, in my defense, let me just squawk a bit that it'd have been nice if Microsoft offered a verbose logging feature of Indexing Service, where I'd have gotten a clue a bit earlier... but it was still dumb on my part.  So let's stop for a minute and consider permissions.

But we're not done yet.  Eventually you will want to query that catalog, using either a query tool built into Manage Computer which I'll show you in a minute, or perhaps through a Web interface.  Before releasing the answers to a query, Indexing Service checks that the asker has the permissions to see the answer.  So let's see what that means for my example of a Web-based search engine for my on-line newsletters.

Suppose the newsletter directory gave System "Full Control" permissions, but denied the IUSR account all access.  What would happen?  Well, Indexing Service would build the catalog for the newsletter directory just fine.  And if I logged onto the server as an administrator and queried that catalog with some command-line tool or the built-in one that I'll show you in a minute, then perhaps the query worked fine.  But from the Web-based interface, the query fails -- why?  Because Indexing Service sees that the IUSR account isn't allowed to see that data.

In my experience, security is a major cause of failed queries, so keep it in mind when use Index Service-based tools.

Using The Catalog:  Querying Indexing Services From Manage Computer

Once you've created that catalog, how do you try it out?  With a tool built into Manage Computer, under the Indexing Service icon -- Query the Catalog.  You'll see a field where you can type in your query words and a button labeled Search.  The query tool will show you all of your hits and provide hyperlinks that you can click to view the files that matched your query.

This isn't really an all-purpose tool, as it's cumbersome to search a catalog unless you're physically seated at the server whose Indexing Service hosts that catalog.  But it's a great debugging tool because it's a quick-and-dirty way to find out if your catalog is working.

Using The Catalog: The Query Language

But how do you address queries?  Index Services has its own built-in query language that's pretty extensive but also pretty ugly.  You can get the whole scoop in the Indexing Service help file, \winnt\help\is.chm.  Open the top-level booklet icon, "Indexing Service," and inside that you'll see another booklet, "Advanced Topics," (using the silly thing with queries is an advanced topic?), and inside there you'll find another booklet entitled "Indexing Service Query Language."  In this section, I'll just offer "the short version" and provide a few examples.

Simple Words

Of course, you can type just one word and Indexing Service will look for that.  Searching for "Kerberos" will turn up any document with the word "Kerberos" in it.  Indexing Service seems not to care about case -- "kerberos" would turn up the same hits as "Kerberos."

Word Variations Work Too

Indexing Service understands variations on words.  For example, if you search for "patches" then you'll not only get hits that match "patches," you'll also get hits that match simply "patch," or "patching."  To do an exact search, surround the search with double quotes.  Thus, if you type


Then you'll get patch, patches, patching and the like, but typing 


Will only match that exact phrase.

Wildcards Are Harder

But recall that Indexing Service tries to understand text not merely as a sequence of characters but instead as a series of words, so searching for "Kerb" would not yield any hits that matched "Kerberos."  How, then, to do wild cards?  By giving Indexing Service what Microsoft calls a "phrase," wherein you surround your query with {phrase} and {/phrase}; it's sort of HTML-ish.  The asterisk is the generic wild card, as always, so to search for any line that contains "Kerb," type


In theory you can make Unix-style regular expressions work by surrounding them with {regex} and {/regex}, but I've not been successful making them work.

Logical Operators

Indexing Service also understands AND, OR, NOT, and parentheses.  You could search for:

"domain controller" and (kerberos or "LAN Manager")

It also understands NEAR, but only in a very lame way -- "NEAR" is defined as "within 50 words" and, no matter what the docs say, it's not possible to redefine.  So this works:

"domain controller" near Kerberos

It's a pretty powerful language -- it's just a little cryptic.

Using The Catalog:  Querying Indexing Services From The Web

Now that you have a working catalog and can query it from the Query the Catalog in Manage Computer, how do you let the rest of the world (or maybe just the rest of your intranet) query the catalog?  With a Web-based query client.  While this isn't a programming text -- nor am I an expert programmer -- here's a very bare-bones, stripped-down set of Web pages that you can modify and put up to let people query some catalog.

Getting Ready

For this example, let me assume that you're going to index files in a directory called Newsletters which sits in your WWWROOT directory.  (Yes, you can do this for files that aren't in WWWROOT, but this is simplest.)  You have already:

Creating the HTML

You'll need two files:  ask.htm, which contains a form that lets people type in their query, and find.asp, which takes the information collected in ask.htm, executes the query and returns the answers.  Ask.htm is pretty short:

<TITLE>Search Newsletter Archive</TITLE>
<Form ACTION="find.asp" METHOD="POST">
Type in your query<br>
<INPUT TYPE="TEXT" NAME="SearchString" SIZE="94" MAXLENGTH="100" VALUE=" "><br>

This just prompts you to "Type in your query," then packages your query in a variable called SearchString and then calls another HTML page called "find.asp."  (Both ask.htm and find.asp should be in your WWWROOT directory.)

Find.asp is a bit more complex, as it must first perform the query and then format it nicely for the user.  It looks like this:

<TITLE>Search Results</TITLE>

'Set the search parameters

'The following line is a comment; it shows how you'd restrict the search to
'just a directory "folderinnews" inside Newsletters.
'FormScope = "/folderinnews" 

'These lines set the search parameters

FormScope = "/"
PageSize = 1000
SearchString = Request.Form("SearchString")
CatalogToSearch = "Newsletters"

' Create query object

set Q = Server.CreateObject("ixsso.Query")
set util = Server.CreateObject("ixsso.Util")
Q.Query = SearchString
Q.Catalog = CatalogToSearch 
Q.SortBy = SearchRankOrder
Q.Columns = "DocTitle, vpath, filename, size, write, characterization, rank, directory, path"
Q.MaxRecords = MaxRecords 
'util.AddScopeToQuery Q, FormScope, "deep"

' Do query

set RS = Q.CreateRecordSet("nonsequential")
RS.PageSize = PageSize
response.write "<p>Your search for <b>" & OrigSearch & "</b> yielded " 

If RS.RecordCount=0 then response.write "no results."
if RS.RecordCount=1 then response.write "1 result:"
If RS.RecordCount>1 then response.write RS.RecordCount & " results:"

response.write "<table border=1><tr><td>Doctitle</td><td>Vpath</td><td>Filename</td>"
response.write "<td>Size</td><td>Write</td><td>Characterization</td><td>Rank</td>"
response.write "<td>Directory</td><td>Path</td></tr>"

'Display the results

Do While Not RS.EOF
' loop through the results.
' Build a hyperlink to the document
hlink = "<a href=""/newsletters/" & RS("filename") & """>" & RS("doctitle") & "</a>"
' Display attributes
response.write "<tr><td>" & hlink & "</td><td>" & RS("Vpath") & "</td><td>"
response.write RS("filename") & "</td><td>" & RS("size") & "</td><td>" & RS("write")
response.write "</td><td>" & RS("characterization") & "</td><td>" & RS("rank")
response.write "</td><td>" & RS("directory") & "</td><td>" & RS("path") & "</td><tr>"
'Get the next result
Loop 'end of DO WHILE loop

response.write "</table>"
set rs=nothing
set q=nothing
set util=nothing


If you just want to try these out, then copy the ask.htm lines into Notepad and save them as ask.htm, then do the same for the find.asp lines.  While still sitting at that computer, open up Internet Explorer and type http://localhost/ask.htm and press Enter and you'll see your form come up.

How the Query Code Works

To understand find.asp -- which, again, is a very stripped-down query page -- let's take it in pieces.  The first part is just HTML through the <BODY> command.  After that, we see this:

'Set the search parameters
'The following line is a comment; it shows how you'd restrict the search to
'just a directory "folderinnews" inside Newsletters.
'FormScope = "/folderinnews" 
'These lines set the search parameters
FormScope = "/"
PageSize = 1000
SearchString = Request.Form("SearchString")
CatalogToSearch = "Newsletters"

That line with just the <% tells the IIS server that a program is starting.  Lines that begin with a single quote are just ignored by the server; they're comments.  The next bunch of lines set the parameters for the search.  "FormScope" lets us tell Indexing Service that we don't want to search an entire directory, just a subdirectory.  If, for example, we had a directory called \inetpub\wwwroot\newsletters\goodstuff and we wanted the search to only look in the \goodstuff directory, then you'd change the line to 

Formscope = "/goodstuff"

PageSize and MaxRecords restrict the search, limiting the number of hits that Indexing Service reports.  SearchString just retrieves the search text.  CatalogToSearch, of course, says to search "Newsletters."  If there were other catalogs on this server, then you'd change this variable to point the search elsewhere.  SearchRankOrder just says to report them from the best to worst match.  OrigSearch is just for my programming convenience.

The next set of lines forms and executes the query:

' Create query object

set Q = Server.CreateObject("ixsso.Query")
set util = Server.CreateObject("ixsso.Util")
Q.Query = SearchString
Q.Catalog = CatalogToSearch 
Q.SortBy = SearchRankOrder
Q.Columns = "DocTitle, vpath, filename, size, write, characterization, rank, directory, path"
Q.MaxRecords = MaxRecords 
' util.AddScopeToQuery Q, FormScope, "deep"

' Do query

set RS = Q.CreateRecordSet("nonsequential")
RS.PageSize = PageSize

The piece towards the top is just "boilerplate," the particular magic words that you must say to ask Indexing Service a question.  Note, however types of "objects" -- that's the programmer word for them -- in the "ServerCreateObject" commands.  The first in particular, ixsso.Query, is the built-in set of routines that control queries.  To find all of the developer documentation about it, search for "ixsso.query."  

Controlling A Query:  What to Retrieve

If you did that search, you'd see that the "query" method of the "ixsso" object -- I'm so glad the developers kept it simple for us -- has attributes with names like Query, Catalog, SortBy, and so on.  But you needn't look that stuff up unless you want to extend this example; I've already done most of the work.  But you do have to fill those attributes with values, and that's what the "Q.query=," "Q.catalog=" and nearby lines do -- they just transfer the values that we set up top into a place where Indexing Service can find it.  A couple of the lines need a bit more explaining.  First, notice the "Q.Columns=" line; that tells Indexing Services exactly which data to retrieve.

You can see the entire list of columns in a catalog in the Indexing Service snap-in in Manage Computer.  Under the icon for the catalog itself there is a folder named Properties.  Look in there and you'll the entire list of a catalog's properties or, as the query calls it, "columns."  (Most of them are of no value -- the list above is about all you'd probably want.)

Controlling A Query:  Where To Look

Second, note the comment that startsline "util.AddScope..."; that tells Indexing Service two things about the search: first, which directory in the catalog should it search, and, second, should it search at that directory level, or search that directory and the directories inside of it?  Recall that Indexing Service automatically catalogs as far down as the directory structure goes; this command doesn't affect that.  Instead, it reflects that fact that Indexing Service doesn't automatically show all of its cards when you make a query -- it only reveals what the query asks for.

Suppose I've got that directory structure that I mentioned before, \Inetpub\wwwroot\Newsletters\goodfiles\hints.txt.  Suppose also that I chose this time to index the whole wwwroot directory.  What would that mean for the scope of the search?  Without an AddScopeToQuery command, Indexing Service will only show results that it found in the top-level directory of the catalog, \Inetpub\wwwroot.  To search the whole directory and the directories inside it, including \Inetpub\wwwroot\Newsletters, \Inetpub\wwwroot\Newsletters\goodfiles and whatever else is in there, I'd use this command:

util.AddScopeToQuery Q, "/", "deep"

That says that the query defined by the object "Q" should start at the top -- "/" -- and should search all directories.  The "deep" keyword is the part that says to search the directories inside the directories.

But what if I only wanted to search \Inetpub\wwwroot\Newsletters?  Then I'd use a scope of "/Newsletters" -- note that this uses the forward rather than backslash.  The command would look like this:

util.AddScopeToQuery Q, "/Newsletters", "shallow"

Finally, what if I wanted to restrict the search to keep it out of the \Inetpub\wwwroot directory, and start searching at \Inetpub\wwwroot\Newsletters, but also to search directories below Newsletters?  Then I'd do this:

util.AddScopeToQuery Q, "/Newsletters", "deep"

It's a really good idea to restrict your query scopes -- you'll be surprised what Indexing Service turns up!  For example, if you did index your entire Web site, then you'd probably be exposing things like code in progress, old code or notes to yourself, much of which you might not want publicly available.

To finish examining find.asp, the "set RS=" line tells IIS where to put the output of the query, into an object called a "record set" that I've unimaginatively called "RS."  And finally, the rest of the program just loops through the returned values and creates a table that reports what it found.  The three commands that say "set something=nothing" recover memory on the IIS server.

Troubleshooting Failed Queries

When you first get started building your search pages and catalogs, you'll probably turn up a lot of failed queries.  They can be frustrating; here's what to check.

By now, you should not only have a working catalog but a nifty Web-based front end for it.  Indexing Services is pretty cool once you get it set up, but, as always with complex tools, it's the initial setup that's the pain.


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

Find out more at

Windows Decisions 2002 in Chicago November 5-7

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

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 sixteen 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  (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 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 link to

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