| Since no one is answering this question, I am going to answer my own question
for the benefit of someone having the same query. I shall post later whether
this has solved the WINS 4280 error code.
> In the Primary WINS Server, Control Panel- network - TCP/IP
> properties is it legal to list Primary WINS Server
> pointing to itself & Secondary WINS Server pointing to the
> actual Secondary WINS Server?
>
The following article is from Microsoft KB.
------------------------------------------------------------------------------
Setting Primary and Secondary WINS Server Options
Article ID: Q150737
Creation Date: 08-MAY-1996
Revision Date: 04-FEB-1997
The information in this article applies to:
Microsoft Windows NT Workstation versions 3.5 and 3.51
Microsoft Windows NT Server versions 3.5 and 3.51
SUMMARY
If a Windows NT server is running the Windows Internet Naming Service (WINS)
and is participating in WINS database replication on the network, special
consideration must be taken configuring where the WINS server points to for
it's own name resolution (this parameter is set in the Network section of
Control Panel, in the Configuration section of TCPIP Protocol).
It is highly recommended that a WINS server point to itself as Primary and
Secondary WINS in the TCP/IP configuration. If another configuration is used,
you may experience random instability in making certain network connections.
MORE INFORMATION
When any WINS enabled computer is booted it must register a variety of
services with WINS. Commonly a computer has a Primary and Secondary WINS
address configured in the TCP/IP setup. If the Primary WINS does not
respond to the registrations, the computer tries the Secondary WINS.
For additional information on the services that can be registered, please
see the following article(s) in the Microsoft Knowledge Base:
ARTICLE-ID: Q119495
TITLE : List of Names Registered with WINS Service
Generally, most clients and servers should be configured with a Primary and
Secondary WINS address, however caution must be taken with how a WINS server
is itself configured. A WINS server eventually register its services in its
own local WINS database, regardless of whether it points to itself or
not (either Primary, Secondary, or none). Registering with itself and another
WINS server can cause problems when it comes to replication and renewal of
these entries.
For example, if you have a WINS server ("Srv1") that points to itself as
Primary and points to another WINS as Secondary ("Wins2"). When Srv1 is
booted, it usually tries to register its services before its own WINS Service
is started. Since those registrations fail, it tries to register them at Wins2.
If Wins2 is available, it accepts the registration requests. However, not all
the services are registered at Wins2, because as these registration requests
are made, Srv1 continues to check its local WINS service. Once the service
is running, it switches back to it and continues registering locally.
After replication has occurred between Srv1 and Wins2, both databases show
this ownership:
Srv1: Owns his Srv1<20>, and Domain<1c> (if it is a domain controller)
Wins2: Owns all other Srv1 registrations, and also owns Domain<1c> from Srv1
This potentially problematic condition is referred to as "split registration."
At this point, Srv1 has reverted to re-registering locally, however it takes
a while before you can see it. Meanwhile, Srv1 and Wins2 are replicating the
split registration mappings to other WINS servers. Eventually these replicas
should be reconciled at the remote WINS (that is, the Wins2 replicas are
replaced by the newer Srv1 replicas). However, before reconciliation is
finished, client connection problems may have occurred, including the
inability to connect to a WINS server that split its registration (in this
example, Srv1), or the inability to resolve the domain<1c> name that Srv1
registered.
The exact conditions that lead to failure are varied. If your WINS servers
are running Windows NT version 3.51 with Service Pack 4 (or greater),
these conditions should only be temporary. However, the problem may be more
severe depending on your replication scheme or if you are running pre- Service
Pack 4 WINS servers.
Another faulty configuration is setting a remote IP address (in this example,
Wins2) as Primary while setting the local WINS (Srv1) as Secondary. In this
case, Srv1 will eventually stop refreshing its NetBIOS lease at Wins2, and
will begin registering locally. Depending on your WINS replication scheme,
this may cause connection problems.
WORKAROUND
It is recommended that a WINS server point to itself as Primary WINS and as
Secondary WINS. This will avoid split registrations and other problems.
STATUS
Microsoft has confirmed this to be a problem in Windows NT version 3.5 and
3.51. We are researching this problem and will post new information here in
the Microsoft Knowledge Base as it becomes available.
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.
�1997 Microsoft Corporation. All rights reserved. Legal Notices.
|