|
Home > Archive > 70-216 > September 2002 > tombstone......??
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| i read all this of course on the MOC... but some explanation from the forum is the best for my brain.....
what about the tombstone on WINS???? some explanation... this will be the last one today....
thanks
alex | |
|
| Tombstoning is the marking of a record for eventual deletion, called tombstoning. The tombstone state of the record then replicates across all WINS servers, preventing an active copy on a different server database from propagating the record.
When a client node registers or refreshes a name, the name might already exist in the WINS database. The action taken by the WINS server depends on the state of the registered name. It might be active, released, or extinct. (An extinct name is referred to as a tombstone.) The name might be a unique name or a group name, owned by the server or a replica, a database entry copied from another WINS server, with a statically or dynamically assigned IP address. The IP address might be the same as or different from that specified in the registration request of the client.
If you read only the MOC it is very dificult to pass exams. You must have a second choice. This description is from Technet. | |
|
| quote:
Originally posted by retep
Tombstoning is the marking of a record for eventual deletion, called tombstoning. The tombstone state of the record then replicates across all WINS servers, preventing an active copy on a different server database from propagating the record.
When a client node registers or refreshes a name, the name might already exist in the WINS database. The action taken by the WINS server depends on the state of the registered name. It might be active, released, or extinct. (An extinct name is referred to as a tombstone.) The name might be a unique name or a group name, owned by the server or a replica, a database entry copied from another WINS server, with a statically or dynamically assigned IP address. The IP address might be the same as or different from that specified in the registration request of the client.
If you read only the MOC it is very dificult to pass exams. You must have a second choice. This description is from Technet.
i have trascender, some study test, mocs, some servers for testing and the forum.... i fail one time a few months ago... | |
|
| quote:
Originally posted by retep
Tombstoning is the marking of a record for eventual deletion, called tombstoning. The tombstone state of the record then replicates across all WINS servers, preventing an active copy on a different server database from propagating the record.
When a client node registers or refreshes a name, the name might already exist in the WINS database. The action taken by the WINS server depends on the state of the registered name. It might be active, released, or extinct. (An extinct name is referred to as a tombstone.) The name might be a unique name or a group name, owned by the server or a replica, a database entry copied from another WINS server, with a statically or dynamically assigned IP address. The IP address might be the same as or different from that specified in the registration request of the client.
If you read only the MOC it is very dificult to pass exams. You must have a second choice. This description is from Technet.
oh men you don´t believe it but is a nightmare for me take all this concepts of networks because really i´m new on this network concepts. i make some implementations of AD with DNS; rras, vpn, dhcp, everything is working fine until today... but this 70216 is really a nightmare for me.... | |
| elio_de_santis 2002-09-10, 5:24 am |
| Here is a good example (excerpt from Syngress)
Imagine that we have three WINS servers in our WINS network: WINS-A, WINS-B, and WINS-C. WINS-B is the hub of the WINS network, and WINS-A and WINS-C are spokes (Figure 8-12). WINS-A receives a NetBIOS name registration for a computer named BLOBALOCITY. After registering its NetBIOS name, we decide that we’re going to take BLOBALOCITY off the network. Meanwhile, BLOBALOCITY’s record is replicated to WINS-B, and WINS-B replicates the record to WINS-C.
Figure 12
(Check figure figure.jpg attached)
To increase the speed and responsiveness of WINS registrations and queries, you want to keep the WINS database lean and mean. You open your WINS management console and delete the record for BLOBALOCITY. You figure the fact that the record was deleted will be replicated over to the other WINS servers, and you can bid adieu to BLOBALOCITY from your WINS network.
When WINS-A next replicates with WINS-B, it doesn’t replicate BLOBALOCITY’s WINS record—it can’t, since the record was deleted. What happens when WINS-B replicates with WINS-A? Since WINS-B still has BLOBALOCITY’s record in its database, it replicates it back to WINS-A. Now BLOBALOCITY has risen from the dead and its record reappears, marked active, in the WINS-A database.
Eventually, BLOBALOCITY’s record will exceed its renewal interval, then its extinction interval, then its extinction timeout, and finally will be deleted. But, if you just delete records, the entire process will take longer than it should, and the stale WINS database records will have a negative impact on WINS server performance. | |
| cm2gj 2002-09-10, 11:06 am |
| quote:
Originally posted by elio_de_santis
Here is a good example (excerpt from Syngress)
so instead of delete a record, the recommended action is tombstoned?
how i make a tombstone? | |
| elio_de_santis 2002-09-11, 1:25 am |
| Excerpt Syngress :
To tombstone a WINS record, open the WINS management console and click on Active Registrations. Right-click on Active Registrations and select Find by Owner. On the Owners tab, select the option button for “All owners,” and click Find Now. Right-click on one of the records in the right pane and select Delete. |
|
|
|
|