bc5ac0a306776ec8e7f9d5a84615b3b1

bc5ac0a306776ec8e7f9d5a84615b3b1

1. What is the Testing acceptance requirement? Just verification, snapshot.
2. There should be some bunch of reports/dashboard for which look and feel should be verified.
3. There should be bunch of dynamic dashboard to be verified on Mobile devices.
4. If there is a Mobile Enterprise Management tools like Good or some App management tool, testing effort would be a lot more.
5. Anything deleted under Administration folder under Project Source should be under a written confirmation.
6. Several issues of MicroStrategy connectivity require changing hosts file. Organization *MUST* be able to readily changes to host file even if they have some umbrella policy.
7. All machines must have latest version acrobat reader and flash player installed.
   8.For Images and few fonts to be shown in dashboard, they need to be copied into I-Server machine.
8. No not-uplift related task should be accepted as part of uplift. Such small tasks are too much of distraction and usually run into server details or administrator rights issue.
9. All remote machines should have good # of license to connect all onsite/offshore resources.
10. All the prompt answers for any report verification to be provided by client or reports to be tested by them or any report testing that requires custom answers must be tested by business first.
11. Projects must be connected to a meaningful database with meaningful data for verification.
12. When a testing has been committed, then the testing criteria and what fulfills a minimum testing should be checked too.
13. All document expected by client should have the format provided by them.
14. As reports are required to be tested, MicroStrategy DBQuery tools should be published on Citrix and database connection information should be provided.
15. If datamart reports are required to be tested, delete right on tables should be provided for testing purpose, as testing require data to be cleaned up loaded by DM report.
16. Again for DM reports, select access should be provided for verification of dada load performed due to Datamart report.
17. All folders created, images and font copies on E1 should be replicated on E2 and E3.
18. Must not accept any development work as part of uplift.
19. All hidden folders should be unhidden during course of Web Testing
20. Everyone should have same version of MS Office
21. Only Upgrade related defects should be fixed. If it is proved by Upgrade team that defect is a known issue on the new version or a defects is due to incorrect behavior of MicroStrategy, it should be passed on to Infra or Development team.
22. Should have SELECT access on metadata database by all resources.
23. On all the installations where defects are being logged, upgrade team must have admin access.
24. Before accepting any Development/enhancement/cosmetics, even for extra money, an impact analysis must be done, it terms of breaking something stable and timeline. I just got a cosmetics request (to change all graph) from Portia one week prior to soft launch, when there are bigger defects lines up.
25. DBA team should keep on monitoring the Log file size on weekly basis and during the migration period and one week prior to that, on daily basis.
26. Criteria for an Upgrade defect must be defined.
    1. If objects are matching in both environment and still do not get matching results, this is a MicroStrategy defect not an Upgrade defect.
    2. Upgrade team should stop at all efforts after troubleshooting a defect and finding that to be a MicroStrategy defect.
    3. Upgrade team should not own fixing any MicroStrategy defects, how simple they would be.
27. 28.If an issue reappears in new version (which was fixed), Uplift team responsibility is limited to troubleshooting and providing solution but not actual implementation, unless that related specific to uplift related.

This is actually coming from a vault. Written in 2014 but still very much applicable.

1. DSNs in ODBC.ini file (in case of Unix) or DSNs in ODBC Administrator (in case of Windows) should be present on all machines having I-Server with exactly same names of DSNs.
2. After every project duplicate, disconnect and reconnect to Project Source.
3. Project duplication setting is heart of the migration. Save the XML file of all trial upgrade. Save all setting as XML file at the last screen of project duplication.
4. Database should have at least 4 times of space of base metadata to be uplifted. There should be same for DB log files too.
5. DB userid for metadata should have rights to create new table space.
6. People should have rights to delete/drop tables from metadata database, at least during upgrade.
7. As most of the operation of duplication/upgrade keeps lock of schema/configuration, avoid accessing metadata/project from other MicroStrategy components.
8. Have ScanMD installed locally to Desktop machine so that you can connect to in case of a Schema error.
9. All Servers are should be activated (License issue).
10. Always have two and three tier connections created for all metadata. ScanMD works only in 2 tier mode.
11. MicroStrategy does not show subscriptions in a 2-tier environment, even though they exist.
12. In the MicroStrategy Intelligence Server Configuration window, under Server Definition > Advanced check the “Use MicroStrategy Scheduler” checkbox. TN 41461
13. Run ScanMD is source itself before starting any upgrade/duplicate
14. Run checks on Source, duplicated and upgraded metadata
    1. 5-10 reports
    2. All objects under Administration under Project Source
    3. WH Catalog
    4. Schema update with all options
    5. Element browsing in Data Explorer
    6. Elements in Element prompt
    7. Profiles
    8. Searches
    9. Security Filters
    10. Security Roles
    11. Object Templates
15. Revisit TN Key: 6444
16. If source or in between version is 9.0.1, please check TN Key: 34570.
17. Whenever you are restarting/stopping/starting server, please check with team.
18. Command Manager connects to a three tier environment only, so it can’t be tested to verify Subscription migration. (Subscriptions can’t be seen in two tier Desktop connection). So an I-Server would be required.
19. Every time a project duplicate is fails. First delete the project fully and then restart the I-server. Never ever restart just after deletion. Restart is must so that few metadata dangling references are removed too. If there is no I-Server configured to destination, configure a one and restart it.
20. Metadata duplication/upgrade should be done during time period when server usage even by mistake is very low.
21. When a ScanMD Fix is performed on a project, the MicroStrategy Intelligence Server should be stopped, or that Project unloaded. No users should be connected to the project undergoing a fix.
22. First unsubscribe the report from MicroStrategy Desktop or Web before deleting it. TN Key: 39827
23. If Project is locked very badly that it could not be released using Administration or Object Manager, use Project Merge to unlock. TN Key: 38541.
24. To unlock schema using command Manager: UNLOCK CONFIGURATION FORCE;
25. To manually unlock project, DELETE from <tablespace>.DSSMDOBJLOCK where OBJECT_TYPE =32. There can be multiple locks.
26. ScanMD cannot make any changes to a project if the project is locked. TN Key: 34620
27. Integrity Manager requires 3 tier connection possibilities to the lower version I-Server.
28. Cubes would require republishing after upgrade.
29. Datamart report should not be executed for verification as this may hit the actual PROD database. Reconfirm, Reconfirm that it is fine to do
30. URL changes can me a mammoth task. Each change = 15 minutes id Dev and Test effort.
31. Enterprise Manager to be explicitly part of or not part of the upgrade. This is a project in itself due to the fact that I-Sever upgrade is happens in a phased manner and stats would be wanted (not needed) till the old I-Server would go offline.
32. Object Template folder report will fail in Integrity Manager as there is no data.
33. Do NOT select PDF options for reports in Integrity Manager
34. Cube status. P = Processing, A = Active, L = Loaded, D = Dirty, F = Filed, M = Monitoring Information Dirty
35. Objects dependent on a DB instances that cannot be deleted for no apparent reason. SELECT a11.object_id, a11.object_name, a11.object_type, a11.project_id, a11.parent_id FROM DSSMDOBJINFO a11, DSSMDOBJDEPN a12 WHERE a11.object_id = a12.object_id AND a12.DEPN_OBJID = `<DB Instance GUID>`
36. For all the I-Servers, you must have rights to select the Database Instance, ODBC and to create ODBC
37. Reports with object prompt and text prompt cannot be tested using Integrity Manager.
38. Never ever copy/paste report for re-rganization of reports as new GUID would be generated. They must be always cut/paste.
39. Goto Tools -> My Preferences -> Editors -> Show Advanced qualification if you can’t edit Apply function filters in spite of being Administrator.
40. Edit KSH file in notepad only
41. If some report is not bringing any data, Prompt summary should be shared by tester.
42. Resource working on duplication/Migration should have appropriate rights. Specially the READ only OM rights
43. A foolproof method for users to check new URLS should be devised. A common problem whenever there is a upgrade and suddenly there is flood of emails by users that old application is not working.
44. Caching must be disabled on Server level in E1 and E2 which is the standard practice across any enterprise application in Dev/UAT environment.
45. All element prompts should be checked.
46. For E2-E3 migration, use E3 box not E2 box.
47. MicroStrategy Schedule options meaning
    a) History List – To send the report or document execution to history.
    b) Cache Update – Scheduled reports generate their own SQL and thus create new cache files. To update the existing cache instead of creating a new one, the Cache Update delivery type should be used.
    c) Cube Refresh – To refresh all Intelligent Cubes currently published.
    d) Mobile – To send the report or document execution to the mobile device.
48. Subscription Properties:
    a) Run Subscription Immediately: To send the report or document to the selected recipients immediately after creating the subscription.
    b) Expire Subscription on – Select Expire subscription on and select a date to configure when the subscription will stop sending reports or documents.
    c) Send Notification to default email address of each recipient – To have an automated delivery notification email sent when the report or document is delivered.
    d) Allow recipients to change delivery settings – To allow recipients to change delivery settings. For example, when this option is enabled, users can change prompt answers or change the time of day that a report or document is sent.
    e) Allow recipients to change personalization – To allow recipients to edit the subscription properties.
    f) Allow unsubscribe – To let users cancel their subscription.
    g) The new scheduled report will overwrite older versions of itself – To ensure that previous versions of the report in the recipients’ delivery location will be replaced with the most recent version. If not selected, the older versions will remain.
    h) Re-run against the warehouse – To retrieve data from the warehouse when the scheduled report or document is executed by the system.
    i) Do not create or update matching caches – If checked, existing matching caches are not updated and new matching caches are not created. A new history cache is created or an existing history cache is updated.