In part 1 of this series we walked through the steps you can take to organise resources before scheduling your update deployments. In this blog we discuss pre-post jobs and finally schedule Azure VM update deployment that leverages the computer grouping to support the end to end process of deploying updates.
Prepare for Pre-Post
The following steps would prepare your environment for using two runbooks that demonstrate the power of the pre-post jobs functionality. The prerequisites are:
- Update Automation Account Runbook Modules (https://github.com/Microsoft/AzureAutomation-Account-Modules-Update)
- Import the ThreadJob Module (https://www.powershellgallery.com/packages/ThreadJob/1.1.2). The simplest option to import is to click the Azure Automation tab and click Deploy to Azure Automation
- Import Runbooks from the Gallery. In this blog I use two runbooks imported from the Runbook gallery. I would suggest renaming the runbooks at the time of import. It gives you the flexibility to re-import and have a separate version. NB. Make sure you always publish the runbook else it would not show up as available for pre/post scripts.
- In Updates Management | Select Schedule deployment
- Provide a name for the schedule deployment, for example MonthlyDevUpdates |Select the Operating system type (Windows or Linux). In my case Windows
- Under Items to update |Click Groups to update | Azure (this deployment is for Azure VMs)
- Select the Subscription in scope | Under Tags select your Tag criteria
5. Click Preview to test the query |Once confirmed click OK and Click Add
6. Click OK to complete the Group selection part of the deployment schedule
7. Under Update classifications | Select the classifications in scope | In my case I selected Critical updates, Security updates, Definition updates and Updates
8. Include/Exclude updates: Use the Include tab to add KB IDs for updates not in your classification selection. For example, in my case I could include a KB number for a specific Update Rollup even though that classification is not selected. Conversely you can specify a KB(s) for any updates you want to exclude.
9. Under Schedule | Select either Day, Week or Month and the subsequent options. Note that the schedule start time must be at least 5 minutes in the future. Allow yourself time to save the job. You also select the time zone as part of this configuration
10. Pre-scripts + Post-scripts | click on the published script you want to use as a pre-script | Ensure that Script type is set to Pre-script and click OK
11. Pre-scripts + Post-scripts | click on the published script you want to use as a post-script | Ensure that Script type is set to Post-script and click OK
12. Review the selections and Click OK
13. Provide the Maintenance window in minutes and select the Reboot options. In my case I use 180 minutes and always reboot for this scheduled job
14. Click Create to complete the deployment schedule
Viewing and Monitoring the Deployment
You view the active deployments and previous deployments by using the History Tab. You can filter by Status (I always select Status: Succeeded 🙂 to get all green )
The job we scheduled is in progress and this is shown below and also shows the stage. It shows that 2 machines are in scope and the pre-script is in progress
When you click on the Deployment name it expands to provide you with additional details. You can click on the link for the script to see additional details
Once completed you can see the overall status and drill into All Logs to get verbose details.
The turn-on and off VMs runbooks are a great way to save money and ensuring compliance. In my case the Dev VMs can be shutdown but still get patched during my patch cycle for the month. Check out Part 3 for the Non-Azure scenario.
The Microsoft documents on Update management are very detailed so check those out to compliment this blog post.
