In this post I would walk you through some of the important pointers on the cloud environment which can help you be prepared before you embark upon the cloud journey with MicroStrategy. Please note in the following 'customer' would mean the purchaser of MicroStrategy Secure Cloud license.
1> Remote Desktop: A Windows machine, also hosted on AWS, is provided with all the MicroStrategy client utilities installed. This windows desktop could be remotely accessed over open internet using the remote desktop protocol (RDP). You would just need to use the terminal services client from your personal Windows machine to connect this remote server.
This remote server is the environment where all development or administrative activities using client utilities (Command Manager, Integrity Manager, Object Manager etc.) need to be carried out.
If you are trying to access this remote machine from within a firewall enabled corporate network then there is one point you may need to consider. Generally when firewall is opened for accessing external IPs then the white-listing is done based upon IP and Port. But here there is a catch.
The Amazon Elastic Load Balancer causes the IP of this remote machine to change; the IPs are generally picked from within a specified IP range. Thus you may need to open the firewall for all the IPs which are there in range to ensure that you are able to access the remote machine at all times even if the there are changes in the IP. Please keep this in view while setting up connectivity from corporate network.
2> Cloud Admin Portal: Cloud Admin Portal is the single portal from where all the MicroStrategy LDAP users could be administered. All the user management activities like user creation, user group creation, role creation, assignment of user groups or roles, password reset etc. could be carried out from this portal.
If you would only use the MicroStrategy LDAP authentication then the users managed through this portal would be able to access MicroStrategy Project from both MicroStrategy Web and Developer.
However, if you would integrate MicroStrategy with your corporate LDAP authentication then the users maintained in Cloud Admin portal could be used to access from MicroStrategy Project from Developer. For Web, authentication would be taking place against your corporate LDAP server.
3> Shared Drive: A shared drive hosted on cloud is provided to enable sharing of documents and files between the cloud and on premise desktop / laptop of the customer. The shared drive could be accessed like a normal shared path from the Cloud remote server. You can connect the drive from your on premise desktop / laptop using WinSCP client through SFTP protocol.
4> Secure VPN tunnel: While you use a cloud based MicroStrategy environment, your database hosting the data-mart could still be on-premise or they could be on cloud as well. Thus there is a need to establish connectivity between MicroStrategy Secure Cloud servers and the on-premise DB servers. This is done by establishing a secured VPN tunnel between the on-premise and cloud servers. This tunnel once established enables a secured and fast communication channel between the on-premise DB and MicroStrategy Cloud.
This activity needs to be done by MicroStrategy Cloud Support Team in partnership with customer infrastructure team. The infrastructure team of customer is required to open the corporate firewall for the necessary ports / IPs. You may also refer this Tech Note for further understanding.
5> Command Manager on Premise: One of the important success factors of a close-knit BI implementation would be to have a dependency between ETL load completion and subsequent automated triggering of MicroStrategy reports. The most optimal approach to achieve this integration would be the ability of an end process in the ETL load workflow to trigger MicroStrategy events through Command Manager; which in turn would trigger subscriptions which are tagged to the Event.
In this process a gap would arise if the ETL server or the server hosting the scheduling tool (which triggers ETL jobs) is on-premise. Obviously you would require a VPN tunnel to be present between the on-premise ETL server and the MSTR Cloud server. But still how would you be able to trigger MicroStrategy events from the on-premise server?
In order to tackle this problem MicroStrategy provide a standalone installer of the Command Manager tool also called Command Manager On Premise. This tool can be installed on the on-premise ETL or scheduling server and using this tool connectivity can be established with MicroStrategy I Server metadata to trigger the events.
6> Scheduling of batch jobs on the Windows remote machine: As discussed under Point# 1 above, the Windows remote machine is provided for use by developers and administrators. All these users would have a non-admin access on this remote machine and thus they will not be able to use the Windows scheduler feature on this remote machine.
In order to use this feature users would need to request a special user id with administrative privileges on the remote machine. The request needs to placed with MicroStrategy Tech Support; generally they cater to this request.
This user id can be used to schedule any batch script on this Windows remote machine. Helpful in scenarios when it is needed schedule a System Manager workflow or any other batch script.
7> SSO Integration with corporate authentication provider:
In this earlier post I had highlighted in detail how the SSO integration would work between MicroStrategy Secure Cloud and an on-premise identity provider. Once the integration is established there are the following ways in which user import into Project metadata can be enabled:
- You may enable batch import of users from the authentication provider server to MicroStrategy metadata. In this process all the existing users would be imported at once. And all the incremental user creations would be imported on a daily basis.
- If the batch import is disabled then there are 2 ways:
- Either you would need to manually create all the user objects in metadata with the same name as they are present in the authentication server.
- Or you would need to allow the user log in for the first time. When the user logs in for the first time, the user object gets created in the metadata but at the same time the user would have no access till the time his particular user gets assigned to the proper group.
If the groups are maintained in the authentication provider server, then the groups also need to be imported into metadata. However in metadata the the groups and user objects would both be standalone objects with no real association being visible. The association would be maintained in the authentication server.
However if the groups are created in MicroStrategy metadata then the association between user group and user to be done in the metadata.
8> Support from MicroStrategy: Support from MicroStrategy forms an integral part towards a successful implementation of MicroStrategy Secure Cloud. There are 2 levels at which support is currently extended.
- First is a dedicated Customer Success Manager (CSM) is associated who would taking the customer through the journey and making it a success. He would interact on a regular basis with the customer and ensure customer makes the best out of the Secure Cloud offering. He could be reached out for any technical, licensing, upgrade and other queries pertaining to the Secure Cloud environment.
- Second is the MicroStrategy Technical Support.This is the same Technical Support we have for other on-premise MicroStrategy installations as well. Since MicroStrategy is the guardian of the infrastructure and the metadata, Tech Support helps to address requests like restart I Server / Web Server, backup metadata etc.; apart from helping address queries related to product issues or other issues.
You may refer MicrStrategy Cloud Support brochure to get some additional information.
I hope this post is informative and would assist in your endeavor.