Change Management Service Description Applies to: Office 365 Dedicated Topic Last Modified: 2015-06-29 Change Management Process... 3 Request for Change Process... 3 Change Windows... 3 Change Notifications from Microsoft... 5 Change Notifications to Microsoft... 6 Engaging Microsoft to Implement Changes... 8 Service Administration Changes... 8 Design or Service Changes... 8 Emergency Changes in Your Environment... 9 Notes: The content of this service description applies only to the legacy platform (2013 server releases) of Office 365 Dedicated. A separate Change Management service description exists for the Office 365 Dedicated services supported by the vnext platform. Unless otherwise indicated, the information in this service description also applies to the International Traffic in Arms Regulations (ITAR-support) version of Office 365. Page 1 of 9
The Microsoft Office 365 Change Management team directs the process and procedures related to approval, scheduling, testing, and deployment of changes in the pre-production and production Office 365 infrastructure environments. The approach used in this service management function is built on the Information Technology Infrastructure Library (ITIL) and Microsoft Operations Framework (MOF) standards, which aligns with the change management process used in most organizations. This service description presents the change management practices that Microsoft has adopted for services provided under the Office 365 for enterprises for enterprises dedicated subscription plans. It specifically applies to the following Office 365 service offerings: Exchange Online SharePoint Online Lync Online Note: To ensure your operational environment provides the resiliency required for the change management model of Office 365 Dedicated, an established network peering configuration as described in the Office 365 Dedicated Network Connectivity Guidance document must exist. The document is available via the Network landing page of the Customer Extranet site for Office 365 Dedicated customers. Legacy Releases Page 2 of 9
Change Management Process The production environment for Microsoft Office 365 is periodically subject to modifications due to requirements for maintenance, security patches, configuration changes that your organization requests, and other factors. Implementing these changes may affect one or more of the Office 365 services provided to your organization. The Office 365 change management team directs the change process in an efficient and effective manner. Request for Change Process The change management process is driven by the Microsoft Request for Change (RFC) process. The RFC process addresses issues that affect the Office 365 Production environment as opposed to design change requests, which affect product design or functionality. The change management process begins by submitting 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 and is deployed to production as appropriate. 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 Change Advisory Board or the Emergency Change Advisory Board. If the board authorizes the change, it is scheduled for deployment 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 (FSC) notification process. 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. There are two types of change windows: Page 3 of 9
Pre-established maintenance change windows that are treated as scheduled downtime for servicelevel agreement (SLA) purposes. Emergency change windows that sometimes must be implemented. The Office 365 change management team works with your organization to determine a change window schedule that has minimal business impact to your users. This is usually once a week for the duration of one eight-hour working shift. The realized service downtime is much shorter in duration than the length of the entire window, normally less than 10 minutes throughout the window while servers are rebooted or clusters are failed over. Office 365 uses following types of change windows: Pre-established maintenance windows (scheduled downtime) Maintenance window. Changes implemented during the maintenance window that have a high risk of impacting, or are known to impact, Office 365 service offerings that you subscribe to. SharePoint Online customization window. Your organization has two windows each month to deploy requested SharePoint Online customizations and configuration changes. These changes are scheduled for implementation on designated Fridays during your off-business hours to avoid conflicts with the maintenance window changes. Note: 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 contacted. If you determine that a non-emergency change requested by Microsoft can't be accommodated at the time indicated in the Forward Schedule of Change due to IT operations or end-user impacts, you can request a postponement of the change for up to two (2) weeks. A change postponement can be requested for Exchange Online, SharePoint Online, OneDrive for Business, or Lync Online. Postponement doesn't apply to security patching, shared networking changes, or break/fix work for the core services. In order to ensure supportability and performance standards are maintained for each service, change postponement can't exceed the two (2) week period. Page 4 of 9
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, which can result in a brief interruption of services, 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. Microsoft implements high-risk and known Office 365 service-affecting changes during change windows to minimize the service impact to organizations. All measures are taken to reduce any service disruptions to the time it takes for a server to reboot or for a cluster to fail over, which is typically less than 10 minutes. Change Notifications from Microsoft Every week the Office 365 change management team sends your change management team a Forward Schedule of Change (FSC) notification via the email distribution list you own and manage. The FSC notification describes the high-level details and end-user impact of the approved changes scheduled for implementation in your hosted Office 365 environment during the upcoming change window(s). The notification process provides a minimum of five (5) business days advance notice of planned service-impacting change activity and recaps the changes scheduled for implementation in the upcoming change window. Page 5 of 9
Change Notifications to Microsoft Microsoft requests that your change management team send an FSC notification to the Office 365 change management 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, but not limited, to the following items should be communicated between the Office 365 change management 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 Lync Online). Security patching, shared networking changes, or break/fix work for the core services are excluded. In order to ensure that supportability and performance standards are maintained for each service, the change freeze can't exceed a two (2) week period. Also, a general production period of 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) records 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. Changes in the security policy regarding service and test accounts that have been assigned to Microsoft (for example, password complexity or reset period). Page 6 of 9
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 7 of 9
Engaging Microsoft to Implement Changes Microsoft has an engagement model for changes that are proposed by your organization and that are outside normal day-to-day operations and maintenance activities. Proposed changes can be proactive, reactive, or apply to both situations. The engagement model for proposed changes is described in the following sections. Service Administration Changes All Office 365 Dedicated services have self-service options that IT pros in your organization can utilize to customize your operating environment. In some cases, service administration changes must be applied by Microsoft. You can request changes using the Customer Request Analysis System (CRAS). For each request type, a Configuration Request (CR) template must be completed and submitted to Office 365 Dedicated Operations personnel. For a complete list of available service administration changes and assistance with placing a CRAS submission, contact your service delivery manager (SDM). 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 might 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 CRAS. 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 8 of 9
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, 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. Page 9 of 9