This month I have two agendas: to finish up Windows Internet Name Service (WINS) once and--I hope--for all, and to pass along a smile and some consternation about some upcoming Microsoft releases of Exchange, Windows NT, and Windows. Last month I discussed push and pull partners in WINS; you need this information if you're going to build a large IP-based network of NT and Windows 95 systems. (For more about WINS, see David Lafferty, "Resolving Names with WINS," and Darren Mar-Elia's upcoming November article, "Implementing Enterprisewide WINS.")
But how will your network's systems that don't understand WINS resolve NetBIOS names? With a WINS proxy agent (WPA).
Suppose you have a domain named US on an intranet with two subnets (call them A and B). Your only domain controller is on B (the only WINS server), and you have a workstation on A that doesn't know how to use WINS. Someone tries to log on to the domain from the workstation on A, so the workstation must find a domain controller. Therefore, the workstation broadcasts, "Does anyone out there have the name US<1C>?" (Recall that <1C> is the suffix that indicates that a machine is a domain controller and can act as a logon server.) Because the workstation is broadcasting and broadcasts don't cross routers, the name resolution request will never reach across to subnet B. Therefore, the domain controller will never respond, and the domain logon will never happen.
(While I'm on the subject, let me answer a common question. If you don't use WINS or LMHOSTS, and if you select Use DNS for Windows Name Resolution, Domain Name System (DNS) will not be able to locate domain controllers. DNS can find machine names, but DNS can't understand suffixes such as <1C>, so it can't find domain controllers. The DNS with NT 5.0 can find special kinds of servers, however, because of RFC 2052 and a new resource record type.)
Suppose, however, that a WINS-aware machine is on subnet A. Suppose, too, that the machine is a kind of good samaritan. It hears the workstation's plaintive cry and repeats the <1C> request, but instead makes the request to the WINS server on subnet B. The WINS server on B says to the good samaritan, "I'm here at address X." The good samaritan then relays the response to the workstation, and the workstation can now locate the domain controller even though the domain controller is on a different subnet. The good samaritan is a WPA.
WPAs also help with name registrations. Suppose our workstation has been named WORKSTATION, but another machine has the same name. Usually, a non-WINS-aware machine tries to ensure that it has a unique name by broadcasting the name on startup, saying in effect, "I think my name is WORKSTATION, but if anyone already uses that name, better tell me now." If another WORKSTATION on the same subnet has the same name, it will reply, "No, I've already got that name."
But if the other machine is on another subnet, how will it know that a name collision has occurred? Usually WINS will tell it, but that service is no help if the machine registering the name doesn't use WINS. The WPA can help here, too. When a non-WINS-aware machine broadcasts a name registration, the WPA looks up that name with the WINS server. If WINS reports a conflict, the WPA acts on behalf of the WINS server and responds saying, "No, you can't use that name; I'm using it."
Oddly enough, WPAs help only with name resolution and name registration conflicts. If a machine named ORANGE on subnet A registers a name, the WPA on A ensures that the name ORANGE doesn't conflict with any names that the WINS server on B knows. But the WPA doesn't register the name with WINS; the WPA just check for conflicts. As a result, the non-WINS-aware workstation named ORANGE on subnet A registers its name just fine at, let's say, 8:00 a.m. Then if a workstation on B tries to register the name ORANGE, the WPA won't challenge the name. Whether the ORANGE on B registers its name via a broadcast or via WINS, the WPA won't notice the conflict because the WPA checks for a name collision only when the ORANGE on A starts up. Even with WPA computers, running a network that combines WINS-aware and non-WINS-aware machines can be a bit tricky.
Further, suppose the ORANGE on subnet B, the same subnet as the WINS server, is also not WINS-aware and registers its name through a broadcast. Because the WINS server is on the same subnet, it hears the broadcast--but does it put that name registration in the WINS database? Again, oddly, no.
To make a machine a WPA, you use a Registry entry, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters. You must add the parameter EnableProxy of type REG_DWORD and set it to 1. You want only one WPA per subnet because multiple WPAs on a subnet confuse matters significantly.
Stinky Exchange 6 and Driver Divorce
I came across some amusing and disturbing rumors this month, one about the
next version of Exchange and another about the next version of NT and Windows.
Exchange is a neat email system, but it's fairly limited. You don't get much
performance out of an Exchange machine beyond two processors and 256MB of RAM;
add an extra processor, and essentially nothing interesting happens. Put more
RAM than 256MB on an Exchange server, and it gets slower. Add these limitations
to a maximum message storage of 16GB for public stores and another 16 GB for
private stores, and the result is that you're hard pressed to put more than
about 3900 users on one Exchange server. (Before the Exchange partisans bombard
me with email, these numbers come from a reputable source, a benchmarking group
of veritable LoadSim wizards; LoadSim, for those just joining us, is a tool that
Microsoft kindly provides to simulate traffic on Exchange servers.) In any case,
Microsoft intends the next version of Exchange to be the scaling version--the
version that can take on bigger loads. That development is good news, and my
hat's off to Microsoft for continuing to improve Exchange.
What I find particularly funny is that Microsoft's internal code name for Exchange 6, the next version, is Osmium. As I recall, osmium is the name of a heavy metal like lead. Osmium is the heaviest substance known--denser than lead--and a reviewer less kind than I am might be tempted to draw comparisons between the metal and the software's documentation and user interfaces. What's oddest of all about the name is that osmium derives from the Greek word for odor. The metal has a distinct, disagreeable smell. Hmmm, so osmium stinks; nope, I'm not even going there...
What were the Microsoft folk thinking? Perhaps they were tired of the references to gold and platinum that fill marketing space, so they looked for a rare metal. Why not iridium or palladium or rhodium, all members of the platinum family? All are rare, beautiful, valuable, and decidedly odor free. Sorry to sound obsessive, but the science of naming beta software fascinates me.
On a more serious note, a contact tells me that Microsoft is no longer planning to use Win32 Driver Model video drivers in NT 5.0. Very bad news! The Win32 Driver Model was, in my opinion, going to be probably the best feature of Windows 98. As the story's been told, the next generation of Windows and of NT were to have 99 percent common code for handling drivers. This common code would have meant, a more stable Windows, because the plan supposedly was to put NT code into Windows rather than vice versa.
That approach is great for Windows users. But NT users would get a big boost, too, because NT drivers and Windows drivers would be identical. Seems as though every neat gadget I see around, such as digital cameras, video capture doodads, or even the infrared port on my Digital Ultra II laptop, will work only under Win95. (You know the Ultra II--it's the laptop that Digital advertises as "designed for Windows NT 4.0." That claim must refer to the laptop rather than its interfaces.) As a writer, I'm often troubled by carpal tunnel discomfort, so I have purchased every voice-based text input software around--Kurzweil, IBM, and Dragon Systems--and only Dragon has software that runs under NT. Scrounging for drivers for oddball gadgets such as cameras and voice recognition is bad enough, but the true frustration comes from video drivers: You buy a nice graphics card, and the best you can do for drivers are betas that never seem to go final.
The consequence is, I'm sure, familiar to many NT users. I keep a copy of Win95 on my laptop so that I can boot it once in a blue moon if I need to download images from my digital camera. As for the video problems, well, you just live with the beta video drivers, despite their lower stability, greater tendency to bugginess, and lower performance. Generally, you can't even complain to the vendor about the weak drivers; the vendor will remind you that the drivers are beta anyway, so what do you expect?
Merging the driver model means that any vendor who writes a Windows 98 driver--and you can bet they all will--also will be writing an NT 5.0 driver. For reasons that my contact could not explain, Microsoft is backing off on that goal and won't merge the video drivers for NT and Windows, at least not for Windows 98 and NT 5.0. (Microsoft confirmed this plan to me but claimed that the company had never promised to merge the drivers; interesting in an Orwellian, Animal Farm kind of a way, isn't it?) I have to wonder whether a technological barrier is preventing Microsoft from merging the drivers, or whether Microsoft is just holding out a few goodies so we'll have a reason to buy the next version of the operating systems? Sometimes I think The X-Files' Fox Mulder will get his sister Samantha back before we get a reliable, unified set of desktop operating systems. If anyone out there has some leverage, talk to the Microsoft folks, OK?