1 Asking users & experts and Testing & modeling users Ref: Ch. 13-14.
Testing as Other Users
2
Testing as Other Users BY BRYAN · OCTOBER 27, 2011 Here’s a quick tip that could be really obvious or make a big difference in your ability to provide support if you haven’t used it before. It’s pretty common to receive an email from a user who has some issue, usually security or preference related. It could be easier to either physically visit the user (if you’re able) or do a screen sharing session (if you have the proper software). But in lieu of those options, it’s also pretty easy to configure MicroStrategy to login as the other user so you can reproduce what they’re seeing. MicroStrategy support two main types of authentication: Standard (login / password) and Windows NT Authentication. If your environment uses Windows NT Authentication, then you can simple set a temporary password as the affected user and login as them to test. You also need to enable Standard Authentication as an allowed Login method under the Authentication tab of the User properties for this to work. Now from MicroStrategy Web, you can log out from your own account, and when you login enter the User ID and temporary Password you’ve set to authenticate as your target user. You can now reproduce the issue or test that your fix will work for them. If your environment is based on Standard authentication, you’re still ok. I worked in an environment which used Standard, mainly because of some quirky VPN related issues that prevented Windows Authentication from working properly. We couldn’t support Windows Authentication on
description
Testing as Other Users
Transcript of Testing as Other Users
Testing as Other Users
BY BRYAN · OCTOBER 27, 2011
Here’s a quick tip that could be really obvious or make a big difference in your ability to provide support if you haven’t used it before. It’s pretty common to receive an email from a user who has some issue, usually security or preference related. It could be easier to either physically visit the user (if you’re able) or do a screen sharing session (if you have the proper software). But in lieu of those options, it’s also pretty easy to configure MicroStrategy to login as the other user so you can reproduce what they’re seeing.
MicroStrategy support two main types of authentication: Standard (login / password) and Windows NT Authentication. If your environment uses Windows NT Authentication, then you can simple set a temporary password as the affected user and login as them to test. You also need to enable Standard Authentication as an allowed Login method under the Authentication tab of the User properties for this to work. Now from MicroStrategy Web, you can log out from your own account, and when you login enter the User ID and temporary Password you’ve set to authenticate as your target user. You can now reproduce the issue or test that your fix will work for them.
If your environment is based on Standard authentication, you’re still ok. I worked in an environment which used Standard, mainly because of some quirky VPN related issues that prevented Windows Authentication from working properly. We couldn’t support Windows Authentication on the main Web Server, but we were able to enable it in a Test environment since the only people who accessed that were the actual Development team on the local network. What may be a little known trick is that you can point a Web Server to multiple IServers. Projects from both servers show up
in the Projects page, and you can differentiate them because they list the Server Name under the Project. In the Test Web Server, we were able to enable Windows Authentication, and pointing to the Production IServer, we were able to temporarily link our own Windows Account to a particular user, thus logging in as them for support. This method is a little more work than using the Standard Authentication method, because you can only have your Windows Account linked to a single login at a time, so you have to be sure to unlink it before linking it to the next.
I use this method quite frequently for troubleshooting and even in development scenarios, such as when working with the Dynamic User Reports from the Landing Page project. It’s one of my favorite support tricks and lets you transparently support your end users without having to bother them much.
