mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-20 12:53:38 +00:00
Merge branch 'main' into nidos_working
This commit is contained in:
@ -1,92 +1,82 @@
|
||||
- name: Delivery Optimization for Windows client
|
||||
- name: Delivery Optimization for Windows client and Microsoft Connected Cache
|
||||
href: index.yml
|
||||
- name: What's new
|
||||
href: whats-new-do.md
|
||||
items:
|
||||
- name: Get started
|
||||
items:
|
||||
- name: What is Delivery Optimization
|
||||
href: waas-delivery-optimization.md
|
||||
- name: What's new
|
||||
href: whats-new-do.md
|
||||
- name: Delivery Optimization Frequently Asked Questions
|
||||
href: waas-delivery-optimization-faq.yml
|
||||
|
||||
|
||||
|
||||
- name: Configure Delivery Optimization
|
||||
- name: Delivery Optimization
|
||||
items:
|
||||
- name: What is Delivery Optimization
|
||||
href: waas-delivery-optimization.md
|
||||
- name: Delivery Optimization Frequently Asked Questions
|
||||
href: waas-delivery-optimization-faq.yml
|
||||
- name: Configure Delivery Optimization for Windows clients
|
||||
items:
|
||||
- name: Windows client Delivery Optimization settings
|
||||
href: waas-delivery-optimization-setup.md#recommended-delivery-optimization-settings
|
||||
- name: Configure Delivery Optimization settings using Microsoft Intune
|
||||
href: /mem/intune/configuration/delivery-optimization-windows
|
||||
- name: Resources for Delivery Optimization
|
||||
items:
|
||||
- name: Set up Delivery Optimization for Windows
|
||||
href: waas-delivery-optimization-setup.md
|
||||
- name: Delivery Optimization reference
|
||||
href: waas-delivery-optimization-reference.md
|
||||
- name: Delivery Optimization client-service communication
|
||||
href: delivery-optimization-workflow.md
|
||||
- name: Using a proxy with Delivery Optimization
|
||||
href: delivery-optimization-proxy.md
|
||||
- name: Microsoft Connected Cache
|
||||
items:
|
||||
- name: MCC overview
|
||||
href: waas-microsoft-connected-cache.md
|
||||
- name: MCC for Enterprise and Education
|
||||
href: mcc-enterprise.md
|
||||
- name: MCC for ISPs
|
||||
items:
|
||||
- name: Configure Windows Clients
|
||||
items:
|
||||
- name: Windows Delivery Optimization settings
|
||||
href: waas-delivery-optimization-setup.md#recommended-delivery-optimization-settings
|
||||
- name: Windows Delivery Optimization Frequently Asked Questions
|
||||
href: ../do/waas-delivery-optimization-faq.yml
|
||||
- name: Configure Microsoft Endpoint Manager
|
||||
items:
|
||||
- name: Delivery Optimization settings in Microsoft Intune
|
||||
href: /mem/intune/configuration/delivery-optimization-windows
|
||||
|
||||
- name: Microsoft Connected Cache
|
||||
items:
|
||||
- name: MCC overview
|
||||
href: waas-microsoft-connected-cache.md
|
||||
- name: MCC for Enterprise and Education
|
||||
href: mcc-enterprise.md
|
||||
- name: MCC for ISPs
|
||||
items:
|
||||
- name: MCC for ISPs Overview
|
||||
href: mcc-isp.md
|
||||
- name: Concepts
|
||||
items:
|
||||
- name: Device Provisioning
|
||||
href: mcc-isp-device-provisioning.md
|
||||
- name: Client Routing
|
||||
href: mcc-isp-client-routing.md
|
||||
- name: Cache Node Configuration
|
||||
href: mcc-isp-cache-node-configuration.md
|
||||
- name: How-to guides
|
||||
items:
|
||||
- name: Operator sign up and service onboarding
|
||||
href: mcc-isp-signup.md
|
||||
- name: Create the MCC in Azure portal
|
||||
href: mcc-isp-create.md
|
||||
- name: Provision and deploy cache node to your server
|
||||
href: mcc-isp-provision-deploy.md
|
||||
- name: Configure client routing for cache node
|
||||
href: mcc-isp-configure-routing.md
|
||||
- name: Verify cache node functionality
|
||||
href: mcc-isp-verify-cache-node.md
|
||||
- name: Update your cache node
|
||||
href: mcc-isp-update.md
|
||||
- name: Monitor cache node health and performance
|
||||
href: mcc-isp-monitor.md
|
||||
- name: Uninstall your cache node
|
||||
href: mcc-isp-uninstall.md
|
||||
- name: Resources
|
||||
items:
|
||||
- name: MCC for ISP Community Forum
|
||||
href: link-to-come
|
||||
- name: FAQs
|
||||
href: mcc-isp-faq.md
|
||||
- name: Common Issues
|
||||
href: mcc-isp-common-issues.md
|
||||
- name: Enhancing VM performance
|
||||
href: mcc-isp-vm-performance.md
|
||||
- name: Support
|
||||
href: mcc-isp-support.md
|
||||
- name: Overview
|
||||
href: mcc-isp-overview.md
|
||||
- name: Concepts
|
||||
items:
|
||||
- name: Device provisioning
|
||||
href: mcc-isp-device-provisioning.md
|
||||
- name: Client routing
|
||||
href: mcc-isp-client-routing.md
|
||||
- name: Cache node configuration
|
||||
href: mcc-isp-cache-node-configuration.md
|
||||
- name: Traffic estimation
|
||||
href: mcc-traffic-estimation.md
|
||||
- name: How-to guides
|
||||
items:
|
||||
- name: Operator sign up and service onboarding
|
||||
href: mcc-isp-signup.md
|
||||
- name: Create the MCC in Azure portal
|
||||
href: mcc-isp-create.md
|
||||
- name: Provision and deploy cache node to your server
|
||||
href: mcc-isp-provision-deploy.md
|
||||
- name: Configure client routing for cache node
|
||||
href: mcc-isp-configure-routing.md
|
||||
- name: Verify cache node functionality
|
||||
href: mcc-isp-verify-cache-node.md
|
||||
- name: Update your cache node
|
||||
href: mcc-isp-update.md
|
||||
- name: Monitor cache node health and performance
|
||||
href: mcc-isp-monitor.md
|
||||
- name: Uninstall your cache node
|
||||
href: mcc-isp-uninstall.md
|
||||
- name: Resources
|
||||
items:
|
||||
- name: Community forum
|
||||
href: link-to-come
|
||||
- name: FAQs
|
||||
href: mcc-isp-faq.md
|
||||
- name: Enhancing VM performance
|
||||
href: mcc-isp-vm-performance.md
|
||||
- name: Support and troubleshooting
|
||||
href: mcc-isp-support.md
|
||||
- name: MCC for ISPs (Private Preview)
|
||||
href: mcc-isp.md
|
||||
- name: Content endpoints for Delivery Optimization and Microsoft Connected Cache
|
||||
href: delivery-optimization-endpoints.md
|
||||
|
||||
|
||||
|
||||
|
||||
- name: Resources
|
||||
items:
|
||||
- name: Set up Delivery Optimization for Windows
|
||||
href: waas-delivery-optimization-setup.md
|
||||
- name: Delivery Optimization reference
|
||||
href: waas-delivery-optimization-reference.md
|
||||
- name: Delivery Optimization client-service communication
|
||||
href: delivery-optimization-workflow.md
|
||||
- name: Using a proxy with Delivery Optimization
|
||||
href: delivery-optimization-proxy.md
|
||||
- name: Content endpoints for Delivery Optimization and Microsoft Connected Cache
|
||||
href: delivery-optimization-endpoints.md
|
||||
|
||||
|
||||
|
BIN
windows/deployment/do/images/mcc-img-metrics.PNG
Normal file
BIN
windows/deployment/do/images/mcc-img-metrics.PNG
Normal file
Binary file not shown.
After Width: | Height: | Size: 40 KiB |
@ -0,0 +1,28 @@
|
||||
# Cache node configuration
|
||||
|
||||
All cache node configuration will take place within Azure portal. This article outlines all of the settings that you will be able to configure.
|
||||
|
||||
## Settings
|
||||
|
||||
| Field Name | Expected Value| Description |
|
||||
| -- | --- | --- |
|
||||
| **Cache node name** | Alphanumeric string that contains no spaces | The name of the cache node. You may choose names based on location like Seattle-1. This name must be unique and can't be changed later. |
|
||||
| **Server IP address** | IPv4 address | IP address of your MCC server. This address is used to route end-user devices in your network to the server for Microsoft content downloads. The IP address must be publicly accessible. |
|
||||
| **Max allowable egress (Mbps)** | Integer in Mbps | The maximum egress (Mbps) of your MCC based on the specifications of your hardware. For example, 10,000 Mbps.|
|
||||
| **Enable cache node** | Enable or Disable | You can choose to enable or disable a cache node at any time. |
|
||||
|
||||
## Storage
|
||||
|
||||
| Field Name | Expected Value| Description |
|
||||
| -- | --- | --- |
|
||||
| **Cache drive** | File path string | Up to 9 drives can be configured for each cache node to configure cache storage. Enter the file path to each drive. For example: /dev/folder/ |
|
||||
| **Cache drive size in gigabytes** | Integer in GB | Set the size of each drive configured for the cache node. |
|
||||
|
||||
## Client routing
|
||||
|
||||
| Field Name | Expected Value| Description |
|
||||
| -- | --- | --- |
|
||||
| **Manual touting - Address range/CIDR blocks** | IPv4 CIDR notation | The IP address range (CIDR blocks) that should be routed to the MCC server as a comma separated list. For example: 2.21.234.0/24, 3.22.235.0/24, 4.23.236.0/24 |
|
||||
| **BGP - Neighbor ASN** | ASN | When configuring BGP, enter the ASN(s) of your neighbors that you want to establish. |
|
||||
| **BGP - Neighbor IP address** | IPv4 address | When configuring BGP, enter the IP address(es) of neighbors that you want to establish. |
|
||||
|
||||
|
@ -0,0 +1,18 @@
|
||||
# Client Routing
|
||||
|
||||
Before serving traffic to your customers, client routing configuration is needed. During the configuration of your cache node in Azure portal, you will be able to route your clients to your cache node.
|
||||
|
||||
Microsoft Connected Cache offers two ways for you to route your clients to your cache node. The first method of manual entry involves uploading a comma-separated list of CIDR blocks that represents the clients. The second method of setting BGP (Border Gateway Protocol) is more automatic and dynamic, which is set up by establishing neighborships with other ASNs. All routing methods are set up within Azure portal.
|
||||
|
||||
Once client routing and other settings are configured, your cache node will be able to download content and serve traffic to your customers.
|
||||
|
||||
At this time, only IPv4 addresses are supported. IPv6 addresses are not supported.
|
||||
|
||||
### Manual routing
|
||||
|
||||
You can manually upload a list of your CIDR blocks in Azure portal to enable manual routing of your customers to your cache node.
|
||||
|
||||
### BGP routing
|
||||
|
||||
BGP (Border Gateway Protocol) routing is another method offered for client routing. BGP dynamically retrieves CIDR ranges by exchanging information with routers to understand reachable networks. For an automatic method of routing traffic, you can choose to configure BGP routing in Azure portal.
|
||||
|
||||
|
@ -0,0 +1,35 @@
|
||||
# Configure client routing for cache node
|
||||
|
||||
All configuration routing takes place within the Azure Portal. There are two main methods to route clients to your cache node:
|
||||
|
||||
- **Manual Routing**: Providing the CIDR blocks that represent the client IP address space, which should be routed to the MCC node.
|
||||
- **BGP Routing**: BGP neighborship sessions from the cache node to the router or route server will be initiated automatically based on the portal configuration.
|
||||
|
||||
> [!NOTE]
|
||||
> Only IPv4 addresses are supported at this time. Entering IPv6 addresses will result in an error.
|
||||
|
||||
## Manual Routing
|
||||
|
||||
1. To configure client routing using manually entered CIDR blocks, navigate to **Settings** >> **Routing Information**.
|
||||
1. Select **Manual prefix entry** as the Prefix Source.
|
||||
1. Paste in the CIDR blocks, with each IP range separated by a comma.
|
||||
1. Lastly, press Save to save your changes.
|
||||
|
||||
## BGP Routing
|
||||
|
||||
1. To configure client routing using BGP, navigate to **Settings** >> **Routing Information**.
|
||||
1. Select **BGP** as the Prefix source.
|
||||
1. Click on **Add neighbor** to add the ASN(s) and IP address(es) of your BGP neighbors.
|
||||
1. If you'd like to download your BGP routes, click on the **Download Routes** button.
|
||||
1. Lastly, press Save to save your changes.
|
||||
1. From your end, establish a neighborship from your router to MCC's host machine. Use the IP address of the host machine that's running the MCC container.
|
||||
|
||||
> [!NOTE]
|
||||
> With the BGP configuration, you're essentially setting up an iBGP neighbor in your public ASN. For example, when you initiate the BGP session from the router to the cache node, you would use your own ASN.
|
||||
|
||||
> [!NOTE]
|
||||
> Make sure there aren't any firewall rules blocking this connection.
|
||||
|
||||
To verify that BGP has been configured properly and that Microsoft Connected Cache services are receiving the route advertisements, wait about five minutes before refreshing cache node settings page and view the BGP routes received.
|
||||
|
||||
If after five minutes, you don't see traffic, navigate to [Support and Troubleshooting](mcc-isp-support.md) for more information.
|
||||
|
@ -0,0 +1,32 @@
|
||||
# Device Provisioning
|
||||
|
||||
Once the user executes the provisioning script, resources are created behind the scenes resulting in the successful cache node installation.
|
||||
The device provisioning script takes the input of different IDs outlined below to create an IoT Central and an IoT Edge device. even though Microsoft Connected Cache scenario is not related to IoT, IoT Central and IoT Edge are installed for management and communication operation purposes.
|
||||
|
||||
### Components installed during provisioning
|
||||
|
||||
#### IoT Central
|
||||
|
||||
IoT Central is the main hub that handles all messaging and requests from IoT Edge devices. To learn more about the interaction between IoT Edge and IoT Central, view [IoT Central](https://docs.microsoft.com/en-us/azure/iot-central/core/concepts-iot-edge) documentation.
|
||||
|
||||
#### IoT Edge
|
||||
|
||||
IoT Edge performs several functions important to manage MCC on your edge device:
|
||||
|
||||
1. Installs and updates MCC on your edge device.
|
||||
1. Maintains Azure IoT Edge security standards on your edge device.
|
||||
1. Ensures that MCC is always running.
|
||||
1. Reports MCC health and usage to the cloud for remote monitoring.
|
||||
|
||||
### Components of the device provisioning script
|
||||
|
||||
There are five IDs that the device provisioning script takes as input in order to successfully provision and install your cache server. The provisioning script will automatically include these keys, with no input necessary from the user.
|
||||
|
||||
| ID | Description |
|
||||
| -- | --- |
|
||||
| Customer ID | The Azure subscription ID that the cache node is created in. |
|
||||
| Cache node ID | The unique alphanumeric ID of the cache node being provisioned. |
|
||||
| Customer key | |
|
||||
| Cache node name | The name of the cache node. |
|
||||
| Tenant ID | The unique ID associated with the Azure account. |
|
||||
|
||||
|
@ -3,21 +3,19 @@
|
||||
## Metrics
|
||||
Within Azure portal, there are a number of metrics that are available to monitor cache node health and performance.
|
||||
|
||||
|
||||
### Available Metrics
|
||||
- **Cache Efficiency**: Cache efficiency is defined as the total cache hit bytes divided by all bytes requested. The higher this value (0 - 100%), the more efficient the cache node is.
|
||||
|
||||
- **Healthy nodes**: The number of cache nodes that are reporting as healthy
|
||||
- **Unhealthy nodes**: The number of cache nodes that are reporting as unhealthy
|
||||
- **Maximum in**: The maximum egress (in Gbps) of inbound traffic
|
||||
- **Maximum out**: The maximum egress (in Gbps) of outbound traffic
|
||||
- **Average in**: The average egress (in Gbps) of inbound traffic
|
||||
- **Average out**: The average egress (in Gbps) of outbound traffic
|
||||
Within Azure portal, you are able to build your custom metrics using the following available metrics:
|
||||
|
||||
### Viewing your metrics
|
||||
To view the metrics associated with your cache nodes, navigate to the **Overview** tab within Azure portal.
|
||||
| Metric name | Description |
|
||||
| -- | ---- |
|
||||
| **Cache Efficiency** | Cache efficiency is defined as the total cache hit bytes divided by all bytes requested. The higher this value (0 - 100%), the more efficient the cache node is. |
|
||||
| **Healthy nodes** | The number of cache nodes that are reporting as healthy|
|
||||
| **Unhealthy nodes**| The number of cache nodes that are reporting as unhealthy|
|
||||
| **Maximum in**| The maximum egress (in Gbps) of inbound traffic|
|
||||
| **Maximum out**| The maximum egress (in Gbps) of outbound traffic|
|
||||
| **Average in**| The average egress (in Gbps) of inbound traffic|
|
||||
| **Average out**| The average egress (in Gbps) of outbound traffic|
|
||||
|
||||
[[ include screenshot of an example view]]
|
||||
|
||||
You can choose to monitor the health and performance of all cache nodes or one by one by using the dropdown menu. The **Egress bits per second** graph shows your inbound and outbound traffic of your cache nodes over time. You can change the time range (1 hour, 12 hours, 1 day, 7 days, 14 days, and 30 days) by selecting the time range of choice on the top bar.
|
||||
|
||||
If you are unable to view metrics for your cache node, it may be that your cache node is unhealthy, inactive, or hasn't been fully configured.
|
||||
To learn more about how to build your custom metrics, visit [Azure Monitor](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/data-platform-metrics) for details.
|
||||
|
0
windows/deployment/do/mcc-isp-overview.md
Normal file
0
windows/deployment/do/mcc-isp-overview.md
Normal file
@ -1,19 +1,19 @@
|
||||
# Uninstall your cache node
|
||||
|
||||
There are two main steps required to uninstall your cache node:
|
||||
1. Delete your cache node from the Azure portal
|
||||
|
||||
|
||||
1. Remove your cache node from Azure portal
|
||||
1. Run the uninstall script to cleanly remove MCC from your server
|
||||
|
||||
|
||||
## Delete your cache node from the Azure portal
|
||||
Navigate to your Overview page. On the top bar, click on **Delete**.
|
||||
## Remove your cache node from Azure portal
|
||||
|
||||
Within Azure portal, navigate to **Cache Nodes**, then select the cache node you wish to delete. Once selected, click **Delete** on the top bar to remove this cache node from your account.
|
||||
|
||||
## Run the uninstall script to cleanly remove MCC from your server
|
||||
In the installer zip file, you'll find the file **uninstallmcc.sh**. This script uninstalls MCC and all the related components. Before you run this script, contact the MCC team. Only run it if you're facing issues with MCC installation.
|
||||
In the installer zip file, you'll find the file **uninstallmcc.sh**. This script uninstalls MCC and all the related components. Only run it if you're facing issues with MCC installation.
|
||||
|
||||
> [!WARNING]
|
||||
> Be cautious before running this script. It will also erase existing IoT workflows in this VM.
|
||||
|
||||
The **uninstallmcc.sh** script removes the following components:
|
||||
|
||||
@ -29,4 +29,7 @@ To run the script, use the following commands:
|
||||
```bash
|
||||
sudo chmod +x uninstallmcc.sh
|
||||
sudo ./uninstallmcc.sh
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
@ -2,6 +2,7 @@
|
||||
|
||||
Microsoft will release updates for MCC periodically to improve performance, functionality, and security. Updates will not require any action from the customer. Instead, when an update is available, your cache node will automatically update during low traffic hours with minimal to no impact to your end customers.
|
||||
|
||||
To view which version your cache nodes are currently on, [[*********]].
|
||||
To view which version your cache nodes are currently on, navigate to the **Cache nodes** tab to view the versions in the list view.
|
||||
|
||||
To view update release notes, visit [Version History](mcc-version-history.md).
|
||||
|
||||
To view update release notes, visit our Tech Community page.
|
@ -1,26 +1,14 @@
|
||||
# Verify cache node functionality
|
||||
|
||||
### Verify client side
|
||||
|
||||
Sign in to the Connected Cache server or use SSH. Run the following command from a terminal to see the running modules (containers):
|
||||
### Verify functionality on Azure portal
|
||||
|
||||
```bash
|
||||
sudo iotedge list
|
||||
```
|
||||
Log into Azure portal and navigate to the Overview page. Select the **Monitoring** tab to verify the functionality of your server(s) by validating the number of healthy nodes shown. If you see any **Unhealthy nodes**, select the "Diagnose and Solve" link to troubleshoot and resolve the issue.
|
||||
|
||||
If the cache server is running properly, you will see the containers **edgeAgent**, **edgeHub**, and **[Your Cache Node name]** listed, all with the status **running**.
|
||||
### Verify functionality on the server
|
||||
|
||||
If it lists the **edgeAgent** and **edgeHub** containers, but doesn't include **MCC**, view the status of the IoT Edge security manager using the command:
|
||||
It can take a few minutes for the container to deploy after you've saved the configuration.
|
||||
|
||||
```bash
|
||||
sudo journalctl -u iotedge -f
|
||||
```
|
||||
|
||||
This command provides the current status of the starting and stopping of a container or the container pull and start.
|
||||
|
||||
### Verify server side
|
||||
|
||||
It can take a few minutes for the container to deploy.
|
||||
|
||||
To validate a properly functioning MCC, run the following command in the terminal of the cache server or any device in the network. Replace `<CacheServerIP>` with the IP address of the cache server.
|
||||
|
||||
@ -46,4 +34,6 @@ Similarly, enter the following URL into a web browser on any device on the netwo
|
||||
http://<CacheServerIP>/mscomtest/wuidt.gif?cacheHostOrigin=au.download.windowsupdate.com
|
||||
```
|
||||
|
||||
If the test fails, for more information, see the [common issues](#common-issues) section.
|
||||
|
||||
If the test fails, for more information, see the [FAQs](#mcc-isp-faq) section.
|
||||
|
||||
|
38
windows/deployment/do/mcc-traffic-estimation.md
Normal file
38
windows/deployment/do/mcc-traffic-estimation.md
Normal file
@ -0,0 +1,38 @@
|
||||
# Traffic Estimation
|
||||
|
||||
During the sign up process, Microsoft will provide you with a traffic estimation based on your ASN(s). We make estimations based on our predictions on historical data about Microsoft content download volume. We will use these estimations to recommend hardware or VM configurations. You can view these recommendations within the Azure portal.
|
||||
|
||||
Note that we make these estimations based on the Microsoft content types that Microsoft Connected Cache serves. To learn more about the types of content that are supported, see [Delivery Optimization and Microsoft Connected Cache content endpoints]().
|
||||
|
||||
## Cache performance
|
||||
|
||||
To make sure you are maximizing the performance of your cache node, please note the following:
|
||||
|
||||
### OS requirements
|
||||
|
||||
The MCC module is optimized for Ubuntu 20.04 LTS. Install Ubuntu 20.04 LTS on a physical server or VM of your choice.
|
||||
|
||||
### NIC requirements
|
||||
|
||||
- Multiple NICs on a single MCC instance are supported using a _link aggregated_ configuration.
|
||||
- 10 Gbps NIC is the minimum speed recommended, but any NIC is supported.
|
||||
|
||||
### Drive performance
|
||||
|
||||
The maximum number of disks supported is 9. When configuring your drives, we recommend SSD drives as cache read speed of SSD is superior to HDD. In addition, using multiple disks is recommended to improve cache performance.
|
||||
|
||||
RAID disk configurations are discouraged as cache performance will be impacted. If using RAID disk configurations, ensure striping.
|
||||
|
||||
### Hardware configuration example
|
||||
|
||||
There are many hardware configurations that suit Microsoft Connected Cache. As an example, below is the hardware configuration of a customer who is able to egress 40 Gbps of traffic.
|
||||
|
||||
**Dell PowerEdge R330**
|
||||
- 2 x Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz , total 32core
|
||||
- 48GB, Micron Technology 18ASF1G72PDZ-2G1A1, Speed: 2133 MT/s
|
||||
- 4 - Transcend SSD230s 1TB SATA Drives
|
||||
- Intel Corporation Ethernet 10G 2P X520 Adapter (Link Aggregated)
|
||||
|
||||
### Virtual Machines
|
||||
|
||||
If you are using a virtual machine as your server, please refer to [VM performance](mcc-isp-vm-performance.md) for tips on how to improve your VM performance.
|
0
windows/deployment/do/mcc-version-history.md
Normal file
0
windows/deployment/do/mcc-version-history.md
Normal file
Binary file not shown.
Binary file not shown.
@ -86,7 +86,7 @@ If you create an issue for something not related to documentation, Microsoft wil
|
||||
- [Product questions (using Microsoft Q&A)](/answers/products/)
|
||||
- [Support requests](#open-a-microsoft-support-case) for Update Compliance
|
||||
|
||||
To share feedback on the fundamental docs.microsoft.com platform, see [Docs feedback](https://aka.ms/sitefeedback). The platform includes all of the wrapper components such as the header, table of contents, and right menu. Also how the articles render in the browser, such as the font, alert boxes, and page anchors.
|
||||
To share feedback about the Microsoft Docs platform, see [Microsoft Docs feedback](https://aka.ms/sitefeedback). The platform includes all of the wrapper components such as the header, table of contents, and right menu. Also how the articles render in the browser, such as the font, alert boxes, and page anchors.
|
||||
|
||||
## Troubleshooting tips
|
||||
|
||||
|
@ -19,15 +19,15 @@ The following posters step through various options for deploying Windows 10 with
|
||||
|
||||
## Deploy Windows 10 with Autopilot
|
||||
|
||||
The Windows Autopilot poster is two pages in portrait mode (11x17). Click the image to view a PDF in your browser. You can also download this poster in [PDF](https://github.com/MicrosoftDocs/windows-itpro-docs/raw/public/windows/deployment/media/Windows10AutopilotFlowchart.pdf) or [Visio](https://github.com/MicrosoftDocs/windows-itpro-docs/raw/public/windows/deployment/media/Windows10Autopilotflowchart.vsdx) format.
|
||||
The Windows Autopilot poster is two pages in portrait mode (11x17). Click the image to view a PDF in your browser. You can also download this poster in [PDF](https://download.microsoft.com/download/8/4/b/84b5e640-8f66-4b43-81a9-1c3b9ea18eda/Windows10AutopilotFlowchart.pdf) or [Visio](https://github.com/MicrosoftDocs/windows-itpro-docs/raw/public/windows/deployment/media/Windows10Autopilotflowchart.vsdx) format.
|
||||
|
||||
[](./media/Windows10AutopilotFlowchart.pdf)
|
||||
[](https://download.microsoft.com/download/8/4/b/84b5e640-8f66-4b43-81a9-1c3b9ea18eda/Windows10AutopilotFlowchart.pdf)
|
||||
|
||||
## Deploy Windows 10 with Microsoft Endpoint Configuration Manager
|
||||
|
||||
The Configuration Manager poster is one page in landscape mode (17x11). Click the image to view a PDF in your browser. You can also download this poster in [PDF](https://github.com/MicrosoftDocs/windows-itpro-docs/raw/public/windows/deployment/media/Windows10DeploymentConfigManager.pdf) or [Visio](https://github.com/MicrosoftDocs/windows-itpro-docs/raw/public/windows/deployment/media/Windows10DeploymentConfigManager.vsdx) format.
|
||||
The Configuration Manager poster is one page in landscape mode (17x11). Click the image to view a PDF in your browser. You can also download this poster in [PDF](https://download.microsoft.com/download/e/2/a/e2a70587-d3cc-4f1a-ba49-cfd724a1736b/Windows10DeploymentConfigManager.pdf) or [Visio](https://github.com/MicrosoftDocs/windows-itpro-docs/raw/public/windows/deployment/media/Windows10DeploymentConfigManager.vsdx) format.
|
||||
|
||||
[](./media/Windows10DeploymentConfigManager.pdf)
|
||||
[](https://download.microsoft.com/download/e/2/a/e2a70587-d3cc-4f1a-ba49-cfd724a1736b/Windows10DeploymentConfigManager.pdf)
|
||||
|
||||
## See also
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Device registration overview
|
||||
description: This article provides and overview on how to register devices in Autopatch
|
||||
ms.date: 07/28/2022
|
||||
ms.date: 09/07/2022
|
||||
ms.prod: w11
|
||||
ms.technology: windows
|
||||
ms.topic: conceptual
|
||||
@ -44,12 +44,12 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto
|
||||
| **Step 1: Identify devices** | IT admin identifies devices to be managed by the Windows Autopatch service. |
|
||||
| **Step 2: Add devices** | IT admin adds devices through direct membership or nests other Azure AD assigned or dynamic groups into the **Windows Autopatch Device Registration** Azure AD assigned group. |
|
||||
| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function hourly discovers devices previously added by the IT admin into the **Windows Autopatch Device Registration** Azure AD assigned group in **step #2**. The Azure AD device ID is used by Windows Autopatch to query device attributes in both Microsoft Endpoint Manager-Intune and Azure AD when registering devices into its service.<ol><li>Once devices are discovered from the Azure AD group, the same function gathers additional device attributes and saves it into its memory during the discovery operation. The following device attributes are gathered from Azure AD in this step:</li><ol><li>**AzureADDeviceID**</li><li>**OperatingSystem**</li><li>**DisplayName (Device name)**</li><li>**AccountEnabled**</li><li>**RegistrationDateTime**</li><li>**ApproximateLastSignInDateTime**</li></ol><li>In this same step, the Windows Autopatch discover devices function calls another function, the device prerequisite check function. The device prerequisite check function evaluates software-based device-level prerequisites to comply with Windows Autopatch device readiness requirements prior to registration.</li></ol> |
|
||||
| **Step 4: Check prerequisites** | The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:<ol><li>**Serial number, model, and manufacturer.**</li><ol><li>Checks if the serial number already exists in the Windows Autopatch’s managed device database.</li></ol><li>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Azure AD device ID has an Intune device ID associated with it**.</li><ol><li>If **yes**, it means this device is enrolled into Intune.</li><li>If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol><li>**If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Azure AD device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>Once it has the device attributes gathered from Azure AD in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not ready** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn’t enrolled into Intune.</li><li>A common reason is when the Azure AD device ID is stale, it doesn’t have an Intune device ID associated with it anymore. To remediate, [clean up any stale Azure AD device records from your tenant](windows-autopatch-register-devices.md#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).</li></ol><li>**If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.</li></ol><li>**If the device is a Windows device or not.**</li><ol><li>Windows Autopatch looks to see if the Azure AD device ID has an Intune device ID associated with it.</li><ol><li>**If yes**, it means this device is enrolled into Intune.</li><li>**If not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol></ol><li>**Windows Autopatch checks the Windows SKU family**. The SKU must be either:</li><ol><li>**Enterprise**</li><li>**Pro**</li><li>**Pro Workstation**</li></ol><li>**If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:</li><ol><li>**Only managed by Intune.**</li><ol><li>If the device is only managed by Intune, the device is marked as Passed all prerequisites.</li></ol><li>**Co-managed by both Configuration Manager and Intune.**</li><ol><li>If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state. The required co-management workloads evaluated in this step are:</li><ol><li>**Windows Updates Policies**</li><li>**Device Configuration**</li><li>**Office Click to Run**</li></ol><li>If Windows Autopatch determines that one of these workloads isn’t enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not Ready** tab.</li></ol></ol></ol>|
|
||||
| **Step 4: Check prerequisites** | The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:<ol><li>**Serial number, model, and manufacturer.**</li><ol><li>Checks if the serial number already exists in the Windows Autopatch’s managed device database.</li></ol><li>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Azure AD device ID has an Intune device ID associated with it**.</li><ol><li>If **yes**, it means this device is enrolled into Intune.</li><li>If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol><li>**If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Azure AD device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>Once it has the device attributes gathered from Azure AD in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not registered** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn’t enrolled into Intune.</li><li>A common reason is when the Azure AD device ID is stale, it doesn’t have an Intune device ID associated with it anymore. To remediate, [clean up any stale Azure AD device records from your tenant](windows-autopatch-register-devices.md#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).</li></ol><li>**If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.</li></ol><li>**If the device is a Windows device or not.**</li><ol><li>Windows Autopatch looks to see if the Azure AD device ID has an Intune device ID associated with it.</li><ol><li>**If yes**, it means this device is enrolled into Intune.</li><li>**If not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol></ol><li>**Windows Autopatch checks the Windows SKU family**. The SKU must be either:</li><ol><li>**Enterprise**</li><li>**Pro**</li><li>**Pro Workstation**</li></ol><li>**If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:</li><ol><li>**Only managed by Intune.**</li><ol><li>If the device is only managed by Intune, the device is marked as Passed all prerequisites.</li></ol><li>**Co-managed by both Configuration Manager and Intune.**</li><ol><li>If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state. The required co-management workloads evaluated in this step are:</li><ol><li>**Windows Updates Policies**</li><li>**Device Configuration**</li><li>**Office Click to Run**</li></ol><li>If Windows Autopatch determines that one of these workloads isn’t enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not registered** tab.</li></ol></ol></ol>|
|
||||
| **Step 5: Calculate deployment ring assignment** | Once the device passes all prerequisites described in **step #4**, Windows Autopatch starts its deployment ring assignment calculation. The following logic is used to calculate the Windows Autopatch deployment ring assignment:<ol><li>If the Windows Autopatch tenant’s existing managed device size is **≤ 200**, the deployment ring assignment is **First (5%)**, **Fast (15%)**, remaining devices go to the **Broad ring (80%)**.</li><li>If the Windows Autopatch tenant’s existing managed device size is **>200**, the deployment ring assignment will be **First (1%)**, **Fast (9%)**, remaining devices go to the **Broad ring (90%)**.</li></ol> |
|
||||
| **Step 6: Assign devices to a deployment ring group** | Once the deployment ring calculation is done, Windows Autopatch assigns devices to one of the following deployment ring groups:<ol><li>**Modern Workplace Devices-Windows Autopatch-First**</li><ol><li>The Windows Autopatch device registration process doesn’t automatically assign devices to the Test ring represented by the Azure AD group (Modern Workplace Devices-Windows Autopatch-Test). It’s important that you assign devices to the Test ring to validate the update deployments before the updates are deployed to a broader population of devices.</li></ol><li>**Modern Workplace Devices-Windows Autopatch-Fast**</li><li>**Modern Workplace Devices-Windows Autopatch-Broad**</li></ol> |
|
||||
| **Step 7: Assign devices to an Azure AD group** | Windows Autopatch also assigns devices to the following Azure AD groups when certain conditions apply:<ol><li>**Modern Workplace Devices - All**</li><ol><li>This group has all devices managed by Windows Autopatch.</li></ol><li>When registering **Windows 10 devices**, use **Modern Workplace Devices Dynamic - Windows 10**</li><ol><li>This group has all devices managed by Windows Autopatch and that have Windows 10 installed.</li></ol><li>When registering **Windows 11 devices**, use **Modern Workplace Devices Dynamic - Windows 11**</li><ol><li>This group has all devices managed by Windows Autopatch and that have Windows 11 installed.</li></ol><li>When registering **virtual devices**, use **Modern Workplace Devices - Virtual Machine**</li><ol><li>This group has all virtual devices managed by Windows Autopatch.</li></ol> |
|
||||
| **Step 8: Post-device registration** | In post-device registration, three actions occur:<ol><li>Windows Autopatch adds devices to its managed database.</li><li>Flags devices as **Active** in the **Ready** tab.</li><li>The Azure AD device ID of the device successfully registered is added into the Microsoft Cloud Managed Desktop Extension’s allowlist. Windows Autopatch installs the Microsoft Cloud Managed Desktop Extension agent once devices are registered, so the agent can communicate back to the Microsoft Cloud Managed Desktop Extension service.</li><ol><li>The agent is the **Modern Workplace - Autopatch Client setup** PowerShell script that was created during the Windows Autopatch tenant enrollment process. The script is executed once devices are successfully registered into the Windows Autopatch service.</li></ol> |
|
||||
| **Step 9: Review device registration status** | IT admins review the device registration status in both the **Ready** and **Not ready** tabs.<ol><li>If the device was **successfully registered**, the device shows up in the **Ready** tab.</li><li>If **not**, the device shows up in the **Not ready** tab.</li></ol> |
|
||||
| **Step 9: Review device registration status** | IT admins review the device registration status in both the **Ready** and **Not registered** tabs.<ol><li>If the device was **successfully registered**, the device shows up in the **Ready** tab.</li><li>If **not**, the device shows up in the **Not registered** tab.</li></ol> |
|
||||
| **Step 10: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. |
|
||||
|
||||
## Detailed prerequisite check workflow diagram
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Register your devices
|
||||
description: This article details how to register devices in Autopatch
|
||||
ms.date: 08/08/2022
|
||||
ms.date: 09/07/2022
|
||||
ms.prod: w11
|
||||
ms.technology: windows
|
||||
ms.topic: how-to
|
||||
@ -28,7 +28,13 @@ Windows Autopatch can take over software update management control of devices th
|
||||
|
||||
### About the use of an Azure AD group to register devices
|
||||
|
||||
You must choose what devices to manage with Windows Autopatch by either adding them through direct membership or by nesting other Azure AD dynamic/assigned groups into the **Windows Autopatch Device Registration** Azure AD assigned group. Windows Autopatch automatically runs its discover devices function every hour to discover new devices added to this group. Once new devices are discovered, Windows Autopatch attempts to register these devices.
|
||||
You must choose what devices to manage with Windows Autopatch by adding them to the **Windows Autopatch Device Registration** Azure AD assigned group. Devices can be added using the following methods:
|
||||
|
||||
- Direct membership
|
||||
- Nesting other Azure AD dynamic/assigned groups
|
||||
- [Bulk add/import group members](/azure/active-directory/enterprise-users/groups-bulk-import-members)
|
||||
|
||||
Windows Autopatch automatically runs its discover devices function every hour to discover new devices added to this group. Once new devices are discovered, Windows Autopatch attempts to register these devices.
|
||||
|
||||
> [!NOTE]
|
||||
> Devices that are intended to be managed by the Windows Autopatch service **must** be added into the **Windows Autopatch Device Registration** Azure AD assigned group. Devices can only be added to this group if they have an Azure AD device ID. Windows Autopatch scans the Azure AD group hourly to discover newly added devices to be registered. You can also use the **Discover devices** button in either the **Ready** or **Not ready** tab to register devices on demand.
|
||||
@ -78,14 +84,26 @@ To be eligible for Windows Autopatch management, devices must meet a minimum set
|
||||
|
||||
For more information, see [Windows Autopatch Prerequisites](../prepare/windows-autopatch-prerequisites.md).
|
||||
|
||||
## About the Ready and Not ready tabs
|
||||
## About the Ready, Not ready and Not registered tabs
|
||||
|
||||
Windows Autopatch introduces a new user interface to help IT admins detect and troubleshoot device readiness statuses seamlessly with actionable in-UI device readiness reports for unregistered devices or unhealthy devices.
|
||||
Windows Autopatch has three tabs within its device blade. Each tab is designed to provide a different set of device readiness status so IT admin knows where to go to monitor, and troubleshoot potential device health issues.
|
||||
|
||||
| Tab | Purpose |
|
||||
| ----- | ----- |
|
||||
| Ready | The purpose of the Ready tab is to show devices that were successfully registered to the Windows Autopatch service. |
|
||||
| Not ready | The purpose of the Not ready tab is to help you identify and remediate devices that don't meet the pre-requisite checks to register into the Windows Autopatch service. This tab only shows devices that didn't successfully register into Windows Autopatch. |
|
||||
| Device blade tab | Purpose | Expected device readiness status |
|
||||
| ----- | ----- | ----- |
|
||||
| Ready | The purpose of this tab is to show devices that were successfully registered with the Windows Autopatch service. | Active |
|
||||
| Not ready | The purpose of this tab is to help you identify and remediate devices that failed to pass one or more post-device registration readiness checks. Devices showing up in this tab were successfully registered with Windows Autopatch. However, these devices aren't ready to have one or more software update workloads managed by the service. | Readiness failed and/or Inactive |
|
||||
| Not registered | The purpose of this tab is to help you identify and remediate devices that don't meet one or more prerequisite checks to successfully register with the Windows Autopatch service. | Pre-requisites failed |
|
||||
|
||||
## Device readiness statuses
|
||||
|
||||
See all possible device readiness statuses in Windows Autopatch:
|
||||
|
||||
| Readiness status | Description | Device blade tab |
|
||||
| ----- | ----- | ----- |
|
||||
| Active | Devices with this status successfully passed all prerequisite checks and subsequently successfully registered with Windows Autopatch. Additionally, devices with this status successfully passed all post-device registration readiness checks. | Ready |
|
||||
| Readiness failed | Devices with this status haven't passed one or more post-device registration readiness checks. These devices aren't ready to have one or more software update workloads managed by Windows Autopatch. | Not ready |
|
||||
| Inactive | Devices with this status haven't communicated with Microsoft Endpoint Manager-Intune in the last 28 days. | Not ready |
|
||||
| Pre-requisites failed | Devices with this status haven't passed one or more pre-requisite checks and haven't successfully registered with Windows Autopatch | Not registered |
|
||||
|
||||
## Built-in roles required for device registration
|
||||
|
||||
@ -119,16 +137,16 @@ Since existing Windows 365 Cloud PCs already have an existing Azure AD device ID
|
||||
1. Go to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/).
|
||||
2. Select **Devices** from the left navigation menu.
|
||||
3. Under the **Windows Autopatch** section, select **Devices**.
|
||||
4. Select either the **Ready** or the **Not ready** tab, then select the **Windows Autopatch Device Registration** hyperlink. The Azure Active Directory group blade opens.
|
||||
4. Select either the **Ready** or the **Not registered** tab, then select the **Windows Autopatch Device Registration** hyperlink. The Azure Active Directory group blade opens.
|
||||
5. Add either devices through direct membership, or other Azure AD dynamic or assigned groups as nested groups in the **Windows Autopatch Device Registration** group.
|
||||
|
||||
> [!NOTE]
|
||||
> The **Windows Autopatch Device Registration** hyperlink is in the center of the Ready tab when there's no devices registered with the Windows Autopatch service. Once you have one or more devices registered with the Windows Autopatch service, the **Windows Autopatch Device registration** hyperlink is at the top of both **Ready** and **Not ready** tabs.
|
||||
> The **Windows Autopatch Device Registration** hyperlink is in the center of the Ready tab when there's no devices registered with the Windows Autopatch service. Once you have one or more devices registered with the Windows Autopatch service, the **Windows Autopatch Device registration** hyperlink is at the top of both **Ready** and **Not registered** tabs.
|
||||
|
||||
Once devices or other Azure AD groups (either dynamic or assigned) containing devices are added to the **Windows Autopatch Device Registration** group, Windows Autopatch's device discovery hourly function discovers these devices, and runs software-based prerequisite checks to try to register them with its service.
|
||||
|
||||
> [!TIP]
|
||||
> You can also use the **Discover Devices** button in either the **Ready** or **Not ready** tab to discover devices from the **Windows Autopatch Device Registration** Azure AD group on demand.
|
||||
> You can also use the **Discover Devices** button in either one of the **Ready**, **Not ready**, or **Not registered** device blade tabs to discover devices from the **Windows Autopatch Device Registration** Azure AD group on demand. On demand means you don't have to wait for Windows Autopatch to discover devices from the Azure AD group on your behalf.
|
||||
|
||||
### Windows Autopatch on Windows 365 Enterprise Workloads
|
||||
|
||||
|
Binary file not shown.
Before Width: | Height: | Size: 560 KiB After Width: | Height: | Size: 561 KiB |
@ -37,7 +37,7 @@ In this example, we'll be discussing a device in the First ring. The Autopatch s
|
||||
|
||||
In the following example, the user schedules the restart and is notified 15 minutes prior to the scheduled restart time. The user can reschedule, if necessary, but isn't able to reschedule past the deadline.
|
||||
|
||||
:::image type="content" source="../media/windows-feature-typical-update-experience.png" alt-text="Typical Windows feature update experience":::
|
||||
:::image type="content" source="../media/windows-feature-typical-update-experience.png" alt-text="Typical Windows feature update experience" lightbox="../media/windows-feature-typical-update-experience.png":::
|
||||
|
||||
### Feature update deadline forces an update
|
||||
|
||||
@ -45,7 +45,7 @@ The following example builds on the scenario outlined in the typical user experi
|
||||
|
||||
The deadline specified in the update policy is five days. Therefore, once this deadline is passed, the device will ignore the active hours and force a restart to complete the installation. The user will receive a 15-minute warning, after which, the device will install the update and restart.
|
||||
|
||||
:::image type="content" source="../media/windows-feature-force-update.png" alt-text="Force Windows feature update":::
|
||||
:::image type="content" source="../media/windows-feature-force-update.png" alt-text="Force Windows feature update" lightbox="../media/windows-feature-force-update.png":::
|
||||
|
||||
### Feature update grace period
|
||||
|
||||
@ -53,7 +53,7 @@ In the following example, the user is on holiday and the device is offline beyon
|
||||
|
||||
Since the deadline has already passed, the device is granted a two-day grace period to install the update and restart. The user will be notified of a pending installation and given options to choose from. Once the two-day grace period has expired, the user is forced to restart with a 15-minute warning notification.
|
||||
|
||||
:::image type="content" source="../media/windows-feature-update-grace-period.png" alt-text="Window feature update grace period":::
|
||||
:::image type="content" source="../media/windows-feature-update-grace-period.png" alt-text="Windows feature update grace period" lightbox="../media/windows-feature-update-grace-period.png":::
|
||||
|
||||
## Servicing window
|
||||
|
||||
|
@ -46,7 +46,7 @@ The final release schedule is communicated prior to release and may vary a littl
|
||||
| Fast | Release start + 60 days |
|
||||
| Broad | Release start + 90 days |
|
||||
|
||||
:::image type="content" source="../media/windows-feature-release-process-timeline.png" alt-text="Windows feature release timeline":::
|
||||
:::image type="content" source="../media/windows-feature-release-process-timeline.png" alt-text="Windows feature release timeline" lightbox="../media/windows-feature-release-process-timeline.png":::
|
||||
|
||||
## New devices to Windows Autopatch
|
||||
|
||||
|
@ -40,6 +40,9 @@ During the [tenant enrollment process](../prepare/windows-autopatch-enroll-tenan
|
||||
|
||||
Each deployment ring has a different set of update deployment policies to control the updates rollout.
|
||||
|
||||
> [!WARNING]
|
||||
> Adding or importing devices into any of these groups directly is not supported and doing so might cause an unexpected impact on the Windows Autopatch service. To move devices between these groups, see [Moving devices in between deployment rings](../operate/windows-autopatch-update-management.md#moving-devices-in-between-deployment-rings).
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Windows Autopatch device registration doesn't assign devices to its test deployment ring (**Modern Workplace Devices-Windows Autopatch-Test**). This is intended to prevent devices that are essential to a business from being affected or devices that are used by executives from receiving early software update deployments.
|
||||
|
||||
@ -58,7 +61,7 @@ The Windows Autopatch deployment ring calculation happens during the [device reg
|
||||
|
||||
| Deployment ring | Default device balancing percentage | Description |
|
||||
| ----- | ----- | ----- |
|
||||
| Test | **zero** | Windows Autopatch doesn't automatically add devices to this deployment ring. You must manually add devices to the Test ring. The recommended number of devices in this ring, based upon your environment size, is as follows:<br><ul><li>**0–500** devices: minimum **one** device.</li><li>**500–5000** devices: minimum **five** devices.</li><li>**5000+** devices: minimum **50** devices.</li></ul>Devices in this group are intended for your IT Administrators and testers since changes are released here first. This release schedule provides your organization the opportunity to validate updates prior to reaching production users. |
|
||||
| Test | **zero** | Windows Autopatch doesn't automatically add devices to this deployment ring. You must manually add devices to the Test ring following the required procedure. For more information on these procedures, see [Moving devices in between deployment rings](/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management#moving-devices-in-between-deployment-rings). The recommended number of devices in this ring, based upon your environment size, is as follows:<br><ul><li>**0–500** devices: minimum **one** device.</li><li>**500–5000** devices: minimum **five** devices.</li><li>**5000+** devices: minimum **50** devices.</li></ul>Devices in this group are intended for your IT Administrators and testers since changes are released here first. This release schedule provides your organization the opportunity to validate updates prior to reaching production users. |
|
||||
| First | **1%** | The First ring is the first group of production users to receive a change.<p><p>This group is the first set of devices to send data to Windows Autopatch and are used to generate a health signal across all end-users. For example, Windows Autopatch can generate a statistically significant signal saying that critical errors are trending up in a specific release for all end-users, but can't be confident that it's doing so in your organization.<p><p>Since Windows Autopatch doesn't yet have sufficient data to inform a release decision, devices in this deployment ring might experience outages if there are scenarios that weren't covered during early testing in the Test ring.|
|
||||
| Fast | **9%** | The Fast ring is the second group of production users to receive changes. The signals from the First ring are considered as a part of the release process to the Broad ring.<p><p>The goal with this deployment ring is to cross the **500**-device threshold needed to generate statistically significant analysis at the tenant level. These extra devices allow Windows Autopatch to consider the effect of a release on the rest of your devices and evaluate if a targeted action for your tenant is needed.</p> |
|
||||
| Broad | Either **80%** or **90%** | The Broad ring is the last group of users to receive software update deployments. Since it contains most of the devices registered with Windows Autopatch, it favors stability over speed in an software update deployment.|
|
||||
@ -80,7 +83,10 @@ When the assignment is complete, the **Ring assigned by** column changes to **Ad
|
||||
|
||||
> [!NOTE]
|
||||
> You can only move devices to other deployment rings when they're in an active state in the **Ready** tab.<p>If you don't see the **Ring assigned by column** change to **Pending** in Step 5, check to see whether the device exists in Microsoft Endpoint Manager-Intune or not by searching for it in its device blade. For more information, see [Device details in Intune](/mem/intune/remote-actions/device-inventory).
|
||||
|
||||
|
||||
> [!WARNING]
|
||||
> Moving devices between deployment rings through directly changing Azure AD group membership isn't supported and may cause unintended configuration conflicts within the Windows Autopatch service. To avoid service interruption to devices, use the **Assign device to ring** action described previously to move devices between deployment rings.
|
||||
|
||||
## Automated deployment ring remediation functions
|
||||
|
||||
Windows Autopatch monitors device membership in its deployment rings, except for the **Modern Workplace Devices-Windows Autopatch-Test** ring, to provide automated deployment ring remediation functions to mitigate the risk of not having its managed devices being part of one of its deployment rings. These automated functions help mitigate risk of potentially having devices in a vulnerable state, and exposed to security threats in case they're not receiving update deployments due to either:
|
||||
|
@ -36,7 +36,7 @@ Once the deferral period has passed, the device will download the update and not
|
||||
|
||||
In the following example, the user schedules the restart and is notified 15 minutes prior to the scheduled restart time. The user can reschedule, if necessary, but isn't able to reschedule past the deadline.
|
||||
|
||||
:::image type="content" source="../media/windows-quality-typical-update-experience.png" alt-text="Typical windows quality update experience":::
|
||||
:::image type="content" source="../media/windows-quality-typical-update-experience.png" alt-text="Typical windows quality update experience" lightbox="../media/windows-quality-typical-update-experience.png":::
|
||||
|
||||
### Quality update deadline forces an update
|
||||
|
||||
@ -48,7 +48,7 @@ In the following example, the user:
|
||||
|
||||
The deadline specified in the update policy is five days. Therefore, once this deadline is passed, the device will ignore the [active hours](#servicing-window) and force a restart to complete the update installation. The user will receive a 15-minute warning, after which, the device will install the update and restart.
|
||||
|
||||
:::image type="content" source="../media/windows-quality-force-update.png" alt-text="Force Windows quality update":::
|
||||
:::image type="content" source="../media/windows-quality-force-update.png" alt-text="Force Windows quality update" lightbox="../media/windows-quality-force-update.png":::
|
||||
|
||||
### Quality update grace period
|
||||
|
||||
@ -56,7 +56,7 @@ In the following example, the user is on holiday and the device is offline beyon
|
||||
|
||||
Since the deadline has already passed, the device is granted a two-day grace period to install the update and restart. The user will be notified of a pending installation and given options to choose from. Once the two-day grace period has expired, the user is forced to restart with a 15-minute warning notification.
|
||||
|
||||
:::image type="content" source="../media/windows-quality-update-grace-period.png" alt-text="Windows quality update grace period":::
|
||||
:::image type="content" source="../media/windows-quality-update-grace-period.png" alt-text="Windows quality update grace period" lightbox="../media/windows-quality-update-grace-period.png":::
|
||||
|
||||
## Servicing window
|
||||
|
||||
|
@ -50,7 +50,7 @@ To release updates to devices in a gradual manner, Windows Autopatch deploys a s
|
||||
|
||||
Windows Autopatch configures these policies differently across update rings to gradually release the update to devices in your estate. Devices in the Test ring receive changes first and devices in the Broad ring receive changes last. For more information, see [Windows Autopatch deployment rings](../operate/windows-autopatch-update-management.md#windows-autopatch-deployment-rings).
|
||||
|
||||
:::image type="content" source="../media/release-process-timeline.png" alt-text="Release process timeline":::
|
||||
:::image type="content" source="../media/release-process-timeline.png" alt-text="Release process timeline" lightbox="../media/release-process-timeline.png":::
|
||||
|
||||
## Expedited releases
|
||||
|
||||
|
@ -42,7 +42,7 @@ The update is released to the Test ring on the second Tuesday of the month. Thos
|
||||
|
||||
Windows Autopatch monitors devices for a set of core reliability metrics as a part of the service.
|
||||
|
||||
The service then uses statistical models to assess if there are significant differences between the two Windows versions. To make a statistically significant assessment, Windows Autopatch requires that at least 500 devices have upgraded to the new version.
|
||||
The service then uses statistical models to assess if there are significant differences between the two Windows versions. To make a statistically significant assessment, Windows Autopatch requires that at least 500 devices in your tenant have upgraded to the new version.
|
||||
|
||||
As more devices update, the confidence of the analysis increases and gives us a clearer picture of release quality. If we determine that the user experience is impaired, Autopatch will either post a customer advisory or pause the release, depending on the criticality of the update.
|
||||
|
||||
@ -51,8 +51,8 @@ Autopatch monitors the following reliability signals:
|
||||
| Device reliability signal | Description |
|
||||
| ----- | ----- |
|
||||
| Blue screens | These events are highly disruptive to end users so are closely watched. |
|
||||
| Overall app reliability | Tracks the total number of app crashes and freezes on a device. A known issue with this measure is that if one app becomes 10% more reliable and another becomes 10% less reliable then it shows up as a flat line in the measure. |
|
||||
| Microsoft Office reliability | Tracks the number of Office crashes or freezes per application per device. |
|
||||
| Overall app reliability | Tracks the total number of app crashes and freezes on a device. A known limitation with this measure is that if one app becomes 10% more reliable and another becomes 10% less reliable then it shows up as a flat line in the measure. |
|
||||
| Microsoft Office reliability | Tracks the number of Office crashes and freezes per application per device. |
|
||||
| Microsoft Edge reliability | Tracks the number of Microsoft Edge crashes and freezes per device. |
|
||||
| Microsoft Teams reliability | Tracks the number of Microsoft Teams crashes and freezes per device. |
|
||||
|
||||
|
@ -51,7 +51,7 @@ sections:
|
||||
- [Switch workloads for device configuration, Windows Update and Microsoft 365 Apps from Configuration Manager to Intune](/mem/configmgr/comanage/how-to-switch-workloads) (minimum Pilot Intune. Pilot collection must contain the devices you want to register into Autopatch.)
|
||||
- question: What are the licensing requirements for Windows Autopatch?
|
||||
answer: |
|
||||
- Windows Autopatch is included with Window 10/11 Enterprise E3 or higher. For more information, see [More about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses).
|
||||
- Windows Autopatch is included with Window 10/11 Enterprise E3 or higher (user-based only). For more information, see [More about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses).
|
||||
- [Azure AD Premium](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses) (for Co-management)
|
||||
- [Microsoft Intune](/mem/intune/fundamentals/licenses) (includes Configuration Manager 2010 or greater via co-management)
|
||||
- question: Are there hardware requirements for Windows Autopatch?
|
||||
@ -76,12 +76,13 @@ sections:
|
||||
- question: What systems does Windows Autopatch update?
|
||||
answer: |
|
||||
- Windows 10/11 quality updates: Windows Autopatch manages all aspects of update rings.
|
||||
- Windows 10/11 feature updates: Windows Autopatch manages all aspects of update rings.
|
||||
- Microsoft 365 Apps for enterprise updates: All devices registered for Windows Autopatch will receive updates from the Monthly Enterprise Channel.
|
||||
- Microsoft Edge: Windows Autopatch configures eligible devices to benefit from Microsoft Edge's progressive rollouts on the Stable channel and will provide support for issues with Microsoft Edge updates.
|
||||
- Microsoft Teams: Windows Autopatch allows eligible devices to benefit from the standard automatic update channels and will provide support for issues with Teams updates.
|
||||
- question: What does Windows Autopatch do to ensure updates are done successfully?
|
||||
answer: |
|
||||
For Windows quality updates, updates are applied to device in the Test ring first. The devices are evaluated, and then rolled out to the First, Fast then Broad rings. There's an evaluation period at each progression. This process is dependent on customer testing and verification of all updates during these rollout stages. The outcome is to ensure that registered devices are always up to date and disruption to business operations is minimized to free up your IT department from that ongoing task.
|
||||
For Windows quality updates, updates are applied to devices in the Test ring first. The devices are evaluated, and then rolled out to the First, Fast then Broad rings. There's an evaluation period at each progression. This process is dependent on customer testing and verification of all updates during these rollout stages. The outcome is to ensure that registered devices are always up to date and disruption to business operations is minimized to free up your IT department from that ongoing task.
|
||||
- question: What happens if there's an issue with an update?
|
||||
answer: |
|
||||
Autopatch relies on the following capabilities to help resolve update issues:
|
||||
|
@ -29,10 +29,10 @@ Windows Autopatch will create Azure Active Directory groups that are required to
|
||||
| Modern Workplace-All | All Modern Workplace users |
|
||||
| Modern Workplace - Windows 11 Pre-Release Test Devices | Device group for Windows 11 Pre-Release testing. |
|
||||
| Modern Workplace Devices-All | All Modern Workplace devices |
|
||||
| Modern Workplace Devices-Windows Autopatch-Test | Immediate ring for device rollout |
|
||||
| Modern Workplace Devices-Windows Autopatch-First | First production ring for early adopters |
|
||||
| Modern Workplace Devices-Windows Autopatch-Fast | Fast ring for quick rollout and adoption |
|
||||
| Modern Workplace Devices-Windows Autopatch-Broad | Final ring for broad rollout into an organization |
|
||||
| Modern Workplace Devices-Windows Autopatch-Test | Deployment ring for testing update deployments prior production rollout |
|
||||
| Modern Workplace Devices-Windows Autopatch-First | First production deployment ring for early adopters |
|
||||
| Modern Workplace Devices-Windows Autopatch-Fast | Fast deployment ring for quick rollout and adoption |
|
||||
| Modern Workplace Devices-Windows Autopatch-Broad | Final deployment ring for broad rollout into the organization |
|
||||
| Modern Workplace Devices Dynamic - Windows 10 | Microsoft Managed Desktop Devices with Windows 10<p>Group Rule:<ul><li>`(device.devicePhysicalIds -any _ -startsWith \"[OrderID]:Microsoft365Managed_\")`</li><li>`(device.deviceOSVersion -notStartsWith \"10.0.22000\")`</li></ul><br>Exclusions:<ul><li>Modern Workplace - Telemetry Settings for Windows 11</li></ul> |
|
||||
| Modern Workplace Devices Dynamic - Windows 11 | Microsoft Managed Desktop Devices with Windows 11<p>Group Rule:<ul><li>`(device.devicePhysicalIds -any _ -startsWith \"[OrderID]:Microsoft365Managed_\")`</li><li>`(device.deviceOSVersion -startsWith \"10.0.22000\")`</li></ul><br>Exclusions:<ul><li>Modern Workplace - Telemetry Settings for Windows 10</li></ul> |
|
||||
| Modern Workplace Roles - Service Administrator | All users granted access to Modern Workplace Service Administrator Role |
|
||||
@ -132,4 +132,4 @@ Windows Autopatch creates an enterprise application in your tenant. This enterpr
|
||||
|
||||
| Script | Description |
|
||||
| ----- | ----- |
|
||||
| Modern Workplace - Autopatch Client Setup | Installs necessary client components for the Windows Autopatch service |
|
||||
| Modern Workplace - Autopatch Client Setup v1.1 | Installs necessary client components for the Windows Autopatch service |
|
||||
|
@ -20,7 +20,7 @@ Windows Autopatch is a cloud service for enterprise customers designed to keep e
|
||||
|
||||
Windows Autopatch provides its service to enterprise customers, and properly administers customers' enrolled devices by using data from various sources.
|
||||
|
||||
The sources include Azure Active Directory (AD), Microsoft Intune, and Microsoft Windows 10/11. The sources provide a comprehensive view of the devices that Windows Autopatch manages. The service also uses these Microsoft services to enable Windows Autopatch to provide IT as a Service (ITaaS) capabilities:
|
||||
The sources include Azure Active Directory (Azure AD), Microsoft Intune, and Microsoft Windows 10/11. The sources provide a comprehensive view of the devices that Windows Autopatch manages.
|
||||
|
||||
| Data source | Purpose |
|
||||
| ------ | ------ |
|
||||
@ -74,7 +74,7 @@ Microsoft Windows Update for Business uses data from Windows diagnostics to anal
|
||||
|
||||
## Microsoft Azure Active Directory
|
||||
|
||||
Identifying data used by Windows Autopatch is stored by Azure Active Directory (Azure AD) in a geographical location. The geographical location is based on the location provided by the organization upon subscribing to Microsoft online services, such as Microsoft Apps for Enterprise and Azure. For more information on where your Azure AD data is located, see [Azure Active Directory - Where is your data located?](https://msit.powerbi.com/view?r=eyJrIjoiODdjOWViZDctMWRhZS00ODUzLWI4MmQtNWM5NjBkZTBkNjFlIiwidCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsImMiOjV9)
|
||||
Identifying data used by Windows Autopatch is stored by Azure Active Directory (AD) in a geographical location. The geographical location is based on the location provided by the organization upon subscribing to Microsoft online services, such as Microsoft Apps for Enterprise and Azure. For more information on where your Azure AD data is located, see [Azure Active Directory - Where is your data located?](https://msit.powerbi.com/view?r=eyJrIjoiODdjOWViZDctMWRhZS00ODUzLWI4MmQtNWM5NjBkZTBkNjFlIiwidCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsImMiOjV9)
|
||||
|
||||
## Microsoft Intune
|
||||
|
||||
|
@ -419,15 +419,9 @@ Your VM (or device) can be registered either via Intune or Microsoft Store for B
|
||||
> [!IMPORTANT]
|
||||
> If you've already registered your VM (or device) using Intune, then skip this step.
|
||||
|
||||
Optional: see the following video for an overview of the process.
|
||||
|
||||
|
||||
|
||||
> [!video https://www.youtube.com/embed/IpLIZU_j7Z0]
|
||||
|
||||
First, you need a Microsoft Store for Business account. You can use the same one you created above for Intune, or follow [these instructions](/microsoft-store/windows-store-for-business-overview) to create a new one.
|
||||
|
||||
Next, to sign in to [Microsoft Store for Business](https://businessstore.microsoft.com/en-us/store) with your test account, select **Sign in** on the upper-right-corner of the main page.
|
||||
Next, to sign in to [Microsoft Store for Business](https://businessstore.microsoft.com/store) with your test account, select **Sign in** on the upper-right-corner of the main page.
|
||||
|
||||
Select **Manage** from the top menu, then select the **Windows Autopilot Deployment Program** link under the **Devices** card. See the following example:
|
||||
|
||||
@ -528,8 +522,6 @@ Select **OK**, and then select **Create**.
|
||||
|
||||
If you already created and assigned a profile via Intune with the steps immediately above, then skip this section.
|
||||
|
||||
A [video](https://www.youtube.com/watch?v=IpLIZU_j7Z0) is available that covers the steps required to create and assign profiles in Microsoft Store for Business. These steps are also summarized below.
|
||||
|
||||
First, sign in to the [Microsoft Store for Business](https://businessstore.microsoft.com/manage/dashboard) using the Intune account you initially created for this lab.
|
||||
|
||||
Select **Manage** from the top menu, then select **Devices** from the left navigation tree.
|
||||
|
Reference in New Issue
Block a user