You can also disable machine-account password changes. To do so, set the RefusePasswordChange value to 1. However, this change doesn't stop your systems from regularly bothering the PDC with password-change requests. To prevent computers from requesting password changes, set the DisablePasswordChange value to 1 on each member computer. (I recommend against setting this value to 1 on your servers because it might make them more vulnerable to an attacker using another computer to impersonate the server.)
By default, the PDC checks its database every 5 minutes (i.e., 300 seconds) for changes to domain users, groups, or policies. When the PDC finds a change, it sends a message to each BDC that new information is available for replication. The BDCs then contact the PDC and request replication. You can use the Pulse value on the PDC to adjust how frequently the PDC checks for changes and notifies BDCs.
To prevent all BDCs from clamoring for changes simultaneously and overloading the PDC, the PDC notifies only a certain number of BDCs at a time. The PulseConcurrency value on the PDC controls this number and defaults to 10. If you have many updates occurring every minute and many DCs, you might need to increase this value so that BDCs receive updates in a timely fashion. However, doing so also increases the load on the PDC.
After pulsing a BDC, the PDC waits a certain period of time for the BDC to respond. The PulseTimeout1 value on the PDC controls this period. The value can range between 1 and 120 (seconds) and defaults to 10. An unresponsive BDC doesn't apply toward the number of BDCs that the PulseConcurrency value specifies, so the PDC can move on to a BDC that's operational and ready for replication. In a slow network environment, such as a network with slow or clogged WAN connections, you might need to increase the PulseTimeout1 value on the PDC so that the PDC doesn't prematurely evaluate a BDC as unresponsive. Otherwise, the PDC might end up replicating to too many BDCs at the same time.
After the PDC initiates replication, the BDC drives the process by repeatedly requesting the next chunk of replication data from the PDC. A BDC might crash or shut down in the middle of this process; the PulseTimeOut2 value on the PDC controls how long the PDC waits for the BDC to request the next chunk. You can set the value to a minimum of 60 (seconds) and a maximum of 3600 (seconds); the default is 300. If you set the value too low, you end up with too many BDCs requesting changes from the PDC at the same time. In this situation, the PDC can't keep up; you might need to set the value higher so that the PDC can handle the load and replicate in an orderly, timely fashion.
The PDC periodically pulses the BDCs even when no changes have occurred. This pulsing can cause unnecessary traffic if you have many DCs spread out over a WAN. The PulseMaximum value on the PDC controls this behavior; the default is 7200 (seconds151;i.e., 2 hours). You can set the value to a minimum of 60 (i.e., 1 minute) and a maximum of 86,400 (i.e., 24 hours).
The PDC breaks replication changes into blocks and feeds each block to the BDC as it requests the data. You can adjust the ReplicationGoverner value on the BDCs to control how much bandwidth replication uses. ReplicationGoverner is specified as a percentage (the default is 100) and controls the rate at which BDCs request data blocks.
The PDC holds changes to the domain database in a log. The ChangeLogSize value on the PDC controls the log's size and defaults to 65,536 (bytes151;i.e., 64KB). In large domains in which many changes occur simultaneously, the log can fill up. When the log is full, the PDC can't record any more changes in it and loses track of which changes the BDCs have received. The PDC then must replicate the entire database to the BDCs151;creating yet more network traffic. You can increase the size of the log to a maximum of 4,194,304 (i.e., 4MB), but be aware that doing so consumes both disk space and RAM.
A Model of Security
The larger your network, the more important your choice of domain model is. Take into account the models' various boundaries of administrative authority and how your company organizes user and computer administration. Consider the models' various risks and the security standards of other domains before deciding how to establish trust relationships. And tune replication if you choose a model that specifies multiple domains, especially if your network has many users or BDCs. (For more information about domain models and trust relationships, see L. J. Locher, "Trusted and Trusting Domains in NT 4.0," December 1999.)
Register
