Omada Identity Installation

Here you can find comprehensive information on how to install the Omada Identity on-premises variant and set-up all of it's related components.

You can find the following information:

• Hardware infrastructure requirements and recommendations
• Software prerequisites
• Required permissions
• Procedure for both manual and Omada Identity installation
• Installation procedure for related components

Disclaimer

Omada Identity is a highly customizable and scalable solution, so the recommendations you can find here are not suited for all situations or implementations. The technical design of an Omada Identity implementation must be planned in detail with Omada consultants and adapted to suit the existing system landscape and environment. You can find detailed implementation requirements in the documentation for the individual Omada Identity modules.

Components of Omada Identity

There are two major components composing the Omada Identity solution:

• Omada Identity Enterprise Server (ES)
• Omada Identity Data Warehouse (ODW)

Omada Identity Enterprise Server

The ES is based on the classic three-level web application architecture comprising of a web browser UI, a web application running on IIs, and a SQL Server database. You can either deploy the web application and database on separate servers or on the same server.

Omada recommends

Deploy the web application and database on separate servers, to have application tier separated from the database tier. This is a recommended approach, if the application is required to be available in a low-trust environment, such as the internet or perimeter network. Additionally, this deployment improves the scalability.

Windows services components of the ES

Role and Policy Engine

Calculates the desired state, what access should identities have, and reconciles it with the actual state of the target systems. It is also responsible for triggering provisioning tasks to the Omada Provisioning Service.

Timer Service

Runs the scheduled tasks in the Enterprise Server, for example populates the audit database.

Omada Provisioning Service

Performs the provisioning tasks against connected systems. In addition to OPS, you can use other provisioning technologies, such as MIM Sync.

Omada Identity Data Warehouse

The Data Warehouse consists of three main components:

• Databases

• SSRS Reports

• SSIS Packages

Optional

In addition, Data Warehouse also contains a fourth, optional, component: Advanced Analytics Service/Tabular model, which requires SQL2016 or later.

You can install Omada Identity Data Warehouse in a single-server or in a distributed environment with each of the components installed on a different server.

SSIS Packages are run using SQL Server Agent jobs that you can schedule and configure.

Disk recommendations

The performance of the Omada Identity system is dependent on the I/O speed of the disk system chosen.

tip

The general recommendation is to use SAN disks.

If SAN disks are not an option, Omada recommends the use of a redundant array of independent disks systems, for example, RAID 1 or RAID 5. This is particularly important on the database server to avoid data loss.

Temporary storage space for Omada Identity Data Warehouse imports

The Data Warehouse (ODW) import requires available temporary storage space, especially on the SSIS Server. You should set Page File on the SSIS server to a certain level, depending on the size of the Omada Identity Data Warehouse imports (the minimum would be twice the size of the memory). SSIS writes data to the TEMP directory of the account running the import. Data may also be written to the tempdb system database.

For Omada Identity Data Warehouse imports, you must ensure the following:

1. The Page File on the SSIS Server is large or able to grow.
2. The TEMP directory of the account running the import is located on a drive with a good amount of free space.
3. The tempdb database has room for temporary growth.

Location of temporary storage

Omada recommends that the temporary storage is not placed on the C: drive.

You should not put dynamic data, including data in the temp folder, on the system drive. Use a data drive, because:

• You cannot extend the system drive without taking the server down, but it is possible with other drives.
• If the system drive is full, the server stops running. But if another drive is full, the server itself can still function. Only server processes that use the full drive are negatively affected.

Scalability an resilience guidelines

Here are general rules for estimating the sizing of memory and disk space for the servers.

Disclaimer

Provided rules are only suggestions.

For production environments, it is important to take expected usage patterns and the structure of the data into account. It is recommended to plan production server sizing together with an Omada consultant.

Memory sizing

Component	Recommendation
Enterprise Server	Add 1 GB memory per 50,000 managed objects for each of the servers, in addition to the 8/16 GB minimum configuration.
Omada Identity Data Warehouse	Add 1/2 GB RAM per 100,000 objects to the database and SSIS servers. You must always test this in your own environment.

Disk space sizing

The sizing of the servers depends both on the number of managed identities, resources, accounts etc. and on the usage/load scenario. It is recommended to perform load performance testing for the specific environment to ensure proper performance for end-users when going live.

Disk space required for ODW - general rule

Calculate 10 KB per resource assignment (20% database size and 80% transaction log size) and add 50% for margin.

Resilience requirements

There are following resilience requirements for ES and ODW

Omada Identity Enterprise Server

Use SQL Server Clustering or Always On Availability Groups for the database for high availability. Use Network load balancing (NLB) for deployment of multiple IIS servers for improved scalability.

Omada Identity Data Warehouse

Use SQL Server Clustering or Always On availability groups for the Warehouse databases for high availability.

If necessary (for example, in the event of a crash, or when upgrading), the standby server becomes the primary one. The Omada Identity Data Warehouse supports this setup, as most of the required data (that is, configuration, master data, transaction data) is stored in the databases. However, some parts of the configuration are kept outside the databases, for example, in XML files. Such files need to be maintained on both application servers.

For resilience on the Omada Identity Data Warehouse imports, the SSIS server should be configured to connect to the SQL server Always On availability group listener for its data store.

An import is likely to fail if running while a switch from the primary to the backup server is occurring. As data is transactional-based, no data will be affected as a rollback will occur.

Omada Identity Data Warehouse SSIS packages are deployed to the MSDB database (and cannot be deployed to SSISDB) and as an Always On availability group is not synchronizing the MSDB, the Omada Identity Data Warehouse installer will need to be run twice. First, install specifying the integration service package storage to the backup SQL Server, then uninstall, then install again specifying the primary SQL server.

It is not recommended to install SSIS in a clustered setup. For more info, see the following Microsoft document.

For reports, use the scale-out deployment of multiple SSRS servers for improved scalability.

Load sharing

If multiple IIS instances are sharing the workload of the Enterprise Server using any available method (NBL, Load Balancer or Application Firewall), two measures must be taken:

1. The ASP.NET session state must be persisted in a SQL Server database or in an ASP.NET session state server. See this link for details.
2. One of SignalR scale out solutions must be enabled: either SQL Server scale out or ServiceBus scale out, depending on the environment.

The same applies if the IIS application pool has more than one worker process configured in the Maximum Worker Processes setting:

Examples of deployment scenarios

Disclaimer

Omada Identity can be set up in various ways, depending on the requirements and system environment. The recommendations provided here should be adapted to your specific conditions. If it is relevant to your organization's needs, you can develop a detailed strategy for hardware sizing and system landscape together with Omada consultants.

There are two deployment scenarios presented here:

• Recommended deployment
• Minimum deployment

The term Recommended refers to a medium-sized system. The approximate range of managed objects in a medium-sized system is 150,000 to 500,000 for Enterprise Server and 1,000 000 to 5,000,000 for Data Warehouse.

Managed objects include primarily identities, resources, resource assignments, business contexts (such as organizational units), business context assignments and policy definitions.

To determine if a system is of medium size, you must also consider the number of connected systems and users, including usage patterns. The recommendations in this document are based on moderate usage with 1-2 self-service requests per user per month.

Recommended deployment

For a production Omada Identity system, Omada recommends that you use three servers for the Omada modules: a database server, a SSIS server (for ODW SSIS Packages), and an Application and SSRS server for running the Omada Identity Web Application and Services in addition to the ODW SSRS Reports.

The recommended server sizing recommendations for this scenario are:

Server	CPU	Memory	Disk Space	Network
Application & SSRS Server	Quad Core	16 GB	80 GB	Gigabit
Database Server	Quad Core	16 GB	200 GB	Gigabit
SSIS Server	Quad Core	16 GB	100 GB	Gigabit
MIM Sync Server (optional)	Dual Core	8 GB	10 GB	Gigabit

Minimum deployment

In a minimum setup, Omada recommends that you use a two-server setup for the Omada modules. One server runs the databases and the Omada Identity Data Warehouse SSIS packages, and the second server runs the Web Application, the Services, and the Omada Identity Data Warehouse Reports.

You can use MIM Sync for automatic provisioning as an alternative or supplement to the Omada Identity provisioning Service. You can use the minimum scenario for a test or demo system, but Omada does not recommend it for a production system.

The recommended server sizing recommendations for this scenario are:

Server	CPU	Memory	Disk Space	Network
Application & SSRS Server	Quad Core	16 GB	80 GB	Gigabit
Database & SSIS Server	Quad Core	16 GB	100 GB	Gigabit
MIM Sync Server (optional)	Dual Core	8 GB	10 GB	Gigabit