SETPRFDC

In October 1998, Microsoft released Windows NT 4.0 Service Pack 4 (SP4), which contains SETPRFDC, a cool utility that lets you adjust secure connections between Windows NT machines. SETPRFDC isn't in any Microsoft Windows NT Resource Kit, but it's a utility you don't want to miss out on. So, call this month's column "This Old Service Pack."

Because NT is a secure OS, NT machines must perform many authentications each day. On domain-based NT networks, computers must find a domain controller for those authentications. Which domain controller does an NT machine use? The machine logon process involves finding a domain controller; the computer uses that domain controller for subsequent authentications until a user reboots the machine. This link is a secure remote procedure call, or secure RPC.

Unfortunately, that machine logon might not be the beginning of a beautiful friendship. Sometimes busy local domain controllers force NT machines to find authentication buddies far away. For example, users at a large firm in Austin might find one day that their computers' domain controllers are in Paris. One long-distance authentication isn't a problem, but if an Austin workstation requires a lot of authentication traffic, that traffic could stress the bandwidth of a slow transatlantic WAN link. The firm's administrators would undoubtedly be happy to hear about SETPRFDC, a utility that lets you specify a new authentication buddy for a running NT machine.

The utility's syntax looks like

SETPRFDC <domain_name> <first_domain_controller>,<second_domain_controller>,<third_domain_controller>

Austin users whose systems are in the TEXAS domain and whose local domain controllers are named TX1 and TX2 can open a command line and type

SETPRFDC TEXAS TX1,TX2

The workstations will attempt to connect to TX1 first; if that connection attempt fails, they'll attempt to connect to TX2. If both connection attempts fail, the machines will maintain their current secure RPC to the Paris domain controller. If SETPRFDC changes the users' connection, it will report which local domain controller the machine connected to.

Is this utility useful? Absolutely. Links similar to the authentication buddy connections exist between member servers and domain controllers, Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs), and domain controllers in trusting domains. Under some circumstances—such as Windows Internet Naming Service (WINS) failures—domain controllers in one domain lose track of their authentication buddies in other domains. When such a situation arises, users face network delays at best and an inability to log on to the domain at worst. Suppose you arrive at your network operations center one morning and see an Event Viewer entry that indicates your network has lost its trust link to another domain. Do you start rebooting servers until the problem disappears? No. You just pull out your list of domain controllers in the trusted domain and use SETPRFDC to dial for secure RPCs.

You can avoid this problem by finding each domain controller an authentication buddy on the same network segment; if WINS gets loopy, the domain controller can find its buddy via broadcasts. Or you can use LMHOSTS files to solve this problem; for more information about this solution, see "Pick Users' Domain Controller," page 185.

Consider how you can use SETPRFDC. Your domain's member servers, file and print servers, Web servers, and Exchange Server systems constantly need authentication help from a domain controller. If they become disconnected from their authentication buddy, they float around the enterprise looking for a new favorite domain controller. To prevent such a server from connecting to a faraway machine, place a SETPRFDC command in an AT command to force your servers to establish secure RPCs with particular domain controllers. (For more information about the AT command, see "Where It's AT," March 1998.)