KB33051: Explanations and Reasonings to common questions asked by MicroStrategy Technical Support when troubleshooting issues in MicroStrategy Web

Starting with the release of Strategy ONE (March 2024), dossiers are also known as dashboards.
The following is a list of common troubleshooting questions that can be asked by Strategy Technical Support when troubleshooting an issue in Strategy Web. An explanation is provided for each regarding the reasoning behind these requests. When reviewing this Article, there are several points to keep in mind:

• Action items may not be included as the troubleshooting steps may differ based on the answers and results from customer environments.  
• Many of these questions are designed to help isolate the scope of an issue and to narrow down the possible suspects, therefore most of them may not resolve an issue or provide an immediate solution on their own.  
• Technical Support strives to tailor questioning to each specific issue, so this is not structured as a comprehensive checklist for customers to go through and answer. Technical Support may ask one, several, or even all of these questions in order to gain a better understanding of an issue and how to proceed.

• Is this environment on a supported configuration?
  It is important to check that all the various Strategy components of the environment are on a Certified configuration; to confirm this, review the Certified Dossier .
  If an environment is not on a supported configuration, there is no way to tell if the unsupported configuration is the cause of the issue or not, as Strategy has never tested that configuration. Thus, this question is commonly asked to ensure the customer environment is one in which the application has been tested.
  
• Is the issue reproducible in Strategy Developer?
  Most of the actions in Strategy Web are actually not handled directly by the Web Server. The requests are forwarded to the Strategy Intelligence Server and the results are sent back through the Web Server to the client machine. Thus, an issue that is caused by or comes from the Intelligence Server will most likely be reproducible in Strategy Developer. When this is the case, it effectively removes the Web Server from the equation, and thus the issue should be resolved first in Developer. Resolving the issue in Developer will usually resolve the issue in Web as well, while the reverse is not necessarily true.
  
  Note: To effectively perform this test, ensure that the Strategy user that can reproduce the issue in Strategy Web is the same one testing in Strategy Developer. If this user does not have access to Strategy Developer, temporarily give them the privileges to access Developer, perform the test, then revoke the privileges.
  
  If the problematic object is a Report, run it as is in Strategy Developer.
  If the problematic object is a Report Services Document (RSD), run it in Strategy Developer to PDF mode.
  
• When did the issue start occurring?
  It is helpful for Strategy Technical Support to know when an issue started occurring or was first noticed. Knowing when an issue began, Technical Support can investigate what other events may have occurred that indirectly caused the issue, such as an upgrade, migration, data load, network change, security updates, user modifications, etc. More often than not, there is a reason an issue “just started happening one day”, though Technical Support does not rule out random events as a suspect.
   
  
• What time did the issue occur?  Is there a pattern to occurrences?
  Knowing the time an issue occurred is vital when reviewing error and diagnostic logs. Multiple errors can be logged by the servers within a short period of time, thus being able to isolate a timestamp in the logs helps Strategy Technical Support pare down logs and rule out errors that did not occur at the time reported. When multiple logs are obtained, Strategy Technical Support can also cross reference errors between the logs using the timestamp, and identify what errors in other logs are related.  Also, knowing the time an issue occurred can help determine whether the issue may be linked to certain events such as high user concurrency situations or server restarts.
   
  
• Are there any customizations in the Strategy Web environment?
  If a customization is in place, Technical Support will request that the customization(s) be disabled or an out of the box environment is tested for the same issue. The reasoning is similar to the question about being on a supported configuration: Strategy only tests out of the box configurations for certification, thus there is no way to tell if an issue is caused by a customization or not, unless a non-customized environment is also tested.  If an issue exists in a customized environment, Technical Support needs to ensure that the issue is also present in a non-customized environment, and will attempt to resolve the issue in that environment only.  If a customization is identified as the cause of the issue, Technical Support can then make a determination on how to proceed.
  Technical Support recommends maintaining an out of the box Web interface available for this reason.  Instead of having to disable customizations or remove plugins on an environment, customers can simply access a separate environment to check the out of the box installation. 
  
  To determine if the issue is caused by a customization, the Strategy Web Administrator should remove all of the plugins from the plugins folder, restart the server, and test the issue again. If the issue persists, the plugins can be put back in the plugins folder and report this to Strategy Technical Support.
  If the issue goes away after removing all plugins, the Administrator should put them back one plugin at a time, testing the issue each time, until a particular plugin has been found to be the culprit. Then report the findings to Strategy Technical Support. 
  
• Are there any load balancers, web server clusters, secure socket layer (SSL), demilitarized zones (DMZ), proxy servers, firewalls, or other network layers or third party features, like antivirus software, enabled?
  Since Strategy Web runs as an application within a 3rd party Application Server and sends requests over the network to both the Intelligence Server and client machine, many network features can be implemented for security or performance purposes.  However, these features and implementations can also play a role in an issue, thus Strategy Technical Support needs to be aware if any exist with the application.  To go back to the common theme, Strategy tests only a base configuration, and thus any additional features could contribute to an issue, and Technical Support may request that they be disabled in order to identify if they have an effect.
   
  
• Which combinations of Web Servers and Intelligence Servers exhibit an issue when a cross server test is performed?
  If a customer has multiple environments to test with (Dev, QA, UAT, etc), Technical Support may request a cross server test. A cross server test is useful in determining if an issue lies with a specific server or combination of servers.
  To perform a cross server test, the basics are to test a different combination of servers.
   
  In the following diagram, let’s say an issue occurs with combination A: Web Server 1 to Intelligence Server 1. 
  A separate combination B of Web Server 2 to Intelligence Server 2 has been tested and the issue does not exist on that environment.
  So, the other combinations can be tested: combination C, Web Server 1 to Intelligence Server 2, and combination D, Web Server 2 to Intelligence Server 1.
  

•  
  Based on the results, the problematic server can be identified:
   
  If combination C fails, then the issue is with Web Server 1, as that is the common server.
  If combination D fails, then the issue is with Intelligence Server 1.
  If combination B failed initially, then the issue exists in multiple environments, but that is also helpful information for Strategy Technical Support to know.
  To perform the cross server test, log into the Web Server 1 Admin page and connect to the Intelligence Server 2. Note that it is not required to disconnect Intelligence Server 1 to perform this test.
  Then log into the Web Server 2 Admin page and connect to the Intelligence Server 1. Note that it is not required to disconnect Intelligence Server 2 to perform this test.
  
  When done, fill in the blanks and provide the following to Strategy Technical Support:
  Web 1 > IServer 1 = Fails
  Web 1 > IServer 2 =
  Web 2 > IServer 2 = Works
  Web 2 > IServer 1 =
  
• Does the issue happen with one user, several users, specific user groups, or all users including the Administrator?
  Narrowing down the cause to specific users or group of users can help Strategy Technical Support identify if an issue is perhaps a privilege or a permissions issue, or if Security Roles and Filters need to be examined. For example, if an issue happens to all users except a Strategy Administrator, then the likelihood of it being an Access Control List (ACL) permissions issue is good, since a Strategy Administrator bypasses all security on objects. In light of this, a very simple way to check for a permissions issue is to temporarily provide a problematic user with the Administration level privilege ‘Bypass all object security’. If enabling this setting resolves the issue, the cause is object ACLs.
  Note: Be sure to disable this privilege after performing this test, as enabling it could cause out of compliance issues and thus should not be a permanent solution. To do this, login to an environment in Workstation, navigate to Users & Groups - All Users, right click the user and select Edit User - Privileges and check the "Bypass all object security access checks" under "Server - Intelligence" as seen in the following image:
   
  

• Does the issue happen on one client machine, several machines, or all machines?  Does the issue occur when using the Web Server machine as a client machine as well?
  Narrowing down the cause to specific machines can help identify if the issue resides on individual machines, or affects an entire end user environment.  For machine specific issues, Technical Support can then suggest looking at client level areas such as Operating System version, browser version, user domains, locations, etc.  When multiple machines or all machines are affected, the troubleshooting focus can then shift away from client-side towards either the web server or even network, with like proxy servers, firewalls, or network hops between server and client machines.
   
  
• Does the issue happen in other browsers?
  Technical Support may request customers to test other browsers to see if an issue persists. Narrowing down the issue to a specific browser can help identify the cause to be the browser’s request handling, preference settings, plugins, add-ins, limitations, or even defects.
  Note: Other browsers tested should still be part of the Certified configurations list.
   
• Does the issue happen in other Strategy projects?
  There are preferences and privileges that are set on the project level, and thus could occur in one project and not another. When this is the case, comparing the preferences and privileges between one project and the other can pinpoint the cause.
   
  
• If the issue is in a Report Services Document, does it happen in all of its execution modes, or is it specific to only one of them?
  It is very common that certain issues only occur in Presentation mode but not in Editable mode.  Narrowing the issue down to a specific Mode can help Strategy Technical Support pinpoint a defect or limitation of the product, as well as aid in setting up reproduction scenarios to determine if a resolution exists or if the issue needs to be logged.
   
  
• Does the issue happen to only one Report, Document or Dossier object, multiple objects, or to all existing objects?
  Identifying if an issue is only specific to a certain object is helpful, as it narrows down the potential suspects, since a Report, Document or Dossier will only use a finite subset of Strategy objects: attributes, metrics, filters, etc.
   
  
• If the issue only happens to one Report, Document or Dossier object, does the issue still persist if the object is recreated?
  Narrowing down the cause to existing Report, Document or Dossier objects or new objects can help determine the origination of the issue. If the issue only occurs with existing objects, Strategy Technical Support can further investigate if the issue is isolated to that one object instance, or if it was caused by another factor, such as an upgrade or migration. This is mainly a troubleshooting step and not intended as a solution.
  
  Note: Refer to the question below for more information on how to approach this.
   
  
• Is the issue with the entire Report, Document or Dossier object or just one of its components?
  Narrowing down the cause to only a component of the Report, Document or Dossier object can save a lot of guesswork, as recreating a component will be fairly easier than recreating the entire object. To discover this, two paths can be followed:
  
• One by one, remove components from the object and test again. For reports, this can mean filters, prompts, attributes, metrics, etc.  For Documents and Dossiers, this can also include selectors, panel stacks, dynamic text fields, images, etc. If the issue goes away after a certain object is removed, the object can be re-added to see if the issue returns.
• Start recreating the object from scratch, ignoring formatting.  Add components one by one into a new report, document or dossier object and test at intervals. If the issue reappears, undo the last addition(s) and verify that the last items added are the actual cause of the issue.
  
  Strategy Technical Support understands that the process of recreating a document might be time consuming. However, depending on the issue, the following test would suffice:
  
  A) Create a new document.
  B) Place all underlying reports in the document, without placing any of them in the template sections.
  C) Test.
  D) Drag all datasets into the template section, without any order or formatting.
  E) Test.
  F) Export the document template from the original document using the Portable Documents feature and import it into the new one created in step A. Match the objects to the formatting imported.
  G) Test.
  
  Report back to Strategy Technical Support the result of the tests.
• Does the issue happen in a Strategy Tutorial Project?
  Narrowing down the cause to a Metadata will pinpoint the cause to a specific schema issue and will make the difference between discovering an environmental schema or data-related specific issue or a defect of the software.
  

 
As mentioned this Technical Note is not designed to be a checklist where customers need to answer all the questions in order for Technical Support to assist.  It's intention is to serve as a resource regarding why Technical Support may ask certain questions, and perhaps by knowing some of the questions beforehand, customers can be better prepared to provide such requested information or can at least ensure that access to this type of information is readily available if necessary.