WINS Proxy Agents

Communicating with systems that don't understand WINS

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 someconsternation about some upcoming Microsoft releases of Exchange, WindowsNT, and Windows. Last month I discussed push and pull partners in WINS; you needthis information if you're going to build a large IP-based network of NT andWindows 95 systems. (For more about WINS, see David Lafferty, "ResolvingNames with WINS," and Darren Mar-Elia's upcoming Novemberarticle, "Implementing Enterprisewide WINS.")

But how will your network's systems that don't understand WINS resolveNetBIOS names? With a WINS proxy agent (WPA).

Suppose you have a domain named US on an intranet with two subnets (callthem A and B). Your only domain controller is on B (the only WINS server), andyou have a workstation on A that doesn't know how to use WINS. Someone tries tolog on to the domain from the workstation on A, so the workstation must find adomain controller. Therefore, the workstation broadcasts, "Does anyone outthere have the name US<1C>?" (Recall that <1C> is the suffixthat indicates that a machine is a domain controller and can act as a logonserver.) Because the workstation is broadcasting and broadcasts don'tcross routers, the name resolution request will never reach across to subnet B.Therefore, the domain controller will never respond, and the domain logon willnever happen.

(While I'm on the subject, let me answer a common question. If you don'tuse 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 findspecial kinds of servers, however, because of RFC 2052 and a new resource recordtype.)

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'splaintive cry and repeats the <1C> request, but instead makes the requestto 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 responseto the workstation, and the workstation can now locate the domain controllereven though the domain controller is on a different subnet. The good samaritanis a WPA.

WPAs also help with name registrations. Suppose our workstation has beennamed WORKSTATION, but another machine has the same name. Usually, anon-WINS-aware machine tries to ensure that it has a unique name by broadcastingthe name on startup, saying in effect, "I think my name isWORKSTATION, but if anyone already uses that name, better tell me now." Ifanother 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 namecollision has occurred? Usually WINS will tell it, but that service is no helpif 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 looksup that name with the WINS server. If WINS reports a conflict, the WPA acts onbehalf of the WINS server and responds saying, "No, you can't use thatname; I'm using it."

Oddly enough, WPAs help only with name resolution and name registrationconflicts. If a machine named ORANGE on subnet A registers a name, the WPA on Aensures that the name ORANGE doesn't conflict with any names that the WINSserver on B knows. But the WPA doesn't register the name with WINS; theWPA just check for conflicts. As a result, the non-WINS-aware workstation namedORANGE on subnet A registers its name just fine at, let's say, 8:00 a.m. Then ifa workstation on B tries to register the name ORANGE, the WPA won't challengethe name. Whether the ORANGE on B registers its name via a broadcast or viaWINS, the WPA won't notice the conflict because the WPA checks for a namecollision only when the ORANGE on A starts up. Even with WPA computers, runninga network that combines WINS-aware and non-WINS-aware machines can be a bittricky.

Further, suppose the ORANGE on subnet B, the same subnet as the WINSserver, 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 doesit put that name registration in the WINS database? Again, oddly, no.

To make a machine a WPA, you use a Registry entry, HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNetBTParameters.You must add the parameter EnableProxy of type REG_DWORD and set it to 1. You want only oneWPA 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 thenext 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 muchperformance out of an Exchange machine beyond two processors and 256MB of RAM;add an extra processor, and essentially nothing interesting happens. Put moreRAM than 256MB on an Exchange server, and it gets slower. Add these limitationsto a maximum message storage of 16GB for public stores and another 16 GB forprivate stores, and the result is that you're hard pressed to put more thanabout 3900 users on one Exchange server. (Before the Exchange partisans bombardme with email, these numbers come from a reputable source, a benchmarking groupof veritable LoadSim wizards; LoadSim, for those just joining us, is a tool thatMicrosoft kindly provides to simulate traffic on Exchange servers.) In any case,Microsoft intends the next version of Exchange to be the scaling version--theversion that can take on bigger loads. That development is good news, and myhat's off to Microsoft for continuing to improve Exchange.

What I find particularly funny is that Microsoft's internal code name forExchange 6, the next version, is Osmium. As I recall, osmium is the nameof a heavy metal like lead. Osmium is the heaviest substance known--denser thanlead--and a reviewer less kind than I am might be tempted to draw comparisonsbetween the metal and the software's documentation and user interfaces. What'soddest of all about the name is that osmium derives from the Greek wordfor odor. The metal has a distinct, disagreeable smell. Hmmm, so osmiumstinks; nope, I'm not even going there...

What were the Microsoft folk thinking? Perhaps they were tired of thereferences to gold and platinum that fill marketing space, so they looked for arare metal. Why not iridium or palladium or rhodium, all members of the platinumfamily? All are rare, beautiful, valuable, and decidedly odor free. Sorry tosound obsessive, but the science of naming beta software fascinates me.

On a more serious note, a contact tells me that Microsoft is no longerplanning to use Win32 Driver Model video drivers in NT 5.0. Very bad news! TheWin32 Driver Model was, in my opinion, going to be probably the best feature ofWindows 98. As the story's been told, the next generation of Windows and of NTwere to have 99 percent common code for handling drivers. This common code wouldhave meant, a more stable Windows, because the plan supposedly was to put NTcode into Windows rather than vice versa.

That approach is great for Windows users. But NT users would get a bigboost, too, because NT drivers and Windows drivers would be identical. Seems asthough every neat gadget I see around, such as digital cameras, video capturedoodads, or even the infrared port on my Digital Ultra II laptop, will work onlyunder 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 laptoprather than its interfaces.) As a writer, I'm often troubled by carpal tunneldiscomfort, so I have purchased every voice-based text input softwarearound--Kurzweil, IBM, and Dragon Systems--and only Dragon has software thatruns under NT. Scrounging for drivers for oddball gadgets such as cameras andvoice recognition is bad enough, but the true frustration comes fromvideo drivers: You buy a nice graphics card, and the best you can do for driversare betas that never seem to go final.

The consequence is, I'm sure, familiar to many NT users. I keep a copy ofWin95 on my laptop so that I can boot it once in a blue moon if I need todownload images from my digital camera. As for the video problems, well, youjust live with the beta video drivers, despite their lower stability, greatertendency to bugginess, and lower performance. Generally, you can't even complainto the vendor about the weak drivers; the vendor will remind you that thedrivers are beta anyway, so what do you expect?

Merging the driver model means that any vendor who writes a Windows 98driver--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 thatgoal and won't merge the video drivers for NT and Windows, at least not forWindows 98 and NT 5.0. (Microsoft confirmed this plan to me but claimed that thecompany 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 atechnological barrier is preventing Microsoft from merging the drivers, orwhether Microsoft is just holding out a few goodies so we'll have a reason tobuy the next version of the operating systems? Sometimes I think TheX-Files' Fox Mulder will get his sister Samantha back before we get areliable, unified set of desktop operating systems. If anyone out there has someleverage, talk to the Microsoft folks, OK?