MicroStrategy User Group and License Management
There are a number of ways to organize user access and privileges. For every expert you’ll get a slightly different opinion. However, if you approach the problem from the perspective of efficient user administration and license management there are only few optimal solutions.
On a basic level users need access to certain projects and folders, and users need certain privileges. Constraining that is the type of licensing and quantity you’ve purchased. The main user administration activity consists of adding/removing users, securing user access, shuffling user privileges, and reporting back to management on the state of user licenses.
Shuffling privileges and efficient auditing is where I think most user management strategies falls short. Sure you can use License Manager, but that is a multi-step process that doesn’t give you real time feedback during user modification or creation. I propose a scheme using two types of groups, one for privilege management and one for security management, depicted below.

License Groups and Security Groups are parents of the two types. In creating the appropriate set of License Groups one must take care to reflect the contract agreements with MicroStrategy. This will greatly reduce confusion when auditing systems later. Additionally, to simplify management further you can put security groups as members of privilege groups and so on. Essentially we are creating a hard seperation between security and privilege (in this case the security roles used in Security Groups just have common privileges).
By doing this we can quickly audit the system without license manger and furthermore, we can shuffle users around to quickly come into compliance. For example, we had a scenario where most of the web professional licenses were unused, however we were out of compliance on web analyst. To address this issue we were able to quickly identify top x heavy users from the analyst group and blindly move them to the web professional group. Since security was seperate we didnt waste anytime on contemplating our complicated access rules.
Like I said before there are many strategies when it comes to user managment. I feel the seperation described above should considered as part of any strategy. Please feel free to provide your own strategies and experiences with MicroStrategy user managment in the comment section below.
I just set something up like this today. One group for folder/attribute/metric access, and the other group for attaching security filters…though, I have another interesting issue I’m trying to deal with. The classic “T” problem…I’m blogging about it at my site, with a reference to this…
Here’s the link.
I agree with ajo about separating privileges and permissions and also tend to take this one additional step by creating groups per project. This makes it easier to carry out project user group analysis and accounting when you have multiple departments / projects using a common infrastructure
|—
| |—-
| |—……
|—
| |—-
| |—……
I agree with ajo about separating privileges and permissions and also tend to take this one additional step by creating groups per project. This makes it easier to carry out project user group analysis and accounting when you have multiple departments / projects using a common infrastructure
[PROJECT1 - Users]
|—[PROJECT1 - WEB Users]
| |—-[PROJECT1 - Web analysts Users]
| |—……
[PROJECT2 - Users]
|—[PROJECT2 - WEB Users]
| |—-[PROJECT2 - Web analysts Users]
| |—……