• USA : +1 973 910 5725
  • INDIA: +91 905 291 3388
  • info@tekslate.com
  • Login

MicroStrategy Architecture

Microstrategy Intelligence Server

MicroStrategy Architecture

A MicroStrategy system is built around a three-tier or four-tier structure. The diagram below illustrates a four-tier system.

MicroStrategy metadata

MicroStrategy users need connectivity to the metadata so that they can access projects, create objects, and execute reports. MicroStrategy Intelligence Server connects to the metadata by reading the server definition registry when it starts.

MicroStrategy Metadata

What happens when Intelligence Server starts?

When Intelligence Server starts, it does the following:

  • Initializes internal processing units
  • Reads from the machine registry which server definition it is supposed to use and connects to the specified metadata database
  • Loads configuration and schema information for each loaded project
  • Loads existing report cache files from automatic backup files into memory for each loaded project (up to the specified maximum RAM setting)
  • Loads schedules
  • Loads MDX cube schemas

MicroStrategy Service Manager

At TekSlate, we offer resources that help you in learning various IT courses. We avail both written material and demo
 video tutorials. To gain in-depth knowledge and be on par with  practical experience,
then explore MicroStrategy Training PDF.

Intelligence Server job processing

The following is a high-level overview of the processing that takes place:

  • A user makes a request from a client application such as MicroStrategy Web, which sends the request to Intelligence Server.
  • Intelligence Server determines what type of request it is and performs a variety of functions to prepare for processing.
  • Depending on the request type, a task list is composed that determines what tasks must be accomplished to complete the job, that is, what components the job has to use within the server that handle things like asking the user to respond to a prompt, retrieving information from the metadata repository, executing SQL against a database, and so on. Each type of request has a different set of tasks in the task list.
  • The components within Intelligence Server perform different tasks in the task list, such as querying the data warehouse, until a final result is achieved.
  • Those components are the stops the job makes in what is called a “pipeline,” a path that the job takes as Intelligence Server works on it.
  • The result is sent back to the client application, which presents the result to the user.

Processing report execution

MicroStrategy - Report Execution

Processing object browsing

MicroStrategy - Processing Object Browsing

MicroStrategy User Model

MicroStrategy users

  • Like most security architectures, the MicroStrategy security model is built around the concept of a user. To do anything useful with MicroStrategy, a user must log in to the system using a login ID and password. The user can then perform tasks such as creating objects or executing reports and documents, and can generally take advantage of all the other features of the MicroStrategy system.
  • Users are defined in the MicroStrategy metadata, and exist across projects. You do not have to define users for every project you create in a single metadata repository.
  • Each user has a unique profile folder in each project. This profile folder appears to the user as the “My Personal Objects” folder. By default other users’ profile folders are hidden. They can be viewed by, in the Desktop Preferences dialog box, in the Desktop: Browsing category, selecting the Display Hidden Objects check box.
  • Administrator is a built-in default user created with a new MicroStrategy metadata repository. The Administrator user has all privileges and permissions for all projects and all objects.

MicroStrategy user groups

A user group (or “group” for short) is a collection of users. Groups provide a convenient way to manage a large number of users.

Instead of assigning privileges, such as the ability to create reports, to hundreds of users individually, you may assign privileges to a group. Groups may also be assigned permissions to objects, such as the ability to add reports to a particular folder.

Controlling access to objects: Permissions

Permissions define the degree of control users have over individual objects in the system. For example, in the case of a report, a user may have permission to view the report definition and execute the report, but not to modify the report definition or delete the report.

While privileges are assigned to users (either individually, through groups, or with security roles), permissions are assigned to objects.

Controlling access to functionality: Privileges

Privileges give users access to specific MicroStrategy functionality. For example, the Create Metric privilege allows the user to use the Metric Editor to create a new metric, and the Monitor Caches privilege allows the user to view cache information in the Cache Monitor.

Defining sets of privileges: Security roles

A security role is a collection of project-level privileges that are assigned to users and groups. For example, you might have two types of users with different functionality needs: the Executive Users who need to run, sort, and print reports, and the Business Analysts who need additional capabilities to drill and change subtotal definitions. In this case, you can create two security roles to suit these two different types of users.

Modes of Authentication

The available authentication modes are:

  • Standard: Intelligence Server is the authentication authority. This is the default authentication mode.
  • Anonymous: Users log in as “Guest” and do not need to provide a password. This authentication mode may be required to enable other authentication modes, such as database warehouse or LDAP.
  • Database warehouse: The data warehouse database is the authentication authority.
  • LDAP (lightweight directory access protocol): An LDAP server is the authentication authority Single sign-on: Single sign-on encompasses several different third-party authentication methods, including:
  • Windows authentication: Windows is the authentication authority o Integrated authentication: A domain controller using Kerberos authentication is the authentication authority
  • Tivoli or SiteMinder: A third-party single sign-on tool, such as Tivoli or SiteMinder, is the authentication authority.

Managing and verifying your licenses

MicroStrategy uses two main categories of licenses:

  • Named User licenses in which the number of users with access to specific functionality is restricted.

In a Named User licensing scheme, the privileges given to users and groups determine what licenses are assigned to users and groups. Intelligence Server monitors the number of users in your MicroStrategy system with each privilege, and compares that to the number of available licenses.

  • CPU licenses, in which the number and speed of the CPUs used by MicroStrategy server products are restricted.

When you purchase licenses in the CPU format, the system monitors the number of CPUs being used by Intelligence Server in your implementation and compares it to the number of licenses that you have. You cannot assign privileges related to certain licenses if the system detects that more CPUs are being used than are licensed. For example, this could happen if you have MicroStrategy Web installed on two dual-processor machines (four CPUs) and you have a license for only two CPUs.


A cache is a result set that is stored on a system to improve response time in future requests. With caching, users can retrieve results from Intelligence Server rather than re-executing queries against a database.

Intelligence Server supports the following types of caches:

  • Result caches: Report and document results that have already been calculated and processed, that are stored on the Intelligence Server machine so they can be retrieved more quickly than re-executing the request against the data warehouse.
  • Report caches can only be created or used for a project if the Enable report server caching check box is selected in the Project Configuration Editor under the Caching: Result Caches: Creation category.
  • The History List is a way of saving report results on a per-user basis. The History List is a folder where Intelligence Server places report and document results for future reference. Each user has a unique History List.

With the History List, users can:

  • Keep shortcuts to previously run reports, like the Favorites list when browsing the Internet.
  • Perform asynchronous report execution. For example, multiple reports can be run at the same time within one browser, or pending reports can remain displayed even after logging out of a project.
  • Element caches: Most-recently used lookup table elements that are stored in memory on the Intelligence Server or MicroStrategy Desktop machines so they can be retrieved more quickly.
  • When a user runs a prompted report containing an attribute element prompt or a hierarchy prompt, an element request is created.
  • Object caches: Most-recently used metadata objects that are stored in memory on the Intelligence Server and MicroStrategy Desktop machines so they can be retrieved more quickly.

When you or any users browse an object definition (attribute, metric, and so on), you create what is called an object cache. An object cache is a recently used object definition stored in memory on MicroStrategy Desktop and MicroStrategy Intelligence Server.


Scheduling is a feature of MicroStrategy Intelligence Server that you can use to automate various tasks. Time-sensitive, time-consuming, repetitive, and bulk tasks are ideal candidates for scheduling. Running a report or document is the most commonly scheduled task since scheduling reports, in conjunction with other features such as caching and clustering, can improve the overall performance of the system.

Time-Triggered and Event – Triggered

With a time-triggered schedule, you define a specific date and time at which the scheduled task is to be run. For example, you can execute a particular task every Sunday night at midnight. Time-triggered schedules are useful to allow large, resource-intensive tasks to run at off-peak times, such as overnight or over a weekend.

An event-triggered schedule causes tasks to occur when a specific event occurs. For example, an event may trigger when the database is loaded, or when the books are closed at the end of a cycle.


A clustered set of machines provides a related set of functionality or services to a common set of users. MicroStrategy recommends clustering Intelligence Servers in environments where access to the data warehouse is mission-critical and system performance is of utmost importance.

A cluster is a group of two or more servers connected to each other in such a way that they behave like a single server. Each machine in the cluster is called a node. Because each machine in the cluster runs the same services as other machines in the cluster, any machine can stand in for any other machine in the cluster.

  • Failover support
  • Load balancing
  • Project distribution and project failover

MicroStrategy - Clustering

For Indepth understanding of MicroStrategy click on

Review Date
Reviewed Item
MicroStrategy Architecture
Author Rating

“At TekSlate, we are trying to create high quality tutorials and articles, if you think any information is incorrect or want to add anything to the article, please feel free to get in touch with us at info@tekslate.com, we will update the article in 24 hours.”

0 Responses on MicroStrategy Architecture"

Leave a Message

Your email address will not be published. Required fields are marked *

Site Disclaimer, Copyright © 2016 - All Rights Reserved.