System Center 2012 Orchestrator – Changing User or Group Rights Post Install

I’ve seen a topic come up from time to time that I think was worth getting out to those that can use it Smile.  This is already published on TechNet (referenced within my blog here) but I wanted to put some finer notes on it to assist.

Issue –  Updating the Primary Administrator and Orchestrator User Group Post Install

So consider the scenario where you have installed and setup Orchestrator, selecting some initial defaults that you were comfortable with for access to the designer and who is the primary administrator for Orchestrator,  then you want to update your environment to support a new group or primary administrator.  In order to change the primary group and / or primary administrator after the fact, you need to leverage a tool called PermissionsConfig.exe located on the Management server.  You can follow the below process to accomplish this.


Changing User / Group Rights After Install

The following process is documented as a supported method to change the admin user and administrator group that is used by Orchestrator.  On occasion, you may need to update one of these (example: picked the wrong group during installation, user that setup Orchestrator is not going to be supporting it going forward).

  • Go to an Administrator elevated cmd prompt
  • Go to the installation directory for System Center 2012 Orchestrator on the Management Server

Example: C:\Program Files (x86)\Microsoft System Center 2012\Orchestrator\Management Server>

  • Execute the following ensuring you are putting in your Group and “primary user” to manage things.  Both need to be on this command line or you will end up overwriting with what you put here (leaving only group and no user or vice versa)

PermissionsConfig.exe -OrchestratorUsersGroup "DOMAIN\GROUPNAME" -OrchestratorUser "DOMAIN\USERNAME" –remote

Note: The above command is word-wrapping for readability – this command is executed all on one line.  Also, be careful not to “copy / paste” using the example from the TechNet article below (or even this blog for that matter).  Ensure that the “-“ between the commands are in fact dashes and not “non ascii” characters, or the command will fail

Additional Note: For additional troubleshooting information on this command (success / failure) navigate to the following directory on the Management Server and review the permissionsconfig.exe*.logs.

%SystemDrive%\programdata\Microsoft System Center 2012\Orchestrator\PermissionsConfig.exe\logs

Below is a abstract of what the command line options mean for your reference




The name of the group to use for Orchestrator permissions.


If this parameter is specified with a user name, the user is granted immediate access to Orchestrator whether a member of the specified group or not. This is to prevent the requirement for the user to log off and on if the group has just been created.


Indicates that the Runbook Designer can be run from a computer other than the management server.

Short, simple, and potentially very useful!  As always –  Happy Automating!

Comments (1)

  1. t3chn1ck says:

    Note for others that With SCO 2012 R2, the PermissionsConfig tool DID NOT create the log file as described. In fact, the tool did not even work until AFTER doing a restart of the Orchestrator Management Service (and all dependencies).

Skip to main content