Maintenance in self-service environments FAQ

Because of the changing nature of technology, the continual appearance of new security threats, and compliance requirements, environments must be updated with all critical security and quality updates. Microsoft built a framework for performing all maintenance activity during the dark hours of the geographic region where your environment is deployed. This maintenance activity includes operating system patching, deployment of security hotfixes, and deployment of quality updates. To minimize application downtime, upgrades occur in batches. Therefore, most capacity is always online, and only a subset is upgraded at a time. This approach enables servicing that involves a small window of service degradation instead of complete downtime.

Infrastructure maintenance in self-service environments

Infrastructure maintenance is the process of updating the environments with the latest security updates and critical hotfixes. Microsoft must complete this process on your environments to ensure security, availability, reliability. This article provides answers to frequently asked questions about Microsoft planned maintenance in self-service environments.

What are the types of planned maintenance activities that are performed on an environment?

Some of the common planned maintenance activities performed by Microsoft are:

• Operating system (OS) security updates
• Security hotfixes
• Microsoft quality updates

What are the planned maintenance windows?

A planned maintenance window is typically during the dark hours of the geographic region that your environment is deployed in. The following table lists the maintenance windows for each geography in Coordinated Universal Time (UTC).

What is the schedule for proactive quality updates?

For information on the upcoming proactive quality update schedule, see the Release schedule for proactive quality updates.

What does near-zero-downtime maintenance mean?

Customers can continue to operate the system during the maintenance activity. They might experience brief interruptions or disconnects during this window, but they don't need full downtime.

What is the experience during the near-zero-downtime maintenance window?

Upgrades occur in batches. Therefore, most capacity is always online, and only a subset is upgraded at a time to help eliminate complete downtime. We recommend that customers adopt priority-based scheduling of batch jobs. Priority-based scheduling eliminates the stickiness of batch jobs that are associated with a batch server and enables near-zero-downtime servicing for security patching and quality updates. By design, all Tier 2 and Tier 3 environments might experience approximately 30 minutes of downtime during the servicing or maintenance operations.

Interactive usage

Users who are connected to the environment might experience a brief disconnection of less than 60 seconds a few times during the servicing window. After recovery, users might experience one of the following outcomes:

• The session recovers gracefully, and the user either goes to the page that they were working on, or redirects to the root/workspace/home page and receives the following message: "Something went wrong. But we were able to recover your session."
• Session recovery fails, and the user who is working on a details page is redirected to the root/workspace/home page and receives the following message: "Something went wrong, and we were unable to recover your session. You've been redirected."

For example, the user might be working on a sales order creating lines or posting. After the interruption, the user might return to the Sales workspace, but the new order and lines should still be available. We recommend that users go back to the main form and check their work.

Batch service

Individual batch servers aren't available for up to 30 minutes. The following activities occur:

• Any running batch jobs are terminated.

• Jobs that were terminated are automatically restarted when the batch service recovers. Set the maximum number of retries to 0 (zero) for any jobs that shouldn't be restarted automatically.

  • Check printing
  • Statement posting

For more information about batch retry, see Retry for any error or batch server restart.

Priority-based scheduling

• If priority-based scheduling is enabled, users experience reduced Application Object Server (AOS) capacity during the maintenance window. Batch jobs are served by the available AOS instances. Therefore, there eventually isn't any complete downtime during the servicing window.
• If priority-based scheduling isn't enabled, any batch groups that are configured with AOS instances experience downtime until the associated AOS instances are updated and back in rotation.

Is it possible to reschedule near-zero-downtime operating system maintenance?

No. To meet regulatory and security compliance standards, Microsoft performs the planned maintenance during the dark hours of the geographic region where your environment is deployed. The main objective of planned maintenance is to regularly patch environments to remediate security vulnerabilities and apply critical quality updates. If you delay updates, you put data security, availability, and reliability at risk.