Using InterSystems Enterprise Manager

Transcription

1 Using InterSystems Enterprise Manager Version January 2016 *** DRAFT *** InterSystems Corporation 1 Memorial Drive Cambridge MA

2 Using InterSystems Enterprise Manager InterSystems Version January 2016 *** DRAFT *** Copyright 2016 InterSystems Corporation All rights reserved.,,,, Caché WEBLINK, and Distributed Cache Protocol are registered trademarks of InterSystems Corporation.,, InterSystems Jalapeño Technology, Enterprise Cache Protocol, ECP, and InterSystems Zen are trademarks of InterSystems Corporation. All other brand or product names used herein are trademarks or registered trademarks of their respective companies or organizations. This document contains trade secret and confidential information which is the property of InterSystems Corporation, One Memorial Drive, Cambridge, MA 02142, or its affiliates, and is furnished for the sole purpose of the operation and maintenance of the products of InterSystems Corporation. No part of this publication is to be used for any other purpose, and this publication is not to be reproduced, copied, disclosed, transmitted, stored in a retrieval system or translated into any human or computer language, in any form, by any means, in whole or in part, without the express prior written consent of InterSystems Corporation. The copying, use and disposition of this document and the software programs described herein is prohibited except to the limited extent set forth in the standard software license agreement(s) of InterSystems Corporation covering such programs and related documentation. InterSystems Corporation makes no representations and warranties concerning such software programs other than those set forth in such standard software license agreement(s). In addition, the liability of InterSystems Corporation for any losses or damages relating to or arising out of the use of such software programs is limited in the manner set forth in such standard software license agreement(s). THE FOREGOING IS A GENERAL SUMMARY OF THE RESTRICTIONS AND LIMITATIONS IMPOSED BY INTERSYSTEMS CORPORATION ON THE USE OF, AND LIABILITY ARISING FROM, ITS COMPUTER SOFTWARE. FOR COMPLETE INFORMATION REFERENCE SHOULD BE MADE TO THE STANDARD SOFTWARE LICENSE AGREEMENT(S) OF INTERSYSTEMS CORPORATION, COPIES OF WHICH WILL BE MADE AVAILABLE UPON REQUEST. InterSystems Corporation disclaims responsibility for errors which may appear in this document, and it reserves the right, in its sole discretion and without notice, to make substitutions and modifications in the products and practices described in this document. For Support questions about any InterSystems products, contact: InterSystems Worldwide Customer Support Tel: Fax: support@intersystems.com

3 Table of Contents About This Book Introducing Enterprise Manager How Enterprise Manager Works About Services About Groups and Instances About Activating Service Changes in a Group About Master Groups and Subgroups About Assigning Instances to Groups About Organizing Enterprise Manager Enterprise Manager Activities About Enterprise Manager Security Using the Enterprise Manager Portal Enterprise Manager Remote API Working with Groups Creating, Modifying, and Deleting Groups Creating a Group Viewing and Modifying a Group Subscribing to and Unsubscribing from a Master Group Deleting a Group Managing a Group s Services Fundamentals of Managing Services Modifying a Group s Service Settings Using the Configuration Service Using the Namespace Service Using Variable Substitution in the Configuration and Namespace Services Synchronized Activation of Namespace Service Changes Using the License Service Using the Security Service Using the Users Service Using the Monitor Service Using the Distributed SQL Security Service Modifying SQL Privileges on Managed Instances Using the Distributed SQL Security API Managing the Distributed SQL Security Queue Creating and Managing Mirror Groups Managing Namespace Groups for a Mirror Creating a Mirror Using a Mirror Group Assigning an Existing Mirror to a Mirror Group Managing Mirrored Databases Modifying a Managed Mirror Modifying a Managed Mirror Outside of Enterprise Manager Deleting a Mirror Group Managing Instances Accepting a Management Request Suspending Management of an Instance Resuming Management of an Instance Using InterSystems Enterprise Manager iii

4 3.4 Removing an Instance from Management Assigning an Instance to a Group Managing Instance Overrides Viewing, Creating, Modifying, and Removing Instance Overrides Settings That Support Instance Overrides Moving an Instance from One Group to Another Removing an Instance from a Group Monitoring Managed Instances Instance and Group Management Pages The All Instances Page The Instance Details Page The Assign Instance to a Group Wizard The Resume Management for Instance Dialog The Action Details Page The Instance Overrides Page The Monitor Page The All Groups Page The Group Details Page The Service Details Page The Mirror Details Page The SQL Security Message Queue Page The Viewing Changes for Service in Group Dialog The Activate Multiple Groups Dialog The Activation Details Page The Variable Substitution Page The Service History Page The Create New Group Dialog The Management Requests Page The Notifications Page The Send a Notification Page Enterprise Manager System Management Enterprise Manager System Management Pages Working with Enterprise Manager Users About Enterprise Manager Users Creating an Enterprise Manager User Editing an Enterprise Manager User s Group-independent Privileges Assigning, Modifying, or Removing a User s Group-specific Privileges Deleting an Enterprise Manager User The Enterprise Manager Users Page Managing Auditing Auditing Basics Supported Audit Events Viewing the Audit Database Exporting the Audit Log Purging the Audit Log Managing Security Managing Enterprise Manager s X.509 Credentials Managing Enterprise Manager s SSL/TLS Configurations Reviewing the Security Policy and Resetting Enterprise Manager s Credentials Security Access Settings iv Using InterSystems Enterprise Manager

5 5.4.5 Choosing an Enterprise Manager Remote API Security Policy Managing Licensing Working with the Enterprise Manager Log Viewing and Searching the Enterprise Manager Log Configuring the Enterprise Manager Log Viewing Background Tasks Managing Application Settings Managing Web Service Timeout Settings Managing Journal Settings Using the Task Manager Working with Notifications Viewing System Information Enterprise Manager Command Line System Management Enabling and Opening the Enterprise Manager Command Line Enterprise Manager Backup, Restore and Recovery Enterprise Manager Server Migration Mirroring Enterprise Manager Appendix A: Initial Enterprise Manager Activities A.1 Installing Enterprise Manager A.1.1 Installation Background and Details A.1.2 Installing Enterprise Manager on Windows A.1.3 Installing Enterprise Manager on UNIX and Linux A.2 Preparing for Enterprise Manager Security A.3 Starting Enterprise Manager A.4 Choosing a Security Policy A.4.1 Configuring the WS-Security Security Policy A.4.2 Configuring the SSL/TLS Security Policy A.4.3 Unsecured A.5 The Enterprise Manager Home Page A.6 Logging Out and Changing Users A.7 Stopping Enterprise Manager Appendix B: Enterprise Manager Tasks in the Caché Management Portal B.1 Applying to Be Managed by Enterprise Manager B.2 Suspending Management B.3 Resuming Management B.4 Removing the Instance from Management B.5 Resetting Instance Credentials and Reapplying for Management B.6 Viewing and Sending Notifications Appendix C: Enterprise Manager Remote API C.1 Enterprise Manager Remote API Session Methods C.1.1 Managing Remote API Sessions C.1.2 Managing Instances C.1.3 Managing Groups C.1.4 Assigning Instances to Groups C.1.5 Managing Services C.1.6 Managing Enterprise Manager Users C.2 Enterprise Manager Remote API Object Classes Using InterSystems Enterprise Manager v

6 List of Tables Table 5 1: Enterprise Manager Audit Events vi Using InterSystems Enterprise Manager

7 About This Book This book explains how to use InterSystems Enterprise Manager. It contains the following chapters and appendices: Introducing Enterprise Manager Working with Groups Managing Instances Instance and Group Management Pages Enterprise Manager System Management Initial Enterprise Manager Activities Enterprise Manager Tasks in the Caché Management Portal Enterprise Manager Remote API There is also a detailed table of contents. The following books provide related information: Caché System Administration Guide Caché Security Administration Guide Caché Parameter File Reference For general information, see Using InterSystems Documentation. Using InterSystems Enterprise Manager 1

8

9 1 Introducing Enterprise Manager InterSystems Enterprise Manager is a powerful application that provides customers with tools to centrally manage Caché and Ensemble instances within an enterprise. Enterprise Manager eliminates the need for administrators to go to each machine to specify many settings related to standardized security configurations, user definitions, licensing, and namespaces and databases. Enterprise Manager allows administrators to control who can make changes to groups and their instances, to undo changes, and to compare or review changes that have been made. This is complemented by support for detailed auditing both on Enterprise Manager for all changes and on the instances for instance changes. Enterprise Manager is a free, stand-alone, secure application. After an instance of an InterSystems product has registered with Enterprise Manager, all communications between Enterprise Manager and the now managed instance are authenticated and encrypted (using SSL/TLS or SOAP message security). Because of Enterprise Manager s security requirements, it supports only those features that aid in system management itself and optionally acts as an enterprise license server. Although Enterprise Manager supports database and application management for its managed instances, it does not support creation or management of databases for its own use, nor does it run applications. This is by design; Enterprise Manager stands at a level above database or application servers, controlling how they are configured and, thereby, what they can do and how they interact. Topics in this chapter include: How Enterprise Manager Works About Services About Groups and Instances Enterprise Manager Activities About Enterprise Manager Security Using the Enterprise Manager Portal Enterprise Manager Remote API Important: For instructions on installing and configuring Enterprise Manager, see the appendix Initial Enterprise Manager Activities. 1.1 How Enterprise Manager Works Enterprise Manager controls a variety of settings for the Caché and Ensemble instances it manages, called managed instances, through collections of related settings called services. All of these settings can be applied to an individual unmanaged Using InterSystems Enterprise Manager 3

10 Introducing Enterprise Manager instance using its Caché or Ensemble management portal, and the Enterprise Manager pages used to apply them to managed instances are very similar or identical to those in the management portals. By collecting instances into groups, Enterprise Manager lets you apply the settings in a service to all of the instances in a group simultaneously. But a managed instance may not get all of its settings from a single group. Because different groups can control different combinations of services and instances can be placed in multiple groups, different settings on an instance may come from different groups, and the instance may share its settings with multiple collections of instances, depending on the service involved. In addition, individual instances can override some of the settings specified by the group or groups they belong to. An activation group combines one or more of the services that apply settings uniformly to any instance assigned to the group. Changes made to a service in an activation group are applied to instances through a step by step process called the activation cycle. For example, the Configuration service lets you change Memory and Startup as well as Journal settings on instances assigned to a group, among others. Some services that are managed by activation groups do not apply settings to the instances assigned to them, but instead group the instances for other purposes. For example, the Distributed SQL Security service lets you make SQL security updates on one instance in a group and then propagate them to the other instances in the group. A structural group manages a service that configures and manages a relationship among instances existing outside Enterprise Manager. For example, a mirror group manages only the Mirror service, which configures and manages managed instances as the members of a Caché mirror, with each mirror group representing a single mirror. Structural groups represent an exception to the many-to-many relationship between groups, services and instances, because they manage only a single service, which cannot be added to an activation group and combined with other services. Enterprise Manager also allows activation groups to subscribe to master groups, which can be used to apply selected settings in a service to multiple subgroups, leaving other settings to be determined at the subgroup or instance level. This combination of services, groups, and master groups allows great flexibility in configuring and maintaining a wide variety of instances across an enterprise. All of the settings in a given service, or individual settings within a service, can be uniform across an entire enterprise, unique for each instance, or specific to a group of instances or to multiple groups of instances whatever suits the situation best. The architecture can be as elaborated and the granularity as fine as is required. Enterprise Manager also allows you to monitor the system health of all of the instances it manages. The Monitoring service can be included in any activation group with other services, but can also used on its own to let you group managed instances for monitoring purposes even if those instances are not grouped for other services. 1.2 About Services Instance settings are grouped into services so they can easily be applied in conformance with common principles of configuration. For example, an enterprise or site may have entirely standardized security and user settings applied through a single group containing all managed instances, so that all users have identical privileges on all instances, while different namespace and database configurations, memory and startup settings, and license keys are applied to various overlapping sets of instances using multiple groups. Additionally, instances can be grouped as members of a Caché mirror independently from the services that manage settings, and for monitoring and SQL security update purposes either independently from or along with other services. The services and their settings are described in the following. For more detailed descriptions of these services, see Managing a Group s Services, Using the Monitor Service, Using the Distributed SQL Security Service, and Creating and Managing a Mirror Group in the chapter Working with Groups. Configuration Service Settings controlled by the Configuration service include: 4 Using InterSystems Enterprise Manager

11 About Services Journal settings Memory and startup, advanced memory, compatibility settings SQL and object settings Device settings Cluster settings Locale definitions License Settings The License service manages the license key in use and maintains license servers as needed. Namespace Service The settings controlled by the Namespace service include: Namespace settings Local database settings Remote database settings ECP settings Shadow server settings Security Service The settings controlled by the Security service include: Roles Resources Security services Web and privileged routine applications System-wide security settings and authentication options Auditing Users Service The settings controlled by the Users service include: Users System-wide security settings LDAP options Security domains Mobile phones Monitor Service The Monitor service does not control any settings, instead grouping managed instances for monitoring purposes. The Monitor service can be combined with other services in an activation group; a group managing the Monitor service is called a monitor group, although it may be an activation group as well. Using InterSystems Enterprise Manager 5

12 Introducing Enterprise Manager Distributed SQL Security The Distributed SQL Security service does not control any settings, but rather allows SQL security modifications made on one instance to be propagated to other instances belonging to the same group. The Distributed SQL Security service can be combined with other services in an activation group, or it can be the only service managed by a group. Mirror Service The Mirror service configures and manages the instances assigned to it as members of a Caché mirror by controlling mirror settings. The Mirror service cannot be combined in a group with any other service; a group managing the Mirror service is called a mirror group. 1.3 About Groups and Instances An Enterprise Manager group consists of the settings for one or more services and the instances to which these settings are applied. Instances managed by Enterprise Manager are organized into groups on the basis of common configuration or management needs for example, they may all be in the same location or on the same network, have similar hardware configurations, use the same version of a particular operating system, or have a common purpose within an organization or to reflect a relationship outside Enterprise Manager, as in the case of mirror groups. Each Enterprise Manager activation group manages one or more of the Configuration, Namespace, License, Security, User, Distributed SQL Security, and Monitor services, and every instance in the group receives the same values for all settings within the service(s) managed by the group. (The Distributed SQL Security and Monitor services do not have settings.) For example, when you edit the Namespace service in a group and create a new local database, the database is created on every instance managed by the group; when you edit the License service in a group and activate a new license, the new license is activated for all instances in the group. A mirror group manages only the Mirror service, but when you change a managed mirror s settings by editing the mirror group, the changes are applied to all members of the mirror in a similar fashion. Each managed instance can be assigned to one group only for each service; if an instance is assigned to a group, it is managed by that group for all services controlled by the group. This determines which combinations of groups an instance can be assigned to. For example, if group A manages the Configuration, Namespace, and Monitor services and group B manages the License, Security, and Users services, an instance can belong to both of these groups, but no others, as between groups A and B all of its services are covered. If groups C through H control one service each, on the other hand, the instance can alternatively belong to all six of these groups, or it can belong to group A or B for three services and three other groups for the other three services. An instance need not be assigned to groups managing all possible services; if your central configuration needs extend only to the Security, Users, and License services, for instance, along with the Monitor service for monitoring purposes, you may not even have any groups controlling the Configuration, Namespace, Distributed SQL Security, or Mirror services. The following topics provide further information About Activating Service Changes in a Group About Master Groups and Subgroups About Assigning Instances to Groups About Organizing Enterprise Manager See the chapter Working with Groups for procedures for using Enterprise Manager to, populate, create, and manage groups. 6 Using InterSystems Enterprise Manager

13 About Groups and Instances About Activating Service Changes in a Group Changes to the settings of the Configuration, License, Namespace and Security services settings within a group are applied to the instances managed by that group through a step by step process called the activation cycle, which allows for full review of changes, potentially by several different users, before they are applied. A user s privileges may allow her to apply one or more of the steps in the cycle to all groups, or only to a specific group or groups (see Editing an Enterprise Manager User s Group-independent Privileges and Assigning, Modifying, or Removing a User s Group-specific Privileges in the Enterprise Manager System Management chapter for more information). The activation cycle proceeds as follows: 1. The edit state of a service within a group is Available. This means it can be edited by any user with the required privileges. 2. A user with the Edit privilege for the Enterprise Manager instance or for the group starts editing the service within the group and the service s edit state becomes Edit. 3. The user editing the service makes one or more changes. 4. The user editing the service submits the changes. (She can also discard them, returning the service to Available, or transfer control of the Edit step to another user). The service s edit state is now Submitted. 5. A user with the Approve privilege for Enterprise Manager or the group approves the changes. (She can also discard them, returning the service to Available, or return the service to Edit, reversing the submission.) The service s edit state is now Approved. 6. A user with the Activate privilege for Enterprise Manager or the group activates the changes. (She can also discard them, returning the service to Available, or return the service to Edit, reversing the submission and approval.) The changes are applied to the instances managed by the group, and the service s edit state returns to Available. There are some exceptions to this process: the Users and Mirror services require only editing and activation, while the activation cycle does not apply to the Monitor and Distributed SQL Security services at all, as they have no settings to modify or activate (although the latter does have a message queue to control). It is important to remember that while different services controlled by a group can be in different edit states, only one user can edit a given service within a group at one time, and that changes from the editing step can be discarded, or returned to edit for further modification, up until their activation. See Modifying a Group s Service Settings in the Working with Groups chapter for more detailed information about the activation cycle About Master Groups and Subgroups An important feature of Enterprise Manager is the ability for an activation group to subscribe one or more of its services to a master group, which can provide service settings to multiple subgroups. A subgroup subscribes to a master group for all the services that both groups control, and only for those services. A group can manage instances or subgroups, but not both. Once the first instance is assigned to an empty group, it becomes an assigned group and subgroups cannot subscribe to it; likewise, once the first subgroup subscribes to an empty group, in becomes a subscribed group and instances can no longer be assigned to it. A group managing any of the Monitor, Distributed SQL Security, or User services cannot act as a master group, and these services cannot subscribe to a master group, although other services managed by the same group can. For example, a group managing the License, Security, and Users services can subscribe to a master group managing (possibly among others) the License service, the Security service, or both, but not to any group managing the Users service, regardless of the other services it manages. A mirror group cannot subscribe to a master group. Each service in a subgroup can subscribe to only one master group, but multiple subgroup services can subscribe to a single master group. For example, one subgroup may have four master groups, one for each service, while another has just one master group for all of its services and a third has one for the Configuration and Namespace services, another for the Security service, and none for the License service. There are only two levels in the master/subgroup hierarchy; a group to which at least one other group is subscribed cannot itself subscribe to another group. Using InterSystems Enterprise Manager 7

14 Introducing Enterprise Manager When a group is subscribed to a master group and there are differences between the two, or when changes are activated in a master group, the differing or changed master group settings are automatically introduced into the activation cycle in all subgroups that subscribe to the master group. When you display or begin editing an affected service in the subgroup, you are informed that there are unactivated master group changes, and these become outstanding changes ready for the submission step (along with whatever other changes you make in that editing session). At that point you can submit, approve, and activate the changes to make the settings in the subgroup, and all of the subgroup s instances, identical to those in the master group. (You can never edit a given service in one member of a master/subgroup pair unless it is available in the other.) Until you submit changes received from a master group, they will always be considered pending in the subgroup. But you can modify one or more of the settings involved before submitting the changes. This establishes a subgroup override for those settings, and you are warned of this when modifying the settings. Subgroup overrides are of two types: If the setting involved occurs just once per instance the ECP settings in the Namespace service, for example, or the memory settings in the Configuration service the entire page on which the setting occurs (and in some cases more than one page) displays a notice when editing the subgroup service that a subgroup override is in place, as well as a link letting you remove it. For instance, if you change ECP settings in the master group and then change one of those settings again before activating the changes in a subgroup, when you next edit the Namespace service in the subgroup, the ECP Settings page includes the notice and link; if you click the link, the setting you changed in the subgroup is returned to the master group value and the override notice is removed. For this type of setting, if there are no subgroup overrides on a page, a notice on the page alerts you when you are editing that the settings are inherited from the master group and that changing any of them will create a subgroup override. If the setting involved is for a new occurrence of a type of object that can occur multiple times per instance for example, a namespace or database in the Namespace service, a device or device type in the Configuration service, or a role in the Security service the subgroup override notice is added only to the edit page for that object. For example, if you change the default routines database for a new namespace inherited from the master group before activating it on the subgroup, the subgroup notice does not appear on the Namespaces page, but only on the Edit Namespace page for that namespace. With this type of override, as an alternative to clicking the override notice, you can simply delete the object (such as the namespace in the previous example) with the override in the subgroup, which removes not the actual object but the subgroup version of it; the object remains, but with all settings as inherited from the master group. Both types of subgroup override also happen when you change subgroup settings originally received from the master group, or when changes are made in the master group to settings that were not originally inherited by the subgroup from the master group. For example, suppose a subgroup has values for all settings in the Configuration service, and you then subscribe this service to a master group. In the master group, you do the following: On the Memory and Startup page, change the Maximum Per-Process Memory setting. On the Devices page, create the device TERM. On the Device Subtypes page, create the subtype legacy. When you edit the Configuration service in the subgroup, you will see the following results: A notice indicates that there are Configuration service changes from the master that have not yet been activated. On the Device Subtypes page, because the subtype legacy did not already exist in the subgroup, it has been added to the service as a change to the service; this is the unactivated change indicated by the notice On the Devices page, because the device TERM already existed in the subgroup and was not inherited from the master group, a subgroup override was created, and the properties of TERM are unchanged, regardless of what they are in the master group; the override notice appears on the Edit Device page for Term only, and not on the Devices page itself. 8 Using InterSystems Enterprise Manager

15 About Groups and Instances On the Memory and Startup page, because there is only one Maximum Per-Process Memory setting per instance and the subgroup value did not come from the master group, the subgroup override notice and link are displayed. If you click the link to accept the Maximum Per-Process Memory change from the master group, this item is included in the pending changes for the Configuration service. In the Configuration and Namespace services, variable substitution lets you vary the value of a setting inherited from a master group across subgroups or vary the value of a group setting across instances managed by the group; see Using Variable Substitution in the Configuration and Namespace Services in the chapter Working with Groups for more information About Assigning Instances to Groups When a populated group is created by selecting an instance and creating a new group during the assignment process, or when the first instance is assigned to an unpopulated group in which you have not yet changed any settings, all settings in the services controlled by the group are taken from that instance; they can then be modified as desired. (Because the Monitor and Distributed SQL Security services do not control settings, if they are the only services managed by a group, the assignment of the first instance does not affect the group.) When subsequent instances are assigned to the group, they generally inherit the settings of the group. However, it is possible for an instance to have a different value for a setting than the group it belongs to, this is called an instance override. Instance overrides are possible only for a specific list of settings in each service; for example, on the Journal Settings page in the Configuration service, they are allowed for the current and alternate journal directories and the journal prefix, but not for the other settings. After an instance is assigned to a group, you can always review the overridable settings for the services the group manages and change the instance from the group value to an instance value, creating an instance override, or from an instance value back to a group value, removing the override. While an instance override exists on a setting, changes to the group value do not affect the instance value. (See Assigning an Instance to a Group in the chapter Managing Instances for procedures for assigning instances; see Managing Instance Overrides in that chapter for details about instance overrides.) Generally, when the first instance is assigned to a group, no instance overrides are added and no changes are made to nonoverridable settings, since the group takes all its values from the instance. When the second and subsequent instances are added to a group, differences between the instance s settings and the group s settings are handled as follows: For nonoverridable settings, the value on the instance is changed to the group value, and you are informed of this during activation. Because these may involve significant changes to the instance s configuration, particularly in the case of databases and namespaces, you have a chance to review these changes before making them permanent. For overridable settings, instance overrides are automatically and silently created. A special case of assigning the first instance, however, is when the group it is assigned to is subscribed to a master group. When this is the case, handling of differences between the instance s settings and subgroup settings not inherited from the master group is the same, but handling of differences between instance settings and settings inherited from the master group is as follows: If one or more nonoverridable settings is affected, you are given the option of establishing all of the instance values as subgroup overrides. If you choose this option, each affected subgroup setting is set to the instance value, overriding the master group value; this is true for overridable settings as well as nonoverridable settings. If you do not choose the option, nonoverridable settings are changed to the subgroup value inherited from the master group, and instance overrides are silently established for overridable settings. When only overridable settings are involved, instance overrides are automatically and silently created; there is no subgroup override option. Using InterSystems Enterprise Manager 9

16 Introducing Enterprise Manager This handling described is the same whether or not the settings in the master group have been activated as changes on the subgroup. If the master group settings have not been activated, once first instance assignment is complete, they will be activated and no longer pending. Mirror groups represent another special case. When you create a mirror group by assigning an instance that is a member of an existing but unmanaged mirror to an empty mirror group, not only does the mirror group take its settings from the instance, but Enterprise Manager automatically includes all other managed instances that are members of that mirror in the mirror group. On the other hand, if the first instance you assign to a mirror group is not a mirror member, the Assign Instance to a Group wizard requires you to create a mirror, of which the instance will become the first failover member, before completing the assignment. Because of the way in which Enterprise Manager takes values from the first assigned instance for all settings in a group, if you attempt to assign the first instance to a group in which you have manually populated some group settings, but not enough to define a viable instance, assignment is refused. (An exception is defining variables using the Variable Substitution option in the Configuration and Namespace services; even with variables manually defined, a group is still considered entirely unpopulated.) In practice, this means that you can assign an instance only to A group in which you have not populated any group settings. A group to which at least one instance has already been assigned (whether or not that instance is still assigned to the group), thereby populating all group settings. A group that is subscribed to a master group and inherits some settings from it, as these are not considered populated group settings. (If the group is removed from the master group, however, these settings become group settings and first instance assignment is refused unless enough settings are populated to define a viable instance.) While you can make changes to the settings of an empty mirror group, these changes are ignored when you assign the first instance to the group, whether that instance is an existing mirror member or not. See Assigning an Instance to a Group in the chapter Managing Instances for further restrictions on how instances can be assigned to groups About Organizing Enterprise Manager Given all of the foregoing, the following three general approaches to creating relationships between master groups, subgroups, and instances can be useful alone or in combination as needed to create the set of populated groups, or hierarchy of master groups and populated subgroups, that fulfills your enterprise configuration needs. Populate group settings from an instance. 1. Create a group. 2. Assign an instance to the group to create group settings for the services it manages. 3. Change the group settings as desired. 4. Add further instances, managing instance overrides as needed. In some cases you may want to configure an instance to use as a template, assign it to a group to create group settings, then remove the instance from the group. Populate subgroup settings from a master group that was populated from an instance. 1. Create a master group. 2. Assign an instance to the master group to create group settings for the services it manages, then remove the instance. 3. Change the master group settings as desired. 10 Using InterSystems Enterprise Manager

17 Enterprise Manager Activities 4. Create a subgroup and subscribe it to the master group, editing the relevant service(s) to activate settings from the master group as subgroup settings. 5. Create subgroup overrides as desired. 6. Add instances to the subgroup, managing instance overrides as needed. In some cases you may want to use the master group as a template only, unsubscribing the subgroup after activating the changes from the master. Populate subgroup settings from both a master group and the first instance. 1. Create a master group, but do not assign an instance to populate all settings; instead change only settings you want the subgroup to inherit. 2. Create a subgroup and subscribe it to the master group. 3. Assign an instance to the subgroup. If at least one nonoverridable setting differs between the master group and the instance, decide whether or not to set all differing settings to the instance values as subgroup overrides. 4. Create or remove subgroup overrides and instance overrides for the first instance as desired 5. Add further instances to the subgroup, managing instance overrides as needed. Having created a group and added instances using the procedures described, you can subscribe the group s services to one or more master groups if it is not already subscribed. If you do, however, bear in mind that (as described in About Master Groups and Subgroups) if you activate changes in the master group, some combination of permanent subgroup overrides, removable subgroup overrides, and changes to be activated will be created, depending on which of the group s settings vary from those of the master group. (Changes from the master group do not affect individual instance settings that are on instance override.) In some cases it may be helpful to use another method of populating a service s settings, which involves exporting settings from one group and importing them into the same service in another group; see Making Service Changes Using the Service History in the chapter Working with Groups for more information. 1.4 Enterprise Manager Activities The primary activity of Enterprise Manager is providing governance for managed instances. This includes: Establishing groups and master groups and determining what settings they control. Accepting new instances for management and assigning them to groups. Performing ongoing management as necessary. This involves monitoring instances, changing various settings and propagating those changes to groups of managed instances, propagating SQL security updates, and managing mirrors. Removing or deleting managed instances, groups, and mirrors as necessary. Another activity is Enterprise Manager system management. This involves activities such as: Overseeing the users who are allowed to change settings and propagate those changes. Establishing security for Enterprise Manager in order to protect its communications with managed instances. Other administrative tasks, such as license management and logging. Using InterSystems Enterprise Manager 11

18 Introducing Enterprise Manager 1.5 About Enterprise Manager Security When deployed, Enterprise Manager can use either of two security policies: WS-Security end-to-end security SSL/TLS point-to-point security With WS-Security, Enterprise Manager uses technology that protects messages as they pass the entire route to and from the managed instances. Because WS-Security provides end-to-end protection, message contents are not visible to any relays nor are they changeable by relays. With SSL/TLS, Enterprise Manager protects messages as it sends and receives them. Both WS-Security and SSL/TLS supply equally robust security. In practice, the choice depends on your organization s usual practices and its familiarity with configuring the options. Important: The security policy selection for Enterprise Manager is permanent. You cannot change it once you choose it. See Preparing for Enterprise Manager Security and Choosing a Security Policy in the chapter Initial Enterprise Manager Activities for information about setting up Enterprise Manager Security. 1.6 Using the Enterprise Manager Portal The Enterprise Manager Management portal provides access to the following four primary Enterprise Manager pages, which are available through links on the portal s home page, and through these to the rest of the Enterprise Manager pages. The first three are used to work with the instances being managed by Enterprise Manager, while the fourth is for managing Enterprise Manager itself. Management Requests Lets you accept or reject requests from Caché and Ensemble instances to be managed by Enterprise Manager. See Accepting a Management Request in the chapter Managing Instances and The Management Requests Page in the chapter Instance and Group Management pages for more information. Instances Lists all instances managed by Enterprise Manager, allowing you to select an instance to suspend, resume, or end management, or to assign the instance to a group. See the chapter Managing Instances and The All Instances Page in the chapter Instance and Group Management pages for more information. Groups Lists all groups within Enterprise Manager, letting you select a group to modify its service settings or subscribe it to a master group, as well delete any group that has no instances assigned to it nor any other group subscribed to it. See the chapter Working with Groups and The All Groups Page in the chapter Instance and Group Management Pages for more information. Monitor Displays the system health state of all managed instances, optionally filtered by monitor group. See Using the Monitor Service in the chapter Working with Groups, Monitoring Managed Instances in the chapter Managing Instances, and The Monitor Page in the chapter Instance and Group Management Pages for more information. 12 Using InterSystems Enterprise Manager

19 Using the Enterprise Manager Portal System Management Provides access to the pages used to configure and manage Enterprise Manager itself. See the chapter Enterprise Manager System Management for more information. The title bar at the top of the portal displays the following links and information: Menu Provides links to the five top-level Enterprise Manager pages Management Requests, Instances, Groups, Monitor, and System Management. Home Displays the portal [Home] page. About Displays information about the Caché instance underlying Enterprise Manager. For a description of this information, see System Overview Information in the Using the Management Portal chapter of the Caché System Administration Guide. Help Displays the online documentation (help) for the page/topic you are viewing. Logout Logs you out and brings you to the Login page of the management portal. Page name tab Displays the name of the current management portal page, for example System Management, Local Databases or System-wide Security Parameters. When you are creating an element, the tab reads New element, for example New Namespace. When you have made changes to settings or element properties that have not yet been saved, an asterisk is appended to the tab s contents, for example Devices*. (You are always prompted for confirmation before navigating away from unsaved changes.) Page Locator Displays the path to the current page (except for the [Home] page). Each page listed in the path is an active link, which you can use to return to a previously displayed page. For example, the location bar for the Memory and Startup page contains Home > All Groups > Group Details > Configuration Service > Advanced Memory Settings, providing links to the each of these pages. The locator bar may not list every page in the path. Server The name of the server running Enterprise Manager. User The name of the user logged into Enterprise Manager. Licensed to License owner as it appears in the license information. Instance The name of the Enterprise Manager instance. The ribbon, below the title bar, includes the following: Buttons used to perform operations on the page, for example New Group on the All Groups page and Suspend, Resume, Remove, and More Information on the Instance Details page. If you are on a page containing services settings and the edit state of the service is other than Edit, the buttons are not available for use. When you are on a page containing services settings, the name of the group and the edit state of the service. If the service is subscribed to a master group, the name of that group and the edit state of the service in that group are also shown. When you are on a page containing a menu, such as System Management or Service Details, you can click in the blank area to the right of a menu or submenu item s label to display information about the item instead of going to the page it is linked to. Using InterSystems Enterprise Manager 13

20 Introducing Enterprise Manager 1.7 Enterprise Manager Remote API The Enterprise Manager Remote API makes most Enterprise Manager functionality available for use in interacting with the Enterprise Manager server and the instances it manages programmatically. See the appendix Enterprise Manager Remote API and the InterSystems Class Reference for information about the Remote API. 14 Using InterSystems Enterprise Manager

21 2 Working with Groups An Enterprise Manager group consists of the settings for one or more services and the instances to which these settings are applied. Enterprise Manager treats the instances assigned to a group in a common manner, making centralized configuration and management possible. See About Groups and Instances in the Introducing Enterprise Manager chapter for important information about the way Enterprise Manager groups work, including the different types of group, assigning instances to groups, activating changes in a group s services on its instances, subscribing subgroups to master groups, and the ways in which group settings can be populated. Working with groups involves the following activities: Creating, Modifying, and Deleting Groups Managing a Group s Services Using the Configuration Service Using the Namespace Service, including the following important topics: Using Variable Substitution in the Configuration and Namespace Services Synchronized Activation of Namespace Service Changes Using the License Service Using the Security Service Using the Users Service Using the Monitor Service Using the Distributed SQL Security Service Creating and Managing a Mirror Group 2.1 Creating, Modifying, and Deleting Groups Managing groups involves several activities: Creating a Group Viewing and Modifying a Group Subscribing to and Unsubscribing from a Master Group Using InterSystems Enterprise Manager 15

22 Working with Groups Deleting a Group This section describes procedures for working with activation groups that is, groups managing some combination of the Configuration, License, Monitor, Namespace, Distributed SQL Security, Security, and Users services. Before working with mirror groups, consult Creating and Managing a Mirror Group for additional information and alternative procedures Creating a Group You can create a group in either of two ways: You can create a fully populated group one that is created from an instance and populates all of its settings with values from that instance. You can create an empty group one that does not specify any values for any settings. This group can then become fully populated by some combination of: taking its settings from a master group, the first instance you assign to it, or both importing settings exported from another group changing setting values manually Because of the way in which Enterprise Manager takes values from the first assigned instance for all settings in a group, if you attempt to assign the first instance to a group in which you have populated some settings, but not enough to define a viable instance, assignment is refused. In planning Enterprise Manager groups, it is important to remember that all instances assigned to a group must use the same character width 8 bit or Unicode. The first instance assigned to a group, whether when it is created or later on, therefore determines the character width of the group, and instances using the other character width cannot be assigned to it. See About Assigning Instances to Groups and About Organizing Enterprise Manager in the Introducing Enterprise Manager chapter for information about how empty and populated groups can be used to organize the instances managed by Enterprise Manager Creating a Populated Group To create a populated group, the procedure is: 1. Identify a managed instance that Specifies values for the settings in the services the group is to manage. is not currently assigned to a group that manages any of those services. 2. From Enterprise Manager home page, select Instances. This displays the All Instances page. 3. On the All Instances page, select the instance from the table listing all the instances. This displays the Instance Details page for that instance. 4. On the Instance Details page, click the Assign to Group button. This displays the Assign instance to group wizard, listing all existing groups. 5. On the Assign instance to group wizard, select the Create a New Group link. This displays the Create New Group wizard. 6. In the Create New Group wizard, complete the following fields: Name The name of the group (required). Description Optional text that describes the group. 16 Using InterSystems Enterprise Manager

23 Creating, Modifying, and Deleting Groups Selected Services radio button Selected when creating an activation and/or monitor group, so that you can then choose some combination of the Configuration, License, Monitor, Namespace, Distributed SQL Security, Security and Users services; for more information on these services, see Managing a Group s Services. Mirror radio button Selected when creating a mirror group; see Creating and Managing a Mirror Group for more information. 7. Click Finish to create the group. The new group is created, and is now selected in the list of groups in the Assign instance to group wizard. Click Next and Finish to assign the instance to the group. Even if you select Cancel to close the Assign instance to group wizard before completing the assignment, the group created when you clocked Finish on the Create New Group wizard remains in Enterprise Manager. The group now appears in the list on the All Groups page. You can now change its settings as desired, using the procedures in the Modifying a Group section. Once you have created a group, you cannot change its the services that it manages. You can also create a populated group by moving an instance from its current group to a new group; see Moving an Instance from One Group to Another in the chapter Managing Instances for more information Creating an Empty Group To create an empty group, the procedure is: 1. Select Groups on the Enterprise Manager home page to display the All Groups page. 2. On the All Groups page, click the New Group button to display the Create New Group wizard. 3. Complete the Create New Group wizard as described in Creating a Populated Group and click Finish to create the group. 4. Click Finish to create the group. The group now appears on the list on the All Groups page. You can now use one of the methods described in About Organizing Enterprise Manager to populate its settings from an instance, a master group, or both, or by importing settings from another group, and then make further changes as described in Modifying a Group section. Once you have created a group, you cannot change its the services that it manages. You can also create an empty group by using the Copy link on the Group Details page to copy either a populated or an empty group; see The Group Details Page for more information Viewing and Modifying a Group To view detailed information about a group and make changes to it, select Groups on the Enterprise Manager home page, then click the group s name in the list on the All Groups page. For an activation group, this displays the Group Details page, which includes the following information. (For a mirror group, the Mirror Details page is displayed; see Creating and Managing a Mirror Group for more information.) The Subscribe button, which lets you subscribe the group to a master group, as described in Subscribing to and Unsubscribing from a Master Group. The group s name. The group s description, which you can create, modify and delete using the Add description and (modify) links as appropriate. Any messages regarding the group, such as that an instance is in the process of being assigned to the group. Using InterSystems Enterprise Manager 17

24 Working with Groups The Services section, which lists the services controlled by the group and lets you make changes to their settings. The following information is included for each service: The service s name. The master group to which the service is subscribed, if any. Use the Unsubscribe link to unsubscribe the group from the master group, as described in Subscribing to and Unsubscribing from a Master Group. The service s edit state and an action link. As described in Modifying a Group s Service Settings, the edit state indicates the most recent step taken in the activation cycle for that service, while the action link lets you proceed with the next step in the cycle. If a service is subscribed to a master group, the activation cycle may be occurring within the subgroup or the master group (but not both at once). The Instances section, which lists all the instances managed by the group, including the following information: Name Click the instance name to display the Instance Details page, on which you can make changes to the instance and take other actions, as described in the chapter Managing Instances. Instance State The state of the instance within this group. Possible values are: Managed The group is managing the instance for its supported services. Being Assigned The instance is in the process of joining this group and some of its settings need to be changed or set as instance overrides, as described in Managing Instance Overrides in the chapter Managing Instances. State The state of the instance in relation to Enterprise Manager itself; on the Group Details page for each group that contains this instance, this value is the same. Possible values are: Managed Enterprise Manager is currently managing the instance. Suspended Management of the instance by Enterprise Manager is currently suspended, as described in Suspending Management of an Instance in the chapter Managing Instances. Not Updated A set of changes were activated but not successfully applied to this instance. This may occur because the instance is down or having connectivity problems. Last Communication The time of the most recent communication of any kind between Enterprise Manager and this instance. This can include an update, a notification sent from one to the other, suspension of management, or resumption of management. This value indicates the most recent verifiable time when the link between the instance and Enterprise Manager was functioning. (Enterprise Manager does not use any ongoing mechanism to maintain or confirm its connections with its managed instances.) Last Update The time of the most recent activation of changes on the instance. Remove Use this link to remove an instance from the group, as described in Removing an Instance from a Group in the chapter Managing Instances Subscribing to and Unsubscribing from a Master Group As described in About Master Groups and Subgroups in the Introducing Enterprise Manager chapter, the Configuration, License, Namespace and Security services can subscribe to a master group managing the same services. When an activation group is subscribed, it is subscribed for all services it has in common with the master group. The Monitor, Distributed SQL Security, and Users services cannot subscribe to a master group, although other services managed by the same group can. A mirror group cannot subscribe to a master group. To subscribe a group to a master group, the procedure is as follows: 18 Using InterSystems Enterprise Manager

25 Creating, Modifying, and Deleting Groups 1. Select Groups on the Enterprise Manager home page, then click the name of group that is going to be the subgroup in the list on the All Groups page. This displays the Group Details page. 2. On the Group Details page, click the Subscribe button at the top of the page. This displays the Assign group to a master group wizard. 3. On the first page of the wizard, there is a table of selectable rows, each of which lists a group s name, description, and supported service(s). Groups in plain rows are available for selection as a master group for this subgroup; those that are highlighted are not. A group is available for selection as a master group only if it manages one or more of the services currently managed by the subgroup (excluding the Monitor, Distributed SQL Security and Users services) and the subgroup is not already subscribed for those common services. the edit state of all such services is Available. Select an available group and then click the Next button. This displays a confirmation page; click Finish. The subgroup is now subscribed to the master group. On the All Groups page, the group you selected as master group is now shown in the Subscribed column for the subgroup. Important: As described in About Master Groups and Subgroups in the Introducing Enterprise Manager chapter, differences between the master group and the group being assigned are automatically introduced into the activation cycle in all subgroups that subscribe to the master group. When you display or begin editing an affected service in the subgroup, you are informed that there are unactivated master group changes, and these become outstanding changes ready for the submission step (along with whatever other changes you make in that editing session). To unsubscribe a group from a master group, the procedure is: 1. Select Groups on the Enterprise Manager home page and optionally clear the Subscribed checkbox to remove master groups from the list on the All Groups page, then locate and click the name of group you are going to unsubscribe in the list. This displays the Group Details page. 2. On the Group Details page, the Services table lists the services that the group manages. If a service is controlled by a master group, that group is shown in the Master Group column for the service. Select Unsubscribe in that row to unsubscribe from the master group; you need only do this once for each master group, even if it manages more than one of the subgroup s services. A confirmation dialog displays; confirm to unsubscribe the group. Important: When a group is unsubscribed from a master group, all values that do not have subgroup overrides are silently and automatically copied from the master group to the subgroup, so that the subgroup is continues to provide the same settings to the instances assigned to it as it did before it was unsubscribed. Should the subgroup later be resubscribed to the master group, these settings will remain subgroup settings and will not revert to master group settings, as they originally were Deleting a Group Deleting a group permanently removes the group and its history from Enterprise Manager. You cannot delete a group if it is managing any instances, or if another group is subscribed to it as a master group. To delete a group, the procedure is: 1. Select Groups on the Enterprise Manager home page to display the All Groups page. 2. Only groups that do not manage any instances have a Delete link; click this link to delete the group. 3. Click OK on the confirmation dialog. Using InterSystems Enterprise Manager 19

26 Working with Groups 2.2 Managing a Group s Services This section describes how Enterprise Manager lets you manage the services that control the values of various settings for a group s managed instances the Configuration, Namespace, License, Security, and Users services. The Distributed SQL Security and Monitor services, which can be included with these services in an activation group, and the Mirror service, which must be the only service managed by a group, are covered in Using the Monitor Service, Using the Distributed SQL Security Service, and Creating and Managing a Mirror Group, respectively. Topics in this section include: Fundamentals of Managing Services Modifying a Group s Service Settings Fundamentals of Managing Services Each activation group manages one or more services. Each service is a collection of related features that the group governs in a uniform manner. Services that control settings on the instances assigned to the group, and that therefore involve a multistep activation cycle to make changes, include the following services detailed later in this section:: Configuration License Namespace Security Users For example, the License service controls the license key and server that all of a group s managed instances use. Each of the other services performs analogous activities for its area. Because services are designed to support complex environments with multiple demands, their features include: Settings for each group s services (except the Users service) are under automatic revision control. This allows you to see all the versions of a service that have been in use, compare versions, revert to prior versions, and export current or prior versions to be imported by another group. The activity of managing or editing a service places a lock on it. To handle special situations, Enterprise Manager supports instance overrides. These allow each instance to have unique values for certain settings. Changes to a group s settings are made using the multistep activation cycle, which is described in detail in Modifying a Group s Service Settings. In Caché security terminology, a service controls access to the Caché server through a particular pathway, such as mirroring or the Caché Terminal. The Enterprise Manager Security service controls roles, resources, application security, SSL/TLS, system-wide settings, and the Caché security services Modifying a Group s Service Settings Modifying the settings of a group s services is one of the key activities of Enterprise Manager, as it allows you to apply changes to all of the instances managed by the group. As described in About Activating Service Changes in a Group in the Introducing Enterprise Manager chapter, changes to a service s settings (except the Users and Mirror services) are made 20 Using InterSystems Enterprise Manager

27 Managing a Group s Services using a multistep activation cycle. One or more individuals may be responsible for the different steps in the cycle, depending in part on which privileges each user holds. When a group is subscribed to a master group, you can make changes to either the master group or the subgroup. If you make changes to the master group, they appear as changes ready for submission when the relevant service is next edited in the subgroup; you can then submit, approve, and activate them for the subgroup in the standard manner. (To activate a change to a setting that is on subgroup override, you must first remove the override, as described in About Master Groups and Subgroups in the Introducing Enterprise Manager chapter.) Also, Enterprise Manager requires that you complete the activation cycle for the master group before beginning it for the subgroup, and vice versa; you cannot edit a service in one unless the edit state of the service in the other is Available. To apply each step in the activation cycle, you must have the required privilege either for all groups or the current group (see Editing an Enterprise Manager User s Group-independent Privileges and Assigning, Modifying, or Removing a User s Group-specific Privileges in the Enterprise Manager System Management chapter for more information) This section describes the process of modifying service settings in detail. Topics include: Service Edit States and Actions Editing a Service Transferring Editing to Another User Submitting Service Changes Approving Service Changes Activating Service Changes Returning Changes to Edit Making Service Changes Using the Service History This section describes procedures for making changes to settings within a service. Descriptions of the actual settings available in each service are provided in Managing a Group s Services Service Edit States and Actions The Group Details page lists all of the services managed by a group, including Whether the service is subscribed to a master group and a link to unsubscribe it from the master group. The service s current edit state and a corresponding service action link, which lets you start the next action in the service s current activation cycle (but not the only possible action). Possible states and their corresponding service actions are shown in the following table: Edit State State Meaning Action Link Action Next Steps Available There are no unactivated changes and the service is available for editing. Edit Locks the service for editing (Service Details page). Start modifying settings. Using InterSystems Enterprise Manager 21

28 Working with Groups Edit State State Meaning Action Link Action Next Steps View Displays the service settings (Service Details page). If you have the needed edit privilege, select Start Editing to lock the service for editing and start modifying settings. Edit (User:username) Another user is currently editing the service. View Displays the service settings (Service Details page). Wait until the other user s changes are activated, or the other user stops editing the service, to edit the service yourself. Edit You are currently editing the service but have not yet made any changes. Edit Resumes editing the service (Service Details page). Start modifying settings, or select Stop Editing to make the service available for edit by others. You are currently editing the service and have made changes. Submit Begins the submission step (Viewing changes for service in group dialog). Select Submit to submit the changes, Discard to discard them and stop editing the service,transfer to transfer editing and the current changes to another user, or Cancel to return to editing. Submitted Changes to the service have been submitted but not yet approved Approve Begins the approval step (Viewing changes for service in group dialog). Select Approve to approve the changes, Discard to discard them and make the service available for editing, or Return to Edit to keep the changes but cancel their submission and return to editing the service (if you have the needed privilege) or transfer editing to another user. Approved Changes to the service have been approved but not yet activated. Activate Begins the activation step (Viewing changes for service in group dialog). Select Activate to activate the changes, Discard to discard them and make the service available for editing, or Return to Edit to keep the changes but cancel their submission and approval and return to editing the service (if you have the needed privilege) or transfer editing to another user. 22 Using InterSystems Enterprise Manager

29 Managing a Group s Services Modifying a group can also involve: Removing an instance from a group. For this procedure, see the section Removing an Instance from a Group. Assigning an instance to a group. For this procedure, see the Assigning an Instance to a Group section in the Managing Instances chapter Editing a Service Enterprise Manager users with edit privileges for a group or the all-groups privilege can make changes to the services managed by a group. This involves modifying settings on various pages and saving each page s set of changes. The procedure is as follows: 1. Select Groups on the Enterprise Manager home page, then click the name of group you want to edit in the list on the All Groups page. This displays the Group Details page, which includes a table listing the services the group manages. 2. In the row for the service you want to edit, click the Edit link to display the Service Details page, which lets you navigate to pages on which you can edit and save settings for the service. (If the View link is displayed instead of Edit even though you have the needed privilege, click View to go to Service Details and then click Start Editing.) The Service Details menu and its entries vary for each service, but all are similar to menus and entries in the Caché management portal. See the separate lists of entries for the Configuration, License, Namespace, Security, and Users services later in this chapter Submitting Service Changes Once you have made edits to a service, the next task is to submit them for approval. This encapsulates them as a unitary set of changes that, if approved and then activated, are applied to the instances managed by the group. Submitting changes requires the Edit security privilege either for the specified group or for all groups. For settings in the Users service, there are no submission or approval steps; only editing and activation are required. The procedure for submitting changes is as follows: 1. On the Group Details page, click the Submit link for the service; on the Service Details page, click the Submit Changes button to the right of the State indicator, which currently highlights the 2. Edit state. Either action displays the Viewing changes for service in group dialog, which lists the changes that have been made to settings in the service. (See The Viewing Changes for Service in Group Dialog in the chapter Instance and Group Management pages for a description of the information provided by this dialog.) 2. If the changes are acceptable, click Submit; otherwise, click Discard to discard the changes and return the service to the edit state Available, or Cancel to return to the Service Details page. This submits the changes for approval and changes the button next to the State indicator from Submit Changes to Approve Changes Transferring Editing to Another User While submitting changes to a service you are editing, you can pass control of the editing process, including the changes you have made, to another user who has the required privilege for that group. To do so, follow the procedure in Submitting Service Changes, but click Transfer instead of Submit to display the Transfer edit rights dialog, then select a user from among those with the needed Edit privilege to transfer service editing to. Using InterSystems Enterprise Manager 23

30 Working with Groups Approving Service Changes Once changes to a service have been submitted, the next task is to approve them. This is a formal acceptance of the set of changes, making them available for activation on the instances managed by the group. For settings in the Users service, there are no submission or approval steps; only editing and activation are required. The procedure for approving changes is as follows: 1. On the Group Details page, click the Approve link for the service; on the Service Details page, click the Approve Changes button to the right of the State indicator, which currently highlights the 3. Submitted state. Either action displays the Viewing changes for service in group dialog box, which lists the submitted changes to the service. (See The Viewing Changes for Service in Group Dialog in the chapter Instance and Group Management pages for a description of this dialog.) 2. If the changes are acceptable, click Approve; otherwise, click Discard to discard the changes and return the service to the edit state Available, or Cancel to return to the Service Details page. This submits the changes for approval and changes the button next to the State indicator from Approve Changes to Activate Changes. When you make changes to service settings in a master group, approval is the final step; once changes are approved, the service becomes available for editing. As described earlier in this section and in About Master Groups and Subgroups, these changes appear as changes ready for submission when the relevant service is next edited in the subgroup; you can then submit, approve, and activate them in the subgroup, subject to any subgroup overrides. Similarly, approval is the final step in any group that is not a master group but does not yet have any instances assigned; once changes are approved, the service is available for editing;. When an instance is assigned to the group, the changes are activated on the instance as part of the assignment process (see Assigning an Instance to a Group in the chapter Managing Instances for more information). Note, however, that all settings in the service(s) managed by a group must be populated before an instance can be assigned to it Activating Service Changes Once changes to a group have been approved (or in the case of the Users service, once the service has been edited), the final task is to activate them. This causes those changes to be applied to all the instances managed by the group. The activation procedure for the Namespace service, which uses synchronized activation, is described in Synchronized Activation of Namespace Service Changes. The procedure for activating changes in the Configuration, License, Security, and Namespace services is as follows: 1. On the Group Details page, click the Activate link for the service; on the Service Details page, click the Activate Changes button to the right of the State indicator, which currently highlights the 4. Approved state. Either action displays the Viewing changes for service in group dialog box, which lists the submitted changes to the service. (See The Viewing Changes for Service in Group Dialog in the chapter Instance and Group Management pages for a description of this dialog.) 2. Before activating your changes, make any changes you want to the contents of the Description and UpdateID text boxes. This text will help you identify these changes and distinguish this version of the service from others on the Service History page (see Making Service Changes Using the Service History for more information). 3. When you are ready to apply the changes to the instances managed by the group, click Activate; this propagates the changes to the managed instances and changes the button next to the State indicator from Activate Changes back to Start Editing while returning the service state to Available. If you choose not to activate the changes, click Discard to discard the changes and return the service to the Available state, or Cancel to return to the Service Details page with the changes still submitted but not activated. 24 Using InterSystems Enterprise Manager

31 Managing a Group s Services If many instances are assigned to a group and the changes are numerous, activation can take a substantial amount of time. You can check on the progress of the activation by clicking the View Details link on the Service Details page to display the Activation Details page (see The Activation Details Page in the chapter Instance and Group Management pages). If Enterprise Manager cannot contact a managed instance, it cannot propagate activated changes to the instance. When such an instance becomes available, it requests all the changes that have been activated while it was unavailable. If the managed instance cannot accept these changes due to an error or conflict, the managed instance enters a state called NotUpdated. The NotUpdated state is similar to the Suspended state (see Suspending Management of an Instance and Resuming Management of an Instance in the chapter Managing Instances ) but includes extra information about the error that caused it. As with the Suspended state, you can resume management either from Enterprise Manager or from the managed instance. You cannot remove an instance from a group while service changes in the group are being activated, nor can you remove an instance in such a group from Enterprise Manager management (see Removing an Instance from a Group and Removing an Instance from Management in the chapter Managing Instances for information about these operations) Returning Changes to Edit While approving or activating changes, you can return the service to the edit step, retaining the changes but canceling their previous submission and approval. To do so, follow the procedure in Approving Service Changes but click Return to Edit instead of Approve to display the Transfer edit rights dialog, then select a user from among those listed (including yourself if you have the needed Edit privilege) to assign service editing to Making Service Changes Using the Service History In addition to changing a service s settings through the activation cycle as described in the preceding sections, and populating settings through first instance assignment and subscription to a master group as described in About Groups and Instances in the chapter Introducing Enterprise Manager, you can also change settings managed by the Configuration, License, Namespace, or Security service using its service history. Each time you activate changes in one of these services, those changes are recorded as a version of the service history. The Service History page, described in the chapter Instance and Group Management Pages, lists the active (current) version and all previous versions of a service, as well as the workspace version (which includes changes that have been made but have not yet been activated) if one exists. The Description and UpdateID text provided when the changes were activated help you to distinguish between versions. Links allow you to Compare two versions of the service. Export either a single version of the service or the differences between two versions so that they can be imported into the same service in another group. Revert the service to a previous version. Edit the Description and UpdateID text of a version of a service. Delete a version of a service You can export either a single version of a service or a comparison between two versions of a service to an.xml file; you can then import that file to the same service in another group on the Service Details page. You can also export a comparison between two versions of a service (but not a single version) directly to another group. The Viewing changes for service in group dialog, which details the differences between two versions of a service and is used to compare, export, and import service versions as well as to submit, approve, and activate changes in a service, is described in The Viewing Changes for Service in Group Dialog in the Instance and Group Management Pages chapter. Using InterSystems Enterprise Manager 25

32 Working with Groups Settings inherited from a master group are not recorded in the service history. Activation of changes inherited from a master group creates a new version in the service history, but the changes do not create any differences from the previous version of the service. License key activations are not included in the License service history. This section covers the following topics: Viewing a Service History Comparing Versions of a Service Exporting Settings to a File Importing Setting from a File Exporting Settings Directly to Another Group Reverting to a Previous Version of a Service Deleting a Previous Version of a Service Viewing a Service History To view the current and previous versions of the Configuration, License, Namespace or Security services in an activation group, the procedure is: 1. Select Groups on the Enterprise Manager home page, then click the name of group that is going to be the subgroup in the list on the All Groups page. This displays the Group Details page. 2. On the Group Details page, select the service you are interested in to display the Service Details page. If the Viewing changes for service in group dialog is displayed instead, click Cancel to return to the Service Details page. 3. On the Service Details page, click View History and Export to display the Service History page, which includes a table listing all versions of the service in chronological order, including the active (current) version, and the workspace version if the group is in the Edit, Submitted, or Approved phases. Comparing Versions of a Service To see the differences between two versions of a service listed on its Service History page, do the following: 1. Navigate to the service s Service History page as described for viewing a service history. 2. Click View Changes in the row for the later version of the service you want to compare to display the Viewing changes for service in group dialog, then select the earlier version in the drop down to list all difference between the two versions. Exporting Settings to a File When you export a single version of a service to a file, all settings in the service that have values are included. When you export a comparison between two versions, only settings that differ between the two versions are exported. After you export settings to a file, you can edit the file to change or remove settings before you import it. To export a single version of a service or a comparison between versions to a file, do the following: 1. Navigate to the service s Service History page as described for viewing a service history. 2. To export a single version of the service, click Export Version in the row for that version to display the Export version of service in group dialog. To export a comparison between versions, click View Changes in the row for the later version to display the Viewing changes for service in group dialog, select the earlier version in the drop down, and click Export to File to display the Export version of service in group dialog. 26 Using InterSystems Enterprise Manager

33 Managing a Group s Services 3. Enter or browse for a full pathname, including filename with.xml extension, in the Export file box and click OK to export the settings to the specified file. (if the file already exists, you are asked to confirm that you want to overwrite it.) Importing Settings from a File To import settings from a file, the service in the target group must be in edit mode. The settings in the file, each of which has an attached action of Add, Change, or Delete, are applied to the importing service s workspace version (changes that have been made but not submitted). There are two modes for importing settings from a file: Strict Settings in the file can be added to the workspace version if they are not already in it, or can change or delete settings that are already in the workspace version. If importing from the file would attempt to add a setting that already exists in the workspace version, or to change or delete a setting that does not exist in the workspace version, import fails. Copy All settings are copied from the file to the workspace version regardless of their attached action; settings that are not in the file are deleted from the workspace version. To import the settings in a file exported as described in the previous procedure, do the following: 1. Select Groups on the Enterprise Manager home page, then click the name of group you want to import to in the list on the All Groups page. This displays the Group Details page, which includes a table listing the services the group manages. 2. Ensure that the group you want to import to is in the Edit phase. In the row for the service you want to export from, Click the Edit link, if displayed, to edit the service and display the Service Details page. If the View link is displayed instead of Edit even though you have the needed privilege, click it to go to Service Details and then click Start Editing. If the Submit link is displayed, click it to display the Viewing changes for service in group dialog, then click Cancel to return to the Service Details page. If the Approve or Activate link is displayed, either complete the activation cycle or return to the Edit phase. 3. On the Service Details page, click the Import Changes button to display the Import service data dialog. If there are changes to the service awaiting submission, you are warned that importing from a file may overwrite these changes. 4. Enter or browse for the full pathname of the file to import, including filename with.xml extension, in the Import file box. 5. Select Strict or Copy import mode, then click OK to import the settings from the specified file. 6. If you selected Strict mode, and one or more of the settings in the import file exist in the workspace version, or if the file you selected contains settings for a different service, import fails. If you selected Copy mode, any such settings are silently automatically overwritten in the importing group with the exporting group s values. 7. When the import is complete, you are returned to the Service Details page; click Submit to see the results of the import operation among the changes in the Viewing changes for service in group dialog. Exporting Settings Directly to Another Group When you export a version of a service directly to another group, only the settings in that version that differ from the previous version are exported. This allows you to easily apply changes to multiple groups. The service in the target group must be in edit mode to receive exported changes directly from another group. The changes from source group are added to any existing changes to be submitted in the service in the target group. Export directly to another group is always in Strict mode (see Importing Settings from a File). To export the changes in a version of a service from a source group to a target group, do the following: 1. Navigate to the service s Service History page as described for viewing a service history. Using InterSystems Enterprise Manager 27

34 Working with Groups 2. Click View Changes in the row for the version you want to export to display the Viewing changes for service in group dialog, review the changes, and click Export to Group to display the Export changes in service in group dialog. 3. Select the target group in the Choose a target group drop down; the relevant service must be open for edit in the group you select. Click OK to export the changes to the selected group s workspace. 4. Return to the Service Details page for the service in the target group and click Submit to see the results of the export operation among the changes in the Viewing changes for service in group dialog. Reverting to a Previous Version of a Service Reverting to a previous version of a service means no longer using the active version of a service and returning to using an older version. To revert to an earlier revision of a service, the procedure is: 1. Follow the procedure for viewing a service history to display the Service History page for the service you want to revert. 2. In the row for the version that you wish to revert to, click Revert. If the service has a workspace version changes that have not been submitted, approved or activated you are warned that reverting will overwrite these changes. 3. Return to the Service Details page for the service and click Submit to see the results of the revert operation in the Viewing changes for service in group dialog, then continue with the activation cycle to activate the changes. Because settings inherited from master groups are not included in service versions, to revert such settings, you must revert the changes in the master group s service history. The reverted settings are then propagated to the subgroup like any other changes. Deleting a Previous Version of a Service Deleting a previous version of a service permanently remove that version from the service history. To delete an earlier revision of a service, the procedure is: 1. Follow the procedure for viewing a service history to display the Service History page for the service you want to delete. 2. In the row for the version that you wish to revert to, click Delete.. 3. Confirm that you want to permanently delete the version on the confirmation dialog. 2.3 Using the Configuration Service Except for Variable Substitution, which is an Enterprise Manager tool, the following categories represent management portal settings, and the links provided are to the relevant Caché documentation. Variable Substitution System Configuration Memory and Startup Journal Settings Connectivity Cluster Settings SQL and Object Settings General SQL Settings 28 Using InterSystems Enterprise Manager

35 Using the Namespace Service System-defined DDL Mappings User-defined DDL Mappings Device Settings Devices Device Subtypes IO Settings Telnet Settings National Language Settings Locale Definitions Additional Settings Compatibility Advanced Memory Monitor Startup 2.4 Using the Namespace Service Unlike other services, Namespace service changes are always applied using synchronized activation, in which all affected instances are updated at the same time, and either all instances are successfully updated or the activation is rolled back and all instances remain unchanged. Except for Variable Substitution, the following categories represent management portal settings, and the links provided are to the relevant Caché documentation. Variable Substitution System Configuration Namespaces Using InterSystems Enterprise Manager 29

36 Working with Groups Important: This release of Enterprise Manager cannot be used to create an Ensemble-enabled namespace, which must instead be created using the management portal of an individual Ensemble instance. Because you cannot create a namespace using the management portal when an instance is assigned to a group managing the Namespace service, this means that you must create Ensemble-enabled namespaces on managed instances while they are not assigned to a Namespace group. When you assign a managed instance with Ensemble-enabled namespaces to a Namespace group, for instance when populating a new group from an instance, they remain Ensemble-enabled on the instance. But when you assign an instance that does not have the namespaces specified by the group, Ensemble-enabled namespaces are not created on that instance; standard namespaces are created instead. Therefore, all desired Ensemble-enabled namespaces must be created on each Ensemble instance before the instance is assigned to a group managing the Namespace service. Note that the namespaces on an instance must match, by name, the namespaces in an existing Namespace group, or they will be deleted when the instance is assigned to the group. For example, suppose you want to assign a number of Ensemble instances with Ensemble-enabled namespaces A, B, and C to a Namespace group. You can populate a group from one such instance or create an empty group with namespaces A, B, and C. Either way, any further instances assigned to the group must have existing Ensemble-enabled namespaces A, B, and C before they are assigned to the group; any instances assigned without Ensemble-enabled namespaces will have standard namespaces A, B, and C created on them instead. Local Databases There are a number of special considerations to bear in mind when creating and managing local databases using the Namespace service, as follows: When an instance is under Enterprise Manager management, some database settings remain accessible through and are still managed using the Caché management portal. After you create a new database using the Namespace service, database properties specified using the Database Wizard and accessible and changeable in the Caché management portal on the Edit database page are not accessible on the Enterprise Manager Database Properties page and cannot be changed. However, before the changes that include a new database are activated, the New database file properties button that appears on the Database Properties page allows you to reopen the Database Wizard and change these properties. If you delete a database in a group, this causes each managed instance to dismount and unlock the database; it does not delete the database file. If databases defined by a group s Namespace service do not exist on an instance being assigned to that group, you may have to provide information needed to create the databases; see Assigning an Instance to a Group in the chapter Managing Instances for more information. When you edit the settings for a local database inherited from a master group, and at least one ECP data server is defined in the subgroup, you can create a subgroup override (see About Master Groups and Subgroups in the chapter Introducing Enterprise Manager ) to make it a remote database instead of local by selecting an ECP data server from the drop down list. Remote Databases Connectivity ECP Settings Shadow Server Settings 30 Using InterSystems Enterprise Manager

37 Using the Namespace Service Using Variable Substitution in the Configuration and Namespace Services Both the Configuration and Namespace services include settings that commonly vary from group to group and instance to instance, as well as between multiple objects of the same type. Local pathnames and filenames are a typical case; for example, the Namespace service controls the pathnames of database directories, while the Configuration service controls the pathnames of the journal file directories and the journal prefix for journal files. To make it possible to vary specific values like these when inheriting settings for an entire service, these services include the Variable Substitution page, on which you can define group variables, which are applied to values inherited by the group from master groups, and instance variables, which are applied to values activated on the instances managed by the group. For example, suppose a number of database servers host identical local databases, but are divided into two groups because they are in different data centers. The Namespace services in the groups subscribe to the same master group to inherit the same set of local database definitions. But due to different storage configurations in the data centers, the base pathname for the local database directories differs between the groups. To solve this, you can create in each group a group variable storagebase with a value representing that data center s base storage path, for example \\datacenter1\storage\dbservers\ for the first group but \\dc2\storage\ for the second. To apply this variable, in the master group setting for the directory of each database you would insert {storagebase} for the base pathname (variable names must always appear in braces within setting values) followed by the directory name, for example {storagebase}cachelib. With the variable s values substituted at the group level when the setting is inherited from the master group, this value would become \\datacenter1\storage\dbservers\cachelib in the first group and \\dc2\storage\cachelib in the second. But what if the database directories are placed in instance directories, so that the pathname also varies between instances? To solve this, you would create the instance variable instancedir for each instance in the group, for example Cache123_dc1dbs\, Cache699_dc1dbs\, and so on. In the master group, each database directory setting would include both variables, for example {storagebase}{instancedir}mgr\cachesys. With the variables values substituted at the group level and at the instance level when the setting is inherited from the master group and activated on the instances, this value would become \\datacenter1\storage\dbservers\cache123_dc1dbs\mgr\cachesys, \\datacenter1\storage\dbservers\cache123_dc1dbs\mgr\cachesys, and so on. As described in About Assigning Instances to Groups in the chapter Introducing Enterprise Manager, variables do not count as populated settings, meaning that you can define variables in a group before assigning the first instance to it to populate its settings. Variable references can be included in the values of the following settings only: Namespace service Namespaces Namespace name Local Databases Database name Database directory Stream location Remote Databases Remote server Remote database directory Database name Stream location Using InterSystems Enterprise Manager 31

38 Working with Groups Shadow Server Settings Journal file directory Database mapping Shadow (local) database directory Configuration service: Journal Settings Journal file directory Alternate journal file directory Variable references can also appear when one of these settings is referenced by another setting, for example in a database name in a drop down list of databases. Variable values are applied only when settings are activated on instances. Any number of group and instance variables can be created in a group; if a group variable and one or more instance variables have the same name, the instance values take precedence. When assigning an instance to a group with settings relying on instance variables, you must create the needed instance variables for the instance before you assign it to the group. (The Variable Substitution Page allows you to create instance variables for instances outside the group.) For example, if using instance variables to define part of the database directory paths for each instance, you must create those instance variables on the instance before assignment, so that when it is assigned the databases can be created in the specified directories. Instance variables and instance overrides (as described in Managing Instance Overrides in the chapter Managing Instances ) represent overlapping functionality to an extent; the method you choose to vary a setting across the instances managed by a group will depend on your circumstances and preferences. To create a variable in a group, use this procedure: 1. Select Groups on the Enterprise Manager home page, then click the name of group in the list on the All Groups page. This displays the Group Details page, which includes a table listing the services the group manages. 2. In the row for the Namespace service or the Configuration service, click the Edit link to display the Service Details page. (If the View link is displayed instead of Edit even though you have the needed privilege, click View to go to Service Details and then click Start Editing.) 3. Select Variable Substitution to display the Variable Substitution page, which lists the group s existing variables. Click the New button to open the Create New Variable box. 4. Enter the name and value for the variable, and indicate whether it is an instance or group variable. If an instance variable, select the instance to which it will be applied from the drop down listing all instances managed by the group. Click Save to save the variable. 5. Activate the changes as described in Modifying a Group s Service Settings. For more information on managing variables, see The Variable Substitution Page in the chapter Instance and Group Management Pages. 32 Using InterSystems Enterprise Manager

39 Using the Namespace Service Synchronized Activation of Namespace Service Changes As described in Activating Service Changes, activation of changes in the Configuration, License, Security and Users services may succeed on some instances in a group and fail on others, leaving the latter in the NotUpdated state until they can be updated. Because Enterprise Manager can manage multiple instances that all have access to the same networked databases, however, and must ensure that the namespace mappings on these databases remain consistent across those instances, the Namespace service is handled differently. Namespace service changes are applied to instances using synchronized activation, which differs from activation in the other services in the following ways: All instances in the Namespace group must be available to be updated at the beginning of the activation. If any instance cannot be contacted or is suspended, activation cannot proceed. All instances in the Namespace group are updated concurrently. Updates within the Namespace group are all or nothing if any instance cannot be updated, all updates must be rolled back so that no instance is updated. If multiple Namespace groups are subscribed to the same master group, all Namespace service changes in these groups that are ready to be activated must be activated in a single synchronized activation. For example, if Namespace subgroups A, B, C, and D subscribe to the same master group, and groups A, B, and D have approved changes ready to be activated, you cannot activate changes in A, B, or D alone; changes can only be activated in all three subgroups simultaneously. This means that all of the instances in these groups must be available for activation to begin, and that failure to update any one of them will lead to the entire activation being rolled back. If subgroup C has changes that are not yet ready for activation, Enterprise Manager alerts you to this during the activation process, giving you the opportunity to also approve the changes in C for activation before continuing, but allowing you to continue without doing so. The procedure for synchronized activation of changes in the Namespace service is described in the following. This procedure has much in common with the procedure outlined in Activating Service Changes, but important differences as well. 1. Begin the activation with one of these actions: On the Group Details page, click the Activate link for the Namespace service. On the Service Details page for the Namespace service, click the Activate Changes button to the right of the State indicator, which currently highlights the 4. Approved state. 2. If the group is not subscribed to a master group for the Namespace Service, or if it is but there are no other subgroups subscribed to that master group, either action displays the Viewing changes for service in group dialog box, which lists the approved changes to the service. (See The Viewing Changes for Service in Group Dialog in the chapter Instance and Group Management pages for a description of this dialog.) 3. If the group shares a Namespace service master group with other subgroups, the Activate Multiple Groups dialog displays, listing all of the subgroups subscribing to the master group and showing the current Namespace service state of each. For each group that has pending Namespace changes, a link is included corresponding to the link that would be displayed for the Namespace service on the Group Details page, allowing you to display the Viewing changes for service in group dialog appropriate to its current service state, so you can do one of the following: move the changes to the next stage of the activation cycle return the service to the Edit state to make further changes discard the changes and return the service to the Available state For example, if the Namespace service in a group is in the Submitted state, an Approve link appears; if a group s Namespace changes are ready for activation, a View link appears. By using these links and the Viewing changes for service in group dialog, you can get pending Namespace changes ready for activation in some or all of the listed groups, Using InterSystems Enterprise Manager 33

40 Working with Groups making adjustments as necessary. While Enterprise Manager always posts an alert message when some of the groups are not ready for activation; you can continue with the activation at any time, with only the groups that are ready. 4. When you are ready to apply the changes to the instances managed by the group or groups, click Activate on the Viewing changes for service in group dialog (for a single group) or the Activate Multiple Groups dialog (for multiple subgroups) to propagates the changes to the managed instances. Click Close in the dialog to return to the Service Details page. When synchronized activation has completed successfully, the button next to the State indicator changes from Activate Changes back to Start Editing and the service state is returned to Available. Depending on the number of instances involved, however, activation may not complete immediately; while activation is in progress, the Activate Changes button is unavailable. Click the View Details link above it to display the Activation Details page, which shows the overall status of the synchronized activation as well as the group and status of each managed instance that is being updated (the page automatically refreshes every five seconds). If activation fails due to an error on one or more instances, information about the errors is displayed. If Enterprise Manager loses contact with one or more instances during the synchronized activation, causing the process to effectively hang indefinitely, you can use the Stop Waiting button to cancel and roll back the synchronized activation so you can diagnose the problem, take remedial action, and try again. If you choose not to begin the synchronized activation, you can always click Discard to discard the changes in the current Namespace group and return the service to the edit state Available, or Cancel to return to the Service Details page of the current Namespace group. 2.5 Using the License Service The following categories represent management portal settings, and the links provided are to the relevant Caché documentation. License Key License Servers 2.6 Using the Security Service The following categories represent management portal settings, and the links provided are to the relevant Caché documentation. Roles When an instance is not assigned to a group managing the Security service, some Roles settings can also be managed by the Distributed SQL Security API; see Using the Distributed SQL Security Service for more information. Resources Services Security Domains Applications: Web Applications Privileged Routine Applications 34 Using InterSystems Enterprise Manager

41 Using the Users Service SSL/TLS Configurations X.509 Credentials System Security: System-wide Security Parameters This service supports Enable audit, Enable configuration security, Role required to connect to this system, Enable writing to percent globals, and Superserver SSL/TLS support. See the Users service for other parameters. Authentication/CSP Session Options Auditing: Configure System Events Configure User Events 2.7 Using the Users Service The following categories represent management portal settings, and the links provided are to the relevant Caché documentation. Users If a user account is disabled by Cache (for example, for too many invalid login attempts) on a managed instance assigned to a group managing the Users service, an instance override is automatically created to prevent the account from being enabled on that instance by any other changes to the Users service in that group. When an instance is not assigned to a group managing the Users service, some Users settings can also be managed by the Distributed SQL Security API; see Using the Distributed SQL Security Service for more information. System-wide Security Parameters This service supports Default security domain, Inactive limit, Invalid login limit, Disable account if login limit reached, Password expiration days, Password pattern, Password validation routine, and Allow multiple security domains. See the Security service for other parameters. LDAP Options Security Domains Mobile Phone Important: The Users service is dependent on the Security service. This means that an instance can be assigned to a group that manages the Users service only if it already belongs to a group that manages the Security service, or the group it is being assigned to manages both the Users service and the Security service. A group managing the Users service cannot be a master group, although a group managing the Users service can subscribe to one or more master groups for the Configuration, License, Namespace, and Security services. Using InterSystems Enterprise Manager 35

42 Working with Groups 2.8 Using the Monitor Service The Monitor service has no settings; its sole purpose is to allow you to select specific collections of instances for monitoring, as described in Monitoring Managed Instances in the chapter Managing Instances. The Monitor service can be managed along with any combination of the Configuration, License, Namespace, Security and Users service, or it can be the only service in a group, but a managed instance can belong to only one group that manages the Monitor service. Typically, the Monitor service is used in one of two ways: Managed instances are assigned to Monitor-only groups on the basis of common attributes that are not reflected in Enterprise Manager, or at least do not correspond to any Enterprise Manager activation groups. For example, you may want to monitor instances based on the type of storage array they are connected to. The Monitor service is included in activation groups that already represent the collection of instances to be monitored. For example, you may use the Namespace service to define the data servers for your ECP application servers, with a different group for each data server. By including the Monitor service in these groups, you can easily monitor your ECP application server instances based on the data servers they connect to. A group managing the Monitor service cannot be a master group, although a group managing the Monitor service can subscribe to one or more master groups for the Configuration, License, Namespace, and Security services. 2.9 Using the Distributed SQL Security Service SQL security on Caché instances is frequently managed programmatically. Enterprise Manager and its associated Distributed SQL Security API let you programmatically execute multiple SQL security commands on all of the instances assigned to a group managing the Distributed SQL Security service. Each SQL security command issued on a managed instance using the Distributed SQL Security API is first executed locally. If the command succeeds, it is forwarded to Enterprise Manager, which then forwards it to the other instances assigned to the Distributed SQL Security group to be executed on those instances. Within Enterprise Manager, you can use the Distributed SQL Security service to display and manage the queue of SQL security commands that have not yet been forwarded to other instances in the group. This section covers the following topics: Modifying SQL Privileges on Managed Instances Using the Distributed SQL Security API Managing the Distributed SQL Security Queue Modifying SQL Privileges on Managed Instances As described in the Roles chapter of the Caché Security Administration Guide, access to a resource is granted to a user by assigning a privilege to a role and then assigning the user to that role. Within Enterprise Manager, roles are managed by the Security service, while users, including the roles they are assigned to, are managed by the Users service. In the management portal of an individual instance, SQL privileges are granted to roles using the SQL Privileges tab on the Edit: role page, as described in Modifying a Role s SQL-Related Options in the aforementioned chapter. For example, you could use this tab to grant the %CREATE_TABLE, %ALTER_TABLE, and %DROP_TABLE privileges to the predefined %Developer role. Once this is done, any user assigned to the %Developer role is granted those privileges. 36 Using InterSystems Enterprise Manager

43 Using the Distributed SQL Security Service You can manage SQL privileges on managed instance in one of two ways, as follows: The SQL Privileges tab of a managed instance s management portal remains active, and can be used to modify the SQL privileges of roles on that instance only. The Distributed SQL Security API lets a user or program with the needed authorization grant and revoke SQL privileges on a managed instance; if the instance is not managed by the Security and Users services, the API can create and remove roles and users as well. When you use the Distributed SQL Security API to successfully execute a SQL security command on a managed instance assigned to a group managing the Distributed SQL Security service, the command is automatically forwarded to Enterprise Manager, which then forwards it to the other instances in the group to be executed on those instances. Important: Only the use of the Distributed SQL Security API on an instance assigned to a group managing the Distributed SQL Security service affects more than a single managed instance. As described in Using the Security Service and Using the Users Service, roles are created and removed, and users are assigned to and removed from roles, using the Security service, while users are created and removed using the Users service. However, if a managed instance is not assigned to a group managing these services, the API can be used to create and remove roles, create and remove users, and assign users to and remove them from roles, as described in the following section. If your needs include extensive programmatic management of SQL security on a given set of managed instances, for greater flexibility in using the Distributed SQL Security API, avoid assigning these instances to groups managing the Security and Users services Using the Distributed SQL Security API To use the Distributed SQL Security API on a managed instance, the calling user or process must have Use permission for the EMSDistributedSQLSecurityAPI resource. On managed instances, the EMSDistributedSQLSecurityAPI resource is available to be assigned to roles, and is assigned by default to the predefined EMSDistributedSQLSecurityAPI role. You can grant a user the needed permission by assigning the user to the EMSDistributedSQLSecurityAPI role, either by editing the Users service in Enterprise Manager, if the instance is assigned to an appropriate group, or using its management portal, if it is not. (See Assigning Users or Roles to the Current Role in the Roles chapter of the Caché Security Administration Guide for instructions on using the Edit: role page to do this in Enterprise Manager or the portal.) The EMSDistributedSQLSecurityAPI resource can be used to authorize use of the Distributed SQL Security API in other ways, as described in Resources and What They Protect in the About Caché Security chapter of the Caché Security Administration Guide. The Distributed SQL Security API is invoked on a managed instance using the %EM.DistSQLSecurity.Execute() method. The method takes as its argument one of the following commands: Instances managed by both Security and Users services: GRANT privilege TO role REVOKE privilege FROM role Instances managed by Security service but not Users service: CREATE USER user IDENTIFIED BY password DROP USER user GRANT privilege TO role REVOKE privilege FROM role Instances not managed by Security or Users services: Using InterSystems Enterprise Manager 37

44 Working with Groups CREATE ROLE role DROP ROLE role GRANT role TO user REVOKE role FROM user CREATE USER user IDENTIFIED BY password DROP USER user GRANT privilege TO role REVOKE privilege FROM role The privilege granted or revoked must be one of the privileges listed in Modifying a Role s SQL-Related Options in the Roles chapter of the Caché Security Administration Guide. The privilege is granted to the user in the namespace in which the API is invoked. When the method is invoked on a managed instance, the command is executed on the local instance. If it fails, an error status is returned and no further processing occurs. If it succeeds, and the instance is assigned to a group managing the Distributed SQL Security Service, the command is sent to a queue in Enterprise Manager, which forwards it to the other members of the group. When the command has been forwarded to all of the instances, it is removed from the queue in Enterprise Manager. If the managed instance on which the API is invoked is suspended, as described in Suspending Management of an Instance in the chapter Managing Instances, the SQL security command fails. If the command succeeds, but Enterprise Manager is unavailable to receive the command, the command is rolled back locally; SQL security remains unmodified on the instance Managing the Distributed SQL Security Queue The Distributed SQL Security service does not have an activation cycle; instead, when you click the name of the service on the Group Details page, the SQL Security Message Queue page displays. This page lists all commands that have been successfully executed on a managed instance in the group and forwarded to the Enterprise Manager queue for propagation, but not yet forwarded by Enterprise Manager to all of the other instances in the group. This includes commands that have not yet been forwarded to instances that are unreachable, for example because they are suspended or due to network outages. You can use the Freeze Updates button to pause forwarding of updates so that you can select one or more updates and take one of the following actions: Delete selected messages Permanently remove the selected updates from the queue; they will not be forwarded to any more instances. Remove instance below from selected messages Cancel forwarding of the selected updates to the instance selected in the drop-down under the button. The updates will still be forwarded to the other instances listed in the Instances Not Updated column. When you have made the desired changes, press the Resume updates button to continue with forwarding of pending updates to instances. See The SQL Security Message Queue Page in the Instance and Group Management Pages chapter for detailed information about using this page to manage Distributed SQL Security service updates. 38 Using InterSystems Enterprise Manager

45 Creating and Managing Mirror Groups 2.10 Creating and Managing Mirror Groups The Mirror service manages instances that have a configured relationship outside of Enterprise Manager they are all members of a single Caché mirror. For this reason, the Mirror service must be the only service managed by its group, which is called a mirror group. A mirror, and thus a mirror group, typically contains two failover members and up to 14 async members, although a single failover member is sometimes configured with some number of asyncs. Before working with Enterprise Manager mirror groups, be sure to review the Mirroring chapter of the Caché High Availability Guide for important information about Caché mirroring, including the configuration of and relationships between mirror members, as well as other details. As with other services, when a mirror is managed by Enterprise Manager that is, when its member instances are managed by Enterprise Manager and are assigned to an Enterprise Manager mirror group you generally cannot modify mirror or mirror member configurations or settings using the management portals of the individual instances, but only through the Enterprise Manager mirror group. There are a few exceptions, as documented in the procedures in this section and summarized in Modifying a Managed Mirror Outside of Enterprise Manager. You can always review mirror configurations and settings in the instance management portals. When a managed instance is a member of a managed mirror, it cannot be individually removed from Enterprise Manager management (see Removing an Instance from Management in the chapter Managing Instances ); instead, the entire mirror can be removed from management as described in Modifying a Managed Mirror. In addition, when a member of a managed mirror is suspended and then resumed (see Suspending Management of an Instance and Resuming Management of an Instance in Managing Instances ), the operation s results are different from when non-mirror member instances are resumed. See Modifying a Managed Mirror Outside of Enterprise Manager for more information on making changes to managed mirrors and mirror members outside of Enterprise Manager. A mirror group cannot be a master group or subscribe to one. There are two ways to place a mirror under Enterprise Manager management using a mirror group, as follows: Creating a Mirror Using a Mirror Group Assigning an Existing Mirror to a Mirror Group This section also covers these topics: Managing Namespace Groups for a Mirror Managing Mirrored Databases Modifying a Managed Mirror Modifying a Managed Mirror Outside of Enterprise Manager Deleting a Mirror Group Managing Namespace Groups for a Mirror To be able to take over in the event of a primary outage, the backup failover member of a mirror must have a synchronized copy of all of the mirrored databases on the primary. Because a DR async can be promoted to failover member, each DR async member must also have a copy of all of the mirrored databases on the failover members. For this reason, the failover members and any DR async members of a managed mirror must all belong to the same group managing the Namespace service, or to Namespace groups that are subscribed to the same master group. That way, it is possible to enforce the addition of a mirrored database (and its associated namespaces) on the failover and DR async members of the mirror by adding it to one group or master group. Using InterSystems Enterprise Manager 39

46 Working with Groups Because a reporting async member may or may not have a copy of all of the mirrored databases on the failover members, the Namespace service requirement does not apply to reporting asyncs; in fact, reporting asyncs do not need to be assigned to a Namespace group at all. However, membership in Namespace groups makes it easier to coordinate mirrored database creation with the failover members and other reporting asyncs, and adds the advantages of enterprise management of multiple instances generally. Also, when making changes such as creating multiple mirrored databases, it is convenient to be able to export the changes from one Namespace group to another, as described in Exporting Mirrored Databases to Another Namespace Group. When you create a mirror using a mirror group within Enterprise Manager, as described in Creating a Mirror Using a Mirror Group, the Namespace groups you prepare for your mirror members will depend in large part on whether there are reporting asyncs to assign to Namespace groups, and which databases they will maintain copies of. The following considerations apply: You must always create a Namespace group for the failover members and any DR asyncs. Any reporting asyncs that will maintain copies of all databases in the mirror can be assigned to the failover Namespace group, so that the mirrored databases can be created on the most possible members in the fewest possible steps. If maintaining the reporting asyncs in separate Namespace groups seems appropriate for ongoing configuration and management reasons, they can be removed from the failover Namespace group after all mirrored databases have been created and assigned to new groups populated by representative members (as described in Creating a Populated Group). Reporting asyncs that will maintain only a subset of the mirrored databases can also be assigned to the failover group before mirrored databases are created and then moved to their own Namespace groups, with the additional steps of first removing the unwanted databases from the mirror on each async (see Managing Mirrored Databases) and then deleting the databases from the corresponding Namespace groups. For instance, consider the following simplified example, in which a read-only reporting async is used as a data warehouse and two read-write reporting asyncs are used for post-production business intelligence queries on different data sets: Having created the mirrored databases while the reporting asyncs are in the failover Namespace group, you would remove each reporting async from the failover Namespace group and assign it to its own Namespace group, then remove and delete the application code databases from the mirror on the RO async and then from the RO async Namespace group group, the data set C databases from the mirror on the AB async and then the AB async group, and the data set B databases from the mirror on the AC async and then the AC async groupgroup. The result would be the following: 40 Using InterSystems Enterprise Manager