What Types of Security are there in MicroStrategy Agent 7.1?
In a MicroStrategy Agent 7.1 environment, security can be regarded at three levels:
Database
Network and operating system
Application
MicroStrategy Agent 7.1 provides the means to implement new security features while allowing full implementation of existing enterprise security measures.
Database security:
In addition to any security features provided by system servers, MicroStrategy Desktop offers the capability to limit database access through security views (any one user may have access to only a portion of any one table).
Network and operating system security:
MicroStrategy Agent 7.1 allows full implementation of existing network security (which affects computer access) and operating system security (which affects file and application access).
Application security:
MicroStrategy Desktop provides four modes for users to authenticate user access to the system:
Standard (system login ID and password)
Trusted (Windows NT login and password)
Pass through (metadata login ID and password)
Guest authentication (server login and password)
Server control:
In a MicroStrategy environment, there are two types of access control:
Privileges (actions that any one user or user group may perform within the system)
Object access (objects, and access conditions to those objects, that any one user or user group has)
Web security:
MicroStrategy Web provides security features particularly suited to internet environments, including:
Special login access for casual users
Full integration with Windows NT trusted access
Independence from downloadable code
Integration with MicroStrategy Intelligence Server access control
See MicroStrategy Knowledge Base document TN4000-7X0-0674 for additional information
What is new in MicroStrategy Narrowcast Server 7.1?
TN6200-071-0073
Subscription Portal:
Intuitive Subscription Portal enables self-subscription to information services via any Web browser.
Users define preferences and delivery addresses via the Subscription Portal.
Users can create, edit and delete user names, passwords and device addresses on each site.
Users can choose schedules for each service and save personalization settings for future use.
Users can manage their profiles specifying the appropriate default languages, time zones and currency settings.
User authentication at the Subscription Portal site ensures that users only have access to the appropriate information.
Users can publish and view services via the Subscription Portal website.
Existing MicroStrategy InfoCenter applications can be upgraded.
Portal Design Wizard enables rapid and easy development of Web-based subscription portals.
Portal Designers can set default settings such as language and Dynamic Hyper Text Markup Language (DHTML) usage.
Portal Design Wizard supports all MicroStrategy 7 prompt types and styles.
SMS Transmission:
SMS transmission capability is provided.
MicroStrategy Narrowcast Server Demonstration:
Integrated Demonstration illustrates Subscription Portal and Delivery Engine component functionality.
Software Development Kit:
Sample code is provided for MicroStrategy Narrowcast Server information source modules, document formatting modules, information transmission modules and the Narrowcast Server application program interface.
Improved documentation is included for the MicroStrategy Narrowcast Server Software Development Kit.
Installation:
A single installation supports the Subscription Portal, Delivery Engine, Narrowcast Administrator and integrated demonstration.
This application demonstrates how a report can be constructed very easily from an arbitrary list of attributes, metrics and elements. It also shows how to add a metric qualification on the report.
After connecting to a project, users are provided with a list of all attributes and metrics in the project. A user can click on any single attribute, to view the elements of this attribute. A user could construct a report by choosing any of these objects.
When adding a metric qualification on the report, a user can choose to qualify the value, rank or percentile of any existing metrics, calculated at any attribute level.
Usage:
1.Choose the data source you want to connect in the Data Source Name drop down box, and click Connect.
2.A login form appears. Type in your login and password in the text box or check Use trusted security check box. Then click Login.
3.Choose a project from the Project drop down box, change your login/password if it is different from the login/password of the data source.
4.You are now returned to the main form. You can browse in the left plane. Click on the + icon of an attribute to retrieve the list of elements of this attribute. From the left plane, choose the attributes, metrics or elements that you want to include in your report. Click >> to move them to the right plane.
5.If you want to add a metric qualification to your report, check the Add Metric qualification check box.
6.Click Execute.
·If you did not check Add Metric qualification check box, you now see the report result grid.
·If you did check Add Metric qualification check box, you are prompted with a Metric Qualification form.
7.Choose a metric on the Metric drop down box. Choose an attribute on which level this metric would be calculated. You can then select the option of qualifying on its value, rank or percentile. Choose an operator from the Choose an operator drop down box and type in the value in the Specify a value box(es).
8.Click Apply to apply the defined metric qualification to the report.
9.The report result grid appears.
Excel Add-In:
Description:
The Excel Add-In sample shows you how to access the MicroStrategy environment and run reports through the Microsoft Excel interface.
This VBA application allows you to connect to an existing MicroStrategy 7.0 project and retrieve a list of all reports in this project. You can choose to run any report and view the report grid in the Excel work sheet.
Usage:
1.Double click on file Doexladd.xla in your Windows Explorer to open this application directly. Click Enable Macros if such a window appears. You can also open Microsoft Excel. Go to Tools Add ins…, and browse to find the Doexladd.xla in your machine. Check the option Microstrategy 7.0 Add in. You will see a Microstrategy 7.0 SDK menu appears on the menu bar.
2.Click Microstrategy 7.0 SDK menu. Choose the item Select project…. A Select a project form appears.
3.Choose in the left plane List of registered projects a data source that you want to connect to. Provide the login/password. Click Connect.
4.A list of project appears if you selected a 3 Tier data source. Provide the login/password for the project and click Connect again. The Select a project form is not visible.
5.Click on a cell in the excel work sheet where you want the report to start.
6.Go back to the Microstrategy 7.0 SDK. Choose Run Report. A Select a report form appears. (You can still choose Select Project… item if you decide to connect to another project.)
7.Wait while the report in the project loads. Choose a report that you want to run. The report is in alphabetical order by its name. The Path text field shows the location of the report.
8.Select a report in the available report list and click Run.
9.The report result grid appears on the work sheet, starting from the cell that you previously selected.
Hello World (VB):
Description:
This simple(one-button-click) application shows the basics of how to execute a report in VB. It connects to the SDK_Demo datasource, logs in as administrator, executes an existing SDK Sample Report and shows the data part of the result set.
Usage:
Click Execute button. The result grid appears.
Hello World (VC):
Description:
This simple(one-button-click) application shows the basics of how to execute a report in VB. It connects to the SDK_Demo datasource, logs in as administrator, executes an existing SDK Sample Report and shows the data part of the result set.
Usage:
Click Execute buttion. The result grid appears.
MiniAgent:
Description:
This VB Sample application demonstrates a basic set of features that can be executed through the MSTR 7.0 Base API.
Working through this sample, users can learn how to connect to a project, browse objects, search for objects of a certain name, obtain filter expressions from a filter object, obtain template layout information from a template object, obtain report template and filter information from a report definition object. Furthermore, users can execute a report definition object while controlling or observing the stages of the execution. Users can also inspect the SQL statements that were executed and see the execution result grid.
Usage:
1.Click Enum Data Sources. A list of registered data source appears.
2.Select the data source you want to connect to and click Login. A login form appears.
3.Provide the login credentials to log in the data source in the login form and click Login. You return to the main form.
4.Choose a project you want to connect to in the Projects under Data Source list box. Click Get Session. Again, the login form appears.
5.Provide project login credentials if they are different from previous. Click Login.
6.If you have successfully created a session, the form extends to show the Part II Basic Object Access plane.
7.You can browse a folder object in the Children plane by clicking on the up arrow button to go to its parent folder. Or, click on the down arrow button to get the items that are contained in the selected folder.
If you selected a Filter object, click Filter Info to see the filter expression of the selected filter.
If you selected a template object, click Template Info to see the template units on the selected template.
If you selected a report definition object, click Report Info to see the filter and template information of the selected report definition.
If you selected a report definition object, you can also execute this report. Click New instance. The plane extends to show Part III Report Execution. Choose which stage you want the report to be executed in the Actions drop down box and click Execute. Meanwhile, you can view the state of the report execution at the State: text field.
If View SQL is enabled, you can view the executed SQL for this report.
If View Grid is enabled, you can view the executed result of this report.
Does MicroStrategy Web support clustering via Cisco Local Router or any other third-party clustering software?
MicroStrategy Web relies on third-party web-clustering software to provide clustering functionality. MicroStrategy Web is designed to be stateless so that each individual MicroStrategy Web node can function without the knowledge of the existence of other nodes. Therefore, any third-party software used to cluster web servers can be used.
What information is shared by the application across MicroStrategy Web nodes?
MicroStrategy Web is designed to be as stateless as possible. Therefore, no information is shared by the MicroStrategy Web application across cluster nodes. All state information for running jobs is pushed to the client browser.
When a report is submitted by a MicroStrategy Web user, the user will receive a wait page in the client browser. This wait page will poll the MicroStrategy Web Server periodically for the status of the report. This polling is performed as new http requests. This http request will contain all state information, including encrypted login information and MicroStrategy Intelligence Server connection information.
Is MicroStrategy Web "cluster-aware"?
The MicroStrategy Web application is designed so that each MicroStrategy Web cluster node does not need to know that it is a member of a cluster. MicroStrategy Web is designed to be stateless, so that each client http request can be processed individually without having to persist information within the MicroStrategy Web application. Therefore, third-party Web-server clustering software can be used to cluster together multiple web servers running MicroStrategy Web.
Should MicroStrategy Web be specifically configured to access a MicroStrategy Intelligence Server cluster?
No. When the administrator configures MicroStrategy Web to access a particular MicroStrategy Intelligence Server, the MicroStrategy Web application will automatically detect that the MicroStrategy Intelligence Server is a member of a cluster. Once this detection is made, MicroStrategy Web will automatically add all the other members of the same cluster into the pool of available MicroStrategy Intelligence Servers.
What information is shared by the application across MicroStrategy Intelligence Server nodes?
Report caches are shared in a cluster and Object caches on each MicroStrategy Intelligence Server node are synchronized.
Is a copy of each report cache retained in each MicroStrategy Intelligence Server node?
No. Each MicroStrategy Intelligence Server retains a lookup table with information about the existence and location of report caches. When a cluster node creates a report cache, information about the location of the new cache is shared with the other cluster nodes. Each cluster node then updates its own lookup table with the location of the new cache.
If a MicroStrategy Intelligence Server node crashes, will report caches be lost?
Although report caches will not be lost, access to report caches may be affected, depending on the way in which the report cache is configured.
If a separate file server is used as a common report cache repository for all MicroStrategy Intelligence Server cluster nodes, then the loss of a cluster node will not affect access to the report cache by other nodes.
If the cluster is configured such that each node locally hosts the report cache created by that node, then those report caches residing in the lost node will naturally be inaccessible. If any report cached in that lost node is requested, then another node within the cluster will re-run and re-cache the report. When the cluster node is recovered and rejoined into the cluster, all report caches in that cluster node will be made available again to the rest of the cluster.
If a MicroStrategy Intelligence Server node is removed from a cluster manually, will report caches be lost?
If an administrator removes a cluster node from a cluster, then all report caches that had been created by that cluster node will be inaccessible by the rest of the cluster, whether or not a separate file server is used as a common report cache. This behavior is by design.
How does MicroStrategy Intelligence Server 7.0 clustering enable cache sharing?
Each node in a MicroStrategy Intelligence Server 7.0 cluster maintains indices of the caches available on the different nodes. When a report is submitted, these indices will be searched and once an existing cache is found (in any nodes), the cached results will be retrieved directly from cache locations in either the local or remote machine.
What methods can be used to guarantee availability of the MicroStrategy Intelligence Server report cache?
To prevent the loss of a MicroStrategy Intelligence Server cluster node from affecting report cache availability, the cluster can be configured such that a separate file server is used as a common report cache repository. In order to maintain cache availability, this separate file server can be configured for failover with third-party clustering software.
If a report cache is created by a MicroStrategy Intelligence Server cluster node, will that report cache be seen in the Cache Monitor of another cluster node?
No. Although the new report cache will be available for use by other cluster nodes, the cache will not appear in the Cache Monitor of other cluster nodes. In order to see all report caches within a cluster, the administrator will need to create a separate data source within Desktop for each cluster node. Then, the report caches within each node can be administered separately, using the same instance of the MicroStrategy Desktop application.
If objects are created, modified or deleted, will the change be reflected across all MicroStrategy Intelligence Server cluster nodes?
Yes. Object caches are synchronized across all cluster nodes. If any change affecting the Metadata is made by one cluster node, then the cluster node broadcasts the change to the other cluster nodes. The other cluster nodes will then update their local object caches.
NOTE: Client-side object caches will not be automatically be refreshed. In MicroStrategy Desktop, for example, a user may have to explicitly click on 'Refresh' to see an object change be reflected in the client application.
Should all MicroStrategy Intelligence Server cluster nodes be configured identically?
Technically, MicroStrategy Intelligence Servers in a cluster do not have to be configured identically. The only technical requirements are that all MicroStrategy Intelligence Servers point to the same metadata and that all MicroStrategy Intelligence Servers have the same projects registered and in the same state (i.e., if Node A has Project A in a 'Loaded' state, then Node B must also have Project A in a 'Loaded' state.).
However, in order to ease administration and to reduce the risk of unbalanced load across cluster nodes, it is recommended that all nodes use the same MicroStrategy Intelligence Server definition and that each machine shows identical characteristics (i.e., equal RAM, hard disk space, CPU).
Is it possible for different nodes of a MicroStrategy Intelligence Server cluster to run against different metadata repositories?
No, all the nodes in the same cluster must run against the same metadata.
Is it possible for different nodes of a MicroStrategy Intelligence Server cluster to run with different configuration settings under the same metadata repository?
Yes this is possible, using caution because users can configure different nodes at different settings. For example, differences in memory allocation for the cache, time out settings, etc can result in uneven performance across cluster nodes.
What communication protocol does MicroStrategy Intelligence Server use for intracluster communication?
MicroStrategy Intelligence Server 7.0 and MicroStrategy Intelligence Server 7.0 SP1 use TCP/IP when communicating between clusters. MicroStrategy Intelligence Server 7.1 will provide the option of using TCP/IP or UDP/IP (Universal Datagram Protocol). In 7.2, UDP support was removed as packet loss affects cluster synchronization.
If a MicroStrategy Intelligence Server cluster node is rebooted, will the node rejoin the cluster automatically?
Whenever a MicroStrategy Intelligence Server cluster node is stopped in any way besides explicitly shutting down the MicroStrategy Intelligence Server service, the node will automatically rejoin the cluster when the MicroStrategy Intelligence Server service is restarted. So, if the node crashes, then the node will rejoin the cluster automatically upon startup.
Does MicroStrategy Intelligence Server support clustering via Microsoft Cluster Server or any other third-party clustering software?
Microsoft Cluster Server (MSCS) can be used for failover of MicroStrategy Intelligence Server. However, MSCS and other third-party clustering software will not provide the load-balancing and some of the failover capabilities of MicroStrategy Intelligence Server's native clustering solution.
Is it possible to run multiple instances of MicroStrategy Intelligence Server on the same Microsoft Windows NT machine?
MicroStrategy 7.0 does not support running multiple instances of MicroStrategy Intelligence Server on the same Microsoft Windows NT machine. This is because MicroStrategy Intelligence Server can support running multiple projects with different prioritization and configuration settings on one server. This functionality was not available in MicroStrategy DSS Server 5.x and thus, required running multiple instances of MicroStrategy Intelligence Server to accomplish the same functionality.
What is the maximum number of nodes that can be supported in a MicroStrategy Intelligence Server 7.0 cluster?
There is no technical hard limit on the maximum number of cluster nodes that can be supported by MicroStrategy Intelligence Server 7.0. However, when the number of nodes increases, there is increasing overhead put on the system by the clustering software. So, there will be practical limits related to the hardware configuration of the users' system.
How is caching different and/or improved in MicroStrategy 7.0?
The MicroStrategy 7.0 architecture offers greatly improved caching support with respect to administration, security, prompting and subsetting.
There are three types of requests for which MicroStrategy 7.0 uses caching to improve response times:
Metadata object requests. Frequently used metadata objects (i.e., templates, filters, reports, metrics, custom groups, consolidations, attributes, etc.) are stored in memory, in addition to the metadata repository, so they can be retrieved more quickly.
Lookup table element requests. Frequently used lookup table elements are stored in memory, in addition to the warehouse database, so they can be retrieved more quickly.
Report execution requests. Pre-calculated and pre-processed report results are stored in memory, and on disk, so they can be retrieved more quickly than re-executing the request against the warehouse database.
Space limits for caching are created when a project is initialized. In two-tier mode, an object and element cache exists in memory on the client for each project that the client accesses. In three-tier mode, for each project an object, element and report cache exists on the server (in memory for all and also on disk for report requests), and only an object and element cache exists in memory on the client. MicroStrategy 7.0 also provides strong cache administration functionality, including cache backup, cache loading and/or unloading from memory, cache updating, cache expiration, cache invalidation, and cache status.
Cache retrieval is affected by multidimensional security. Multidimensional security (also knows as the security filter) is the feature set that allows a data filter to be assigned to a project-user combination. Whenever a user runs any report within a given project, the security filter is applied to the underlying query. When a report request hits a report cache, the cache-matching algorithm accounts for the user of security filters.
Caching has also been improved to support prompts. When a report is cached, it is indexed by the answers to the prompts used for the report. In order to retrieve results from the cache, a report request must include the exact same prompt answers as the execution that created the cache. When using server caching, the user is prompted for prompt answers before the cache-matching algorithm checks for a cache match. A common usage scenario is to be able to have a prompted report use the cache, regardless of what the user requests.
What types of flat files does the report cache on the MicroStrategy Intelligence Server 7.0 create? Are they accessible from other tools?
Report caches stored on disk on the MicroStrategy Intelligence Server 7.0 are in a preprocessed, proprietary format. Therefore, they are not accessible by means other than the MicroStrategy COM API. Datamarting is implemented in MicroStrategy Intelligence Server 7.1 to address this requirement. Element and Metadata Object caches only exist in memory and are not stored on disk, unlike Report caches.
Can a SQL generation request be cached?
Yes, a SQL generation request can be cached. The next time the same report is run, the SQL is retrieved from the cache instead of being generate at the runtime.
Is there a setting that can control the client side cache?
There are no exposed settings regarding the client side cache.
Is there an expiration time for the different caches?
For the report cache default, the expiration time is 24 hours, but it is configurable up to 999,999 hours. For element cache and object cache there is no expiration time setting. The only ways of removing them are either purging the caches from the project configuration or restarting the MicroStrategy Intelligence Server.
Will Cache files be created when Caching is turned off at the Project Configuration?
If the History List (Inbox) is enabled, cache files will still be created.
Are there any special requirements needed to move objects across projects? Yes. In order to perform cross-project operations, the projects involved must originate from the same source project. In other words, the projects can only be related by the duplication of a single project. This ensures that the projects have a similar set of schema and application objects, and that the object ID's in the two projects are the same. MicroStrategy Object Manager uses the object and version ID's across the projects to perform comparisons. MicroStrategy Object Manager prevents the user from attempting operations across unrelated projects.
How does MicroStrategy Object Manager determine if two projects are related? MicroStrategy Object Manager compares the Schema ID's of the two projects. Duplicated projects have different Project ID's, but their Schema ID's are the same.
What is the Conflict Resolution Window?
The Conflict Resolution window provides the user with a means to decide how to handle object conflicts between the source project and the destination project. In addition, the Conflict Resolution window displays the object name in the original project, the object name in the destination project and the type of conflict. Users may also specify a new name for the object depending on the action chosen. A sample of the Conflict Resolution grid is shown below:
How does MicroStrategy Object Manager determine if two objects in different projects are the same? To determine if two objects are the same, MicroStrategy Object Manager compares their Object ID's. If these ID's are the same, MicroStrategy Object Manager then compares the Version ID's. If the Version ID's are the same, the Conflict Resolution grid lists the conflict as 'Exists Identically.' If the Version ID's are different, the Conflict Resolution grid lists the conflict as 'Exists Differently.'
How can the user determine the Object ID of an object?
To view the Object ID of an object, right-mouse click on the object and select 'Properties.' The Object ID and Version ID are listed on the 'General' tab.
Why does MicroStrategy Object Manager search for object dependencies?
MicroStrategy Object Manager makes a list of all object dependencies before copying an object to prevent metadata inconsistency. The time required for dependency checking varies based on a customer's metadata size and schema complexity. For large metadata and complex schemas, gathering all the dependencies may take a long time.
Can schema objects be copied across projects with MicroStrategy Object Manager?
Yes, schema objects can be copied across projects using MicroStrategy Object Manager. MicroStrategy Object Manager moves objects seamlessly between similar projects such as from a development project version to a production project version where the warehouses are the same in terms of views, prefixes, and warehouse structure. However, subtle changes in the warehouse that relate to prefixes, views, or table structure cannot be tracked by MicroStrategy Object Manager. For situations where the projects' warehouse structures or setups are dissimilar, users may be required to make further edits of the objects to ensure full integration into the destination project. These edits may include hierarchical relationship changes or modifications to the prefixes.
How does MicroStrategy Object Manager integrate with the MicroStrategy Product Suite security model?
Security in MicroStrategy Object Manager is based on the MicroStrategy 7.x Product Suite security model. All activities that can be performed in MicroStrategy Object Manager are governed by privileges and access control lists. For example, if a user is not allowed to access a certain folder in MicroStrategy Agent, they will not be able to access the folder in MicroStrategy Object Manager.
Is it possible to use MicroStrategy Object Manager while other users are making changes in MicroStrategy Agent? Using MicroStrategy Object Manager to copy/move objects around is not recommended while other user sessions are making changes using MicroStrategy Agent, as it could lead to metadata inconsistency. Project and schema locking prevent multiple users sessions from manipulating the schema at the same time. This prevents metadata inconsistency from occurring.
What are the tracing options available in MicroStrategy Object Manager?
Tracing is available under the Tools/Diagnostics menu. These tracing options apply to every MicroStrategy product installed on the machine.
To see the SQL that has been executed against the metadata, go to the Advanced tab and turn on 'SQL Tracing' under the DSS MDServer key.
Function level tracing can be accomplished by going to the Advanced tab and turning on 'Function Level Tracing' under the DSS ObjectManager key.
Where are dependent objects copied if they do not already exist in the destination project?
If the location exists in the destination project, the dependent object is copied to that location. If the location does not exist in the destination project, a new folder entitled 'Dependencies' is created and the object is copied to that folder.
What happens if the owner of an object does not exist in the destination project?
If the owner of the source object does not exist in the destination project, the user login for the destination project takes ownership of the object when it is copied or replaced.
Where can users find more information on MicroStrategy Object Manager?
Further information can be found in the release notes, as well as in MicroStrategy Object Manager's online help.
