Terminology
This section defines key terms pertaining to the Operations Console and the tenant creation and data migration process.
General Terms
Operations Console
The tool used to create tenants and tenant instances, move data from one tenant instance to another (for example, from the staging instance of a tenant to the production instance), and perform various administrative tasks.
Backup Types
There are three steps to the process of backing up a database:
- Back up the database on the source system.
- Copy the database from the source system to the target system.
- Restore the database on the target system.
Use Microsoft SQL to perform the backup. There are several backup types you can choose from when using the Operations Console:
- From last MSSQL backup: Copies the source database from the source database backup location to the target database backup location and restores the database from there.
- From live MSSQL backup: Performs a live Microsoft SQL backup of the source database and places the backup in the source database backup location. Copies the source database backup to the target database backup location and restores the database from there.
- From copied MSSQL backup: The source database has already been manually copied to the target database backup location. If you choose this option, the system adds a field called Backup Filename where you enter the name of the Microsoft SQL backup.
- Database already restored: The database was already restored manually outside of the Operations Console (for example, through Microsoft SQL Server Management Studio). Choosing this option means the database is not backed up or restored.
Types of Data
Configuration Data (Settings)
Configuration data, also called settings, is defined as core configuration attributes that define Ivanti Service Manager.
The only configuration data (settings) that the system migrates when you migrate configuration data (settings), as described in Updating Configuration Data (Copy Settings), are the following:
- Allowed attachments
- Authentication providers such as LDAP, SAML, OpenId, and Windows Integrated Security
- Bulk upload profiles
- Dynamic styles
- Global constants
- Integration settings
- LDAP configurations
- Object matching lists
- Password policies
- Voice integrations
- Watch list items
- Email configurations (including approval status keywords, email status update mapping settings, ignore message with subject settings, object mappings for email, task assignment status keywords, truncate body settings, and trusted sender domains)
You cannot migrate other types of configuration data (settings) using the Operations Console. To migrate this data, do so manually outside of the Operations Console by using Microsoft SQL commands.
Master Data
Master data is defined as data sets that are used across an organization and are typically unique to that organization. User and role definitions, role assignments, and categories are examples of master data.
Master data is migrated together with metadata so that it is consistent with the business object definitions. There are four types of master data and you can migrate any or all of them:
- User data, except for user email addresses because they may have been scrubbed.
- User-related data, such as contact group, standard user team, organizational unit, and so on.
- Service request data, such as request offerings, request parameters, and so on.
- Escalation schedule.
You can now track these types of master data:
- Analytic metrics dashboards and configuration
- Schedule entries
- Escalation settings and schedules
- Escalation clock control
- Service level packages
- Service level targets
To see a list of master data for a tenant, if any has been defined, place your mouse over the destination tenant.
The only way to migrate master data is by enabling the Ivanti Service Manager development project and using the push link. See The Four Ways to Migrate Data for more information about this method of migrating data and see Example: Migrating Service Level Data for an example.
Metadata
Configured business objects, business object attributes, forms, grids, quick actions, searches, and so on. When you reconfigure your Ivanti Service Manager system, most of the changes are implemented by editing metadata.
The types of metadata are as follows:
- Business objects
- Counters
- Forms
- Grids
- Layouts
- Quick actions
- Rules
- Rule overrides
- Branding
- Roles
- Validation (pick list) definitions
- Business rules
- Searches (namely saved searches)
- Dashboards
- Chart-part metadata (one type of dashboard)
- Grid-part metadata (one type of dashboard)
- Special-part metadata (one type of dashboard)
- View-part metadata (one type of dashboard)
- Workflows
- Workflow types
- Reports (subscription, schedule, and distribution are not migrated from source to target)
- Validation data (of pure validation business objects and custom data)
- Images in the frs_def_images table
You can lock all of the metadata, except for quick actions, dashboards, searches, and reports. Those four types of metadata cannot be locked and are always open to be edited in the production instance of the tenant. To lock the other types of metadata, set the metadata to read-only. Each tenant instance has a Metadata Locked field that lets you know if the metadata is locked for an instance of a tenant.
Transactional Data
A customer's data records, including incidents, changes, service requests, and so on.
The only way to migrate transactional data is by enabling the Ivanti Service Manager development project and using the push link. See The Four Ways to Migrate Data for more information about this method of migrating data and see Example: Migrating Service Level Data for an example.
Validation Data
Validation data objects defined by customers. You must migrate all validation data together at the same time and you must migrate metadata and validation data together in the same migration. This guarantees that when metadata is migrated, it includes all pick list definitions that are associated with validation objects.
Validation data is any data that is configured as part of a validation business object. A validation business object and its associated data (for example, a pick list and the data in the list) are both considered validation data. But a standard business object and its associated data (for example, a pick list and the data in the list) are not both validation data. If the business object is a standard business object, then that is validation data, but the associated data is not considered validation data.
Business Object | Is it Validation Data? |
|---|---|
Standard business object | Yes |
Validation business object | Yes |
Data associated with a standard business object | No |
Data associated with a validation business object | Yes |
Landscapes
Landscape Definition
A landscape is a set of IT infrastructure components that support tenant instances of the same type (where type refers to production, staging, and UAT). The production landscape only contains the production instances of tenants, the staging landscape only contains the staging instances of tenants, and the UAT landscape only contains the UAT instances of tenants.
Typical Production Landscape shows a typical configuration for a production landscape. Components and their locations vary from customer to customer. For example, on-premise customers probably only have one production tenant in their production landscape.
Typical Production Landscape
Landscape Components
At a minimum, a landscape contains these components:
- An individual, isolated Microsoft SQL Ivanti Service Manager application database (called IvantiSM) in each tenant (each tenant instance has its own database, but not its own database instance).
- A central Ivanti Service Manager configuration database (called ConfigDB) containing information about all tenant instances in the landscape.
- A shared pool of Ivanti Service Manager application servers for all Ivanti Service Manager instances in the landscape.
- A shared database cluster for the Ivanti Service Manager configuration and Ivanti Service Manager application databases.
- A shared pool of workflow servers used by all Ivanti Service Manager instances in the landscape.
- A shared pool of escalation engines used by all Ivanti Service Manager instances in the landscape. This is sometimes combined with the workflow server.
- A shared pool of email listeners used by all Ivanti Service Manager instances in the landscape.
- A shared pool of integration servers per function, such as survey, Discovery, Desktop Server and Management (DSM), Report Server, License Server, and so on.
Types of Landscapes
There are six types of landscapes:
- Production landscape: Hosts the production instances of tenants. Used during the data migration lifecycle. This is the environment where the product is deployed.
- Staging landscape: Hosts the staging instances of tenants. Used during the data migration lifecycle. This is the environment where development work is done.
- UAT landscape: Hosts the UAT instances of tenants. Used during the data migration lifecycle. This is the environment where testing is done.
- Pilot landscape: Optional. A standalone landscape that hosts the pilot tenant to provide customers with early access to a new Ivanti Service Manager point release.
- Development landscape: Optional. A standalone landscape that hosts tenant templates for demos, test drives, training, and so on.
- Other landscape: Optional. A standalone landscape type that can be used for any purpose.
Tenant and Tenant Instance Types
A tenant is a Ivanti Service Manager system for a particular customer or application.
An instance of the Ivanti Service Manager tenant within a landscape. By default, each customer receives a production instance of the tenant and a staging instance of the tenant. Additional optional tenant instances are also available. The name and URL for each tenant instance must be unique.
The term "tenant instance" is NOT related to the term "database instance". The use of the word instance, when referring to a tenant, simply means one copy or version of it.
The available tenant instances are:
- Production instance of a tenant: A tenant instance containing your production database (including all configuration and transactional data). All customers have a production instance of their tenant. The production instance of the tenant resides in a hardened environment in the production landscape. We do not recommend making metadata or configuration changes directly to the production instance of the tenant during production usage. Instead, make those changes in the staging instance of the tenant, push them to the UAT instance of the tenant for testing, and then push them to the production instance of the tenant. You can make some changes to master data (such as adding employees, role assignments, and so on) directly to the production instance of the tenant.
- Staging instance of a tenant: A tenant instance for developing and configuring your Ivanti Service Manager system and business processes. This tenant instance is generally used for configuration and metadata changes (but not transactional data changes). It undergoes a baselining process, in which it is updated periodically or by customer request from the production instance of the tenant to ensure that it is in sync with the production instance of the tenant prior to configuration and metadata changes. It can also be used to test new releases, new capabilities, and for training. All customers have a staging instance of their tenant.
- UAT instance of a tenant: A temporary tenant instance used for configuration testing and validation before the new configuration is pushed to an existing production tenant instance. The UAT instance of the tenant is required when reconfiguring an existing production instance of the tenant. It is optional when provisioning the production instance of the tenant for the first time or when upgrading to a new Ivanti Service Manager release.
On-premise customers may or may not use a UAT instance of a tenant.
- Pilot instance of a tenant: During the upgrade process to a new release, an optional pilot instance of the tenant is made available to customers to allow early access to a new point release. The pilot instance of the tenant resides in the pilot landscape.
- Development instance of a tenant: An optional development instance of the tenant for testing or development. The development instance of the tenant resides in the development landscape.
- Other instance of a tenant: An optional instance of the tenant for testing or development. The other instance of the tenant resides in the other landscape.
- Tenant environment: Infrastructure that ties together the production, staging, and UAT instances of a tenant. This infrastructure allows a complete change management process to manage and control the development and deployment lifecycles between these instances of the tenant.
- Tenant template: A preconfigured ("out-of-the-box") tenant that is typically used to set up a new tenant. A template implements best practices according to ITIL standards, and optimizes processes to allow fast implementation.