After you set up server communication as described in Setting Up Communications for Enterprise Configuration and Enterprise Event Logging, you set up the configuration manager and its profiles. With the profiles, you designate the configuration information that can be distributed to managed servers. Then you can set up other servers as managed servers. The managed servers receive configuration information through subscriptions to profiles on the configuration manager. Each managed server stores the distributed information as managed objects in its database. Managed servers receive periodic updates of the configuration information from the configuration manager, or an administrator can trigger an update by command.
You can distribute the following configuration information from a configuration manager to managed servers:
Policy objects include policy domains, and the policy sets, management classes, copy groups and client schedules associated with them. However, a configuration manager does not distribute an active policy set and any of its associated objects. On each managed server, you must activate a policy set in each managed policy domain.
Note: | The configuration manager does not distribute definitions for any storage pools identified as destinations in the policy. Definitions of storage pools and device classes are not distributed by a configuration manager. |
Enterprise Configuration Scenario gives you an overview of the steps to take for one possible implementation of enterprise configuration. Sections that follow give more details on each step.
To illustrate how you might use these functions, suppose your enterprise has offices around the world, with one or more TSM servers at each location. To make managing these servers easier, you want to control the configuration of all TSM servers from one TSM server in the headquarters office. Figure 55 shows the hierarchy that you want to set up.
Figure 55. A Scenario for Implementing Enterprise Configuration
You want to set up a configuration manager named HEADQUARTERS. Managed servers have the names of cities where they are located. You have three groups of managed servers, one in the Americas, one in Europe, and one in Asia. Each of the servers supports backup and archive services for client machines in that office. For client backup operations, you want to use the default policy that stores backups on disk. Each server has an automated tape library configured to work with TSM, and you want to use the tape library at each location for client archive operations and for TSM server database backups. You want to be able to monitor activities on all servers. You also want to designate some other users as administrators who can work with these servers.
The following sections give you an overview of the steps to take to complete this setup. For details on each step, see the section referenced.
Figure 56 shows the specific commands needed to set up one TSM server as a configuration manager. The following procedure gives you an overview of the steps required to set up a server as a configuration manager.
Figure 56. Setting Up a Configuration Manager
Use the following command:
set configmanager on
This command automatically creates a profile named DEFAULT_PROFILE. The default profile includes all the server and server group definitions on the configuration manager. As you define new servers and server groups, they are also associated with the default profile. For more information, see Creating the Default Profile on a Configuration Manager.
The tasks that might be involved include:
Example 1: You need a shorthand way to send commands to different groups of managed servers. You can define server groups. For example, you can define a server group named AMERICAS for the servers in the offices in North America and South America. See Defining a Server Group and Members of a Server Group for details.
Example 2: You want each managed server to back up its database and storage pools regularly. One way to do this is to set up TSM server scripts and schedules to automatically run these scripts everyday. You can do the following:
Example 3: You want clients to back up data to the default disk storage pool, BACKUPPOOL, on each server. But you want clients to archive data directly to the tape library attached to each server. You can do the following:
Note: | You must set up the storage pool itself (and associated device class) on each managed server, either locally or by using command routing. If a managed server already has a storage pool associated with the automated tape library, you can rename the pool to TAPEPOOL. |
Example 4: You want to ensure that client data is consistently backed up and managed on all servers. You want all clients to be able to store three backup versions of their files. You can do the following:
For example, you can define one profile named ALLOFFICES that points to all the configuration information (policy domain, administrators, scripts, and so on). You can also define profiles for each type of information, so that you have one profile that points to policy domains, and another profile that points to administrators, for example.
For details, see Creating and Changing Configuration Profiles.
Figure 57 shows the specific commands needed to set up one TSM server as a managed server. The following procedure gives you an overview of the steps required to set up a server as a managed server.
Figure 57. Setting Up a Managed Server
Setting up the managed server can be done by an administrator working at a central location, or by administrators working at the servers that will be managed servers.
A server becomes a managed server when that server first subscribes to a profile on a configuration manager.
See Getting Information about Profiles. Look for definitions of objects on the managed server that have the same name as those defined on the configuration manager. With some exceptions, these objects will be overwritten when the managed server first subscribes to the profile on the configuration manager. See Associating Configuration Information with a Profile for details on the exceptions.
If the managed server is a new server and you have not defined anything, the only objects you will find are the defaults (for example, the STANDARD policy domain).
A managed server can only subscribe to profiles on one configuration manager. See Subscribing to a Profile.
If you receive error messages during the configuration refresh, such as a local object that could not be replaced, resolve the conflict and refresh the configuration again. You can either wait for the automatic refresh period to be reached, or kick off a refresh by issuing the SET CONFIGREFRESH command, setting or resetting the interval.
You may receive warning messages about storage pools that do not exist, but that are needed for the active policy set. Define any storage pools needed by the active policy set, or rename existing storage pools. See Defining or Updating Primary Storage Pools or Renaming a Storage Pool.
Administrative schedules are not active when they are distributed by a configuration manager. The schedules do not run on the managed server until you make them active on the managed server. See Tailoring Schedules.
The initial setting for refreshing the configuration information is 60 minutes. See Refreshing Configuration Information.
Task | Required Privilege Class |
---|---|
Set up a server as a configuration manager | System |
To set up one TSM server as the source for configuration information for other servers, you identify the server as a configuration manager. A configuration manager can be an existing TSM server that already provides services to clients, or can be a server dedicated to just providing configuration information to other TSM servers.
Enter the following command:
set configmanager on
When a server becomes a configuration manager, the server automatically creates a default profile named DEFAULT_PROFILE. The default profile contains any definitions of servers and server groups that exist on the configuration manager. You can change or delete the profile named DEFAULT_PROFILE.
When a managed server first subscribes to a profile on a configuration manager, the configuration manager automatically also subscribes the managed server to the profile named DEFAULT_PROFILE, if it exists. The information distributed via this profile gets refreshed in the same way as other profiles. This helps ensure that all servers have a consistent set of server and server group definitions for all servers in the network.
If you do not change the DEFAULT_PROFILE, whenever a managed server subscribed to the DEFAULT_PROFILE profile refreshes configuration information, the managed server receives definitions for all servers and server groups that exist on the configuration manager at the time of the refresh. As servers and server groups are added, deleted, or changed on the configuration manager, the changed definitions are distributed to subscribing managed servers.
You create configuration profiles on a configuration manager, which distributes the information associated with the profiles to any managed server that subscribes to those profiles. Creating a configuration profile includes these steps:
Once you define the profile and its associations, a managed server can subscribe to the profile and obtain the configuration information.
After you define a profile and associate information with the profile, you can change the information later. While you make changes, you can lock the profiles to prevent managed servers from refreshing their configuration information. To distribute the changed information associated with a profile, you can unlock the profile, and either wait for each managed server to refresh its configuration to get the changed information or notify each managed server to refresh its configuration. The following sections provide information on each of these tasks.
Task | Required Privilege Class |
---|---|
Define profiles | System |
When you define the profile, you select the name and can include a description. For example, to define a profile named ALLOFFICES, enter the following command:
define profile alloffices description='Configuration to be used by all offices'
Task | Required Privilege Class |
---|---|
Define profile associations | System |
After you define a profile, you associate the configuration information that you want to distribute via that profile. You can associate the following configuration information with a profile:
Note: | Be careful if you are distributing definitions of administrators that have the same name as administrators already defined to managed servers. The configuration refresh overwrites the administrator definition and authority defined on the managed server. If the authority level of an administrator is less on the configuration manager than it was on the managed server, you could have problems with access to the managed server after distributing the administrator definition. |
The configuration manager does not distribute information about whether an administrator is locked (preventing access to the server).
The administrator with the name SERVER_CONSOLE is never distributed from the configuration manager to a managed server.
The DEFAULT_PROFILE that is automatically created on a configuration manager already points to all servers and server groups defined to that server. If you leave the DEFAULT_PROFILE intact, you do not need to include servers or server groups in any other profile. Any servers and server groups that you define later are associated automatically with the default profile and the configuration manager distributes the definitions at the next refresh.
For a server definition, the following attributes are distributed:
When server definitions are distributed, the attribute for allowing replacement is always set to YES. You can set other attributes, such as the server's node name, on the managed server by updating the server definition.
A managed server may already have a server defined with the same name as a server associated with the profile. The configuration refresh does not overwrite the local definition unless the managed server allows replacement of that definition. On a managed server, you allow a server definition to be replaced by updating the local definition. For example:
update server santiago allowreplace=yes
This safeguard prevents disruption of existing functions that require communication among servers (such as virtual volumes).
Table 17 summarizes what happens when servers or server groups being
distributed have the same names as servers or server groups on the managed
server.
Table 17. Results of Configuration Refresh with Duplicate Object Names
Local definition (on managed server) | Object with duplicate name to be distributed | Result of configuration refresh |
---|---|---|
Server | Server | The local server definition is replaced by the distributed server definition only if an administrator for the managed server updated the local definition to allow replacement. |
Server | Server group | The local server definition remains. The server group definition is not distributed. |
Server group | Server | The local server group is deleted. The server definition is distributed. |
Server group | Server group | The local server group definition is replaced by the distributed server group definition. |
When you point to a policy domain in a profile, the configuration information that will be sent to the managed servers includes the policy domain itself, and all policy sets with their associated management classes, copy groups, and client schedules in the domain. However, the ACTIVE policy set and its associated management classes, copy groups, and client schedules are not included.
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.
Associations between clients and schedules are not distributed with the configuration information. For clients in a managed policy domain to run client schedules, you must associate the clients with the schedules on the managed server.
A subscribing managed server may already have a policy domain with the same name as the domain associated with the profile. The configuration refresh overwrites the domain defined on the managed server unless client nodes are already assigned to the domain. Once the domain becomes a managed object on the managed server, you can associate clients with the managed domain. Future configuration refreshes can then update the managed domain.
If nodes are assigned to a domain with the same name as a domain being distributed, the domain is not replaced. This safeguard prevents inadvertent replacement of policy that could lead to loss of data. To replace an existing policy domain with a managed domain of the same name, you can do the following steps on the managed server:
When the configuration manager distributes administrative schedules, the schedules are not active on the managed server. An administrator on the managed server must activate any managed schedules to have them run on the managed server.
A configuration refresh does not replace or remove any local schedules that are active on a managed server. However, a refresh can update an active schedule that is already managed by a configuration manager.
Before you can associate specific configuration information with a profile, the definitions must exist on the configuration manager. For example, to associate a policy domain named ENGDOMAIN with a profile, you must have already defined the ENGDOMAIN policy domain on the configuration manager.
Suppose you want the ALLOFFICES profile to distribute policy information from the STANDARD and ENGDOMAIN policy domains on the configuration manager. Enter the following command:
define profassociation alloffices domains=standard,engdomain
You can make the association more dynamic by specifying the special character, * (asterisk), by itself. When you specify the *, you can associate all existing objects with a profile without specifically naming them. If you later add more objects of the same type, the new objects are automatically distributed via the profile. For example, suppose you want the ADMINISTRATORS profile to distribute all administrators registered to the configuration manager. Enter the following commands on the configuration manager:
define profile administrators description='Profile to distribute administrators IDs' define profassociation administrators admins=*
Whenever a managed server that is subscribed to the ADMINISTRATORS profile refreshes configuration information, it receives definitions for all administrators that exist on the configuration manager at the time of the refresh. As administrators are added, deleted, or changed on the configuration manager, the changed definitions are distributed to subscribing managed servers.
Task | Required Privilege Class |
---|---|
Define profile associations
Update profiles | System |
You can change a profile and its associated configuration information. For example, if you want to add a policy domain named FILESERVERS to objects already associated with the ALLOFFICES profile, enter the following command:
define profassociation alloffices domains=fileservers
You can also delete associated configuration information, which results in removal of configuration from the managed server. Use the DELETE PROFASSOCIATION command. See Removing Configuration Information from Managed Servers for details.
On a configuration manager, you cannot directly change the names of administrators, scripts, and server groups associated with a profile. To change the name of an administrator, script, or server group associated with a profile, delete the object then define it again with a new name and associate it with the profile again. During the next configuration refresh, each managed server makes the corresponding changes in their databases.
You can change the description of the profile. Enter the following command:
update profile alloffices description='Configuration for all offices with file servers'
If you are making changes to a profile, you may want to prevent any
subscribing managed server from refreshing its configuration information until
you are done. You can lock the profile to prevent access to the profile
by a managed server. Locking prevents a managed server from getting
information that is incomplete because you are still making
changes.
Task | Required Privilege Class |
---|---|
Lock and unlock profiles | System |
For example, to lock the ALLOFFICES profile for two hours (120 minutes), enter the following command:
lock profile alloffices 120
You can let the lock expire after two hours, or unlock the profile with the following command:
unlock profile alloffices
To distribute the changed profile, you can wait for each managed server to
refresh its configuration to get the changed information, or you can notify
each managed server from the configuration manager. Managed servers
refresh profile information on a configuration refresh period. See Refreshing Configuration Information for how to set this period.
Task | Required Privilege Class |
---|---|
Notify servers that subscribe to profiles to refresh configuration information | System |
From the configuration manager, to notify all servers that are subscribers to the ALLOFFICES profile, enter the following command:
notify subscribers profile=alloffices
The managed servers then refresh their configuration information, even if the time period for refreshing the configuration has not passed.
Task | Required Privilege Class |
---|---|
Delete profile associations | System |
To remove configuration information from managed servers, you can do one of two things: delete the association of the object with the profile, or delete the object itself from the configuration manager.
Note: | To remove all configuration information that is defined in the database of a managed server as a result of a profile subscription, you must delete the subscription using the option to discard all managed objects. See Deleting Subscriptions. |
On the configuration manager, you can delete the association of objects with a profile. For example, you may want to remove some of the administrators that are associated with the ADMINISTRATORS profile. With an earlier command, you had included all administrators defined on the configuration manager (by specifying ADMINS=*). To change the administrators included in the profile you must first delete the association of all administrators, then associate just the administrators that you want to include. Do the following:
lock profile administrators
delete profassociation administrators admins=* define profassociation administrators admins=admin1,admin2,admin3,admin4
unlock profile administrators
notify subscribers profile=administrators
When you delete the association of an object with a profile, the configuration manager no longer distributes that object via the profile. Any managed server subscribing to the profile deletes the object from its database when it next contacts the configuration manager to refresh configuration information. However, a managed server does not delete the following objects:
Also the managed server does not change the authority of an administrator if doing so would leave the managed server without any administrators having the system privilege class.
You can avoid both problems by ensuring that you have locally defined at least one administrator with system privilege on each managed server.
If you no longer need an object defined on the configuration manager itself or on any managed server, you can delete the object itself. Deleting the object itself from the configuration manager has an effect similar to deleting the association of that object with the profile: the configuration manager no longer distributes that object, and a managed server attempts to delete the object from its database when it refreshes configuration information.
Task | Required Privilege Class |
---|---|
Delete profiles | System |
You can delete a profile from a configuration manager. Before deleting a profile, you should ensure that no managed server still has a subscription to the profile. If the profile still has some subscribers, you should first delete the subscriptions on each managed server. When you delete subscriptions, consider whether you want the managed objects to be deleted on the managed server at the same time. For example, to delete the subscription to profile ALLOFFICES from managed server SANTIAGO without deleting the managed objects, log on to the SANTIAGO server and enter the following command:
delete subscription allofficesThen, on the configuration manager, enter the following command:
delete profile alloffices
See Deleting Subscriptions for more details about deleting subscriptions on a managed server.
Note: | You can use command routing to issue the DELETE SUBSCRIPTION command for all managed servers. |
If you try to delete a profile that still has subscriptions, the command fails unless you force the operation:
delete profile alloffices force=yes
If you do force the operation, managed servers that still subscribe to the deleted profile will later contact the configuration manager to try to get updates to the deleted profile. The managed servers will continue to do this until their subscriptions to the profile are deleted. A message will be issued on the managed server alerting the administrator of this condition.
Task | Required Privilege Class |
---|---|
Request information about profiles | Any administrator |
You can get information about configuration profiles defined on any configuration manager, as long as that server is defined to the server with which you are working. For example, from a configuration manager, you can display information about profiles defined on that server or on another configuration manager. From a managed server, you can display information about any profiles on the configuration manager to which the server subscribes. You can also get profile information from any other configuration manager defined to the managed server, even though the managed server does not subscribe to any of the profiles.
For example, to get information about all profiles on the HEADQUARTERS configuration manager when logged on to another server, enter the following command:
query profile server=headquarters
The following shows what the results might look like:
+--------------------------------------------------------------------------------+ |Configuration Profile name Locked? | |manager | |--------------- --------------- ------- | |HEADQUARTERS ADMINISTRATORS No | |HEADQUARTERS DEFAULT_PROFILE No | |HEADQUARTERS ENGINEERING No | |HEADQUARTERS MARKETING No | +--------------------------------------------------------------------------------+
You may need to get detailed information about profiles and the objects associated with them, especially before subscribing to a profile. You can get the names of the objects associated with a profile by entering the following command:
query profile server=headquarters format=detailed
The following shows what the results might look like:
+--------------------------------------------------------------------------------+ | Configuration manager: HEADQUARTERS | | Profile name: ADMINISTRATORS | | Locked?: No | | Description: | | Server administrators: ADMIN1 ADMIN2 ADMIN3 ADMIN4 | | Policy domains: | |Administrative command schedules: ** all objects ** | | Server Command Scripts: | | Client Option Sets: | | Servers: | | Server Groups: | | | | Configuration manager: HEADQUARTERS | | Profile name: DEFAULT_PROFILE | | Locked?: No | | Description: | | Server administrators: | | Policy domains: | |Administrative command schedules: | | Server Command Scripts: | | Client Option Sets: | | Servers: ** all objects ** | | Server Groups: ** all objects ** | | | | Configuration manager: HEADQUARTERS | | Profile name: ENGINEERING | | Locked?: No | | Description: | | Server administrators: | | Policy domains: ENGDOMAIN | |Administrative command schedules: | | Server Command Scripts: QUERYALL | | Client Option Sets: DESIGNER PROGRAMMER | | Servers: | | Server Groups: | | | | Configuration manager: HEADQUARTERS | | Profile name: MARKETING | | Locked?: Yes | | Description: | | Server administrators: | | Policy domains: MARKETDOM | |Administrative command schedules: | | Server Command Scripts: QUERYALL | | Client Option Sets: BASIC | | Servers: | | Server Groups: | +--------------------------------------------------------------------------------+
If the server from which you issue the query is already a managed server (subscribed to one or more profiles on the configuration manager being queried), by default the query returns profile information as it is known to the managed server. Therefore the information is accurate as of the last configuration refresh done by the managed server. You may want to ensure that you see the latest version of profiles as they currently exist on the configuration manager. Enter the following command:
query profile uselocal=no format=detailed
To get more than the names of the objects associated with a profile, you can do one of the following:
headquarters: query domain engdomain format=detailed
You can also route commands from the configuration manager to another server to get details about definitions that already exist.
Task | Required Privilege Class |
---|---|
Define subscriptions to profiles
Set the period for configuration refreshes | System |
After an administrator at a configuration manager has created profiles and associated objects with them, managed servers can subscribe to one or more of the profiles.
Notes:
Unless otherwise noted, the commands in this section would be run on a managed server:
After a managed server subscribes to a profile, the configuration manager sends the object definitions associated with the profile to the managed server where they are automatically stored in the database. Object definitions created this way in the database of a managed server are called managed objects. With a few exceptions, you cannot change managed objects on the managed server. The exceptions are that you can change:
Before a managed server subscribes to a profile, be aware that if you have defined any object with the same name and type as an object associated with the profile that you are subscribing to, those objects will be overwritten. You can check for such occurrences by querying the profile before subscribing to it.
When a managed server first subscribes to a profile on a configuration manager, it also automatically subscribes to DEFAULT_PROFILE, if a profile with this name is defined on the configuration manager. Unless DEFAULT_PROFILE is modified on the configuration manager, it contains all the server definitions and server groups defined on the configuration manager. In this way, all the servers in your network receive a consistent set of server and server group definitions.
Note: | Although a managed server can subscribe to more than one profile on a configuration manager, it cannot subscribe to profiles on more than one configuration manager at a time. |
Changes may be made to a profile, after a managed server subscribes to it. An administrator on the configuration manager can notify your server of a change by issuing the NOTIFY SUBSCRIBERS command. The configuration manager contacts each managed server having a subscription to one of the specified profiles. When a managed server is contacted, it begins refresh processing to get the configuration updates from the configuration manager.
This section describes a typical scenario in which a server subscribes to a profile on a configuration manager, HEADQUARTERS. In this scenario an administrator for the HEADQUARTERS server has defined three profiles, ADMINISTRATORS, ENGINEERING, and MARKETING, each with its own set of associations. In addition, DEFAULT_PROFILE was automatically defined and contains only the server and server group definitions defined on the HEADQUARTERS server. An administrator for HEADQUARTERS has given you the names of the profiles that you should be using. To subscribe to the ADMINISTRATORS and ENGINEERING profiles and keep them current, perform the following steps:
You might want to perform this step to see if the object names on the profiles are used on your server for any objects of the same type. Issue this command:
query profile * server=headquarters format=detailed
You might want to get detailed information on some of the objects by issuing specific query commands on either your server or the configuration manager.
Note: | If any object name matches and you subscribe to a profile containing an
object with the matching name, the object on your server will be replaced,
with the following exceptions:
|
After the initial subscription, you do not have to specify the server name on the DEFINE SUBSCRIPTION commands. If at least one profile subscription already exists, any additional subscriptions are automatically directed to the same configuration manager. Issue these commands:
define subscription administrators server=headquarters define subscription engineeringThe object definitions in these profiles are now stored on your database. In addition to ADMINISTRATORS and ENGINEERING, the server is also subscribed by default to DEFAULT_PROFILE. This means that all the server and server group definitions on HEADQUARTERS are now also stored in your database.
If you do not perform this step, your server checks for updates to the profiles at start up and every 60 minutes after that. Set up your server to check HEADQUARTERS for updates once a day (every 1440 minutes). If there is an update, HEADQUARTERS sends it to the managed server automatically when the server checks for updates.
set configrefresh 1440
Task | Required Privilege Class |
---|---|
Request information about subscriptions
Request information about profiles | Any administrator |
From time to time, you may want to see what profiles a server is subscribed to. You may also want to see the last time that the configuration associated with that profile was successfully refreshed on your server. The QUERY SUBSCRIPTION command gives you this information. You can name a specific profile or use a wildcard character to display all or a subset of profiles to which the server is subscribed. For example, the following command displays ADMINISTRATORS and any other profiles that begin with the string "ADMIN":
query subscription admin*
Here is a sample of the output:
+--------------------------------------------------------------------------------+ |Configuration Profile name Last update | |manager date/time | |--------------- --------------- -------------------- | |HEADQUARTERS ADMINISTRATORS 06/04/1998 17:51:49 | |HEADQUARTERS ADMINS_1 06/04/1998 17:51:49 | |HEADQUARTERS ADMINS_2 06/04/1998 17:51:49 | +--------------------------------------------------------------------------------+
To see what objects the ADMINISTRATORS profile contains, use the following command:
query profile administrators uselocal=no format=detailed
You will see output similar to the following:
+--------------------------------------------------------------------------------+ | Configuration manager: HEADQUARTERS | | Profile name: ADMINISTRATORS | | Locked?: No | | Description: | | Server administrators: ADMIN1 ADMIN2 ADMIN3 ADMIN4 | | Policy domains: | |Administrative command schedules: ** all objects ** | | Server Command Scripts: | | Client Option Sets: | | Servers: | | Server Groups: | +--------------------------------------------------------------------------------+
Managed objects are stored in the database of a managed server as a result of subscriptions to profiles on a configuration manager. Any object that was created or updated in the database of the managed server as a result of a subscription has the string $$CONFIG_MANAGER$$ in place of the name of the administrator who last changed the object. For example, if the policy domain named ENGDOMAIN is a managed object and you enter this command on the managed server:
query domain engdomain format=detailedYou will see output similar to the following:
+--------------------------------------------------------------------------------+ | Policy Domain Name: ENGDOMAIN | | Activated Policy Set: | | Activation Date/Time: | | Days Since Activation: | | Activated Default Mgmt Class: | | Number of Registered Nodes: 0 | | Description: Policy for design and software engineers | | Backup Retention (Grace Period): 30 | |Archive Retention (Grace Period): 365 | | Last Update by (administrator): $$CONFIG_MANAGER$$ | | Last Update Date/Time: 06/04/1998 17:51:49 | | Managing profile: ENGINEERING | +--------------------------------------------------------------------------------+
The field Managing profile shows the profile to which the managed server subscribes to get the definition of this object.
Task | Required Privilege Class |
---|---|
Delete subscriptions to profiles | System |
If you decide that a server no longer needs to subscribe to a profile, you can delete the subscription. When you delete a subscription to a profile, you can choose to discard the objects that came with the profile or keep them in your database. For example, to request that your subscription to PROFILEC be deleted and to keep the objects that came with that profile, issue the following command:
delete subscription profilec discardobjects=no
After the subscription is deleted on the managed server, the managed server issues a configuration refresh request to inform the configuration manager that the subscription is deleted. The configuration manager updates its database with the new information.
When you choose to delete objects when deleting the subscription, the server may not be able to delete some objects. For example, the server cannot delete a managed policy domain if the domain still has client nodes registered to it. The server skips objects it cannot delete, but does not delete the subscription itself. If you take no action after an unsuccessful subscription deletion, at the next configuration refresh the configuration manager will again send all the objects associated with the subscription. To successfully delete the subscription, do one of the following:
Task | Required Privilege Class |
---|---|
Set the period for configuration refreshes | System (on the managed server) |
Notify servers that subscribe to profiles to refresh configuration information | System (on the configuration manager) |
On a configuration manager, an administrator can make changes to configuration information that is associated with a profile. How quickly the changes get distributed to a subscribing managed server depends on the configuration refresh period set on the managed server and whether the administrator on the configuration manager sent a notification.
By default, a managed server refreshes its configuration information every 60 minutes. To cause an immediate refresh, change this period. For example, to immediately refresh the configuration and change the frequency of future refreshes to once a day, enter the following command for the managed server:
set configrefresh 1440
By issuing this command with a value greater than zero, you cause the managed server to immediately start the refresh process.
At the configuration manager, you can cause managed servers to refresh their configuration information by notifying the servers. For example, to notify subscribers to all profiles, enter the following command:
notify subscribers profile=*
The managed servers then start to refresh configuration information to which they are subscribed through profiles.
A managed server automatically refreshes configuration information when it is restarted.
To monitor for any problems during a configuration refresh, you can watch the server console or activity log of the managed server. One problem that may occur is that the refresh process may skip objects. For example, a policy domain of the same name as an existing policy domain on the managed server is not distributed if the policy domain has client nodes assigned to it. See Associating Configuration Information with a Profile for details on when objects cannot be distributed.
The configuration manager sends the objects that it can distribute to the managed server. The configuration manager skips (does not send) objects that conflict with local objects. If the configuration manager cannot send all objects that are associated with the profile, the managed server does not record the configuration refresh as complete. The objects that the configuration manager successfully sent are left as local instead of managed objects in the database of the managed server. The local objects left as a result of an unsuccessful configuration refresh become managed objects at the next successful configuration refresh of the same profile subscription.
You may want to return one or more managed objects (objects distributed by a configuration manager via profiles) to local control on the managed servers. You can do this from the configuration manager or from the managed servers.
To do this from the configuration manager, you do not simply delete the association of the object from the profile, because that would cause the object to be deleted from subscribing managed servers. To ensure the object remains in the databases of the managed servers as a locally managed object, you can copy the current profile, make the deletion, and change the subscriptions of the managed servers to the new profile.
For example, servers are currently subscribed to the ENGINEERING profile. The ENGDOMAIN policy domain is associated with this profile. You want to return control of the ENGDOMAIN policy domain to the managed servers. You can do the following:
copy profile engineering engineering_b
delete profassociation engineering_b domains=engdomain
americas,europe,asia: delete subscription engineering discardobjects=no
delete profile engineering
americas,europe,asia: define subscription engineering_b
To return objects to local control when working on a managed server, you can delete the subscription to one or more profiles. When you delete a subscription, you can choose whether to delete the objects associated with the profile. To return objects to local control, you do not delete the objects. For example, use the following command on a managed server:
delete subscription engineering discardobjects=no
Include in your profiles any administrators that you want to give access to all servers in the network. These administrators must then maintain their passwords on the configuration manager. To ensure passwords stay valid for as long as expected on all servers, set the password expiration period to the same time on all servers. One way to do this is to route a SET PASSEXP command from one server to all of the others.
Ensure that you have at least one administrator that is defined locally on each managed server with system authority. This avoids an error on configuration refresh when all administrators for a server would be removed as a result of a change to a profile on the configuration manager.
In rare situations, when a managed server contacts a configuration manager to refresh configuration information, the configuration manager may determine that the profile information on the two servers is not synchronized. It may appear that the configuration information is more recent on the managed server than on the configuration manager. This could occur in the following situations:
If the configuration manager still has a record of the managed server's subscription to the profile, the configuration manager does not send its profile information at the next request for refreshed configuration information. The configuration manager informs the managed server that the profiles are not synchronized. The managed server then issues a message indicating this condition so that an administrator can take appropriate action. The administrator can perform the following steps:
It is possible that the configuration manager may not have a record of the managed server's subscription. In this case, no action is necessary. When the managed server requests a refresh of configuration information, the configuration manager sends current profile information and the managed server updates its database with that information.
To switch a managed server from one configuration manager to another, perform the following steps:
Verify that all subscriptions have been deleted by querying subscriptions.
Under normal circumstances, you do not need to delete subscribers from a configuration manager. You only need to delete a subscription to a profile on the managed server (by using the DELETE SUBSCRIPTION command). When you issue the DELETE SUBSCRIPTION command, the managed server automatically notifies the configuration manager of the deletion by refreshing its configuration information. As part of the refresh process, the configuration manager is informed of the profiles that the managed server subscribes to (and does not subscribe to). If the configuration manager cannot be contacted immediately for a refresh, the configuration manager will find out that the subscription was deleted the next time the managed server refreshes configuration information.
Deleting subscribers from a configuration manager is only necessary as a way to clean up in certain unusual situations. For example, you may need to delete subscribers if a managed server goes away completely or deletes its last subscription without being able to notify the configuration manager. You then use the DELETE SUBSCRIBER command to delete all subscriptions for that subscriber (the managed server) from the configuration manager's database.
To rename a managed server, perform the following steps: