diff --git a/windows/client-management/enroll-a-windows-10-device-automatically-using-group-policy.md b/windows/client-management/enroll-a-windows-10-device-automatically-using-group-policy.md index ec40469278..80e253c59f 100644 --- a/windows/client-management/enroll-a-windows-10-device-automatically-using-group-policy.md +++ b/windows/client-management/enroll-a-windows-10-device-automatically-using-group-policy.md @@ -16,6 +16,7 @@ ms.collection: highpri **Applies to:** +- Windows 11 - Windows 10 Starting in Windows 10, version 1709, you can use a Group Policy to trigger auto-enrollment to Mobile Device Management (MDM) for Active Directory (AD) domain-joined devices. @@ -196,6 +197,9 @@ Requirements: - 21H2 --> [Administrative Templates (.admx) for Windows 10 November 2021 Update (21H2)-v2.0](https://www.microsoft.com/download/details.aspx?id=104042) + - 22H2 --> [Administrative Templates (.admx) for Windows 10 October 2022 Update (22H2)](https://www.microsoft.com/download/104677) + + - 22H2 --> [Administrative Templates (.admx) for Windows 11 2022 September Update (22H2)](https://www.microsoft.com/download/details.aspx?id=104593) 2. Install the package on the Domain Controller. @@ -216,6 +220,10 @@ Requirements: - 21H1 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 10 May 2021 Update (21H1)** - 21H2 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2021 Update V2 (21H2)** + + - 22H2 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 10 October 2022 Update (22H2)** + + - 22H2 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 11 September 2022 Update (22H2)** 4. Rename the extracted Policy Definitions folder to `PolicyDefinitions`. diff --git a/windows/deployment/update/media-dynamic-update.md b/windows/deployment/update/media-dynamic-update.md index af27a5c840..135a23932a 100644 --- a/windows/deployment/update/media-dynamic-update.md +++ b/windows/deployment/update/media-dynamic-update.md @@ -76,6 +76,7 @@ This table shows the correct sequence for applying the various tasks to the file |Add Features on Demand | | | 20 | |Add Safe OS Dynamic Update | 6 | | | |Add Setup Dynamic Update | | | | 26 +|Add setup.exe from WinPE | | | | 27 |Add latest cumulative update | | 15 | 21 | |Clean up the image | 7 | 16 | 22 | |Add Optional Components | | | 23 | @@ -188,7 +189,7 @@ Mount-WindowsImage -ImagePath $MEDIA_NEW_PATH"\sources\install.wim" -Index 1 -Pa # # update Windows Recovery Environment (WinRE) # -Copy-Item -Path $MAIN_OS_MOUNT"\windows\system32\recovery\winre.wim" -Destination $WORKING_PATH"\winre.wim" -Force -Recurse -ErrorAction stop | Out-Null +Copy-Item -Path $MAIN_OS_MOUNT"\windows\system32\recovery\winre.wim" -Destination $WORKING_PATH"\winre.wim" -Force -ErrorAction stop | Out-Null Write-Output "$(Get-TS): Mounting WinRE" Mount-WindowsImage -ImagePath $WORKING_PATH"\winre.wim" -Index 1 -Path $WINRE_MOUNT -ErrorAction stop | Out-Null @@ -299,7 +300,7 @@ Move-Item -Path $WORKING_PATH"\winre2.wim" -Destination $WORKING_PATH"\winre.wim ### Update WinPE -This script is similar to the one that updates WinRE, but instead it mounts Boot.wim, applies the packages with the latest cumulative update last, and saves. It repeats this for all images inside of Boot.wim, typically two images. It starts by applying the servicing stack Dynamic Update. Since the script is customizing this media with Japanese, it installs the language pack from the WinPE folder on the language pack ISO. Additionally, add font support and text to speech (TTS) support. Since the script is adding a new language, it rebuilds lang.ini, used to identify languages installed in the image. Finally, it cleans and exports Boot.wim, and copies it back to the new media. +This script is similar to the one that updates WinRE, but instead it mounts Boot.wim, applies the packages with the latest cumulative update last, and saves. It repeats this for all images inside of Boot.wim, typically two images. It starts by applying the servicing stack Dynamic Update. Since the script is customizing this media with Japanese, it installs the language pack from the WinPE folder on the language pack ISO. Additionally, add font support and text to speech (TTS) support. Since the script is adding a new language, it rebuilds lang.ini, used to identify languages installed in the image. For the second image, we'll save setup.exe for later use, to ensure this version matches the \sources\setup.exe version from the installation media. If these binaries are not identical, Windows Setup will fail during installation. Finally, it cleans and exports Boot.wim, and copies it back to the new media. ```powershell # @@ -312,7 +313,7 @@ $WINPE_IMAGES = Get-WindowsImage -ImagePath $MEDIA_NEW_PATH"\sources\boot.wim" Foreach ($IMAGE in $WINPE_IMAGES) { # update WinPE - Write-Output "$(Get-TS): Mounting WinPE" + Write-Output "$(Get-TS): Mounting WinPE, image index $($IMAGE.ImageIndex)" Mount-WindowsImage -ImagePath $MEDIA_NEW_PATH"\sources\boot.wim" -Index $IMAGE.ImageIndex -Path $WINPE_MOUNT -ErrorAction stop | Out-Null # Add servicing stack update (Step 9 from the table) @@ -415,6 +416,11 @@ Foreach ($IMAGE in $WINPE_IMAGES) { Write-Output "$(Get-TS): Performing image cleanup on WinPE" DISM /image:$WINPE_MOUNT /cleanup-image /StartComponentCleanup | Out-Null + # If second image, save setup.exe for later use. This will address possible binary mismatch with the version in the main OS \sources folder + if ($IMAGE.ImageIndex -eq "2") { + Copy-Item -Path $WINPE_MOUNT"\sources\setup.exe" -Destination $WORKING_PATH"\setup.exe" -Force -ErrorAction stop | Out-Null + } + # Dismount Dismount-WindowsImage -Path $WINPE_MOUNT -Save -ErrorAction stop | Out-Null @@ -496,7 +502,7 @@ Add-WindowsPackage -Path $MAIN_OS_MOUNT -PackagePath $LCU_PATH -ErrorAction stop # Copy our updated recovery image from earlier into the main OS # Note: If I were updating more than 1 edition, I'd want to copy the same recovery image file # into each edition to enable single instancing -Copy-Item -Path $WORKING_PATH"\winre.wim" -Destination $MAIN_OS_MOUNT"\windows\system32\recovery\winre.wim" -Force -Recurse -ErrorAction stop | Out-Null +Copy-Item -Path $WORKING_PATH"\winre.wim" -Destination $MAIN_OS_MOUNT"\windows\system32\recovery\winre.wim" -Force -ErrorAction stop | Out-Null # Perform image cleanup Write-Output "$(Get-TS): Performing image cleanup on main OS" @@ -526,7 +532,7 @@ Move-Item -Path $WORKING_PATH"\install2.wim" -Destination $MEDIA_NEW_PATH"\sourc ### Update remaining media files -This part of the script updates the Setup files. It simply copies the individual files in the Setup Dynamic Update package to the new media. This step brings an updated Setup.exe as needed, along with the latest compatibility database, and replacement component manifests. +This part of the script updates the Setup files. It simply copies the individual files in the Setup Dynamic Update package to the new media. This step brings an updated Setup files as needed, along with the latest compatibility database, and replacement component manifests. This script also does a final replacement of setup.exe using the previously saved version from WinPE. ```powershell # @@ -536,6 +542,10 @@ This part of the script updates the Setup files. It simply copies the individual # Add Setup DU by copy the files from the package into the newMedia Write-Output "$(Get-TS): Adding package $SETUP_DU_PATH" cmd.exe /c $env:SystemRoot\System32\expand.exe $SETUP_DU_PATH -F:* $MEDIA_NEW_PATH"\sources" | Out-Null + +# Copy setup.exe from boot.wim, saved earlier. +Copy-Item -Path $WORKING_PATH"\setup.exe" -Destination $MEDIA_NEW_PATH"\sources\setup.exe" -Force -ErrorAction stop | Out-Null + ``` ### Finish up diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md index 81dd91dbd5..c250ba4502 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md @@ -58,7 +58,6 @@ The Windows Autopatch deployment ring calculation happens during the [device reg - 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%)**. - 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%)**. - | 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 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:
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. | @@ -84,7 +83,7 @@ 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.

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 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] +> [!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 diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md index 3b22965f8e..7fdb0ac0d9 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md @@ -119,6 +119,6 @@ There are two statuses associated with paused quality updates, **Service Paused* | Service Paused | If the Windows Autopatch service has paused an update, the release will have the **Service Paused** status. You must [submit a support request](windows-autopatch-support-request.md) to resume the update. | | Customer Paused | If you've paused an update, the release will have the **Customer Paused** status. The Windows Autopatch service can't overwrite a customer-initiated pause. You must select **Resume** to resume the update. | -## Incidents and outages +## Remediating Ineligible and/or Not up to Date devices -Windows Autopatch provides information on how you can remediate [Ineligible Devices (Customer Actions)](../operate/windows-autopatch-wqu-reports-overview.md#ineligible-devices-customer-action) and/or the Windows Autopatch service may remediate [Not up to Date devices](../operate/windows-autopatch-wqu-reports-overview.md#not-up-to-date-microsoft-action) to bring them back into compliance. +To ensure your devices receive Windows quality updates, Windows Autopatch provides information on how you can remediate [Ineligible Devices (Customer Actions)](../operate/windows-autopatch-wqu-reports-overview.md#ineligible-devices-customer-action). In addition, the Windows Autopatch service may remediate [Not up to Date devices](../operate/windows-autopatch-wqu-reports-overview.md#not-up-to-date-microsoft-action) to bring them back into compliance. diff --git a/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md b/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md index 5c6402aa17..ed12776057 100644 --- a/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md +++ b/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md @@ -28,6 +28,7 @@ Describes the best practices, location, values, policy management, and security ## Reference The **Act as part of the operating system** policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Potential access isn't limited to what is associated with the user by default. The calling process may request that arbitrary extra privileges be added to the access token. The calling process may also build an access token that doesn't provide a primary identity for auditing in the system event logs. + Constant: SeTcbPrivilege ### Possible values diff --git a/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md b/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md index 82c3f5ffc9..cc0957e9e8 100644 --- a/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md +++ b/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md @@ -29,9 +29,11 @@ Describes the best practices, location, values, policy management, and security This user right determines if users can create a symbolic link from the device they're logged on to. -A symbolic link is a file-system object that points to another file-system object that is called the target. Symbolic links are transparent to users. The links appear as normal files or directories, and they can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with UNIX operating systems. Microsoft has implemented symbolic links to function just like UNIX links. +A symbolic link is a file system object that points to another file system object that is called the target. Symbolic links are transparent to users. The links appear as normal files or directories, and they can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with UNIX operating systems. Microsoft has implemented symbolic links to function just like UNIX links. + +> [!WARNING] +> This privilege should only be given to trusted users. Symbolic links can expose security vulnerabilities in applications that aren't designed to handle them. ->**Warning:**   This privilege should only be given to trusted users. Symbolic links can expose security vulnerabilities in applications that aren't designed to handle them. Constant: SeCreateSymbolicLinkPrivilege ### Possible values diff --git a/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md b/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md index d7510658e7..5f6ed628f4 100644 --- a/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md +++ b/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md @@ -33,7 +33,8 @@ Normally, an application running on Windows can negotiate for more physical memo Enabling this policy setting for a specific account (a user account or a process account for an application) prevents paging of the data. Thereby, the amount of memory that Windows can reclaim under pressure is limited. This limitation could lead to performance degradation. ->**Note:**  By configuring this policy setting, the performance of the Windows operating system will differ depending on if applications are running on 32-bit or 64-bit systems, and if they are virtualized images. Performance will also differ between earlier and later versions of the Windows operating system. +> [!NOTE] +> By configuring this policy setting, the performance of the Windows operating system will differ depending on if applications are running on 32-bit or 64-bit systems, and if they are virtualized images. Performance will also differ between earlier and later versions of the Windows operating system. Constant: SeLockMemoryPrivilege diff --git a/windows/security/threat-protection/windows-sandbox/windows-sandbox-configure-using-wsb-file.md b/windows/security/threat-protection/windows-sandbox/windows-sandbox-configure-using-wsb-file.md index 2b518a0153..a6ce54113b 100644 --- a/windows/security/threat-protection/windows-sandbox/windows-sandbox-configure-using-wsb-file.md +++ b/windows/security/threat-protection/windows-sandbox/windows-sandbox-configure-using-wsb-file.md @@ -76,6 +76,7 @@ Enables or disables networking in the sandbox. You can disable network access to `value` Supported values: +- *Enable*: Enables networking in the sandbox. - *Disable*: Disables networking in the sandbox. - *Default*: This value is the default value for networking support. This value enables networking by creating a virtual switch on the host and connects the sandbox to it via a virtual NIC. @@ -184,6 +185,7 @@ Enables or disables sharing of the host clipboard with the sandbox. `value` Supported values: +- *Enable*: Enables sharing of the host clipboard with the sandbox. - *Disable*: Disables clipboard redirection in the sandbox. If this value is set, copy/paste in and out of the sandbox will be restricted. - *Default*: This value is the default value for clipboard redirection. Currently, copy/paste between the host and sandbox are permitted under *Default*.