locked
Managment Reporter Client setup/configuration RRS feed

  • Question

  • I'm looking into way of controlling server connection information for mulitple users across mulitple computers using AD Group Policy.  Currently it appears the Management Reporter server connection information is not stored in a file on the users machine or terminal server, but is stored in the registry at HKLM\Software\Microsoft\Dynamics\ManagementReporter\60\Client, String variable ServerConnection.  I've noticed there an identical path in HKCU, but nothing is stored up in there.  Is there a way to make the ServerConnection information get stored in the HKCU location instead of HKLM?

    Reasons for this could be: Roaming Profiles (users using more then one workstation, and having this connection information follow them would be very beneficial), and Terminal Servers.  With terminal servers, we could have two different users logged in, each with Management Reporter access, but each using a different Management Reporter Server to connect to their own Management Reporter setup/system.  We could then simply control their access/connection information using Group Policy to push the proper information out.

    I hope this is a valid option, and something that is fairly easy to manipulate.

    Thanks
    Jerry
    Wednesday, March 17, 2010 5:23 PM

Answers

  • Hi Jerry,

    Management Reporter actually does use HKCU.  We write the connection string provided during install to HKLM to allow the MR client to be installed on a terminal server (or any other machine where multiple users will log on) so that each user doesn't have to provide a connection.  When you start Designer or Viewer, it looks for a connection in HKCU first.  If it doesn't find that, it falls back to HKLM.  If it doesn't find one there (or fails to connect to either), it asks the user to provide one.  When a user enters a connection string (either for the first time or if they change it from the Connection dialog), we write it to HKCU.

     

    The client installation will allow you to proceed without entering a connection string at all.  In that case, nothing gets written to HKLM and each user has to enter the connection when they start Designer/Viewer for the first time.

    I hope this helps.

    Jeff

    Thursday, March 18, 2010 5:44 PM

All replies

  • Hi Jerry,

    You are correct, currently the connection is being used in the HKLM.

    I will submit your suggestion to development to see if this is something that could be switched.

    Thanks,

    Tina
    Thursday, March 18, 2010 4:06 PM
  • Hi Jerry,

    Management Reporter actually does use HKCU.  We write the connection string provided during install to HKLM to allow the MR client to be installed on a terminal server (or any other machine where multiple users will log on) so that each user doesn't have to provide a connection.  When you start Designer or Viewer, it looks for a connection in HKCU first.  If it doesn't find that, it falls back to HKLM.  If it doesn't find one there (or fails to connect to either), it asks the user to provide one.  When a user enters a connection string (either for the first time or if they change it from the Connection dialog), we write it to HKCU.

     

    The client installation will allow you to proceed without entering a connection string at all.  In that case, nothing gets written to HKLM and each user has to enter the connection when they start Designer/Viewer for the first time.

    I hope this helps.

    Jeff

    Thursday, March 18, 2010 5:44 PM
  • This sounds great.  So we could actually group GPOs to push out the necessary connection string to the users HKCU when they log into the Terminal Server session, thus keeping the install generic (i.e. not configured for any one particular system) but at the same time keeping them from having to actually enter that information upon connecting the first time.

    Thank you!!

    Now, if we could just get the Management Reporter service to be a multitenant install (like SQL Server). :)

    - Jerry

    Thursday, March 18, 2010 7:00 PM