PowerPC WINS Server Shows the Doma

Last reviewed: December 4, 1997
Article ID: Q162696
The information in this article applies to:
  • Microsoft Windows NT Server versions 3.51 and 4.0

SYMPTOMS

A network client is unable to browse computers that reside on the primary domain controller's (PDC’s) own segment by means of File Manager or Network Neighborhood. All other segments are visible and can be browsed. However, the client is able to connect to any computer on the PDCs segment, as long as the server name is known.

CAUSE

The PDC for the domain is also running Windows Internet Name Service (WINS), and that server is on the PowerPC, MIPS, or Alpha platforms. If nbtstat -n is run from the PDC, it will show that the domainname<1D> is in conflict. This happens when a segment master browser for the domain (on a different segment than the PDC) releases its names during a shutdown. When that computer releases the domainname<1D>, the WINS server/PDC logs a duplicate name error, and shows its own <1D> entry to be in conflict. If the domainname<1D> name is not registered in the WINS database, the WINS server will always discard that entry. But, it is necessary for the name to be registered by means of NetBT (the NetBIOS interface on TCP/IP), as that is the name that the server listens to and mailslot browser broadcasts on.

For additional information, please see the following articles in the Microsoft Knowledge Base:

   ARTICLE-ID: Q119493
   TITLE     : NetBIOS over TCP/IP Name Resolution and WINS

   ARTICLE-ID: Q119495
   TITLE     : List of Names Registered with WINS Service

   ARTICLE-ID: Q120151
   TITLE     : Browsing a Wide Area Network with WINS

RESOLUTION

To resolve this issue, perform one of the following:

  • Move the WINS service off of the PDC to another server.

    -or-

  • Run your PDC/WINS server on a different platform, for example, Intel.

    -or-

  • For Windows NT 4.0, obtain the latest service pack, but for Windows NT 3.51 obtain the hotfix mentioned below.

STATUS

Microsoft has confirmed this to be a problem in Windows NT versions 3.51 and 4.0. This problem was corrected in the latest Microsoft Windows NT 4.0 U.S. Service Pack. For information on obtaining the service pack, query on the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K
Keywords          : kbbug3.51 kbbug4.00 NTSrv nttcp kbnetwork
Version           : WinNT:3.51,4.0
Platform          : winnt


================================================================================


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: December 4, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.