Sure. There are two issues involved here. First, note that the terminal server will generally begin sending RADIUS requests to a secondary RADIUS server when it is not getting answers from the primary RADIUS server within a designated period of time. Now, normally the TSX RADIUS server does not assume that a user is "really on" until it gets a "START" type record at the accounting port. However, terminal servers don't automatically start sending accounting requests to the secondary accounting server just because they don't get answers to RADIUS requests. Actually, they MIGHT... because RADIUS does send replies to accounting requests, and the terminal server is not getting answers to its accounting requests either.
Here's what you need to do. Set up the address of the secondary RADIUS server in the terminal server and shut the primary radius server down. This command ought to do it:
STOP/PROGRAM=RADIUS_SThen, monitor the RADIUS event log and see if it's continually griping about PPP not converging. If it is, no need to run this seondary RAIDUS server in "don't waint for accounting records to assume a user is logged in" mode. This involves patching TPR and restarting the RADIUS server. To learn how to do this read about "PPP did not converge".
The second issue is, "does the secondary TSX node have to be a slave to the primary TSX node. No, but if it's not any changes to the user authorization database won't be immediately reflected on the seondary node; you will have to stop the BBS name server, copy the UAF.BBS file from the master machine, and restart the name server periodically.