It would be really helpful if you could describe a pipleine in Update Management, and get the updates to flow through that pipeline.
e.g. You have a Dev, Test and Production Environment.
You want to keep machines up to date, but do not want to affect Production users with faulty pathes.
If you could describe an update pipleine, saying, deploy any updates to Dev, then to test then to prod, this would ensure updates can be developed and tested against before they reach production.
When patch tuesday arrives, these patches would be available for your 1st environment in the pipleine, and wouldn't be available to the second until they had passed the 1st. (And so on down the pipeline..)
Update Management solution of Azure Automation is a free tool to allow basic patch management by triggering the machine’s OS to install updates as per provided configuration at stated time.
Hence there are two ways to achieve your scenario “exactly same updates” in test & then prod, by either manipulating the OS behavior or tweaking the AUM config:
- - Host the updates locally using Microsoft WSUS [https://docs.microsoft.com/azure/automation/automation-configure-windows-update#make-wsus-configuration-settings] or Reposync utility from RedHat [https://access.redhat.com/solutions/23016]or Ubuntu Landscape [https://docs.ubuntu.com/landscape/], etc. And the configure the update service or package manager of all your machines to use the local update source. In this way the updates installed when using Update Management will only be what is available in your local patch server which is running (say) WSUS or RH Reposync. And if the patch server remain unchanged in 2-3 weeks when you start update schedule for Prod, they will also fetch updates from same local patch server and have exactly same updates as your non-prod.
- - Use the MS CXP created – Create-azUpdatePatchDeploymentList PowerShell script [https://www.powershellgallery.com/packages/Create-azUpdatePatchDeploymentList/]. It will query for existing needed updates applied and create a new schedule as needed which only include the updates retrieved from query of the result of an earlier UM schedule run.
Customers can choose either (1) or (2) – based on the environment & control requirements.
Mark Nash commented
The idea would be that you define the pipeline as : (Dev) -> (Test) -> (Prod)
There are 3 available patches at start of Monday
Dev gets patched with all 3 successfully
2 new patches are released on patch Tuesday
Test deploys Dev's 3 successful patches but then fails 1
Prod deploys Test's 2 successful patches
Dev gets the 2 new patches deployed, and successfully completes both
No new patches released
Test successfully installs the 2 new patches and the patch it previously failed
Prod patches with the 3 patches that succeded on Test