Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Orchestration Groups with Microsoft Endpoint Configuration Manager
Published May 05 2020 08:10 AM 5,680 Views
Microsoft

 

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.

 

TL; DR

  • 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

 

Demonstration

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:

 

PaulIvey_0-1588689706130.png

 

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:

 

PaulIvey_1-1588689706135.png

 

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):

 

PaulIvey_2-1588689706158.png

 

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

 

PaulIvey_3-1588689706168.png

 

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:

 

PaulIvey_4-1588689706172.png

 

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

 

PaulIvey_5-1588689706175.png

 

Here is our new orchestration group, ready and waiting:

 

PaulIvey_6-1588689706177.png

 

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:

 

PaulIvey_7-1588689706188.png

 

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

 

PaulIvey_8-1588689706190.png

 

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):

 

PaulIvey_9-1588689706192.png

 

PaulIvey_10-1588689706194.png

 

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

 

PaulIvey_11-1588689706196.png

 

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:

 

PaulIvey_12-1588689706203.png

 

 

Log files

Site server logs:

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

PaulIvey_13-1588689706212.png

 

  • 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:

PaulIvey_14-1588689706214.png

 

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

 

PaulIvey_15-1588689706220.png

 

Client logs:

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

PaulIvey_16-1588689706237.png

 

  • 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):

 

PaulIvey_17-1588689706243.png

 

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

@paul_msft

My CIS Tech Community Blog Posts

Senior Customer Engineer (formally PFE)

 

5 Comments
Copper Contributor

Hi,

are pre-script and post-scripts running for all kind of updates? Or is there a way to skip scripts for specific update classifications like definition updates.

With the previous server groups feature I had the problem with clusters like Hyper-V clusters (S2D, ...) or Exchange DAG groups, that definition updates for Windows Defender also run pre- and post-scripts. And in pre-script I suspended cluster nodes, moved loads to other servers. And in the post-script I resumed the system. This is very annoying for definition updates as this meant unnecessary failovers most likely multiple times a day.

Regards,

Frank

Microsoft

Hi @Frank Hofmann

 

Thanks for your comment!

 

As this is still pre-release, now is a great time to raise these ideas/questions. In answer to your question, currently the orchestration behaviour is the same for all types of updates, although please feel free to vote and/or share this UserVoice suggestion I submitted today after reading your comment - it's a great point! https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/40349350-orchestration-gr...

 

Cheers

Paul

 

Copper Contributor

Hi @Paul_Ivey

thanks for the overview of the function and for raising the voice to improve this option.

Since the server groups were announced, I believe we all, are expecting this function to be heavily utilised to simplify the patching workload, however this is yet at the same place, however it has changed the name =)

hi @Frank Hofmann 

For the moment there is no way to mitigate this kind of the behabiour for the endpoint protection definition updates triggering the pre and post scripts as the orchestration is triggered by any update, however, modifying the pre and post scripts to check if the machine is in a scheduled maintenance window or the script was initiated by the update installation like SCEP definitions - is the workaround

 Logic that is used to identify the scheduled MW has started and is active -  look through the servicewindowmanager.log, where '*The Service Window={*' is present,  because only manualy created MWs do have their SIds in curly brackets being reported in the log (to be more accurate you can use the exact SID of the MW, but for my usecases it was enough), then there is the filter for the MW date, comparing with today and the next is to look if there is already a record about the MW start and MW finish

An example of the Pre script

$log="c:\windows\startSccmMW.txt"
$InMW=0
if (Test-Path -Path $log) {Remove-Item -Path $log}
$error.Clear()
"Script runing time is">>$log
Get-Date >> $log
$error >> $log
$today=get-date -format "MM-dd-yyyy"

$ServiceWindowlog=get-content -path C:\Windows\ccm\logs\servicewindowmanager.log |Where-Object {$_ -like '*The Service Window={*'}

foreach ($line in $ServiceWindowlog)
{
if ($line.Contains($today.ToString()))
 {
      if ($line.Contains('has started at'))
          {
            $InMW=1
            $line >> $log
           }
      elseif ($line.Contains('has ended at'))
           {
             $InMW=0
             $line >> $log
            }
      else
          {
             $InMW=0
          }
  }
}
"">> $log
If ($InMW -eq "1")

{
"Mashine is in scheduled MW now" >> $log
#you should put the code to be executed in the MW only time here
}
else {"There is no active scheduled MW now" >> $log }
$error >> $log


So the Pre script would be actually triggered evey time there is the daily definition update, but the required action would only run when it would be a scheduled Maintenance Window

Hope this may help somebody or put some more interesting idea into smds head.

BR


 


Copper Contributor

Hi @Paul_Ivey :

 

What will be the behavior if the pre-script is failed (other than 0) the orchestration group will go head or it will come out from the orchestration and stops installing updates from SCCM?

 

Could you please help on this scenario. 

Copper Contributor

As per my testing, it just continues whether or not we get return code 0. 

Co-Authors
Version history
Last update:
‎Mar 22 2022 09:17 AM
Updated by: