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.
Hello all --
A quieter month (thankfully) as I got some serious work done on the Fourth Edition and was pleasantly surprised to find that the Mastering Windows XP Professional book was Amazon's best-selling computer book world-wide, at least for a week or so!
The big news this month is that I'm preparing low-cost audiocassettes and CDs of my Server class. The Web site is SSL-ed and I'd really like to hear if it poses problems for anyone, and I've got a bunch of XP info as well as a discussion of FTP permissions and DNS replication internals. And hey, speaking of internals, let me take a chance to plug once more my buddies Dave Solomon and Mark Russinovich's Windows 2000 Internals class in Austin this coming December 11-13, it is truly a rare event (and no, I don't make any money from this endorsement).
I write this as I'm about to amble off to Comdex. It's supposed to be a smaller show than usual -- no surprise -- but if any of you are there, stop by one of my talks and say "hi."
The bad guys made us postpone the NYC and Pasadena classes, but New York is rescheduled for December 3/4 at the LaGuardia Crowne Plaza. (We're putting together days for a week in Pasadena and either Portland or Seattle sometime in mid-March 2002.) If you've been interested in attending my Windows 2000 Server seminar, then there's still time to sign up. We've also announced the first two seminars for 2002: we're back to Philadelphia on January 14/15 and making our first foray into Columbus, Ohio on the 16/17th. I am told that Columbus is the town with the best proximity to the most towns on the Eastern Seaboard, so we'll see if that makes it a good seminar town! They've certainly always welcomed me electronically, as their CBS affiliate AM station, WTVN, has me on regularly to chat about techie stuff. I'm finding that I need more time to write so I will not be doing as many seminars in 2002 as I did in 2001 -- sorry! -- and thus won't be able to visit as many cities as I did in the past 12 months. I hope, then, that if you'd like to attend one of my seminars, that you'll please consider joining me in NYC, Philly, or Columbus. More cities on the way, but we're still figuring out which ones -- if you'd be interested in attending a seminar in your city, please consider voting at http://www.minasi.com/pickcity.htm.
Our two-day Windows 2000 seminars have been a lot of fun and the attendees have been great. Built atop the Third Edition, we add coverage of things even more up-to-date than the Third; I've already added coverage of Windows .NET Server enhancements, a big section on troubleshooting group policies and some major enhancements to the Active Directory replication info, stuff too new to have made it into the Third -- and there's more coming. Visit www.minasi.com/pubsems.htm to see specific session dates and locations, seminar outline, and how to sign up.
Every month, we get a few dozen people asking if we offer our two-day Managing, Installing, and Troubleshooting Windows 2000 Server class on audio or video. I can't afford to put together an acceptable-quality video, but I will be recording the New York City class and offering it for sale both in audio cassette form and audio CD form. For $199 ($225 for CDs, they cost more to duplicate), you'll get about 12-14 hours of lecture as well as a bound printed copy of the class's accompanying PowerPoint slides. If you'd like to be notified when they'll be available -- I anticipate around the first of the year -- then please sign up at www.minasi.com/audiosales; it does not oblige you to buy.
As I reported last month, my latest book, Mastering Windows XP Professional, hit the stands in mid-October. But I was pleasantly stunned by the response! At one point, the book was Amazon's 22nd best-selling book. Momi Ford, a friend from Indiana, tells me that Bookpool ran out almost immediately, but I'm not surprised -- they sold it for such a great price -- 22 bucks! Many thanks to those of you who picked it up, and thanks for the kind comments. (And to those who've read it and liked it, may I ask that you PLEASE! consider posting a few words on Amazon, whether you bought it there or not? Many thanks, particularly to the three folks who so quickly posted the very kind reviews.) If you don't have the book and are interested in it, you can find it at http://www.amazon.com/exec/obidos/ASIN/0782129811/markminasi.
As I don't sell things directly off the site (yet), SSL hasn't been that important. But there are forms on my site that let you choose a password. And even though the passwords don't do anything scarier than give you access to back issues, some folks use the same password for everything, so I was a little concerned that those forms should use encrypted transmissions.
This month, I finally got around to getting an SSL certificate (from Thawte, the price was right) for the www.minasi.com system. When next you log on to perhaps change your password or review old newsletters, then you'll notice that the transaction is encrypted. Now, I'm not doing anything fancy here -- it's just straight SSL, port 443 -- but if that presents a problem, then please drop me a line, and thanks.
Now that XP is finally out and "shrink wrapped," I'm getting more questions, as well as sharp-eyed readers pointing out (ouch) errors.
A reader asks how to use XP Pro as a file server in a home or a small business wherein the clients all run Windows 9x or WinME. He was quite perplexed about the whole thing because he was used to the old Windows 9x/ME notion that shares could have two passwords, the "read only" and "read/write" passwords. It's an excellent question because it reminds us of some of the very significant under-the-hood differences between Windows (9x) and NT (Windows XP). The notion of two passwords that everyone uses doesn't exist in NT.
He didn't see how to set the read-only and read/write passwords for XP in the book, not surprisingly, as of course NT doesn't do security that way. And I'm not a big fan of the idea of using XP Pro or any version of Workstation as a file server, but here's my answer to his question.
We're talking about a system wherein the shared files sit on the XP box, NOT the WinME box. WinME doesn't offer much in the way of flexibility with permissions. So if you're used to Windows 9x's lame two-level passwords from Windows For Workgroups, Win 9x, or WinME, then get ready for a more powerful set of permissions because XP isn't REALLY Windows... it's NT!
Let's say that you have three people in your household -- Mom, Dad, and Junior. You have a file named DADSSTUFF.DOC that you want Dad to be able to read and write, Mom to be able to view, and Junior to not be able to access at all.
Step 1: Tell XP about Dad, Mom, and Junior. Create local user accounts by that name.
Step 2: Tell the WinMe workstations about Dad, Mom, and Junior. Create local user accounts on the WinME boxes by those names. Junior should only log on as Junior, Mom as Mom and Dad as Dad.
Step 3: Set security on DADSSTUFF.DOC. Because of its security-oriented nature, XP gives you two levels of security: share security and NTFS security, that is file-level security. Modify NTFS security by right-clicking the file, choosing Properties and clicking the Security tab. Just Add Junior and deny him all access, add Mom and give her Read access, and add Dad and give him full control. Share the folder that contains DADSSTUFF.DOC That'll do it!
But I warned the reader that in my opinion that this wasn't an optimal answer mainly because it's a lot of work to maintain. As Mom (for example) has an account on each WinME box as well as the Win XP box, then when she wants to change her password, she needs to do it separately on each box -- yuck. A method that CENTRALIZED the user accounts would be far better, and (no surprise) there is such a method -- an Active Directory domain. For that, one needs a Windows 2000 Server, and I recommend that approach. But you can certainly make the XP-as-file-server approach work also with, again, a bit of work. Nevertheless, it was an interesting question -- I'd completely forgotten about how Windows 9x handles share access control, and never considered that someone would want to duplicate it in XP!
Reader Paul Smith wrote to ask this: he replaced an NT 4.0 workstation with an XP Professional workstation. As the machine sits on a segment without any servers, he was used to setting the NT 4.0 Workstation machine up as the Master Browser on that segment. But he found that the XP Professional system refused to assume the Master Browser role, and wondered what could be the cause. It was a fascinating question, so I hazarded a guess and (whew) was right. (You know what they say, even a blind pig finds an acorn occasionally.<g>)
The answer was XP Professional's built-in "firewall," the Internet Connection Firewall (ICF). It's a very, very simple "firewall" in that once enabled, all it does is to block all incoming TCP and UDP ports. That's not such a bad thing on a system that only acts as a client -- receives e-mail, surfs the Web, or attaches to NT-based file and print shares -- but in this case the system was also being used as a kind of low-intensity server by nudging it to be the Master Browser on its segment. As ICF tells the system to ignore all incoming data except for responses to questions initiated at the system, the XP Pro box never had any interest in becoming the Master Browser.
My next thought was to try to figure out how to disable ICF from the command line. I'd hoped that NETSH would have a command for it, but I couldn't find one. There is, however, a service that drives both ICF and the Internet Connection Sharing (ICS), the simple NAT router that's been around since Windows 98 SE. So one way to shut off ICF from the command line is this improbable-looking-but-effective command:
net stop "Internet Connection Firewall (ICF) / Internet Connection Sharing (ICS)"
That's clearly not the best way, however, as the Advanced Properties still show ICF as being enabled, even though it isn't.
I was looking through the Mastering Windows XP Pro book on Remote Desktop and I realized that we missed out on a way to use Remote Desktop on XP... you can access an XP desktop via Internet Explorer, just as you can Terminal Services on Windows 2000 Server.
Remote Desktop is a very nice remote control system sort of like PCAnywhere, built into XP Pro. (Not XP Home, unfortunately.) You turn it on by right clicking My Computer, choosing Properties and then the "Remote" tab. That lets you enable two different remote support tools -- "Remote Assistance," which piggybacks on Instant Messenger, and "Remote Desktop." Check the box under "Remote Desktop" labeled "Allow users to connect remotely to this computer," and, if you like, pick the users authorized to use a Remote Desktop by clicking the "Select Remote Users..." button. (You probably needn't, as anyone who's a local administrator is already authorized to use Remote Desktop.)
It looks like Terminal Services, but it's different in that only one desktop can be active at any moment. So, for example, if I were logged in locally at an XP box and someone tried to control it remotely via Remote Desktop, then I'd see a dialog box warning me that I was about to be disconnected.
Anyway, that's just the server side of it. The person doing the controlling from a remote location needs client software, and XP comes with it in the form of a little program called "Remote Desktop Connection," which we covered pretty well in the text. But what we forgot to mention was that you don't need that client program; Internet Explorer 4.0 or later will do fine.
As I've explained in previous newsletters and in Mastering Windows 2000 Server, 3rd Edition, you can control a Terminal Services session (or, now, a Remote Desktop session) in a Web browser. You must install the "Tsweb" function into an Internet Information Services version 5.0 or later Web server; you can do that either by installing the Terminal Server Advanced Client software that appeared with Windows 2000 Service Pack 1, or you can set up an XP Pro box as an IIS 5.1 Web server -- its "Details" button in Add/Remove Programs includes the ability to install Tsweb. Either way, once you've got an IIS server running Tsweb, you just open up IE and point to that server and add "/tsweb." For example, if you had Tsweb running on a machine called relay.acme.com, then you'd point IE to http://relay.acme.com/tsweb. The Web server will next offer your browser an ActiveX component, which you should allow it to install. You'll then get a screen that lets you punch in the name of the computer that you want to either start a Terminal Services session or a Remote Desktop session with. Thus, one IIS server can act as a kind of "relay point" to many desktops and/or servers. It's quite useful -- I use it all the time, so take a minute and check it out.
Leaving XP behind...
A reader wrote to ask how to set up an FTP site so that users could log in and upload files, but not be able to download or read them, or even to list them -- sort of like a night deposit box in a bank, where you can drop off a deposit but once you've done that, you can't get the deposit back, or see what others have deposited.
It's an interesting question because it lets me highlight how you can use different sets of permissions to accomplish the same thing.
By default, all FTP uploads and downloads happen from/to the Inetpub\ftproot directory. Yes, you can modify that, but let's just stay with the basics for this example. When you log into an FTP site and type "dir," that's what you end up seeing -- the files and folders in that directory. If you have permission to upload files, that's also where they go.
Letting a user download, view, or list the files in a directory are all "read"-type permissions. Uploading is a "write" type permission. So, in short, to create a drop box, deny your users "read" permission, and allow them "write" permission. But where to do it? As it turns out, you can accomplish this in one of two ways -- with FTP permissions or NTFS permissions. (This discussion assumes that Inetpub\ftproot is on an NTFS drive.)
The FTP server has a very crude set of permissions that you can use to control how people access Inetput\ftproot. You can view those permissions from the IIS snap-in -- right-click "Default FTP Site," then choose Properties, and in the resulting property page choose the "Home Directory" tab. You'll see three check boxes labeled Read, Write, and Log Visits. By default, Read and Log Visits are checked, Write is not.
Whenever someone tries to read or write a file on the Inetpub\ftproot directory USING FTP, then the FTP server consults these permissions. If the user is trying to read something, then the Read check box must be checked, or the action is disallowed. If the user is trying to write something, then the Write check box must be checked, or the action is disallowed. Once the FTP server has given approved the request, the FTP server software then either reads or writes the file. And THAT's where the second level of security pops in.
Any file read or write gets checked by NTFS. It's not enough for FTP to be willing to accept the read or write; NTFS has to agree. The FTP permissions are crude, just "Read" or "Write" -- checking "Read" lets anyone read files, "Write" lets anyone write files. But, as you know, NTFS lets us be a lot more selective. That's why you can adjust permissions to allow a drop box in either of two ways.
Method 1: let the FTP permissions do the job. In the FTP Properties tab "Home Directory," un-check Read and check Write. But make sure that NTFS won't get in the way -- make sure that the NTFS permissions on Inetpub\ftproot allow writes. You could set it as "Everyone/Full Control," although "Everyone/Write" works as well.
Method 2: let NTFS do the work. In the FTP Properties tab "Home Directory," make sure that the Write box is checked -- what you do with Read is irrelevant. Then adjust the NTFS permissions on Inetpub\ftproot by right-clicking the folder in Explorer and choosing Properties, then Security. It will probably be inheriting security settings from its parent, so un-check the box that says "Allow inheritable permissions from parent to propagate to this object." You'll get a dialog box offering you three choices -- Copy, Remove, or Cancel; choose Remove. Then click Add to bring up the list of users in your domain and choose the Authenticated Users group; click Add and OK to add them to the permissions list for Inetpub\ftproot. You'll now see Authenticated Users and they will have check boxes under "Allow" for "Read & Execute," "List Folder Contents," and "Read." Un-check those boxes. Check the box next to Read under Deny, and check the box next to Write under Allow. You'll now find that you can log onto the FTP server and upload files, but not see files or download files.
Whichever method you use, you're not done yet -- there's the matter of anonymous logins. Now that you've told FTP to accept uploads -- writes -- then you've got to consider anonymous logins. ANYONE can log onto your FTP server and upload files, which means that a malicious person could just keep uploading garbage until it filled up your hard drive. So it'd be nice to be able to be selective, letting anyone except the anonymous user upload files. You could accomplish this in two ways.
First, you could simply disallow any anonymous logins. From that Properties page for the FTP site, click the Security Accounts tab and un-check "Allow Anonymous Logins." Or you could turn, again, to NTFS permissions. People who log in anonymously aren't anonymous to NTFS-- it sees them as a user named ISR_servername. So, if your FTP server were named myftpserver, then you'd just modify the NTFS permissions on Inetpub\ftproot, adding a permission for IUSR_MYFTPSERVER, and then deny that user any write permissions.
And once you do this, remember to log on not as anonymous, but instead with your account name. If the account is a domain account, then log on as domainname\username -- FTP's not smart enough to check both the local SAM and the domain.
This may simply be geeky details, but I noticed the other day that I didn't really explain in Mastering Windows 2000 Server how primary DNS servers update their information to secondary DNS servers. Of course, if the DNS servers are running an Active Directory-integrated zone then you already know how they replicate - within 15 minutes inside a site and some other value across sites. But how do standard primary/secondary DNS setups replicate? Does the primary tap the secondary on the shoulder whenever there's news? Do the secondaries bug the primary to tell them about changes?
Recall that you make any changes to a zone to the primary DNS server for that zone; if you were to make a change to a zone at a secondary server for that zone, then the change would be lost. So how do those changes on the primary get synchronized to the secondaries?
When the primary learns something new, it does not contact the secondaries; rather, it's the job of the secondaries to ask the primary periodically if there are any changes. They do that every few minutes, and "few minutes" is defined by an item in the Start Of Authority record. SOA records contain two bits of information essential to a secondary DNS server -- the serial number and the refresh interval.
The refresh interval is a period of time specified in seconds; 900 seconds -- 15 minutes -- is Windows 2000's DNS default. That tells the secondary DNS server for a zone to ask the primary every 15 minutes, "may I see your SOA record?" The secondary asks about the primary's SOA record because it will then use the serial number on the primary to determine whether or not something has changed. What's the serial number? Well, every time you update a zone file on the primary, then the DNS server increments the serial number; if it was 44 before you added a new host, then the serial number goes to 45 after you add that host.
So for example, let's say that the secondary has updated its zone from the primary at 10 AM, learning among other things that the latest serial number for the zone is 237. At 10:01, you add a new host "A" record at the primary. The primary stores that new A record and increments the serial number to 238. The secondary, of course, knows nothing of this.
But 15 minutes after the last synchronization, the secondary asks the primary for the SOA record. When the primary responds, the secondary notices that the serial number is now larger than it was the last time that it asked, so something must have changed. The secondary requests an update on the zone records, and now it's in sync. 15 minutes later, it requests the SOA record again and, if the serial number hasn't changed, does not request an update. The secondary thus polls the primary every 15 minutes, whether things have changed or not. So basically DNS replication works by having the secondaries request changes from the primary periodically.
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 reliably good show, and one gaining in popularity, as it seems that every one that I attend is larger than the one before. It's got great sessions and is back in San Francisco. Info at www.techmentorevents.com. Last time, they had a very cool feature in that you could take any Microsoft cert test for half price, so on the off-chance that you didn't see any sessions that you wanted to sit in on (an unlikely event!), then you could take a test. They even ran tests until about 9 at night.
I will be doing a general session on Windows XP and .NET Server, as well as a breakout session on Troubleshooting Group Policies and a really geeky (but hopefully clear and entertaining) session on Active Directory replication. If you can make it then I surely hope to see you there!
The same folks that put on that Windows 2000/Exchange 2000 Connections conference in Scottsdale are coming to Palm Springs in early May of next year. I get to keynote this conference and to do a talk that I do a little less frequently than my others -- my Software Conspiracy talk. If you'd like to hear my views on why software is so buggy and what we can do about it then don't miss the keynote.
I'm also doing some breakouts; my "AD classic" talk (an overview of Active Directory with Whistler updates), an explanation of what Windows XP and 2002 will do for (or to) you, and then you can see the World Opening of my new 2000 security talk, "12 Things You Can Do To Secure Your Windows 2000 Network". I've also been asked to host a "Reader To Reader" session, where you can bring your most puzzling stumpers. These sessions worked out fantastically in Scottsdale, so don't miss this show.
Find out more at www.winconnections.com.
The searchwin2k.com folks (who run a great portal offering tons of Windows 2000 information as well as jumping-off points to other great resources) have put together an interesting conference in The Windy City early this November, but world events have prompted them to move it to May. (Better time for good weather in Chicago anyway.) John Enck, one of my former co-workers at Windows NT (now 2000) magazine, will be offering his unique perspectives, as will Laura DiDio -- Laura's been an NT industry watcher for as long as I can remember. They'll also have geek talks, including my look ahead at .NET Server (and what will be by then a look BEHIND to XP) as well as an AD/migration talk.
Interestingly enough, the conference is free. Free, that is, if you meet their criteria and no, I don't know what those criteria are -- but it only takes a minute or two to apply. Give it a shot and perhaps I'll see you at the Chicago Hilton!
Find out more at http://www.windowsdecisions2002.com/.
I'm keeping busy doing Windows 2000/.NET Server seminars and writing the Fourth Edition, but I've still got time to visit your firm. In just two days, I'll make your current NT techies into 2000/2002 techies. To join the large pharmaceutical, agricultural, aerospace, banking, government, transportation, and other organizations that I've assisted, either take a peek at the course outline at www.minasi.com/w2koutln.htm, mail Jennifer Williams at email@example.com, or call her at (757) 426-1431 (between 1 and 5 Eastern time, weekdays, please).
Have a quiet and safe month and if you're in the U.S., then don't eat too much turkey! Please share this newsletter; I'd like very much to expand this newsletter into a useful source of NT/2000/.NET Server/XP information. Please forward it to any associates who might find it helpful, and accept my thanks. We are now at over seventeen thousand subscribers and I hope to use this to get information to every single Mastering NT and 2000 Server reader. Thanks for letting me visit with you, and take care -- may we all weather this current industry slowdown and this not-by-the-usual-rules war! Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews. As always, I'm at http://www.minasi.com/gethelp.
To subscribe, visit http://www.minasi.com/nwsreg.asp. To change e-mail, format, etc., link to http://www.minasi.com/edit-newsletter-record.htm. To unsubscribe, link to http://www.minasi.com/unsubs.asp. Visit the Archives at http://www.minasi.com/archive.htm. Please do NOT reply to this mail; for comments, please link to http://www.minasi.com/gethelp.
All contents copyright 2001 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.