1. In Dev/UAT, Cache should be disabled server level itself and should not be enabled at any other level.
2. If there is any upgrade of I-Server, Metadata must be updated accordingly.
3. For a fresh setup, Dev should be duplicated into UAT/PROD rather than creating fresh blank MDs in UAT/PROD. If not done, objects won’t be get migrated using OM as both metadata would be having different Schema GUIDs. Schema GUID can be found only using OM.(I have seen some violation of this rule)
4. MD Database backup should be performed on the production environment before changes are made.
5. When a new table is added to the development warehouse and the project’s Warehouse Catalog, a logical table is created. This table can be used as a source table for an existing attribute/fact or a new attribute/ fact. When this object is ready to be transferred to the production environment, the system administrator first need to confirm the existence of the table in the production warehouse. The table should not be added to the production project’s Warehouse Catalog. Doing so will create a new Object ID for a logical table of the same name. The system administrator should use MicroStrategy Administrator – Object Manager to copy the schema object. The logical table from the development project will be copied to the production project as a dependent. If an existing schema object is in the production project, select ‘Replace’ in the Conflict Resolution Dialog.
6. Only one session of MicroStrategy – Object Manager should be open at one time.
7. Object Manager requires the destination project to have the same or newer metadata version than the source project
8. Use Multi-process mode for ODBC connectivity to the warehouse/metadata/statistics for all database/ODBC driver configurations.
9. During initial stages of project development, Attributes should be created with Automatic mapping. May be after 2-3 months, it should be changed to manual. It can be controlled using Options of WH Catalog.
10. If you use local MSTR installation to access client metadata, both must be on same version.
11. Have only one child at the lowest level else report that contains Children will ignore filters of parent(s).
12. There MUST not be any M-to-M relationship between any two attributes. Such a relationship should be broken down using Fact less fact table or a relationship table. PDF describe it in detail.
13. Metadata on OS/390 and Sybase should be avoided as MD Doctor is not certified.
14. Always take a 100% backup of metadata before running ScanMD or MD Doctor. No users should be connected to the project undergoing a fix.
15. Retain a copy of the MDDoctor.log generated by MD Doctor for any instance where the utility was run in “fix mode”.
16. Attribute lookups and relationships should generally not use fact tables.
17. Partition mapping tables for warehouse partitioning may never be used as attribute lookup or relationship tables.
18. All attributes name given in a Freeform SQL reports should be unique.
19. For a large schema, schema reading should be disabled in WH Catalog (to save time).
20. A new dependent able should not be added using WH catalog in PROD, as OM take care of it “now”. In fact doing this would add GUID inconsistency for lifetime of meatadata.
21. Use MicroStrategy (Datadirect) ODBC drivers even if you have product’s own drivers. (There are rare of rare instances (Some SQL issues) when MicroStrategy would ask you to use DBMS drivers)
22. Have a DSN naming convention.
23. Overlapped objects, Lines and rectangles, Relative paths for images, Line Breaks within text fields and Word-wrapping in grids would not be shown in Excel export of a RS document.
24. Schema objects should be created in a 2-tier connection when creating in bulk.
25. Perform a Schema update immediately before object migration.
26. Rename Administrator account to avoid hacking or better delete the account with login name Administrator.
27. Create at least three administrator level accounts to manage administrator account in case the password is lost.
28. When deleting a user, delete the profile too.
29. Avoid using Custom Groups as much as possible.
30. Not to overdo performance at the cost of correctness of report.
31. Login/password used in DNS used in MicroStrategy I-Server configuration should be a top secret. Person with bad intent can mess up metadata w/o any chance of recovery unless having backups.
32. No changes must be made into Prod server directly. There should be only object transfers into PROD environment.
33. Only in case of migration having gone bad and system can not be reverted back to the old system, change to PROD environment to make it at par with DEV/QA/UAT should be made.
34. Very limited person should have access to License Manager.
35. You can play around with Named User license ;-).
36. MicroStrategy doesn’t come to know about license violations if the I-Server restricted to access internet. (and if you are NOT doing it, don’t think that MicroStrategy, Inc. won’t come knocking your door to pay up, if there is prolonged license violations.)