mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-27 20:57:23 +00:00
fixing spacing issues
This commit is contained in:
parent
544aa51167
commit
590efeee46
@ -2,25 +2,35 @@
|
||||
title: Application development for Windows as a service (Windows 10)
|
||||
description: In today’s environment, where user expectations frequently are set by device-centric experiences, complete product cycles need to be measured in months, not years.
|
||||
ms.assetid: 28E0D103-B0EE-4B14-8680-6F30BD373ACF
|
||||
ms.pagetype: security
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: manage
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: jdeckerMS
|
||||
---
|
||||
|
||||
# Application development for Windows as a service
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows 10 Mobile
|
||||
- Windows 10 IoT Core (IoT Core)
|
||||
|
||||
In today’s environment, where user expectations frequently are set by device-centric experiences, complete product cycles need to be measured in months, not years. Additionally, new releases must be made available on a continual basis, and must be deployable with minimal impact on users. Microsoft designed Windows 10 to meet these requirements by implementing a new approach to innovation, development, and delivery called [Windows as a service (WaaS)](introduction-to-windows-10-servicing.md). The key to enabling significantly shorter product cycles while maintaining high quality levels is an innovative community-centric approach to testing that Microsoft has implemented for Windows 10. The community, known as Windows Insiders, is comprised of millions of users around the world. When Windows Insiders opt in to the community, they test many builds over the course of a product cycle and provide feedback to Microsoft through an iterative methodology called flighting.
|
||||
|
||||
Builds distributed as flights provide the Windows engineering team with significant data regarding how well builds are performing in actual use. Flighting with Windows Insiders also enables Microsoft to test builds in much more diverse hardware, application, and networking environments than in the past, and to identify issues far more quickly. As a result, Microsoft believes that community-focused flighting will enable both a faster pace of innovation delivery and better public release quality than ever.
|
||||
|
||||
## Windows 10 release types and cadences
|
||||
|
||||
Although Microsoft releases flight builds to Windows Insiders, Microsoft will publish two types of Windows 10 releases broadly to the public on an ongoing basis:
|
||||
|
||||
**Feature updates** install the latest new features, experiences, and capabilities on devices that are already running Windows 10. Because feature updates contain an entire copy of Windows, they are also what customers use to install Windows 10 on existing devices running Windows 7 or Windows 8.1, and on new devices where no operating system is installed. Microsoft expects to publish an average of one to two new feature updates per year.
|
||||
**Quality updates** deliver security issue resolutions and other important bug fixes. Quality updates will be provided to improve each feature currently in support, on a cadence of one or more times per month. Microsoft will continue publishing quality updates on Update Tuesday (sometimes referred to as Patch Tuesday). Additionally, Microsoft may publish additional quality updates for Windows 10 outside the Update Tuesday process when required to address customer needs.
|
||||
|
||||
During Windows 10 development, Microsoft streamlined the Windows product engineering and release cycle so that we can deliver the features, experiences, and functionality customers want, more quickly than ever. We also created new ways to deliver and install feature updates and quality updates that simplify deployments and on-going management, broaden the base of employees who can be kept current with the latest Windows capabilities and experiences, and lower total cost of ownership. Hence we have implemented new servicing options – referred to as Current Branch (CB), Current Branch for Business (CBB), and Long-Term Servicing Branch (LTSB) – that provide pragmatic solutions to keep more devices more current in enterprise environments than was previously possible.
|
||||
|
||||
The following table shows describes the various servicing branches and their key attributes.
|
||||
|
||||
| Servicing option | Availability of new feature upgrades for installation | Minimum length of servicing lifetime | Key benefits | Supported editions |
|
||||
|-----------------------------------|-----------------------------------------------------------|--------------------------------------|-------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
|
||||
| Current Branch (CB) | Immediately after first published by Microsoft | Approximately 4 months | Makes new features available to users as soon as possible | Home, Pro, Education, Enterprise, Mobile, IoT Core, Windows 10 IoT Core Pro (IoT Core Pro) |
|
||||
@ -28,56 +38,87 @@ The following table shows describes the various servicing branches and their key
|
||||
| Long-Term Servicing Branch (LTSB) | Immediately after published by Microsoft | 10 Years | Enables long-term deployment of selected Windows 10 releases in low-change configurations | Enterprise LTSB |
|
||||
|
||||
For more information, see [Windows 10 servicing options for updates and upgrades](introduction-to-windows-10-servicing.md).
|
||||
|
||||
## Supporting apps in Windows as a service
|
||||
|
||||
The traditional approach for supporting apps has been to release a new app version in response to a Windows release. This assumes that there are breaking changes in the underlying OS that could potentially cause a regression with the application. This model involves a dedicated development and validation cycle that requires our ISV partners to align with the Windows release cadence.
|
||||
|
||||
In the Windows as a service model, Microsoft is making a commitment to maintaining the compatibility of the underlying OS. This means Microsoft will make a concerted effort to ensure that there are no breaking changes that impact the app ecosystem negatively. In this scenario, when there is a release of a Windows build, most apps (those with no kernel dependencies) will continue to work.
|
||||
|
||||
In view of this change, Microsoft recommends that our ISV partners decouple their app release and support from specific Windows builds. Our mutual customers are better served by an application lifecycle approach. This means when an application version is released it will be supported for a certain period of time irrespective of however many Windows builds are released in the interim. The ISV makes a commitment to provide support for that specific version of the app as long as it is supported in the lifecycle. Microsoft follows a similar lifecycle approach for Windows that can be referenced [here](http://go.microsoft.com/fwlink/?LinkID=780549).
|
||||
|
||||
This approach will reduce the burden of maintaining an app schedule that aligns with Windows releases. ISV partners should be free to release features or updates at their own cadence. We feel that our partners can keep their customer base updated with the latest app updates independent of a Windows release. In addition, our customers do not have to seek an explicit support statement whenever a Windows build is released. Here is an example of a support statement that covers how an app may be supported across different versions of the OS:
|
||||
|
||||
| Example of an application lifecycle support statement |
|
||||
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Contoso is a software development company and is the owner of the popular Mojave app which has a major share in the enterprise space. Contoso releases its next major release Mojave 14.0 and declares mainstream support for a period of three years from the release date. During mainstream support all updates and support are complimentary for the licensed product. Contoso also declares an additional two years of extended support where customers can purchase updates and support for a grace period. Beyond the extended support end date this product version is no longer supported. During the period of mainstream support Contoso will support Mojave 14.0 on all released builds of Windows. Contoso will also release updates to Mojave as necessary and independent of the Windows product releases. |
|
||||
|
||||
In the following sections, you will find additional information about the steps Microsoft takes to maintain the compatibility of the underlying OS. You will also find guidance on steps you can take to help maintain the compatibility of the combined OS and app ecosystem. There is a section on how to leverage Windows flighting builds to detect app regressions before a Windows build is released. Lastly, we describe how we use an instrumentation and telemetry-driven approach to increase the quality of Windows builds. We recommend ISVs adopt a similar approach with their app portfolio.
|
||||
|
||||
## Key changes since Windows 7 to ensure app compatibility
|
||||
We understand that compatibility matters to developers. ISVs and developers want to ensure their apps will run as expected on all supported versions of the Windows OS. Consumers and businesses have a key investment here—they want to ensure that the apps they have paid for will continue to work. We know that compatibility is the primary criteria for purchase decisions. Apps that are well written based on best practices will lead to much less code churn when a new Windows version is released and will reduce fragmentation—these apps have a reduced engineering investment to maintain, and a faster time to market.
|
||||
In the Windows 7 timeframe, compatibility was very much a reactive approach. In Windows 8 we started looking at this differently, working within Windows to ensure that compatibility was by design rather than an afterthought. Windows 10 is the most compatible-by-design version of the OS to date. Here are some key ways we accomplished this:
|
||||
|
||||
We understand that compatibility matters to developers. ISVs and developers want to ensure their apps will run as expected on all supported versions of the Windows OS. Consumers and businesses have a key investment here—they want to ensure that the apps they have paid for will continue to work. We know that compatibility is the primary criteria for purchase decisions. Apps that are well written based on best practices will lead to much less code churn when
|
||||
a new Windows version is released and will reduce fragmentation—these apps have a reduced engineering investment to maintain, and a faster time to market.
|
||||
|
||||
In the Windows 7 timeframe, compatibility was very much a reactive approach. In Windows 8 we started looking at this differently, working within Windows to ensure that compatibility was by design rather than an afterthought.
|
||||
Windows 10 is the most compatible-by-design version of the OS to date. Here are some key ways we accomplished this:
|
||||
- **App telemetry**: This helps us understand app popularity in the Windows ecosystem to inform compatibility testing.
|
||||
- **ISV partnerships**: Work directly with external partners to provide them with data and help fix issues that our users experience.
|
||||
- **Design reviews, upstream detection**: Partner with feature teams to reduce the number of breaking changes in Windows. Compatibility review is a gate that our feature teams must pass.
|
||||
- **Communication**: Tighter control over API changes and improved communication.
|
||||
- **Flighting and feedback loop**: Windows insiders receive flighted builds that help improve our ability to find compatibility issues before a final build is released to customers. This feedback process not only exposes bugs, but ensures we are shipping features our users want.
|
||||
|
||||
## Microsoft uses data to make Windows 10 better
|
||||
|
||||
Microsoft uses diagnostic and usage data to identify and troubleshoot problems, improve our products and services, and provide our users with personalized experiences. The usage data we collect also extends to the apps that PCs in the Windows ecosystem are running. Based on what our customers use, we build our list to test these apps, devices, and drivers against new versions of the Windows OS. Windows 10 has been the most compatible version of Windows to-date, with over 90% compatibility against thousands of popular apps. The Windows Compatibility team commonly reaches out to our ISV partners to provide feedback if issues are discovered, so that we can partner together on solutions. Ideally, we’d like our common customers to be able to update Windows seamlessly and without losing functionality in either their OS or the apps they depend on for their productivity or entertainment.
|
||||
|
||||
The following sections contain some best practices Microsoft recommends so you can ensure your apps are compatible with Windows 10.
|
||||
|
||||
**Windows version check**
|
||||
|
||||
The OS version has been incremented with Windows 10. This means that the internal version number has been changed to 10.0. As in the past, we go to great lengths to maintain application and device compatibility after an OS version change. For most app categories (without any kernel dependencies) the change will not negatively impact app functionality, and existing apps will continue to work fine on Windows 10.
|
||||
|
||||
The manifestation of this change is app-specific. This means any app that specifically checks for the OS version will get a higher version number, which can lead to one or more of the following situations:
|
||||
- App installers might not be able to install the app, and apps might not be able to start.
|
||||
- Apps might become unstable or crash.
|
||||
- Apps might generate error messages, but continue to function properly.
|
||||
|
||||
Some apps perform a version check and simply pass a warning to users. However, there are apps that are bound very tightly to a version check (in the drivers, or in kernel mode to avoid detection). In these cases, the app will fail if an incorrect version is found. Rather than a version check, we recommend one of the following approaches:
|
||||
- If the app is dependent on specific API functionality, ensure you target the correct API version.
|
||||
- Ensure you detect the change via APISet or another public API, and do not use the version as a proxy for some feature or fix. If there are breaking changes and a proper check is not exposed, then that is a bug.
|
||||
- Ensure the app does NOT check for version in odd ways, such as via the registry, file versions, offsets, kernel mode, drivers, or other means. If the app absolutely needs to check the version, use the GetVersion APIs, which should return the major, minor, and build number.
|
||||
- If you are using the [GetVersion](http://go.microsoft.com/fwlink/?LinkID=780555) API, remember that the behavior of this API has changed since Windows 8.1.
|
||||
|
||||
If you own apps such as antimalware or firewall apps, you should work through your usual feedback channels and via the Windows Insider program.
|
||||
|
||||
**Undocumented APIs**
|
||||
Your apps should not call undocumented Windows APIs, or take dependency on specific Windows file exports or registry keys. This can lead to broken functionality, data loss, and potential security issues. If there is functionality your app requires that is not available, this is an opportunity to provide feedback through your usual feedback channels and via the Windows Insider program.
|
||||
|
||||
**Develop Universal Windows Platform (UWP) and Centennial apps**
|
||||
|
||||
We encourage all Win32 app ISVs to develop [Universal Windows Platform (UWP)](http://go.microsoft.com/fwlink/?LinkID=780560) and, specifically, [Centennial](http://go.microsoft.com/fwlink/?LinkID=780562) apps moving forward. There are great benefits to developing these app packages rather than using traditional Win32 installers. UWP apps are also supported in the [Windows Store](http://go.microsoft.com/fwlink/?LinkID=780563), so it’s easier for you to update your users to a consistent version automatically, lowering your support costs.
|
||||
|
||||
If your Win32 app types do not work with the Centennial model, we highly recommend that you use the right installer and ensure this is fully tested. An installer is your user or customer’s first experience with your app, so ensure that this works well. All too often, this doesn’t work well or it hasn’t been fully tested for all scenarios. The [Windows App Certification Kit](http://go.microsoft.com/fwlink/?LinkID=780565) can help you test the install and uninstall of your Win32 app and help you identify use of undocumented APIs, as well as other basic performance-related best-practice issues, before your users do.
|
||||
|
||||
**Best pratcices:**
|
||||
- Use installers that work for both 32-bit and 64-bit versions of Windows.
|
||||
- Design your installers to run on multiple scenarios (user or machine level).
|
||||
- Keep all Windows redistributables in the original packaging – if you repackage these, it’s possible that this will break the installer.
|
||||
- Schedule development time for your installers—these are often overlooked as a deliverable during the software development lifecycle.
|
||||
|
||||
## Optimized test strategies and flighting
|
||||
|
||||
Windows OS flighting refers to the interim builds available to Windows Insiders before a final build is released to the general population. The more Insiders that flight these interim builds, the more feedback we receive on the build quality, compatibility, etc., and this helps improve quality of the final builds. You can participate in this flighting program to ensure that your apps work as expected on iterative builds of the OS. We also encourage you to provide feedback on how these flighted builds are working for you, issues you run into, and so on.
|
||||
|
||||
If your app is in the Store, you can flight your app via the Store, which means that your app will be available for our Windows Insider population to install. Users can install your app and you can receive preliminary feedback on your app before you release it to the general population. The follow sections outline the steps for testing your apps against Windows flighted builds.
|
||||
|
||||
**Step 1: Become a Windows Insider and participate in flighting**
|
||||
As a [Windows Insider,](http://go.microsoft.com/fwlink/p/?LinkId=521639) you can help shape the future of Windows—your feedback will help us improve features and functionality in the platform. This is a vibrant community where you can connect with other enthusiasts, join forums, trade advice, and learn about upcoming Insider-only events.
|
||||
|
||||
Since you’ll have access to preview builds of Windows 10, Windows 10 Mobile, and the latest Windows SDK and Emulator, you’ll have all the tools at your disposal to develop great apps and explore what's new in the Universal Windows Platform and the Windows Store.
|
||||
|
||||
This is also a great opportunity to build great hardware, with preview builds of the hardware development kits so you can develop universal drivers for Windows. The IoT Core Insider Preview is also available on supported IoT development boards, so you can build amazing connected solutions using the Universal Windows Platform.
|
||||
|
||||
Before you become a Windows Insider, please note that participation is intended for users who:
|
||||
- Want to try out software that’s still in development.
|
||||
- Want to share feedback about the software and the platform.
|
||||
@ -85,11 +126,17 @@ Before you become a Windows Insider, please note that participation is intended
|
||||
- Really know their way around a PC and feel comfortable troubleshooting problems, backing up data, formatting a hard drive, installing an operating system from scratch, or restoring an old one if necessary.
|
||||
- Know what an ISO file is and how to use it.
|
||||
- Aren't installing it on their everyday computer or device.
|
||||
|
||||
**Step 2: Test your scenarios**
|
||||
|
||||
Once you have updated to a flighted build, the following are some sample test cases to help you get started on testing and gathering feedback. For most of these tests, ensure you cover both x86 and AMD64 systems.
|
||||
**Clean install test:** On a clean install of Windows 10, ensure your app is fully functional. If your app fails this test and the upgrade test, then it’s likely that the issue is caused by underlying OS changes or bugs in the app. If after investigation, the former is the case, be sure to use the Windows Insider program to provide feedback and partner on solutions.
|
||||
**Clean install test:** On a clean install of Windows 10, ensure your app is fully functional. If your app fails this test and the upgrade test, then it’s likely that the issue is caused by underlying OS changes or bugs in the app.
|
||||
If after investigation, the former is the case, be sure to use the Windows Insider program to provide feedback and partner on solutions.
|
||||
|
||||
**Upgrade Test:** Check that your app works after upgrading from a down-level version of Windows (i.e. Windows 7 or Windows 8.1) to Windows 10. Your app shouldn’t cause roll backs during upgrade, and should continue to work as expected after upgrade—this is crucial to achieve a seamless upgrade experience.
|
||||
|
||||
**Reinstall Test:** Ensure that app functionality can be restored by reinstalling your app after you upgrade the PC to Windows 10 from a down-level OS. If your app didn’t pass the upgrade test and you have not been able to narrow down the cause of these issues, it’s possible that a reinstall can restore lost functionality. A passing reinstall test indicates that parts of the app may not have been migrated to Windows 10.
|
||||
|
||||
**OS\\Device Features Test:** Ensure that your app works as expected if your app relies on specific functionality in the OS. Common areas for testing include the following, often against a selection of the commonly used PC models to ensure coverage:
|
||||
- Audio
|
||||
- USB device functionality (keyboard, mouse, memory stick, external hard disk, and so on)
|
||||
@ -101,10 +148,14 @@ Once you have updated to a flighted build, the following are some sample test ca
|
||||
- Print\\Scan
|
||||
- Sensors (accelerometer, fusion, and so on)
|
||||
- Camera
|
||||
|
||||
**Step 3: Provide feedback**
|
||||
|
||||
Let us know how your app is performing against flighted builds. As you discover issues with your app during testing, please log bugs via the partner portal if you have access, or through your Microsoft representative. We encourage this information so that we can build a quality experience for our users together.
|
||||
|
||||
**Step 4: Register on Windows 10**
|
||||
The [Ready for Windows 10](http://go.microsoft.com/fwlink/?LinkID=780580) website is a directory of software that supports Windows 10. It’s intended for IT administrators at companies and organizations worldwide that are considering Windows 10 for their deployments. IT administrators can check the site to see whether software deployed in their enterprise is supported in Windows 10.
|
||||
|
||||
## Related topics
|
||||
[Windows 10 servicing options for updates and upgrades](introduction-to-windows-10-servicing.md)
|
||||
|
||||
|
@ -2,16 +2,20 @@
|
||||
title: Manage and update Windows 10 (Windows 10)
|
||||
description: Learn about managing and updating Windows 10.
|
||||
ms.assetid: E5716355-02AB-4B75-A962-14B1A7F7BDA0
|
||||
ms.pagetype: security
|
||||
keywords: ["Windows 10", "MDM", "WSUS", "Windows update"]
|
||||
keywords: Windows 10, MDM, WSUS, Windows update
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: manage
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: jdeckerMS
|
||||
---
|
||||
|
||||
# Manage and update Windows 10
|
||||
|
||||
Learn about managing and updating Windows 10.
|
||||
|
||||
## In this section
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
|
@ -2,29 +2,37 @@
|
||||
title: Windows 10 servicing options for updates and upgrades (Windows 10)
|
||||
description: This article describes the new servicing options available in Windows 10.
|
||||
ms.assetid: D1DEB7C0-283F-4D7F-9A11-EE16CB242B42
|
||||
ms.pagetype: security
|
||||
keywords: ["update", "LTSB", "lifecycle", "Windows update", "upgrade"]
|
||||
keywords: update, LTSB, lifecycle, Windows update, upgrade
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: manage
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: jdeckerMS
|
||||
---
|
||||
|
||||
# Windows 10 servicing options for updates and upgrades
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows 10 Mobile
|
||||
- Windows 10 IoT Core (IoT Core)
|
||||
|
||||
This article describes the new servicing options available in Windows 10, Windows 10 Mobile, and IoT Core and how they enable enterprises to keep their devices current with the latest feature upgrades. It also covers related topics, such as how enterprises can make better use of Windows Update, and what the new servicing options mean for support lifecycles.
|
||||
|
||||
**Note**
|
||||
Several of the figures in this article show multiple feature upgrades of Windows being released by Microsoft over time. Be aware that these figures were created with dates that were chosen for illustrative clarity, not for release roadmap accuracy, and should not be used for planning purposes.
|
||||
|
||||
## Introduction
|
||||
|
||||
In enterprise IT environments, the desire to provide users with the latest technologies needs to be balanced with the need for manageability and cost control. In the past, many enterprises managed their Windows deployments homogeneously and performed large-scale upgrades to new releases of Windows (often in parallel with large-scale hardware upgrades) about every three to six years. Today, the rapid evolution of Windows as a platform for device-like experiences is causing businesses to rethink their upgrade strategies. Especially with the release of Windows 10, there are good business reasons to keep a significant portion of your enterprise's devices *current* with the latest release of Windows. For example, during the development of Windows 10, Microsoft:
|
||||
- Streamlined the Windows product engineering and release cycle so that Microsoft can deliver the features, experiences, and functionality customers want, more quickly than ever.
|
||||
- Created new ways to deliver and install feature upgrades and servicing updates that simplify deployments and on-going management, broaden the base of employees who can be kept current with the latest Windows capabilities and experiences, and lower total cost of ownership.
|
||||
- Implemented new servicing options – referred to as Current Branch (CB), Current Branch for Business (CBB), and Long-Term Servicing Branch (LTSB) – that provide pragmatic solutions to keep more devices more current in enterprise environments than was previously possible.
|
||||
|
||||
The remainder of this article provides additional information about each of these areas. This article also provides an overview of the planning implications of the three Windows 10 servicing options (summarized in Table 1) so that IT administrators can be well-grounded conceptually before they start a Windows 10 deployment project.
|
||||
|
||||
Table 1. Windows 10 servicing options
|
||||
|
||||
| Servicing option | Availability of new feature upgrades for installation | Minimum length of servicing lifetime | Key benefits | Supported editions |
|
||||
|-----------------------------------|-----------------------------------------------------------|--------------------------------------|-------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
|
||||
| Current Branch (CB) | Immediately after first published by Microsoft | Approximately 4 months | Makes new features available to users as soon as possible | Home, Pro, Education, Enterprise, Mobile, IoT Core, Windows 10 IoT Core Pro (IoT Core Pro) |
|
||||
@ -32,121 +40,200 @@ Table 1. Windows 10 servicing options
|
||||
| Long-Term Servicing Branch (LTSB) | Immediately after published by Microsoft | 10 Years | Enables long-term deployment of selected Windows 10 releases in low-change configurations | Enterprise LTSB |
|
||||
|
||||
## Streamlined product development and release cycles
|
||||
|
||||
**Product cycles and builds**
|
||||
|
||||
The Windows engineering team adds new features and functionality to Windows through *product cycles* comprised of development, testing, and release phases. Each day during a product cycle, the team compiles the source code for Windows and assembles the output into a *build* that users can install on their devices. The first recipients of builds are Microsoft employees who begin what Microsoft calls *selfhost* testing.
|
||||
|
||||
**Testing and release prior to Windows 10**
|
||||
|
||||
Prior to Windows 10, Microsoft issued and extensively tested many builds internally before selecting one for testing outside Microsoft. After repeating the external test cycle several times against builds of progressively better quality, the engineering team selected a build to enter the release phase. At the end of this phase, the team published the build as a new version of Windows – an event referred to as the *Release to Manufacturing* (RTM) milestone. In total, product cycles took between one and three years to complete, with testing and release processes taking up as much as half of the total investment in time.
|
||||
|
||||
**A different approach for Windows 10**
|
||||
|
||||
In today’s environment, where user expectations frequently are set by device-centric experiences, complete product cycles need to be measured in months, not years. Additionally, new releases must be made available on a continual basis, and must be deployable with minimal impact on users. Microsoft designed Windows 10 to meet these requirements by implementing a new approach to innovation development and delivery called *Windows as a Service* (WaaS).
|
||||
The key to enabling significantly shorter product cycles while maintaining high quality levels is an innovative community-centric approach to testing that Microsoft has implemented for Windows 10. The community, known as Windows Insiders, is comprised of millions of users around the world. When Windows Insiders opt in to the community, they test many builds over the course of a product cycle, and provide feedback to Microsoft through an iterative methodology called *flighting*.
|
||||
Builds distributed as *flights* provide the Windows engineering team with significant data regarding how well builds are performing in actual use. Flighting with Windows Insiders also enables Microsoft to test builds in much more diverse hardware, application, and networking environments than in the past, and to identify issues far more quickly. As a result, Microsoft believes that community-focused flighting will enable both a faster pace of innovation delivery, and better public release quality than ever.
|
||||
|
||||
**Windows 10 release types and cadences**
|
||||
|
||||
Although Microsoft releases flight builds to Windows Insiders, Microsoft will publish two types of Windows 10 releases broadly to the public on an ongoing basis:
|
||||
- **Feature upgrades** that install the latest new features, experiences, and capabilities on devices that are already running Windows 10. Because feature upgrades contain an entire copy of Windows, they are also what customers use to install Windows 10 on existing devices running Windows 7 or Windows 8.1, and on new devices where no operating system is installed.
|
||||
- **Servicing updates** that focus on the installation of security fixes and other important updates.
|
||||
Microsoft expects to publish an average of two to three new feature upgrades per year, and to publish servicing updates as needed for any feature upgrades that are still in support. Microsoft will continue publishing servicing updates on Update Tuesday (sometimes referred to as Patch Tuesday). Additionally, Microsoft may publish additional servicing updates for Windows 10 outside the Update Tuesday process when required to address customer needs.
|
||||
|
||||
**The cumulative nature of all Windows 10 releases**
|
||||
It is important to note that, in order to improve release quality and simplify deployments, all new releases that Microsoft publishes for Windows 10 will be *cumulative*. This means new feature upgrades and servicing updates will contain the *payloads* of all previous releases (in an optimized form to reduce storage and networking requirements), and installing the release on a device will bring it completely up to date. Also, unlike earlier versions of Windows, you cannot install a subset of the contents of a Windows 10 servicing update. For example, if a servicing update contains fixes for three security vulnerabilities and one reliability issue, deploying the update will result in the installation of all four fixes.
|
||||
|
||||
## New Windows 10 delivery and installation alternatives
|
||||
|
||||
As with earlier releases of Windows, Windows 10 includes support for the deployment of new releases using Windows Update, Windows Server Update Services, System Center Configuration Manager, and third-party configuration management tools. Because of the importance of the Windows as a Service (WaaS) approach to delivering innovations to businesses, and the proven ability of Windows Update to deploy releases quickly and seamlessly to consumers and small businesses, several of the largest investments in Windows 10 focus on enabling broader use of Windows Update within enterprises.
|
||||
|
||||
**Windows Update use by consumers and small businesses**
|
||||
|
||||
Since Microsoft introduced the first generation of Windows Update with Windows 95, Windows Update has evolved to become the standard way for consumers and small businesses to help keep devices running Windows secure and running reliably. Almost one billion Windows devices communicate with the Windows Update service on a regular basis. The process of downloading and installing updates has evolved to be less and less obtrusive to users. More recently, Microsoft also has used Windows Update to deliver larger, feature-centric updates, such as the upgrade from Windows 8 to Windows 8.1, and is using Windows Update to upgrade devices running Windows 7 and Windows 8.1 to Windows 10.
|
||||
|
||||
**Windows Update use within enterprises**
|
||||
|
||||
Although Windows Update greatly simplifies and accelerates update deployment, enterprises are not using Windows Update as broadly as consumers and small businesses. This is largely because Windows Update maintains control over which updates are installed and the timing of installation. This makes it difficult for IT administrators to test updates before deployment in their specific environment.
|
||||
|
||||
**The role of Windows Server Update Services**
|
||||
|
||||
To help address the concerns of IT administrators, Microsoft released Windows Server Update Services in 2005. Windows Server Update Services enables IT administrators to obtain the updates that Windows Update determines are applicable to the devices in their enterprise, perform additional testing and evaluation on the updates, and select the updates they want to install. Windows Server Update Services also provides IT administrators with an all or nothing way to specify when they want an approved update to be installed. Because IT administrators ultimately select and install most updates identified by Windows Update, the role of Windows Server Update Services in many enterprises is to provide IT administrators with the additional time they need to gain confidence in the quality of updates prior to deployment.
|
||||
|
||||
**New Windows Update capabilities in Windows 10**
|
||||
|
||||
To enable enterprises to manage more of their devices using Windows Update directly, Windows 10 provides IT administrators with a way to configure devices so that Windows Update will defer new feature upgrade installations until approximately four months after Microsoft first publishes them. The additional time can be used to perform testing or enable releases to gain additional time in market prior to deployment.
|
||||
At the end of each approximately four month period, Microsoft executes a set of processes that require no action from enterprise IT administrators. First, Microsoft creates new installation media for the feature upgrade by combining the original installation media with all the servicing updates published by Microsoft since the original media’s release. This reduces the time it can take to install a feature upgrade on a device. Second, Microsoft *republishes* the new media to Windows Update with *targeting* instructions that state (in effect) “install this media on devices that are configured for deferred installation of new feature upgrades.” At this point, devices configured to defer installation will begin receiving and installing the feature upgrade automatically.
|
||||
|
||||
**The role of Windows Update for Business**
|
||||
|
||||
Although Windows 10 will enable IT administrators to defer installation of new feature upgrades using Windows Update, enterprises may also want additional control over how and when Windows Update installs releases. With this need in mind, Microsoft [announced Windows Update for Business](http://go.microsoft.com/fwlink/p/?LinkId=624798) in May of 2015. Microsoft designed Windows Update for Business to provide IT administrators with additional Windows Update-centric management capabilities, such as the ability to deploy updates to groups of devices and to define maintenance windows for installing releases. This article will be updated with additional information about the role of Windows Update for Business in servicing Windows 10 devices as it becomes available.
|
||||
|
||||
## Windows 10 servicing options
|
||||
|
||||
Historically, because of the length of time between releases of new Windows versions, and the relatively low number of enterprise devices that were upgraded to newer versions of Windows during their deployment lifetimes, most IT administrators defined servicing as installing the updates that Microsoft published every month. Looking forward, because Microsoft will be publishing new feature upgrades on a continual basis, *servicing* will also include (on some portion of an enterprise's devices) installing new feature upgrades as they become available.
|
||||
In fact, when planning to deploy Windows 10 on a device, one of the most important questions for IT administrators to ask is, “What should happen to this device when Microsoft publishes a new feature upgrade?” This is because Microsoft designed Windows 10 to provide businesses with multiple servicing options, centered on enabling different rates of feature upgrade adoption. In particular, IT administrators can configure Windows 10 devices to:
|
||||
- Receive feature upgrades immediately after Microsoft makes them available publicly, so that users gain access to new features, experiences, and functionality as soon as possible. For more information, see [Immediate feature upgrade installation with Current Branch (CB) servicing](#immediate-upgrade-cb).
|
||||
- Defer receiving feature upgrades for a period of approximately four months after Microsoft makes them available publicly, to provide IT administrators with time to perform pre-deployment testing and provide feature upgrades releases with additional time-in-market to mature. For more information, see [Deferred feature upgrade installation with Current Branch for Business (CBB) servicing](#deferred-upgrade-cbb).
|
||||
- Receive only servicing updates for the duration of their Windows 10 deployment in order to reduce the number of non-essential changes made to the device. For more information, see [Install servicing updates only by using Long-Term Servicing Branch (LTSB) servicing](#install-updates-ltsb).
|
||||
The breakout of a company’s devices by the categories above is likely to vary significantly by industry and other factors. What is most important is that companies can decide what works best for them and can choose different options for different devices.
|
||||
|
||||
## Plan for Windows 10 deployment
|
||||
|
||||
The remainder of this article focuses on the description of the three options outlined above, and their planning implications, in more detail. In practice, IT administrators have to focus on two areas when planning a Windows 10 device deployment:
|
||||
- **When should new feature upgrades be deployed?** Should the device install new feature upgrades when they are published by Microsoft? If so, should installation occur immediately or on a deferred basis?
|
||||
- **How will releases be installed on devices?** Will Windows Update or Windows Server Update Services be used to install new releases, or will installation be performed using a configuration management system such as Configuration Manager?
|
||||
- **How will releases be installed on devices?** Will Windows Update or Windows Server Update Services be used to install new releases, or will installation be performed using a configuration management system such as
|
||||
Configuration Manager?
|
||||
|
||||
The content that follows will provide IT administrators with the context needed to understand why these areas are pivotal, and the choices available to them.
|
||||
|
||||
**How Microsoft releases Windows 10 feature upgrades**
|
||||
|
||||
When it is time to release a build as a new feature upgrade for Windows 10, Microsoft performs several processes in sequence. The first process involves creating either one or two servicing branches in a source code management system. These branches (shown in Figure 1) are required to produce feature upgrade installation media and servicing update packages that can be deployed on different Windows 10 editions, running in different configurations.
|
||||
|
||||

|
||||
|
||||
Figure 1. Feature upgrades and servicing branches
|
||||
|
||||
In all cases, Microsoft creates a servicing branch (referred to in Figure 1 as Servicing Branch \#1) that is used to produce releases for approximately one year (although the lifetime of the branch will ultimately depend on when Microsoft publishes subsequent feature upgrade releases). If Microsoft has selected the feature upgrade to receive long-term servicing-only support, Microsoft also creates a second servicing branch (referred to in Figure 1 as Servicing Branch \#2) that is used to produce servicing update releases for up to 10 years.
|
||||
|
||||
As shown in Figure 2, when Microsoft publishes a new feature upgrade, Servicing Branch \#1 is used to produce the various forms of media needed by OEMs, businesses, and consumers to install Windows 10 Home, Pro, Education, and Enterprise editions. Microsoft also produces the files needed by Windows Update to distribute and install the feature upgrade, along with *targeting* information that instructs Windows Update to only install the files on devices configured for *immediate* installation of feature upgrades.
|
||||
|
||||

|
||||
|
||||
Figure 2. Producing feature upgrades from servicing branches
|
||||
|
||||
Approximately four months after publishing the feature upgrade, Microsoft uses Servicing Branch \#1 again to *republish* updated installation media for Windows 10 Pro, Education, and Enterprise editions. The updated media contains the exact same feature upgrade as contained in the original media except Microsoft also includes all the servicing updates that were published since the feature upgrade was first made available. This enables the feature upgrade to be installed on a device more quickly, and in a way that is potentially less obtrusive to users.
|
||||
|
||||
Concurrently, Microsoft also changes the way the feature upgrade is published in the Windows Update service. In particular, the files used by Windows Update to distribute and install the feature upgrade are refreshed with the updated versions, and the targeting instructions are changed so that the updated feature upgrade will now be installed on devices configured for *deferred* installation of feature upgrades.
|
||||
|
||||
**How Microsoft publishes the Windows 10 Enterprise LTSB Edition**
|
||||
|
||||
If Microsoft has selected the feature upgrade to receive long-term servicing support, Servicing Branch \#2 is used to publish the media needed to install the Windows 10 Enterprise LTSB edition. The time between releases of feature upgrades with long-term servicing support will vary between one and three years, and is strongly influenced by input from customers regarding the readiness of the release for long-term enterprise deployment. Figure 2 shows the Windows 10 Enterprise LTSB edition being published at the same time as the other Windows 10 editions, which mirrors the way editions were actually published for Windows 10 in July of 2015. It is important to note that this media is never published to Windows Update for deployment. Installations of the Enterprise LTSB edition on devices must be performed another way.
|
||||
|
||||
**How Microsoft releases Windows 10 servicing updates**
|
||||
|
||||
As shown in Figure 3, servicing branches are also used by Microsoft to produce servicing updates containing fixes for security vulnerabilities and other important issues. Servicing updates are published in a way that determines the Windows 10 editions on which they can be installed. For example, servicing updates produced from a given servicing branch can only be installed on devices running a Windows 10 edition produced from the same servicing branch. In addition, because Windows 10 Home does not support deferred installation of feature upgrades, servicing updates produced from Servicing Branch \#1 are targeted at devices running Windows 10 Home only until Microsoft publishes feature upgrades for deferred installation.
|
||||
|
||||

|
||||
|
||||
Figure 3. Producing servicing updates from servicing branches
|
||||
|
||||
**Release installation alternatives**
|
||||
|
||||
When IT administrators select Windows Update and/or Windows Server Update Services to deploy feature upgrades and servicing updates, Windows 10 and Windows Update will determine and deploy the correct releases for each of the three servicing options at the appropriate times. If there are multiple feature upgrades receiving long-term servicing support at the same time, Windows Update will select updates for each device that are appropriate for the feature upgrades they are running.
|
||||
|
||||
When IT administrators manage deployments of feature upgrades and servicing updates directly with configuration management products such as Configuration Manager, they are responsible for the timing of installation of both feature upgrades and servicing updates. It is important to note that until IT administrators install a new servicing update, devices may remain exposed to security vulnerabilities. Therefore, when managing deployments directly, IT administrators should deploy new servicing updates as soon as possible.
|
||||
|
||||
## Servicing options and servicing branch designations
|
||||
|
||||
Servicing options have several different attributes that affect deployment planning decisions. For example, each servicing option:
|
||||
- Is supported on a selected set of Windows 10 editions (and no Windows 10 edition supports all three servicing options).
|
||||
- Has a policy that determines the periods of time during which Microsoft will produce servicing updates for a given feature upgrade.
|
||||
- Has a policy that determines when devices being managed by Windows Update or Windows Server Update Services will install new feature upgrades when they become available from Microsoft.
|
||||
Because the servicing lifetime of a feature upgrade typically ends when the servicing lifetime of the subsequent feature upgrade begins, the length of servicing lifetimes will also vary. To simplify referring to these ranges, Microsoft created *servicing branch designations* for each of the three time range/servicing branch combinations. The designations are Current Branch (CB), Current Branch for Business (CBB), and Long-Term Servicing Branch (LTSB).
|
||||
|
||||
Because the servicing lifetime of a feature upgrade typically ends when the servicing lifetime of the subsequent feature upgrade begins, the length of servicing lifetimes will also vary. To simplify referring to these ranges,
|
||||
Microsoft created *servicing branch designations* for each of the three time range/servicing branch combinations. The designations are Current Branch (CB), Current Branch for Business (CBB), and Long-Term Servicing Branch (LTSB).
|
||||
Because there is a one-to-one mapping between servicing options and servicing branch designations, Microsoft occasionally refers to servicing options using servicing branch-centric terminology. The following sections describe servicing options and servicing branch designations, including terminology, servicing lifetime policies, upgrade behavior, and edition support, in more detail.
|
||||
|
||||
**Service lifetime and feature upgrade installation paths**
|
||||
|
||||
Although Microsoft is currently planning to release approximately two to three feature upgrades per year, the actual frequency and timing of releases will vary. Because the servicing lifetimes of feature upgrades typically end when the servicing lifetimes of other, subsequent feature upgrades begin, the lengths of servicing lifetimes will also vary.
|
||||
|
||||

|
||||
|
||||
Figure 4. Example release cadence across multiple feature upgrades
|
||||
|
||||
To show the variability of servicing lifetimes, and show the paths that feature upgrade installations will take when Windows Update and Windows Server Update Services are used for deployments, Figure 4 contains three feature upgrade releases (labeled *X*, *Y*, and *Z*) and their associated servicing branches. The time period between publishing X and Y is four months, and the time period between publishing Y and Z is six months. X and Z have long-term servicing support, and Y has shorter-term servicing support only.
|
||||
|
||||
The same underlying figure will be used in subsequent figures to show all three servicing options in detail. It is important to note that Figure 4 is provided for illustration of servicing concepts only and should not be used for actual Windows 10 release planning.
|
||||
|
||||
To simplify the servicing lifetime and feature upgrade behavior explanations that follow, this document refers to branch designations for a specific feature upgrade as the +0 versions, the designations for the feature upgrade after the +0 version as the +1 (or successor) versions, and the designation for the feature upgrade after the +1 version as the +2 (or second successor) versions.
|
||||
|
||||
### <a href="" id="immediate-upgrade-cb"></a>
|
||||
|
||||
**Immediate feature upgrade installation with Current Branch (CB) servicing**
|
||||
As shown in Figure 5, the Current Branch (CB) designation refers to Servicing Branch \#1 during the period that starts when Microsoft publishes a feature upgrade targeted for devices configured for *immediate* installation and ends when Microsoft publishes the *successor* feature upgrade targeted for devices configured for *immediate* installation.
|
||||
|
||||

|
||||
|
||||
Figure 5. Immediate installation with Current Branch Servicing
|
||||
|
||||
The role of Servicing Branch \#1 during the CB period is to produce feature upgrades and servicing updates for Windows 10 devices configured for *immediate* installation of new feature upgrades. Microsoft refers to devices configured this way as being *serviced from CBs*. The Windows 10 editions that support servicing from CBs are Home, Pro, Education, and Enterprise. The Current Branch designation is intended to reflect the fact that devices serviced using this approach will be kept as current as possible with respect to the latest Windows 10 feature upgrade release.
|
||||
Windows 10 Home supports Windows Update for release deployment. Windows 10 editions (Pro, Education, and Enterprise) support Windows Update, Windows Server Update Services, Configuration Manager, and other configuration management systems:
|
||||
- When IT administrators use Windows Update to manage deployments, devices will receive new feature upgrades and servicing updates as soon as they are published by Microsoft in the Windows Update service, targeted to devices configured for *immediate* feature upgrade installation.
|
||||
- When devices are being managed by using Windows Server Update Services, the same workflows are executed as with Windows Update except IT administrators must approve releases before installations begin.
|
||||
- When using configuration management systems such as Configuration Manager to manage deployments, IT administrators can obtain installation media from Microsoft and deploy new feature upgrades immediately by using standard change control processes. IT administrators who use configuration management systems should also make sure to obtain and deploy all servicing updates published by Microsoft as soon as possible.
|
||||
It is important to note that devices serviced from CBs must install two to three feature upgrades per year to remain current and continue to receive servicing updates.
|
||||
|
||||
### <a href="" id="deferred-upgrade-cbb"></a>
|
||||
|
||||
**Deferred feature upgrade installation with Current Branch for Business (CBB) servicing**
|
||||
As shown in Figure 6, the Current Branch for Business (CBB) designation refers to Servicing Branch \#1 during the period that starts when Microsoft republishes a feature upgrade targeted for devices configured for *deferred* installation and ends when Microsoft republishes the *second successor* feature upgrade targeted for devices configured for *deferred* installation.
|
||||
|
||||

|
||||
|
||||
Figure 6. Deferred installation with Current Branch for Business Servicing
|
||||
|
||||
The role of Servicing Branch \#1 during the CBB period is to produce feature upgrades and servicing updates for Windows 10 devices configured for *deferred* installation of new feature upgrades. Microsoft refers to devices configured this way as being *serviced from CBBs*. The Windows 10 editions that support servicing from CBBs are Pro, Education, and Enterprise. The Current Branch for Business designation is intended to reflect the fact that many businesses require IT administrators to test feature upgrades prior to deployment, and servicing devices from CBBs is a pragmatic solution for businesses with testing constraints to remain as current as possible.
|
||||
Windows 10 (Pro, Education, and Enterprise editions) support release deployment by using Windows Update, Windows Server Update Services, Configuration Manager, and other configuration management systems:
|
||||
- When IT administrators use Windows Update to manage deployments, devices will receive new feature upgrades and servicing updates as soon as they are published by Microsoft in the Windows Update service, targeted to devices configured for *deferred* feature upgrade installation. It is important to note that, even when devices are configured to defer installations, all servicing updates that are applicable to the feature upgrade that is running on a device will be installed immediately after being published by Microsoft in the Windows Update service.
|
||||
- When devices are being managed through Windows Server Update Services, the same workflows are executed as with Windows Update except IT administrators must approve releases before installations begin.
|
||||
- When using configuration management systems such as Configuration Manager to manage deployments, IT administrators can obtain media published for deferred installation from Microsoft and deploy new feature upgrades by using standard change control processes. When deferring feature upgrade installations, IT administrators should still deploy all applicable servicing updates as soon as they become available from Microsoft.
|
||||
Microsoft designed Windows 10 servicing lifetime policies so that CBBs will receive servicing updates for approximately twice as many months as CBs. This enables two CBBs to receive servicing support at the same time, which provides businesses with more flexibility when deploying new feature upgrades. That said, it is important to note that Microsoft will not produce servicing updates for a feature upgrade after its corresponding CBB reaches the end of its servicing lifetime. This means that feature upgrade deployments cannot be extended indefinitely and IT administrators should ensure that they deploy newer feature upgrades onto devices before CBBs end.
|
||||
|
||||
### <a href="" id="install-updates-ltsb"></a>
|
||||
|
||||
**Install servicing updates only by using Long-Term Servicing Branch (LTSB) servicing**
|
||||
|
||||
As shown in Figure 7, the Long-Term Servicing Branch (LTSB) designation refers to Servicing Branch \#2 from beginning to end. LTSBs begin when a feature upgrade with long-term support is published by Microsoft and end after 10 years. It is important to note that only the Windows 10 Enterprise LTSB edition supports long-term servicing, and there are important differences between this edition and other Windows 10 editions regarding upgradability and feature set (described below in the [Considerations when configuring devices for servicing updates only](#servicing-only) section).
|
||||
|
||||

|
||||
|
||||
Figure 7. Servicing updates only using LTSB Servicing
|
||||
|
||||
The role of LTSBs is to produce servicing updates for devices running Windows 10 configured to install servicing updates only. Devices configured this way are referred to as being *serviced from LTSBs*. The Long-Term Servicing Branch designation is intended to reflect the fact that this servicing option is intended for scenarios where changes to software running on devices must be limited to essential updates (such as those for security vulnerabilities and other important issues) for the duration of deployments.
|
||||
Windows 10 Enterprise LTSB supports release deployment by using Windows Update, Windows Server Update Services, Configuration Manager, and other configuration management systems:
|
||||
- When IT administrators use Windows Update to manage deployments, Windows Update will install only servicing updates, and do so as soon as they are published by Microsoft in the Windows Update service. Windows Update does not install feature upgrades on devices configured for long-term servicing.
|
||||
- When devices are being managed using Windows Server Update Services, the same workflows are executed as with Windows Update except IT administrators must approve releases before installations begin.
|
||||
- When using configuration management systems such as System Center Configuration Manager to manage deployments, IT administrators should make sure to obtain and deploy all servicing updates published by Microsoft as soon as possible.
|
||||
|
||||
**Note**
|
||||
It is important to note again that not all feature upgrades will have an LTSB. The initial release of Windows 10, published in July 2015, has an LTSB and Microsoft expects to designate one additional feature upgrade in the next 12 months for long-term support. After that, Microsoft expects to publish feature upgrades with long-term servicing support approximately every two to three years. Microsoft will provide additional information in advance of publishing new feature upgrades so that IT administrators can make informed deployment planning decisions.
|
||||
|
||||
### <a href="" id="servicing-only"></a>
|
||||
|
||||
**Considerations when configuring devices for servicing updates only**
|
||||
Before deciding to configure a device for LTSB-based servicing, IT administrators should carefully consider the implications of changing to a different servicing option later, and the effect of using Windows 10 Enterprise LTSB on the availability of *in-box* applications.
|
||||
|
||||
Regarding edition changes, it is possible to reconfigure a device running Windows 10 Enterprise LTSB to run Windows 10 Enterprise while preserving the data and applications already on the device. Reconfiguring a device running Windows 10 Enterprise LTSB to run other editions of Windows 10 may require IT administrators to restore data and/or reinstall applications on the device after the other edition has been installed.
|
||||
Regarding in-box applications, Windows 10 Enterprise LTSB does not include all the universal apps that are included with other Windows 10 editions. This is because the universal apps included with Windows 10 will be continually upgraded by Microsoft, and new releases of in-box universal apps are unlikely to remain compatible with a feature upgrade of Windows 10 Enterprise LTSB for the duration of its servicing lifetime. Examples of apps that Windows 10 Enterprise LTSB does not include are Microsoft Edge, Windows Store Client, Cortana (limited search capabilities remain available), Outlook Mail, Outlook Calendar, OneNote, Weather, News, Sports, Money, Photos, Camera, Music, and Clock.
|
||||
|
||||
Windows 10 Enterprise LTSB does include Internet Explorer 11, and is compatible with Windows 32 versions of Microsoft Office. IT administrators can also install universal apps on devices when apps are compatible with the feature upgrades running on the device. They should do so with care, however, as servicing updates targeted for devices running Windows 10 Enterprise LTSB will not include security or non-security fixes for universal apps. Additionally, Microsoft will not provide servicing updates for specific releases of apps on any Windows 10 edition after the feature upgrade of Windows 10 with which the apps were included reaches the end of its servicing lifetime.
|
||||
|
||||
**Servicing option summary**
|
||||
|
||||
Table 2. Servicing option summary
|
||||
<table>
|
||||
<tr>
|
||||
@ -235,8 +322,11 @@ universal apps removed
|
||||
</table>
|
||||
|
||||
## Related topics
|
||||
|
||||
[Plan for Windows 10 deployment](../plan/index.md)
|
||||
|
||||
[Deploy Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=624776)
|
||||
|
||||
[Manage and update Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=624796)
|
||||
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user