To subscribe, visit http://www.minasi.com/nwsreg.htm. To unsubscribe, link to http://www.minasi.com/unsubs.htm. Visit the Archives at http://www.minasi.com/archive.htm.
I know, I know, this newsletter's late; sorry, I've been busy with classes -- but I think this one will make up for the wait. We had some really great sessions in Austin, Denver, Chicago, Topeka, Tampa, Detroit, Minneapolis and northern New Jersey. Had to cancel Atlanta and Pittsburgh, but with hope we'll try those cities again if we get any interest on the city vote page at www.minasi.com/pickcity.htm. You might recall that I'd announced that I'd have to cancel Kansas City but in actual fact it ran after all -- a reader named Pat Oblander, of Shawnee County, kindly decided to put together a class in its place. So I was able to go to Topeka instead of Kansas City and teach a class to a great group, and Pat got a class at a reduced rate. Thanks, Pat!
This month brings the Third Edition of Mastering Windows 2000 Server at long last, a bunch of new seminars, and some tech tips.
Stu Sjouwerman of Sunbelt Software runs a nifty e-mail newsletter about Windows 2000 called W2KNews (www.w2knews.com) that goes out to ... umm ... about a half-billion people or so. (Or maybe it just seems that way; whatever the numbers, Stu's the envy of the rest of us e-mail newsletter folks.) So it was extremely kind of Stu to mention my Web site in a recent W2KNews issue. Apparently a fair number of the W2KNew-ers who stopped by decided to sign up for the newsletter, as our subscriber base went from about 7500 to about 11,000 in four days. (It also gave my ASP scripts a bit of a stress test, and they sometimes failed. Apologies to those who got errors when trying to sign up; I've rewritten much of the logic and most operations should be trouble-free. I haven't yet written a routine to let you update e-mail accounts, but I'm working on it.) I wanted to include this note first of all to thank Stu, welcome our new arrivals, and to pass along W2KNews's URL so that any of my subscribers who are looking for another source of good Windows 2000 and NT information might consider joining his mailing list.
If you've just joined, then don't miss out on the archives at www.minasi.com/archive.htm. The back issues may contain the answer to a question or two. (And no, I don't have a search engine built into it yet, it's on my list of things to do...)
Mastering Windows 2000 Server, 2nd edition shipped at just about the same time as Windows 2000. I based it on my (and others') early experiences with 2000. As I'd been using the NT 5.0 and then Windows 2000 betas for four years, I felt that it was pretty good and, thankfully, much of the computer book-buying public agreed, and the book has sold well and received many kind compliments.
But there's a level of in-the-guts knowledge that no one can achieve in the beta process. So while I thought I knew 2000, I soon found out that I had plenty more to learn. All of a sudden, companies that had been pretty much ignoring Windows 2000 -- it's surprising how many felt that Microsoft would never ship the thing at all -- starting hiring consultants and teachers to help their staff evaluate and plan for Windows 2000. As one of those consultants and teachers, I got a chance to re-evaluate the book: what I'd included, what I'd not included, and how I arranged the information. Feedback from the hundreds of thousands of people who've purchased the 2nd Ed as well as those who took my classes helped hammer out a new, better Third Edition. But if you own a Second Ed, why buy the Third? Here's a brief answer.
There's all that, and much more. Bookpool has it at http://www.bookpool.com/.x/d6ridbaqt0/sm/0782128726 at $35.50 and Amazon's got it at http://www.amazon.com/exec/obidos/ASIN/0782128726/markminasi for $48. (And no, sorry, Sybex doesn't have any plans to sell only the CD, from what they've told me.)
The good citizens of Montreal demanded that we bring the "Mastering Windows 2000 Server: a guide to planning, installing, and running Windows 2000 Server in your network" seminar to their town -- they've been number one in the city voting for a month or two now -- and so we'll be there this June 20/21 at the Four Points Sheraton near Dorval. Toronto was hot on Montreal's heels, so we're going there also a couple of days beforehand, at the Toronto Airport Marriott on June 18/19. We're also going to four U.S. cities:
You can sign up at www.minasi.com/seminar-register.htm. I hope to see you there!
May will be here sooner than you think, so if you've been thinking about signing up for our sessions in Long Beach (CA), San Jose, or St. Louis sessions, then now's the time! Register at www.minasi.com/seminar-register.htm. Bring three or more to the seminar and get a discount, but no matter how many you bring, everyone gets a copy of the Third Edition.
Want to see a seminar come to your city? Vote at www.minasi.com/pickcity.htm.
I've been getting a lot of questions recently along the lines of "how will Windows 2000 find my DNS server?" The question often runs something like this:
"I've got three machines on a network that I'm using to experiment with Active Directory. One is a server acting as the domain controller; the second is a server acting as DNS server for my domain bowsers.com. The last one is a workstation that I'm trying to join to bowsers.com, but it complains that it can't find a domain controller for bowsers.com. The three machines are all on a single Ethernet segment, so they SHOULD be able to find that DNS server and that DNS server ought to be able to point them to the domain controller -- but apparently they don't. How do I get my workstations and servers to find bowsers.com through my DNS server? Or is this impossible unless I register bowsers.com with Network Solutions?" (Which you can't do, as someone else owns bowsers.com. And for anyone reading this who's wondering why we'd want a domain named bowsers.com, it's the name of a domain that I use as an example in the DNS section of my book.) This discussion builds on skills and techniques explained in the AD and DNS chapters in the Mastering book, although of course the newer edition is a more complete springboard.
The question lets me zero in a bit on troubleshooting both domain logins and DNS/AD interaction, and these techniques will work even in a non-trivial environment. But let's work out a few examples with a simple network. So let's suppose you've set up three machines on a small test network, with IP addresses 10.1.1.1, 10.1.1.2, and 10.1.1.3. Let's make 10.1.1.1 the DNS server; call it DNS. Let's make 10.1.1.2 the domain controller for bowsers.com, and we'll call it DC. Finally, make 10.1.1.3 the workstation; call it WS. Suppose the workstation, WS, tries to log into bowsers.com. Make sure that each system has bowsers.com as its DNS suffix, either by going into the Network Identification tab (My Computer/Properties) or via DHCP. This discussion assumes that you've read the Active Directory and DNS sections of Mastering Windows 2000 Server.
First, set up DNS on the dns.bowsers.com system, the machine with IP address 10.1.1.1, in a manner similar to the bowsers.com example.
The DNS server should point to itself as a preferred DNS server. Either configure that "preferred DNS server" parameter with DHCP via global or scope settings, or via the TCP/IP configuration page. It's far better to configure DNS for a workstation via DHCP settings, but if you need to configure it via Advanced Properties then go over to the workstation, right-click My Network Places and choose Properties, then look for the object with a name like "Local Area Connection." Right-click that and again choose Properties. In the resulting property page, click "Internet Protocol (TCP/IP)" and then the Properties button. That will raise another property page; click the radio button labeled "Use the following DNS server addresses:" and fill in the IP address for your DNS server in the field labeled "Preferred DNS server:," then click OK and close the property pages.
Verify your preferred DNS server's IP address by typing "ipconfig /all" and amongst the output should be a line like
DNS Servers . . . . . . . . . . . : 10.1.1.1
If you don't see a line like that, then go back and re-check your TCP/IP configuration on the workstation, or the global or scope settings in DHCP.
Next, create the zones for your Active Directory, as the DNS chapter shows. Create a forward lookup zone for bowsers.com and a reverse lookup zone for 10.in-addr-arpa. Make sure to put a pointer record for dns.bowsers.com at 10.1.1.1. Also ensure that both zones allow dynamic updates, or you won't be able to create an Active Directory with this DNS server.
You're now ready to run another test, with NSLOOKUP. You should be able to open up a command line at the DNS server (or any other computer, for that matter) and type "nslookup." You should see something like this:
C:/>nslookup Default Server: dns.bowsers.com Address: 10.1.1.1 >
If that doesn't work, then you might see this sequence of responses:
C:/>nslookup DNS request timed out. timeout was 2 seconds. *** Can't find server name for 10.1.1.1: Timed out *** Default servers are not available Default Server: UnKnown Address: 10.1.1.1
If you see this error message, it's because nslookup needs to be able to reverse-resolve the IP address of the preferred DNS server, so you forgot to create the 10.in-addr.arpa zone. Now, the two tests that I've shown you so far, the IPCONFIG /ALL and the nslookup, are tests that you should run not only on the DNS server but on all other systems as well, at least on a test network. On a real-live network, you'd only run the tests on systems that were having trouble connecting to the domain.
But on a system other than the DNS server, you might see this error:
C:/>nslookup DNS request timed out. timeout was 2 seconds. Default Server: [10.1.1.1] Address: 10.1.1.1
That probably means that for some reason your workstation can't even CONNECT to 10.1.1.1. Exit from nslookup (type "exit") and try ping, tracert, and the usual other tools to troubleshoot basic IP connectivity. If you've gotten this far, then you know that you're getting to the right DNS server. (I said that you wouldn't see this result on when you run nslookup from the DNS server because it seems pretty unlikely that the DNS server can't ping itself!)
Next, let's create the domain controller. Set up dc.bowsers.com as I've already said, with IP address 10.1.1.2. Run the IPCONFIG /ALL and nslookup tests to ensure that it's communicating correctly with the DNS server. Go back to the DNS server and look in the bowsers.com forward lookup zone folder for a record for dc.bowsers.com at 10.1.1.2. If there's one in there, delete it, as we're going to check dynamic DNS updates.
Return to the dc.bowsers.com machine and type "ipconfig /registerdns." That should force the dc.bowsers.com machine to re-register itself with the bowsers.com DNS server. Back at the DNS server, open up the DNS snap-in, and then open the "bowsers.com" zone to check that dc.bowsers.com is registered as IP address 10.1.1.2. If it isn't, look in the Event Viewer on dc.bowsers.com for any potential clues about why it didn't work.
Assuming that the dynamic registration worked correctly, run DCPROMO as the Active Directory chapter explains. Once finished, you should have a functioning bowsers.com Active Directory domain controller. You should be able to run all of the Active Directory tools, including Active Directory Users and Computers, on the dc.bowsers.com system.
The fact that this is working so far might seem a bit counterintuitive. After all, someone else OWNS bowsers.com, so how is it that we're successfully usurping his/her registered domain? Well, every one of our systems so far looks to dns.bowsers.com for name resolution. Whenever dns.bowsers.com (or any other DNS server that I've ever heard of) gets a name resolution request for a given DNS domain, then the DNS server FIRST looks at its own zones before going out onto the public Internet to resolve a name. Furthermore, your machines might not even be CONNECTED to the Internet, which would be another reason why you're not finding the "real" bowsers.com. But this would work even if your 10.x.x.x network were connected to the public Internet. Because your local DNS server first checks to see if it's got a local bowsers.com zone before asking the Internet's DNS servers, and because you've installed a bowsers.com zone on that DNS server, then that DNS server will never go out to the Net to resolve a bowsers.com record. By the way, that also means that if you were connected to the public Internet then you would be unable to visit the real bowsers.com, as your DNS server wouldn't be able to see it because of its local records.
In other words, the question of how your DNS server finds bowsers.com is a question of which DNS server it sees as being "authoritative" for bowsers.com. Normally DNS servers find the authoritative DNS server for a given DNS zone by searching the public Internet, and that's usually the result that you want. But to create a DNS namespace internal to your company only, you'd create zones as you've seen so far. And if you had OTHER DNS servers in your network, you'd make sure that they saw the local DNS zone for bowsers.com by making those DNS servers all SECONDARY DNS servers for your internal bogus bowsers.com domain. That way, they'd all contain a copy of your bowsers.com zone locally -- and so would never venture out on the Internet to resolve bowsers.com names.
Now we're ready for a workstation. Set up ws.bowsers.com at 10.1.1.3 and do the DNS tests with IPCONFIG /ALL and nslookup. Join the domain as you read in the book, by right-clicking the My Computer icon, then going to Properties and Network Identification. Your system will now have a domain account and, when you reboot, it'll log onto the domain, making it ready to let you log onto a domain account.
But what if it didn't, or if you're unsure about whether or not DNS and AD are working together correctly? Then fire up nslookup and let's go through how DNS helps a workstation find a domain controller.
A workstation wants to find not just ANY DC, but a DC on its site. Workstations look in the Registry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters for a value called DynamicSiteName. That contains the name of the site that the workstation lives in. (If you think that you've never created a site in your small AD, you're not quite right -- AD created one for you called "Default-First-Site-Name." It then places every DC in that site. You can change that, of course, but until you set up your sites that's what you get.) (If you can't find a value entry named "DynamicSiteName," then don't worry, AD's got a backup plan, as you'll see in a moment.) Armed with its domain name and site name, the workstation queries DNS for domain controllers by requesting the records of type "SRV" with the name _kerberos._tcp.<sitename>._sites.dc._msdcs.<name of AD domain>. So, assuming that you've not named your site, then in our example your workstation WS would query for the SRV record with the name
You can see what your system would get by running nslookup:
C:/>nslookup Default Server: dns.bowsers.com Address: 10.1.1.1 >set type=srv >_kerberos._tcp.default-first-site-name._sites.dc._msdcs.bowsers.com _kerberos._tcp.default-first-site-name._sites.dc._msdcs.bowsers.com SRV service location: priority = 0 weight = 100 port = 88 svr hostname = dc.bowsers.com
Now, if you DON'T see something like that, then you might see an error along the lines of "non-existent domain." Despite what the error seems to be saying, bowsers.com probably DOES exist. What doesn't exist is a domain controller. You might try to get a clue about what's going on by typing a few more commands into nslookup:
>set type=any >bowsers.com
You'll get a bunch of information about bowsers.com, including the name of its DNS servers. There should be only one name -- dns.bowsers.com, at 10.1.1.1. If not, then go back and re-check what you've done so far.
In case you're wondering, what happens next in the logon process? The workstation sends a "please log me on" message to each of the domain controllers. That provides another service: site detection. Suppose you had a laptop that moved from place to place with you. That laptop would remember the last site that you logged onto, and would try to log onto a DC on that (distant) site again, even if you were at a new site. But the DCs that the laptop contacted at the old site would look at the laptop's new IP address in its new site, and thus discover that the laptop is in a different site from the DCs that it's been asking to log it in. The DCs would then tell the laptop, "don't ask us -- go ask at this other site," and so the laptop would end up moving its logon request to a new site.
Finally, let's take up this question: what if my workstation DIDN'T have a dynamicsitename Registry entry? Or what if all of the DCs on a given site were down -- would the workstation be smart enough to go look on another site for DCs? The answer is the same in both cases. If there's no local value for dynamicsitename, or if all of the local DCs haven't responded, then your system does a slightly different SRV query: for _kerberos._tcp.dc._msdcs.bowsers.com. That returns the name of every DC in the domain. If you ever build a multi-site domain, then you can use nslookup to dump the names of every DC:
C:/>nslookup Default Server: dns.bowsers.com Address: 10.1.1.1 >set type=srv >_kerberos._tcp.dc._msdcs.bowsers.com
Whew! That was a long example, but I hope it explained a bit of the internals of how workstations find DCs, and how to set up slightly-deceptive DNS servers. What's that you say -- you'd never set up a bowsers.com internally for production use? Of course not. But you'd almost certainly want to set up your DNS zones on the INTERNAL DNS servers to see different zones than the EXTERNAL DNS servers do. If you're megabucks.com then of course you'll have a DNS infrastructure that the public uses to find your Web and mail servers, but you'll use a separate set of DNS zones for your intranet. If you DON'T do that, then you're publishing an awful lot of information about your internal network where anyone can read it!
Now that Windows 2000 requires 25 character product IDs, I just about get carpal tunnel every time I run Setup on Windows 2000. But there's a way to get Windows 2000 to stop asking for the Product ID, Jim Adair, an attendee at one of our seminars, tells me:
"Hi Mark, here's the modification you can make to not require a product ID in a Windows 2000 Pro install. Find the setupp.ini file in the i386 directory, and make it look like this:
[Pid] ExtraData=646E77637A6F6D79626A1D94089595 Pid=51873270
"The only thing that you end up changing is the last four digits of the Pid number. Not sure exactly what this does - maybe makes it like the select cd's?? Either way, works great for both manual and unattended installs. "Thanks for a great class, really enjoyed it. -- Jim Adair"
Great tip, thanks Jim!
I've recently gotten a few spam mails from people who build simple scripts that seem to jump me straight to their Web site... but without Internet Explorer! What seems to be a Web site appears, but there's no address bar and no window, just a full-screen view of a site. The first few times, I ended up using Task Manager to get rid of it. Turns out they're doing it by invoking Internet Explorer in what is called "kiosk" mode. You'd kick it off from a command line like this: "iexplore -k www.minasi.com."
Use alt-F4 to get rid of the IE. Surprisingly, you can still do most of the usual IE stuff in kiosk mode, you've just got to know the keyboard shortcuts. They're in a Knowledge Base article, Q154780.
I recently bought a new laptop, an IBM T21 ThinkPad. One of the features that most attracted me to it was its built-in Ethernet adapter. That adapter's not a PCMCIA-based one, but instead a mini-PCI adapter. That's important to me because the T21 can thus support the PXE protocol that the Remote Installation Server (RIS) needs. You see, I when I want to wipe the slate clean on the laptop and rebuild it, then all I need do is just plug it into my network, turn it on and tell it to boot from the network. That causes the laptop to boot from the RIS server, which cleans off the laptop's hard disk and installs a completely new copy of the operating system.
The one troublesome part appeared to be due to the Plug and Play nature of Windows 2000. I'd go into a hotel to do a seminar and set up the laptop all by itself, with no other computers. (I run the Powerpoint and some demonstrations on the laptop.) The Ethernet card would wake up, sense that it wasn't connected to a hub, and just power itself down. As the Plug and Play system essentially "disconnected" the card due to no line activity, Windows 2000 didn't load a TCP/IP stack onto the Ethernet card, and so I had no TCP/IP stack. As a result of that, I couldn't do a lot of demonstrations. I needed to wake up that Ethernet card... somehow. I tried loading the MS Loopback Adapter, a driver that ships with Windows 2000 that will simulate a network card. You can indeed load a TCP/IP stack on it, but I found that it greatly slowed down the boot process for the laptop. (I suspect that something's getting bound to the stack on that card that ultimately doesn't like the loopback adapter.) I did find one workaround: I carried a PCMCIA Ethernet card with me and plugged it into the PCMCIA slots, then ran a crossover cable from the internal Ethernet to the PCMCIA Ethernet. But that seemed a bit... inelegant.
So I looked up the pin-outs for a standard Cat5 patch cable and figured out a way to wire up a simple connector that would convince my Ethernet adapter that there was a hub talking to it. Here's how.
1) Get a standard Cat5 cable. With a wire cutters, clip one end off, leaving about three inches of cable.
2) Take a razor and slice the cable sheathing lengthwise to reveal the wires inside.
3) You will find six wires inside the cable sheathing: solid blue, blue and white striped, solid brown, brown and white striped, solid orange, orange and white striped, solid green, and green and white striped. Using the wire cutters, strip about a half-inch of insulation from the green, green and white striped, orange, and orange and white striped wires. Leave the blues and browns alone.
4) Twist the solid orange and solid green wires together. Wrap them in a bit of insulating tape if you like. Then twist the green-and-white and orange-and-white wires together and, again, wrap them in a bit of tape.
Plug the RJ-45 connector into the Ethernet cable and power up the laptop. Windows 2000 will think there's a live Ethernet connected to the adapter, and you'll be in business.
Stumbled across this one last month; you'll love it. Right-click the taskbar and choose Toolbars/Address. You get an IE-type address bar in your taskbar. What's it good for? Everything. Type a command, it executes. Type a folder name, Explorer opens up and shows you the folder. Type a URL, the Web page appears. It's sort of a "universal command line."
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:
My buddy George Spalding and I had such a great time in Comdex Vegas that we're doing it again in Chicago for Spring Comdex. Get the skinny on 2000 (and Whistler!) from George, me, and some great speakers including my co-authors Christa Anderson and Doug Toombs, as well as Todd Lammle, The Cisco God. Info at http://www.key3media.com/comdex/chicago2001/mid_windows2000.html.
The same folks that brought WinConnections 2000 twice in Arizona last year are returning but this time in Monterey. I'm doing a general session as well as a variety of other topics. Find out more at www.winconnections.com.
The Interex guys, the people who put on HP World, have hired me to do an all-day pre-conference tutorial in San Francisco on Sunday, May 6 on the topic of Active Directory at their InterWorks 2001 conference. Information at http://www.interex.org/conference/iworks2001/index.html.
George and Mark visit Our Neighbor To The North to do a one-day soup-to-nuts program as part of the Toronto Comdex show. Just one day, just George and Mark, and for once I get to go to Canada in the SUMMER! (For some reason the vast majority of my Canadian clients hire me in the Winter. I've always just assumed that it was just part of The Universe's Dire Plan To Get Me.) Find out more at http://www.webeventregistration.com/registration2/conference_home?v_conference_id=749. (More about Canada Comdex, not about The Universe's Dire Plan.)
I'm keeping busy doing Windows 2000 seminars, but I've still got time to visit your firm. In just two days, I'll make your current NT techies into 2000 techies. To join the large pharmaceutical, agricultural, aerospace, banking, government, transportation, and other organizations that I've assisted, either take a peek at the course outline at 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 great month -- thank God it looks like winter's over, the daffodils and jonquils finally came up last week. (Now if my tech stocks would come up also, sigh.) Please share this newsletter; I'd like very much to expand this newsletter into a useful source of NT/2000 information. Please forward it to any associates who might find it helpful, and accept my thanks. We are now at more than eleven thousand subscribers (at least until I clean out the "dead addresses" file) and I aim to use this to get information to every single Mastering NT and 2000 Server reader. Thanks for letting me visit with you, and take care! Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews. As always, I'm at firstname.lastname@example.org.
To subscribe, visit http://www.minasi.com/nwsreg.htm. To unsubscribe, link to http://www.minasi.com/unsubs.htm. Visit the Archives at http://www.minasi.com/archive.htm.
All contents copyright 2001 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.