Event details
While we understand the shift of planning and operation of moving from Windows Update for Business to Windows AutoPatch, once you have done the planning for WUFB, it's set and forget. Getting an understanding of the questions below will help us determine if we can make the shift and if it would be helpful. As we are in Australia, we won't be able to dial into the 'AMA". Happy for a separate call:
- If during a ring deployment, devices are offline due to users travelling, the user is on leave and comes back. How are these devices handled?
- General hesitation as patching is in our metrics which has board visibility. If we don't meet our SLAs, we can hold our MSP accountable. If we fail to meet our SLAs, it's now a Woodside problem. How are existing SLAs handled?
- If there is an issue with an update ring, this has to be paused. Who calls when to proceed, and what implications does this have if we miss our patching targets?
- At the moment, we exclude drivers/firmware. Can this be done with autopatch? An example is through Windows Update for Business, we deployed the latest sound audio driver update, and it broke our audio and stopped them working on all our devices. When a support case was raised, Microsoft (rightly so) mentioned that they couldn't be held responsible for vendors releasing faulty drivers. Another alternative would be to have a dedicated ring solely for Drivers/Firmware. Another example is the BIOS. When it updates, we don't have any granularity, i.e. device has to be plugged in, and the user isn't using it. At the moment, if we deploy it, a user could shut their laptop lid.
- What does the reporting look like?
- Who makes the call if an update gets pushed out and needs to be rolled back? Or if Woodside finds an issue with an update, what do we do?
- If we have update failures, as in update failed to install. Who fixes this? Microsoft or us?
Formatted for readability by your friendly Windows Community Manager.
- Chris_Tulip
Microsoft
1. In this case the Grace Period policy would kick in and all devices outside the test ring will have 2 days to schedule and update.
2. Windows Autopatch aims to keep at least 95% of eligible devices on the latest Windows quality update 21 days after release. If we don't meet that target then it's an active incident that Autopatch works to resolve.
3. At GA there are two types of pause: service pauses and customer pauses. A service pause is triggered when we detect a significant impact to devices based on a release. If you want to resume after the service has paused you will need to raise a support request. At GA we will have a capability for you to pause and resume different update rings.
4. Right now the scope of what Autopatch does for Drivers / Firmware is simply to allow drivers which are deployed through Windows Update to flow through the same ring structure as Quality Updates. We agree that this story isn't amazing right now and are investigating improvements in the future.
5. At GA we will have reporting on Windows Quality Updates which shows current patch status in your environment. We are working on additional reporting for other update types after GA.
6. Windows Autopatch makes the decision to release an update based on a set of quality signals. That article does a good job describing the process we use to assess build quality as it rolls out to customer devices. In the event of an issue please raise a support request
7. Windows Autopatch is responsible for patching eligible devices. The eligibility criteria are determined as the things which Autopatch can't fix and those devices will be marked ineligible for the service. Windows Autopatch aims to keep at least 95% of eligible devices on the latest Windows quality update 21 days after release. We prioritize getting all customers to 95% before working on the last 5% of devices for any customer. After all customers are at 95% we start working on the largest buckets of impacted devices to drive compliance numbers up across all customers.
