Symantec Access Management

Hi, looking some clarification on how to implement the ServerCommandTimeDelay registry parameter in a Siteminder R12.5 environment.  Have gotten some conflicting information that it requires a global restart in order to implement?

Running a multi-master policystore environment with policyservers/policystore is multiple territories.  In order to implement ServerCommandTimeDelay and/or ServerCmdMsec in Policy Server registry, does it require that we stop all policyservers in all territories, implement the registry change, and then restart all policy servers at the same time?  If this is not done, it may lead to policystore corruption?  This doesn't seem like a practical or even feasible solution, does anyone have any advice on how to implement?  Can we simply add the reg key in one territory, restart the policy servers in that one territory, and then move on to the next territory in the new few days?  I would understand the parameter may not provide any benefit until all territories have the reg key(s) in place and their respective policy servers been restarted, but to coordinate among multiple territories is near impossible.

Any comments on whether others have implemented both ServerCommandTimeDelay and/or ServerCmdMsec and whether its resolved replication issues would be helpful as well...

Thanks !

What parameters guide when / how does PolicyServer-A write into the PolicyStore.

ServerCmdDelay // dword - server command cache time in seconds.

is the number of seconds the policy server caches server and/or agent commands before writing them out to the policy store journal.

Default Value : 10 by default as shown above; it will also be set to 10 seconds if the setting is missing from the registry.

ServerCmdMsec, // dword - 1 if server command need to be stored with msec timestamp, 0 otherwise.

The Policy Server command replication can now be made to use sub second recording and ordering

Default Value : If the registry value is 0 or does not exist, the default existing behavior will be executed i.e. in seconds. If it is 1, then Server Command store in Millisecond implementation.

What parameters guide how frequently OR at what duration does PolicyServer-B speak to the PolicyStore and read the ServerCommands.

ApplyAdminChanges determines how often the remote policy servers pick these changes up.

SMCONSOLE >> Advanced Tab >> Apply Administrative Changes (get saved in Registry as JournalRefresh).

Default Value : 60 seconds.

Can be defined in seconds only.

OR

Corresponding Registry Entry >> JournalRefresh // dword - process journal entries refresh interval in seconds.

Additional Info

ServerCommandTimeDelay is a parameter designed to adjust Server Command processing to allow for clocks that are out of sync between Policy Servers.

- In R12.51 this was deprecated.

- Instead we now use “MaxTimeDeltaBetweenServers” from R12.51. Since you mentioned R12.5 hence ServerCommandTimeDelay would be applicable to you.

- MaxTimeDeltaBetweenServers // dword - the maximum time delta allowed between servers using the same policy store, in seconds.

- We have raised an Enhancement Request to make sure there is backward compatibility i.e. customers using ServerCommandTimeDelay and upgrading to R12.51 / above.

- Our current R12.51 installer code handles in-place upgrade i.e. if it finds ServerCommandTimeDelay in registry; it would flip to new parameter. However in parallel upgrade there is no provision. The Enhancement Request caters to handling both forms of upgrade.

Usecase: Common PolicyStore. PolicyServer-A connected to WAMUI-A. Make changes in WAMUI-A. Changes getting reflected in PolicyServer-B connected to WAMUI-B. All machines are in time sync.

Our recent testing in a CA Internal Production deployment indicated that the foremost parameter that impact the sync of data across different PS Cache was "ServerCommandTimeDelay". Therefore the first parameter to apply and test would be "ServerCommandTimeDelay". Note, all the other 3 parameters have default value if they are not defined in registry. ServerCommandTimeDelay is the only parameter amongst all 4 which does not have a default value per say. Hence only apply ServerCommandTimeDelay to a reasonable value (e.g. 60 seconds) and then do your testing. It did resolve our sync issue by only setting ServerCommandTimeDelay (We had 4 PS and 4 WAM UI, hence we tested using 4 WAM UI/PS connected to same store).

These parameters are applied to registry. Registry changes are picked up only during booting process of Policy Server. The registry is local to every policy server machine. Hence you'd need to apply them individually and restart each policy server.

My recommendation would be to apply the changes within one cluster and restart the policy servers within one cluster. So that it allows continued uptime for Production traffic. When one cluster is down, request would failover to the secondary/tertiary cluster. When the primary cluster is brought up, request would failback to primary cluster.

Let me know if this helps.

Regards

Hubert

Thanks ! Appreciate the detailed response !!

Hi,

Did Hubert response helps answer your question? If it is, please help to mark Hubert's response as answer.

If not, please let us know.

Thanks.