Orchestration Groups with Microsoft Endpoint Configuration Manager

Published May 05 2020 08:10 AM 3,697 Views


With the release of Microsoft Endpoint Configuration Manager (formally SCCM) version 2002 came an exciting and highly-anticipated feature known as orchestration groups. Orchestration groups are an evolution of the server groups feature, allowing a greater level of control to the deployment of software updates. Orchestration groups are objects within Configuration Manager rather than a collection setting and can be any Configuration Manager client, not just servers.  In version 2002, orchestration groups is a pre-release feature.



  • Orchestration groups work to “orchestrate” the installation of software updates to specific clients. If a client that is a member of an orchestration group needs to install an update, the orchestration of the entire orchestration group begins, ensuring that the rules of the relevant orchestration group are honoured (as are maintenance windows)
  • You can specify timeouts for orchestration group members and the entire orchestration group
  • The orchestration rules available are:
    • Allow a percentage of the machines to be updated at the same time - This is the percentage of machines in an orchestration group that can have updates installed simultaneously. This allows flexibility for orchestration groups’ membership counts changing
    • Allow a number of the machines to be updated at the same time – This is the specific number of machines in an orchestration group that can have updates installed simultaneously
    • Specify the maintenance sequence – This is the order in which to update each machine within an orchestration group (maybe you want to ensure your SQL server is updated and rebooted  - if needed - before you update and reboot other machines that rely on the SQL server, for example)
  • Pre-scripts and post-scripts – Specify PowerShell scripts to run before and after each machine in an orchestration group is updated (maybe there are certain services that you need to ensure are stopped before and started after, for example). These will only run if the client being processed has updates to install



This orchestration group will contain 5 members and will use the sequence rule with both a pre-script and post-script to demonstrate those running. Not all members require the updates that will be deployed.

The deployment will not be affected by maintenance windows for this demonstration, but note that when using the sequence rule, if one member is unable to install updates due to a maintenance window, the orchestration will not progress through any other members until that member has been able to install the update/s.


Create orchestration group

From within the Assets and Compliance workspace of the Configuration Manager console, a new Orchestration Group node is visible. Right-clicking on this and selecting Create Orchestration Group (or selecting the node and clicking the option in the ribbon) results in the create orchestration group wizard appearing:




Here you can input a name and description for the orchestration group, as well as specify the timeout values. I have left the timeout values as the current default values:




The next stage is to select the members of the orchestration group (note: a client is only able to be a member of one orchestration group; if a client is already a member of another orchestration group, it will not be visible to select for this group):




The next step is to specify the orchestration rule mentioned earlier:




Once you define your desired rule and proceed, you will be presented with a stage for pre-script and a stage for post-script. Here is my example pre-script. I will use an almost identical post-script, with “pre” substituted for “post”. Take note of the return value being required upon success:




Proceeding past the script stages will present you with a familiar-looking summary screen before wizard completion:




Here is our new orchestration group, ready and waiting:




Monitoring orchestration

Once software updates are deployed and a member of an orchestration group has an update to install, the orchestration of the orchestration group will begin, to ensure that no updates are installed in a way that contradicts your orchestration group rules (note: if users install updates via the Software Center, orchestration will be bypassed). You can also manually trigger orchestration to begin with the Start Orchestration option:




Once orchestration has begun, you can see that the relevant orchestration group is now in progress:




Double-clicking or selecting Show Members on the orchestration group will list all members and show the progress of orchestration (states include: Idle, Waiting, In Progress, Failed and Reboot pending):






From one of the clients that did have an update to install, we can see that the pre-script and post-script ran successfully:




If for whatever reason you want to be able to re-run orchestration, you can select the member/s and choose to Reset Orchestration Group Member, which will allow orchestration to be run again:





Log files

Site server logs:

  • Policypv.log shows that the site targets the orchestration group to the relevant clients:



  • SMS_OrchestrationGroup.log shows the behaviours of the orchestration group. When the orchestration was just created and no clients had evaluated updates yet, we see a lot of this:



Once orchestration begins, the SMS_OrchestrationGroup.log shows some progress:




Client logs:

  • MaintenanceCoordinator.log shows the lock acquisition, update installation, pre-script and post-script progress, and lock release process:



  • PolicyAgent.log shows if/when the client processes the membership of an orchestration group (the highlighted GUID is the unique ID for the orchestration group):




The usual logs relating to software updates also show the usual software updates behaviour.

As always, please keep sending suggestions, smiles and frowns to provide us with valuable feedback, which all help towards creation of great features like the one discussed in this blog post.


Paul Ivey


My CIS Tech Community Blog Posts

Senior Customer Engineer (formally PFE)


Version history
Last update:
‎Aug 20 2020 05:56 AM
Updated by: