Applies to: Office 365 Dedicated vnext Topic Last Modified: 10-Jun-2015 The team of Office 365 Dedicated directs the processes and procedures related to approval, scheduling, and deployment of changes in your pre-production and production Office 365 infrastructure environment. The approach used in this service management function is built on the Information Technology Infrastructure Library (ITIL) and Microsoft Operations Framework (MOF) standards both align with the change management process used in most organizations. This service description applies to the following services: Exchange Online Dedicated SharePoint Online Dedicated & OneDrive for Business Dedicated Lync Online Dedicated Notes: In general, the Office 365 multi-tenant collateral set applies to Office 365 Dedicated vnext. For change management, the description within this document applies only to the vnext release and completely supersedes the Service Update material for the multi-tenant release of Office 365. Page 1 of 8
Processes The production environment for Office 365 Dedicated is periodically subject to modifications due to requirements for maintenance, upgrades, security patches, customer-requested changes, and other factors. Implementing these changes may not affect or potentially will affect one or more of the Office 365 services that are provided to your organization. The purpose of the Office 365 team is to direct the change process in an efficient and effective manner that enables rapid deployment of engineering improvements and reduces change impact to our customers. Microsoft Initiated Changes There are two types of Microsoft initiated changes that occur in the Office 365 environment: Regular Updates (formerly referred to as Non-disruptive Changes) that are not expected to impact current customer activities and Impacting or Potentially Impacting Changes that may in some way affect Office 365 services. Regular Updates Regular updates are non-disruptive changes that can occur at any time and are not included in the Forward Schedule of Change process described below. A typical example is recurring code improvements. Impacting or Potentially Impacting Changes Changes that may impact current customer activities or that will impact the services customers have purchased (either as part of the deployment procedure or based upon changes in the service) are Microsoft initiated changes driven by the Request for Change (RFC) process. The change management process begins when the Office 365 engineering teams submit an RFC using the Microsoft RFC tool. Through a series of decision matrices, the request is classified as having a low, medium, or high impact to the availability, stability, or security of the service. If the request is classified as a known change type that is either auto-approved or functionally approved, the request is not reviewed by the Change Advisory Board (CAB) or the Emergency Change Advisory Board (ECAB) and is deployed to production as appropriate. Page 2 of 8
Any change that is classified as having a known or high-risk impact to one of the services provided by Office 365 is reviewed by the CAB or the ECAB. If the board authorizes the change, it is scheduled for deployment. Based on expected impact, the change may be slotted during an Office 365 change window. Your organization is notified five (5) business days in advance of the deployment via the Forward Schedule of Change notification process described below. Change Windows A change window is defined as a period of time when Microsoft deploys changes that carry a high risk of impacting, or are known to impact, Office 365 service offerings. The following are the two types of change windows: Pre-established maintenance change windows (scheduled downtime) Maintenance window. Changes that are implemented during the maintenance window have a high risk of impacting, or are known to impact, Office 365 service offerings to which you subscribe. The regional planned downtime maintenance windows are currently the following: o o o The Americas: 21:00 to 03:00 Pacific Time (GMT-8) Europe, the Middle East, and Africa: 20:00 to 02:00 (GMT) Asia Pacific and Greater China: Saturdays 1:00 am to Sundays 4:00 pm (GMT+8) Microsoft typically plans downtime for times when service usage is historically at its lowest Fridays and Saturdays based on regional time zones. Normally the realized service downtime is much shorter in duration than the length of the entire window - typically less than 10 minutes intermittently throughout the window while servers are rebooted or clusters are failed over. Notes: 1. Any service downtime that is incurred during a pre-established maintenance window is removed from service-level agreement (SLA) reporting. If a service is impacted beyond the communicated window, the Office 365 incident management process is initiated and your organization is provided with the appropriate communication. 2. If you determine that a non-emergency change requested by Microsoft cannot be accommodated at the time indicated in the Forward Schedule of Change due to IT operations or end-user impacts, you are able to request a postponement of the change for up to two (2) weeks. A change Page 3 of 8
postponement can be requested for Exchange Online, SharePoint Online, OneDrive for Business, or Lync Online; the postponement does not apply to security patching, shared networking changes, or break/fix work for the core services. Due to the need to ensure that supportability and performance standards are maintained for each service, the change postponement cannot exceed the two (2) week period. Emergency windows Emergency patch window. The Microsoft Security Response Center (MSRC) releases security bulletins on the second Tuesday of every month ( Patch Tuesday ), or as appropriate, to mitigate zero-day exploits. In the event that proof-of-concept code is publicly available regarding a possible exploit or if a new critical security patch is released, Microsoft is required to apply patches to affected Office 365 systems as soon as possible to immediately remediate the vulnerability to your hosted environment. During this window, the Office 365 operations team updates or patches all applicable Office 365 systems. Affected services may experience a brief interruption (typically less than 10 minutes) while servers are rebooted or clusters are failed over. Emergency downtime window. In the event that an emergency change is necessary to stabilize or secure an Office 365 hosted environment, the emergency downtime window process is initiated. Your IT representatives are notified prior to the change occurring. During this window, the realized downtime to your services is minimized to the time it takes to reboot a server or to fail over a cluster to mitigate the emergency situation. Change Notifications from Microsoft Changes that are classified as an impacting change are posted to the Service Status section of the Office 365 portal under the Planned Maintenance category. The FSC notification describes the high-level details and end-user impact of the approved changes that are scheduled for implementation in the hosted Office 365 environment. This FSC notification process provides a minimum of five (5) business days advance notice of planned service-impacting change activity. Page 4 of 8
Change Notifications to Microsoft Microsoft requests that your change management team send an FSC notification to the Office 365 team that outlines any planned change activity in your environment that has a potential of impacting an Office 365 service that Microsoft provides to your organization. The notification should provide the associated details of those changes. All change activity in your environment that is related to, but not limited to, the following items should be communicated between the Office 365 team and your change management team no later than three (3) business days prior to implementation: General Internally published change freeze calendars that you want Microsoft to honor (for example, for financial processing or global deployments). Note: Change freeze requests apply only to the core services of Office 365 (Exchange Online, SharePoint Online, OneDrive for Business, and/or Lync Online); excluded from the freeze are security patching, shared networking changes, or break/fix work for the core services. Due to the need to ensure that supportability and performance standards are maintained for each service, the change freeze cannot exceed a two (2) week period. Also, a general production period that is a minimum of two (2) weeks must follow the freeze to provide adequate time for all pending changes to be applied. Public and internal Domain Name System (DNS) record changes for Microsoft. Changes to the IP address or server name of internal DNS servers that Microsoft directs its DNS servers to for DNS name resolution within the Customer Network. IP address or server name changes to your internal domain controllers and that Microsoft directs its domain controllers to for authentication. Retiring, renaming, or reassigning of the IP address of the domain controllers in your preferred domain controller list. Patching or upgrading of co-located domain controllers in the Microsoft data centers. Group Policy changes that modify the behavior of the browser settings for your users. Page 5 of 8
Changes in the security policy regarding service and test accounts that have been assigned to Microsoft (for example, password complexity or reset period). Firewall rules for connecting to Office 365 services. Deletion of a domain trust. Network All point-of-presence devices that connect to Office 365 or the Internet. All core infrastructure devices in your organization. Exchange Online All changes to your messaging environment during the migration phase (for example, patching, upgrades, or hotfixes). Patching, upgrading, or rebooting of any mail server (for example, Microsoft Exchange Server, Lotus, GroupWise) that acts as a bridgehead in the Exchange Online topology. Decommissioning of any messaging server. Deploying add-ins for the Microsoft Outlook messaging and collaboration client to users. Page 6 of 8
Engaging Microsoft to Implement Customer Initiated Changes Microsoft has an engagement model for changes by your organization that address service administration or requests that are outside normal day-to-day operations and maintenance activities that are proactive, reactive, or both types. The engagement model customer initiated changes is described below. Service Administration Changes All of the services of Office 365 Dedicated have self-service capabilities that IT professionals of your organization can utilize to customize your operating environment. In some cases, service administration changes must be applied by Microsoft. The changes can be requested via the Customer Request Analysis System (CRAS). For each request type, a Configuration Request template must be completed and submitted to Operations personnel of Office 365 Dedicated. See the Customer Operations Handbook - Office 365 Dedicated vnext for a complete list of available service administration changes and the process to place the request. Your Microsoft Service Delivery Manager also is available to provide assistance. Design or Service Changes Any change proposals from your organization that call for a significant modification or alteration to agreed, contractually-bound, solution architectures, designs, or service packages must be reviewed and approved through established Microsoft channels. Review and approval is required because such changes potentially may degrade Office 365 service performance, affect the ability of either Microsoft or your organization to meet operating-level agreement (OLA) and service-level agreement (SLA) commitments, or affect obligations concerning the cost of goods sold. Generally, Microsoft strictly manages changes by minimizing one-time requests from your organization and focusing on new features that can provide benefits to all customers. To evaluate, manage, and implement a change requests, Microsoft uses the well-defined processes set forth in the Customer Request Analysis System (CRAS). Contact your Service Delivery Manager for assistance with the CRAS process. CRAS is not used for addressing break-fix issues or issues that affect any Office 365 service offerings. Any issue that has an impact on an Office 365 service offering should be managed through standard support escalation processes. Page 7 of 8
Emergency Changes in Your Environment If an emergency or non-communicated change in your corporate environment affects the availability of, or connectivity to, an Office 365 service, you should engage the Microsoft service desk by email (if available) or phone as soon as possible. The service desk is available 24 hours a day, 7 days a week. The information contained in this document represents the current view of Microsoft Corporation on the topics described as of the date of publication. Because Microsoft must respond to changing market conditions, the content of this document should not be interpreted to be a commitment on the part of Microsoft. The accuracy of any information presented after the date of publication cannot be guaranteed by Microsoft. The Information is provided for marketing purposes only and cannot be incorporated within, or attached to, any type of agreement. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give the user (you) any license to these patents, trademarks, copyrights, or other intellectual property. Page 8 of 8