Synchronize policy information to another SP server

IBM has evaluated the request, and has determined that it can not be implemented at this time or does not align with the current multi-year strategy. This request may be resubmitted for consideration after 18 months from the date of submission. The request submitter will automatically be notified by email when the request qualifies for reconsideration and resubmission.

@IBM_Tivoli_Developer:
I read through your link. A configuration manager does not do the following according to https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.1/com.ibm.itsm.srv.doc/t_network_config_profile_policy.html:

A configuration manager does not distribute the following information:
•An active policy set and any of its associated management classes, copy groups, and client schedules. On each managed server, you must activate a policy set in each managed policy domain.
•Associations between clients and schedules. To have clients in a managed policy domain run client schedules, you must associate the clients with the schedules on the managed server.
•Client actions, which are schedules that are created by using the DEFINE CLIENTACTION command. On each managed server, you can define and delete client actions, even if the corresponding domain is a managed object.
•Definitions for any storage pools that are identified as destinations in the policy. Definitions of storage pools and device classes are not distributed by a configuration manager.
Policy domains can refer to storage pool names in the management classes, backup copy groups, and archive copy groups. As you set up the configuration information, consider whether managed servers already have or can set up or rename storage pools with these names.

My requirement is to copy/synchronize Policy Domains, the client schedules and their associations to the remote server. The client schedules should be active on the remote server.



@Josh.Davis:
Thanks for your approach. Your example for my sync script works - only the syntax was false. It only works with "UPD SCR EXPORTSYNC "(SERVERB) DEL SCHED WINDOWS *".

@IBM_Tivoli_Developer & Josh.Davis:
Is there a better way to reach my goal than using the export function in this way?

Disclaimer: I'm not an IBMer, and do not speak for development.

I tested on my systems, and confirmed:
* DEL ASSOC will not take wildcards for domain and schedule names
* DEL SCHED will not take wildcards for domain
* Enterprise configuration profiles do not propagate schedule associations (on purpose).
* EXPORT SERVER only adds, and never removes (on purpose).
* REPLICATE only does node and file data (on purpose)
* PROTECT only does chunks (on purpose)

In general, schedule associations being replicated would be an issue because dsmwebcli.log or dsmsched.log on the clients, and the actlog on SERVER-B, would continually report errors. The SERVER-B will have a different UUID, server name, and IP address, but will keep trying to connect to the same IP and port on the client that's pointed to SERVER-A.

For a true DR situation, it's better to use HADR and storage/os based replication.

Export is not really the right way to do it. I think having export do any sort of removal on a target server is counter to the intent of the command.

I could imagine export skipping associations completely.
I could imagine a DEFINE PROFASSOCIATION SCHEDASSOC=*.

The key here would be how many people want the ability to sync schedule associations with a remote server vs the amount of effort that would take to do it.

It's probably better to update your script a bit to do:
DEL SCR EXPORTSYNC
Y
DEF SCR EXPORTSYNC DESC="Sync policy with SERVERB"
UPD SCR EXPORTSYNC "SERVERB: DEL SCHED UNIX *"
UPD SCR EXPORTSYNC "SERVERB: DEL SCHED WINDOWS *"
UPD SCR EXPORTSYNC "EXPORT POLICY TOSERVER=SERVERB REPLACEDEF=YES"

Update the script any time you add a new policy domain.