Merge pull request #6768 from MicrosoftDocs/main

merge main to live, 10:30 Tuesday
This commit is contained in:
Jeff Borsecnik 2022-06-28 10:36:34 -07:00 committed by GitHub
commit 491a94e6d6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 11 additions and 7 deletions

View File

@ -6,7 +6,7 @@ ms.topic: article
ms.prod: w10
ms.technology: windows
author: dansimp
ms.date: 06/26/2017
ms.date: 06/28/2022
ms.reviewer:
manager: dansimp
---
@ -19,7 +19,7 @@ The table below shows the applicability of Windows:
|--- |--- |--- |
|Home|No|No|
|Pro|No|No|
|Windows SE|No|No|
|Windows SE|No|Yes|
|Business|No|No|
|Enterprise|Yes|Yes|
|Education|Yes|Yes|

View File

@ -102,7 +102,7 @@ Window Autopatch deploys mobile device management (MDM) policies to configure Mi
## Microsoft 365 Apps servicing profiles
A service profile takes precedence over other management tools, such as Microsoft Endpoint Manager or the Office Deployment Tool. This means that the servicing profile will affect all devices that meet the [device eligibility requirements](#device-eligibility) regardless of existing management tools in your environment. So, if you're targeting a managed device with a servicing profile it will be ineligible for Microsoft 365 App update management.
A [service profile](/deployoffice/admincenter/servicing-profile#compatibility-with-other-management-tools) takes precedence over other management tools, such as Microsoft Endpoint Manager or the Office Deployment Tool. This means that the servicing profile will affect all devices that meet the [device eligibility requirements](#device-eligibility) regardless of existing management tools in your environment. So, if you're targeting a managed device with a servicing profile it will be ineligible for Microsoft 365 App update management.
However, the device may still be eligible for other managed updates. For more information about a device's eligibility for a given [update type](windows-autopatch-update-management.md#update-types), see the Device eligibility section of each respective update type.

View File

@ -14,7 +14,7 @@ author: dansimp
ms.reviewer: isbrahm
ms.author: dansimp
manager: dansimp
ms.date: 01/26/2022
ms.date: 06/28/2022
ms.technology: windows-sec
---
@ -88,7 +88,7 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
| Rule level | Description |
|----------- | ----------- |
| **Hash** | Specifies individual hash values for each discovered binary. This is the most specific level, and requires more effort to maintain the current product versions hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
| **Hash** | Specifies individual [Authenticode/PE image hash values](#more-information-about-hashes) for each discovered binary. This is the most specific level, and requires more effort to maintain the current product versions hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
| **FileName** | Specifies the original filename for each binary. Although the hash values for an application are modified when updated, the file names are typically not. This level offers less specific security than the hash level, but it doesn't typically require a policy update when any binary is modified. |
| **FilePath** | Beginning with Windows 10 version 1903, this level allows binaries to run from specific file path locations. More information about FilePath level rules can be found below. |
| **SignedVersion** | This level combines the publisher rule with a version number. It allows anything to run from the specified publisher with a version at or above the specified version number. |
@ -146,6 +146,10 @@ You can also use the following macros when the exact volume may vary: `%OSDRIVE%
## More information about hashes
WDAC uses the [Authenticode/PE image hash algorithm](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx) when calculating the hash of a file. Unlike the more popular, but less secure, [flat file hash](/powershell/module/microsoft.powershell.utility/get-filehash), the Authenticode hash calculation omits the file's checksum and the Certificate Table and the Attribute Certificate Table. Therefore, the Authenticode hash of a file does not change when the file is re-signed or timestamped, or the digital signature is removed from the file. By using the Authenticode hash, WDAC provides added security and less management overhead so customers do not need to revise the policy hash rules when the digital signature on the file is updated.
The Authenticode/PE image hash can be calculated for digitally-signed and unsigned files.
### Why does scan create four hash rules per XML file?
The PowerShell cmdlet will produce an Authenticode Sha1 Hash, Sha256 Hash, Sha1 Page Hash, Sha256 Page Hash.