To subscribe, visit http://www.minasi.com/nwsreg.htm. To unsubscribe, link to http://www.minasi.com/unsubs.htm. To change e-mail address, switch between HTML or text format, etc., link to http://www.minasi.com/edit-newsletter-record.htm. Visit the Archives at http://www.minasi.com/archive.htm. Please do NOT reply to this mail; for comments, please link to www.minasi.com/gethelp. Document copyright 2002 Mark Minasi.
Hello all --
The second edition of the Linux book is (whew) done and will appear on the shelves in late November. More on it as November approaches, but basically I focused entirely on RedHat Linux 7.3, updating the book to reflect the many changes in Linux since early 2000, zeroing in on RedHat-specific syntax and adding coverage of a few new things, including Winbind, wireless NICs, and CD-less installations. This month, I finished the course material for the two-day XP Support class coming to Atlanta this September 12/13. (If you can't afford the seminar but are interested in the material then we're selling the course books stand-alone for $69.95, details below.) The on-line Forum is under way and doing well, and I'm busy with .NET Server RC1. Oh, and this month I got an AWARD! An actual AWARD! Which brings me to...
I got a surprising e-mail from my associate publisher, Neil Edde, about a week ago congratulating me on my award. I had no idea what he was talking about, so he directed me to CertCities.Com. I know CertCities.Com, as they're a big site run by 101 Communications, the folks who also put out Certified Professional Magazine (which includes terrific articles from the likes of Jeremy Moskowitz, Roberta Bragg and Bill Boswell, among others) and run TechMentor, a semi-annual NT-oriented conference. (There's one in San Diego next week.)
Anyway, the CertCities guys decided to create a "Reader's Choice" award and included a category, "Favorite Technical Author." And I got it -- which prompted Neil's e-mail. Of course, it was a poll of hundreds of readers, and I don't know if any of you folks voted, but to whomever voted -- thank you. This is amazingly cool, and I appreciate the very kind compliment.
If your company is making the move from Wintendo (Win 9x), NT 4.0 or Windows 2000 Pro to XP Professional, then we've got the seminar for you! "XP Professional for Support Professionals" shows your desktop support techies how to deploy, network, manage, support and troubleshoot XP Professional, in just two days. This seminar is packed with demonstrations and a course guide filled with step by step procedures. As always, I try my best to make explaining entertaining so come join us if you can either in September in Atlanta, or November in either New Orleans or Denver. Visit www.minasi.com/pubsems.htm for schedule specifics or www.minasi.com/xpsupport.htm for the course outline.
For those of you who can't make it to the XP seminars but would like to learn some of the material covered in the class, I'm afraid I do not have an audio seminar for XP yet, although I'm considering it. But I am selling copies of the course book, 279 text- and screenshot-filled PowerPoint slides printed and GBC bound. For more information, please visit www.minasi.com/buyxpbook.htm.
Our two-day Windows 2000 seminars have been a lot of fun and the attendees have been great. Built atop the Fourth Edition, we add coverage of things even more up-to-date than that edition. Visit www.minasi.com/pubsems.htm to see specific session dates and locations, seminar outline, and how to sign up. We're coming to New York/New Jersey (Mahwah) and DC in September, and Tampa in November. Those will be our only Server seminars for the rest of the year, and I hope you'll join me for a seminar that will fill your brain with knowledge and share a few laughs in the process.
NOTE that every attendee to the seminar receives a copy of the new Fourth Edition of Mastering Windows 2000 Server!
Want to attend the Server class but haven't the time or money? $225 gets you the audio version of the seminar complete with over 10 hours of lecture accompanied by illustrative PowerPoints, all nicely cross-indexed for future reference. Pick up a copy today at www.minasi.com/audiosales. Only 70 left and then they are gone forever.
Do computer bugs bug you? Find out why they're so prevalent and what you can do about them by grabbing a copy of my 1999 McGraw-Hill book The Software Conspiracy: Why Software Vendors Produce Faulty Products, How They Can Harm You, And What You Can Do About It. It's just five bucks in e-book (PDF) format. If you've read my other books then you know my technical writing -- but this book is aimed at both techies and non-techies. The much-respected Kirkus Reviews said of that it was "A lucidly written, eminently practical guide to fighting back against the modern scourge of software 'bugs' ... An absorbing, easily understandable, and inspiring book..." Get your copy at www.softwareconspiracy.com.
As I said last month, we're working on making the Web site more reliable. Verizon clearly can't keep our frame relay up more than about 90 percent of the time, so I got a few static addresses from Cox Cable. I don't expect Cox to be any more reliable, just that at any given moment in time the chances will be good that at least one of them will be up. So I've taken the www.minasi.com Web server and given it two IP addresses -- one on the Verizon line and one on the Cox line. Do an nslookup on www.minasi.com and you'll see that. I intend to do the same thing for my DNS server just as soon as VeriSign permits me to -- they recently decided to put passwords on people's domains and sent mine to an address I haven't lived at in five years and now I'm struggling to get them to change it. Once I'm sure that all works, I'll double-address the e-mail server as well.
Please let me know how the reliability is; if you can't get on then I'd appreciate knowing when you tried. I hope to deliver excellent availability, and I thank you for your patience.
The Tech Forum at www.minasi.com/forum has been up for about a month and it's really cooking; we're up to 300 members and growing.
As I said in the last newsletter, while I wish I had the answer to everyone's questions, I don't. There are a lot of NT-related things that I've never done anything with (IAS and ISA come to mind) and so I can't help. I've found that more and more area-specific on-line forums have popped up and there's some pretty good stuff there, which is why I started mine. So far, people have posted 504 discussion topics and 2500 comments on those topics, and the forum crowd has successfully tackled a number of tough topics.
So if you've got a question then you might consider first stopping by the forum and searching to see if someone else has already covered the topic. You can, of course, search and read the forum without registering. Whether to pose a question or offer help, stop by and say hi -- or just chat in the "general" forums. See you there!
This month, I came across two books that I can't resist telling you about.
Some of my favorite writers are hard to find; they're not current giants like King or Grisham, nor are they traditional classics like Twain or Shakespeare. Many of them wrote what was considered pulp fiction at the time -- mysteries, suspense, or science fiction -- and at least until they've been dead long enough for their copyrights to run out, it's not likely that anyone will reprint them, particularly when there are good contemporary authors producing plenty of good new books. That's a shame, as the 40's, 50's and early 60's saw some wonderful storytelling from folks like William Tenn, C.M. Kornbluth, Fredric Brown, Richard Matheson and Clifford Simak. (There was, to be sure, some terrible stuff back then too, but that can all be thankfully forgotten.)
Anyway, I was pleased to see that some of Fredric Brown's mystery and suspense titles have been revived at http://www.stewartmasters.com/home.html. Their first title, Hunter and Hunted Part One, collects four of Brown's "Ed and Am Hunter" novels in one book. (I've ordered it but haven't gotten my copy yet.) I honestly haven't read of that series, but if it's half as good as Brown's other stuff then I'm sure it'll be good for at least a transatlantic flight's worth of reading.
The other neat title that I happened across was High Score! The Illustrated History of Electronic Games, a new title from McGraw-Hill/Osborne. It's sort of a softcover coffee table book about video and computer games. I guarantee you that anything you've ever played on a computer or in an arcade has a paragraph or two in this colorful browse-fest. It still throws me that this business that I've been with since its inception is old enough to be able to populate a retrospective, but I guess it's so. Some of the best part of the book was reading about the games that I thought were terrible at the time; ever wonder "what WERE they thinking?" when you use some badly-written program? I found a few answers there.
As of late August 2002 it's official: the MS folks have settled on an official name for the next version of NT Server. .NET Server will be available in four flavors called
Thus far, I haven't figured out a good short name -- W2003S? Time will tell.
This month, let's tackle some more DNS problems, pass along a tip on re-formatting CF cards, tell you how your switches may be keeping you from logging on, and share an observation about multihomed, multiprotocol systems.
I periodically hear from people who, in the process of troubleshooting some problem, decide to look in their event logs or other application logs find scary-looking references to a machine named "prisoner.iana.org;" for example, a few Google references include
"...My SurfControl server tells me that my printserver keeps trying to contact prisoner.iana.org..."
"...My printserver (Win2K, SP1) has recently begun connecting to prisoner.iana.org..."
"Why is my Win2K DNS server constantly attempting to [communicate] with prisoner.iana.org (18.104.22.168) on tcp port 53? "
By default, Windows 2000, XP and .NET Server 2003 systems try to register their dynamic DNS information. Now, I know that you know that, (if you read Chapter 7 of my book, anyway) but let's look more closely and be sure that we really do know what's going on.
First, recall that there are both forward lookup zones and reverse lookup zones. On a forward lookup zone, you'd look up a host name and get an IP address in return. For example, when you punch "www.minasi.com" into your browser and the browser looks www.minasi.com up to get an IP address of 22.214.171.124 or 126.96.36.199, that was a forward lookup, a lookup in the forward lookup zone for minasi.com. Technically the DNS world would call that an "A record lookup," as the record that says "if you're looking for the machine named X, then its IP address is Y."
There are also reverse lookups; you could, for example, fire up nslookup and type "set type=ptr," press Enter and then type "188.8.131.52" and you'll get back "www.minasi.com." You must first type "set type=ptr" because the reverse records, the ones that say "the machine with IP address Y is known by the DNS name X," are called "PTR records." But in order for you to do that reverse lookup, IP-to-name rather than the more common name-to-IP, someone must have created a zone for the range of IP addresses. You may recall that it's an odd-looking zone, with the IP addresses backwards and .in-addr.arpa appended to it; for example, as I run a C network 184.108.40.206, my reverse lookup zone looks like 253.246.206.in-addr.arpa, and to find 220.127.116.11 you'd look for the "111" PTR record in that zone.
Because 2K and later systems try to register both their forward and reverse lookup, rebooting my Web server would cause it to try to register both its host name in the www.minasi.com forward lookup zone and its IP address in the 253.246.206.in-addr.arpa reverse lookup zone.
Now, in that example I referred to my Web server, which has a routable IP address. But the vast majority of PCs on the Internet don't have routable addresses; instead, they use an IP address in one of the three private IP address ranges set aside by RFC 1918:
The idea is that anyone can create a private intranet using these IP addresses and then they won't step on anyone else's addresses. But what happens if you give a Windows 2000 or later system an IP address in this range? It will first register its host name in the proper forward lookup zone. It does that by finding out which DNS server is the primary DNS server for the zone whose name matches the computer's DNS suffix. In English, that means that if you've given your computer with an IP address of 192.168.0.33 the name myserver.bigfirm.biz then your computer will ask its local DNS server, "who's the primary DNS server for bigfirm.biz?," and your local DNS server will venture out to the Internet to find the primary DNS server for bigfirm.biz, and, once it finds that answer, it returns it to your computer. Your computer then contacts that primary DNS server for bigfirm.biz directly and tries to register its name and IP with bigfirm.biz's DNS server -- "say, bigfirm.biz's primary DNS server, would you please create an A record for me, indicating that whenever someone wants to find 'myserver' in bigfirm.biz that I'm right here at 192.168.0.33?" And, if bigfirm.biz's DNS server allows it -- it might not because the server might not be configured to accept dynamic updates, or it might be AD-integrated and myserver might not be a member of the domain -- then the record goes into the zone.
Now, in that particular bigfirm.biz example, the primary DNS server for bigfirm.biz is my DNS server, as I registered the name, and so it'd reject the update, as I've got the bigfirm.biz zone set up for static updates only. But remember the beauty of split-brain DNS; you could have decided to create your own bigfirm.biz zone on your local DNS server, in which case your system would never run across my DNS server, and, provided you enabled dynamic lookups, your system would have successfully registered.
Once it's registered (or tried to register) its name in a forward lookup zone, your system would seek out the reverse lookup zone, whose name it derives from its own IP address and subnet mask, and so decides that it needs to find the primary DNS server for the 168.192.in-addr.arpa reverse lookup zone so that it can register its PTR record with that server. So, as before, your local DNS server searches the Internet's DNS servers to find the ONE server on ALL of the Internet who's the big dog for PTR records in the range of 192.168.x.x.
And perhaps now you can see the problem.
There are tons of private networks out there using the 192.168.x.x address range, and they're all non-routable. Referring back to my earlier example, There's only one machine with the routable address 18.104.22.168, but there are probably thousands of systems out there with the private IP address 192.168.0.33. Me knowing that you have an internal system named myserver.bigfirm.biz at address 192.168.0.33 would be of no value whatsoever, as I couldn't contact that machine anyway, so there wouldn't be a point in you registering that information on a publicly-visible DNS server. Worse yet, if every machine with IP address 192.168.0.33 all tried to register their information then you'd have a real mess.
No, in reality the chances are good that you either don't give a hoot whether or not myserver.bigfirm.biz registers its PTR records, or the only systems that care about myserver.bigfirm.biz's PTR record are the other systems inside your intranet. The right thing to do, then, is to set up your own 168.192.in-addr.arpa zone -- configured to accept dynamic updates! -- on your internal DNS server. Then your systems will think that server is the official primary DNS server for 192.168.x.x reverse lookups, and register their PTR information without a problem, and without any mysterious event log references to prisoner.iana.org.
By the way, in case you're wondering, I don't know how to tell a 2K system to register its A (forward) record and not its PTR (reverse) record, or if it's possible at all to do that.
But this doesn't answer my initial question: what IS this prisoner.iana.org? Well, once RFC 1918 (and its predecessors, actually) came out, the IANA -- the old name, recall, for the folks in charge of handing out IP address blocks -- realized that they needed a "placeholder" in-addr.arpa zone for the three ranges of non-routable addresses. So they put zones named 10.in-addr.arpa, 16.172.in-addr.arpa, and 168.192.in-addr.arpa on a three DNS servers named blackhole-1.iana.org, blackhole-2.iana.org and prisoner.iana.org, at IP addresses 22.214.171.124, 126.96.36.199, and 188.8.131.52, and prisoner is set as the primary DNS server for the zones.
Thus, if one of your systems with a 192.168.x.x address tries to register its PTR record then it will, unless you have a local DNS server with a 168.192.in-addr.arpa zone, end up trying to register with prisoner.iana.org -- which will reject the request. The bottom line is, don't worry about it in most cases. In one case, however, you MIGHT worry about it, if you were running an intranet with a dialup connection to the Internet. If your intranet systems have private addresses and you don't have a local reverse lookup zone for your private addresses then you will cause your systems to try to contact prisoner, which would trigger a dialup. And if you're connected via ISDN in some country not blessed with as low a set of telecomm rates as we enjoy in the US, then that could be a quite expensive proposition. Again, the answer in that case would either be to tell your system not to do dynamic updates at all, or to create a local DNS server with a dynamic 168.192.in-addr.arpa zone.
DNS continues to be one of the most bedeviling parts of working with Active Directory, particularly for the guy at home trying to set up a test system to play with. Let's look at two problems related to DNS questions that I've been hearing a lot in the past few months.
Recall from the book (Fourth Edition), my articles in Windows and .NET Magazine (www.winnetmag.com, the old articles can be read online for free), and Newsletter 23 that many Active Directory setups work best when run with an internal DNS server that "shadows" a domain's external DNS server. So, for example, bigfirm.biz might have a publicly-visible DNS server with a few records in it, but if bigfirm.biz has an Active Directory also named bigfirm.biz then it's probably best from a security and flexibility point of view if Bigfirm runs a DNS server inside its intranet, and that DNS server hosts the dynamic zone for bigfirm.biz. I outline the steps for setting that up in the book, the magazine articles and Newsletter 23.
Along the way, a lot of people get lost for two reasons: first, they think that they have to set up a forwarder for their internal split-brain DNS server in order for that internal DNS server to resolve EXTERNAL addresses. That's not necessary, as we'll see. Second, in the process of setting up their DNS server they end up running the Configure A DNS Server Wizard (a bad idea) and in the process the wizard mistakenly makes your DNS server into a so-called "root" server, with the result that your DNS server can no longer resolve names out on the external Internet.
These two problems are connected: people run the wizard, and it often thinks that your system is not connected to the Internet, and so it makes the system a private root. Private roots never search the Internet to resolve names, and so any attempt to resolve an Internet name fails. The poor guy who's just trying to get DNS working well enough to build an AD says aha, I'll add a forwarder, that must be the answer. Unfortunately, when your DNS server thinks that it is a root server, it grays out the tab where you can specify forwarders. So our hapless AD explorer is now thinking "OK, I ran the stupid wizard that the server wanted me to run, and now I can't resolve names on the Internet, and I can't add forwarders to my DNS. AUUUUUUGHHHH!" So let's look into this in a bit more detail...
When you first start DNS, you get a big panel in the right of the MMC pane that suggests that you run the "Configure A DNS Server" wizard. I don't use it, as it's not that useful. (You can access it any time by right-clicking your server's icon in the DNS snap-in and you'll see the option to run the wizard.) Its main job seems to be to figure out whether your system is connected to the Internet net or not and, if the wizard senses that you are not connected to the Internet then is configures your DNS server with a private root. (I suspect that the problem is that people run the wizard on a system that only dials up to the Internet, and they run the wizard when they're not dialed up. The wizard then deduces that there is no Internet, and so makes the DNS server a root.)
"Private root" means that when you ask this DNS server to resolve an address then it assumes that it, the DNS server, knows the answers to all DNS questions that matter. Normal DNS servers say "well, if I don't know the answer, I'll start searching the world-wide DNS hierarchy of servers," and starts from the 13 root-level DNS servers and works its way down. Private root DNS servers kind of do the same thing, except they believe that they ARE not only one of those root servers -- they think they're the ONLY root server, the only authority. (You may well even work with some people like this.)
Being a private root server changes a couple of other things as well. For one thing, root servers clearly have no need of a root hints file, because they already know what server is the root -- themselves. So right-clicking a server's icon in DNS and choosing "Properties," then clicking the "Root Hints" tab will show the tab grayed out. Root servers also have no need of forwarders, as they know everything anyway, and so you will also see that the check boxes in the "Forwarders" tab on that same property page are grayed out.
This looks grim, but it's not. To uproot a private root server, just follow a few steps.
If you examine the property page for the DNS server again, you will find that Root Hints and Forwarding are no longer grayed out.
With that out of the way, let's tackle another misconception -- forwarding and split brain.
By default, every kind of DNS server that I've ever worked on was able to resolve names on the public Internet, as soon as you turned it on. For example, take an NT 4.0, Windows 2000, or .NET Server and install the DNS Server service. Make it your preferred DNS server. Start trying to resolve names and you'll be able to resolve any public address that you like. No configuration necessary. (Of course, that assumes that the DNS server is connected to the public Internet when you query the DNS server.
I think some people assume that because their DNS server has a non-routable address that the server couldn't resolve names out on the public Internet, and that they therefore need to forward requests out to a DNS server with a routable address. But that's not true: if you've got a non-routable address and a NAT/PAT router then you can always initiate communications out to someone on the public Internet. The only difference that you'll see is that no one out on the public Internet can initiate communications to YOU -- so if that DNS server on your intranet were supposed to be an authoritative server for addresses that you want the public Internet to see, then that's not going to work unless you map port 53 on that server (the DNS query port) to some external address.
So, to summarize: let's say that you've got a network with one (or a few) routable IP addresses and mostly private addresses of the 10.x.x.x, 172.16.x.x, or 192.168.x.x varieties. You want to build an Active Directory with some domain name -- let's say bigfirm.biz -- but you don't want to or can't register that domain name. So you need a DNS server that will let you have your own private bigfirm.biz. To set it up, just
You're now 100 percent ready to build an AD on your private network, and still be able to resolve names on the public Internet.
I use an IBM Microdrive in my digital camera and like it a lot. But now and then I have to clean it off by transferring pictures to a CD-ROM or my hard disk and when I do, I logically just use Windows Explorer to format the Microdrive -- I've also done that with flash memory-based CF cards. But I used Explorer to format the Microdrive recently and when I returned the drive to the camera (it was a Minolta Dimage7), the camera complained that the "card" was unusable. I tried using the camera's on-board formatting routine to format the Microdrive to make the Minolta happy, but no dice.
I feared the worst, but then re-inserted the card into my CF reader and examined the format -- FAT32. I tried re-formatting at FAT16 and the camera loves the drive, once again. A search of several digital cameras' Web sites shows that pretty much every camera's built to handle FAT16 and FAT16 only. Some other cameras, however, have smarter on-board operating systems, and can re-format a FAT32 CF card to FAT16. Apparently the problem lay with the Minolta's on-board software.
We got an interesting question on the Forum this month and talking about it with some friends reminded me of a tip that I've meant to write up but never have -- an interaction of network switches and broadcasts. Network switches cost more than hubs because of course they increase network throughput. One way that they accomplish that is via something called a "spanning tree algorithm" and unfortunately it has the side-effect of getting in the way of some of the early transmissions that systems use when first logging onto the domain. The particular forum participant who brought up the question found that he was getting errors on logon that kept his workstation from downloading his profile, but once he was logged on he could access everything as usual. At our suggestion, he turned off spanning tree on his switch and the logon problem disappeared.
Here's another thing to put on your list of troubleshooting steps. Ask yourself: is this system multihomed? Is it "multiprotocol-ed?" Time and time again I've seen that many NT/2000 server functions get a bit confused when they must serve more than one NIC. Over the years, we've seen problems with WINS, master browsers, and domain controller functions when run on a multi-homed system. I avoid multi-homed systems as much as is possible for that reason.
Similarly, folks running systems running more than one protocol should closely watch the binding order of those protocols. This is less of an issue than it used to be, as 2000 only loads TCP/IP by default, but in the days when IPX and TCP/IP loaded together then many times a terribly slow system's performance could be spruced up with a bit of binding order... "always remind to re-bind!"
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:
A terrific show that I'd attend even if they didn't pay me to be there. It's got great sessions and is in San Diego this September. Info at www.techmentorevents.com. For the past two conferences that have offered you the opportunity to take any Microsoft cert test for half price, so on the off-chance that you didn't see any sessions that you wanted to sit in on (an unlikely event!), then you could take a test. They even ran tests until about 9 at night.
I'm doing "Securing Your Network -- A Dozen Tips," "Troubleshooting Group Policies," and "Tuning Windows 2000/XP/.NET Computers" as well as a general session. If you can make it then I surely hope to see you there!
I'm teaching in Atlanta September 12/13 and Atlanta Comdex/Interop is smack dab up against that so I agreed to come down and do my brand-new "Dot-Net: Not Yet?" talk, a very comprehensive overview of .NET Server. If you're going to Atlanta Comdex and bought a "attend the talks" pass then please consider joining me at 3:45 PM in Building B, Level 3, Room B313a/b at the Georgia World Congress Center.
Bill Wally of Darton College and the Albany Chamber of Commerce are hosting a one-day seminar that I'm doing where I'll cover a potpourri of topics -- an Active Directory overview, an introduction to Group Policies and a talk on NT/2000 security. I'm not sure what they're charging but if you're interested, contact Bill at email@example.com.
They said it was dead but they were wrong. George Spalding's Frontlines, the premier conference for technical support folks, is back (yay!) in Orlando (boo!) this October. In case you've never been to a Frontlines, it's a conference for help desk and support people -- on the "front lines" -- and offers two very full days of sessions aiming to build and refresh both the "soft" and "hard" skills that you need in order to get your job done. In the process, you of course meet others in our industry so at worst you have someone with whom to bitch about tech support life and at best you may find someone who's already solved a problem that you're struggling with right now. George and I will do our ever-popular Networking 101, where we explain every single networking concept known to Man in just three hours; I will do my talk about the best and worst of XP and .NET Server, and George and I will run Tech Support Jeopardy, where geeks vie for fabulous prizes and merchandise. Info at www.front-lines.com.
What was once the "WinConnections" conference is now "Windows and .NET Magazine Live!" and this fall it goes to Orlando. In addition to the great content (which keeps getting better, thanks to conference chairs Don Jones and Jeremy Moskowitz), the magazine has now brought together all of the Connections conferences -- not only is there stuff for administrators, but developers as well. If you sign up for the entire week then you end up getting access to conferences focusing on 2000/.NET/XP administration, Exchange, SQL Server, XML, Web Services. ASP.NET, and Visual Studio.NET. It's a kind of "superconference" that ends up being quite a good value for your conference dollar. The speakers are an all-star line-up, including my co-author Christa Anderson as well as a long list of top-of-the-line experts. I'm keynoting as well as doing several sessions, including a new one on tuning systems. www.winconnections.com for more info.
George Spalding and I team up yet again for Fall Comdex's "Extreme Knowledge" (doesn't that sound painful, "extreme" knowledge?) seminar sessions on Microsoft Windows technologies. If you're going to Vegas this November then consider dropping by to hear me, Christa Anderson, Todd Lammle, Doug Toombs, Jeremy Moskowitz and others deliver the goods on running Windows without pane! The general Comdex site is www.comdex.com but they seem not to have anything specific on the site yet.
I'm keeping busy doing Windows 2000/.NET Server seminars and writing, but I've still got time to visit your firm. In just two days, I'll make your current NT techies into 2000/.NET techies. To join the large educational, pharmaceutical, agricultural, aerospace, banking, government, transportation, and other organizations that I've assisted, either take a peek at the course outline at www.minasi.com/w2koutln.htm, mail our assistant at Assistant@Minasi.com, or call her at (757) 426-1431 (only between 9-5 Eastern time, weekdays, please).
Have a quiet and safe month. I'll be traveling to conferences and classes and working on the .NET Server book (thank God for VMWare). I don't often get a chance to say it, but many thanks to the many of you who've bought a book, audio seminar, attended a conference or a live seminar.
Please share this newsletter; I'd like very much to expand this newsletter into a useful source of NT/2000/.NET Server/XP information. Please forward it to any associates who might find it helpful, and accept my thanks. We are now at over 21,000 subscribers and I hope to use this to get information to every single Mastering XP, NT and 2000 Server reader. Thanks for letting me visit with you, and take care -- I'm still predicting that the economy will roar back by the end of September, so polish up those resumes! Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews. As always, I'm at http://www.minasi.com/gethelp.
To subscribe, visit http://www.minasi.com/nwsreg.asp. To change e-mail, format, etc., link to http://www.minasi.com/edit-newsletter-record.htm. To unsubscribe, link to http://www.minasi.com/unsubs.asp. Visit the Archives at http://www.minasi.com/archive.htm. Please do NOT reply to this mail; for comments, please link to http://www.minasi.com/gethelp.
All contents copyright 2002 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.