diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md
index 59fdbb3c53..a196916be3 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md
@@ -4,7 +4,7 @@ description: This article explains how Windows Autopatch manages Microsoft 365 A
 ms.date: 02/28/2023
 ms.prod: windows-client
 ms.technology: itpro-updates
-ms.topic: conceptual
+ms.topic: how-to
 ms.localizationpriority: medium
 author: tiaraquan
 ms.author: tiaraquan
@@ -73,21 +73,13 @@ If Windows Autopatch detects issues between versions of Microsoft 365 Apps for e
 
 Windows Autopatch will either:
 
-- Choose to stay on the previous version for rings that haven't received the update yet.
+- Choose to stay on the previous version for devices that haven't received the update yet.
 - Force all devices to roll back to the previous version.
 
 > [!NOTE]
-> Windows Autopatch doesn't currently allow customers to force their devices to stay on a previous version or rollback to a previous version.
+> Windows Autopatch doesn't allow you to:<ul><li>Pause or rollback an update in the Microsoft Intune admin center</li><li>Submit a request to the Windows Autopatch Service Engineering Team to pause or rollback an update</li>
 
-Windows quality updates are bundled together into a single release in the [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview). Therefore, we can't roll back only a portion of the update for Microsoft 365 Apps for enterprise.  
-
-## Compatibility with Servicing Profiles
-
-[Servicing profiles](/deployoffice/admincenter/servicing-profile) is a feature in the [Microsoft 365 Apps admin center](https://config.office.com/) that provides controlled update management of monthly Office updates, including controls for user and device targeting, scheduling, rollback, and reporting.
-
-A [service profile](/deployoffice/admincenter/servicing-profile#compatibility-with-other-management-tools) takes precedence over other policies, such as a Microsoft Intune policy or the Office Deployment Tool. 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 [software update workload](windows-autopatch-update-management.md#software-update-workloads), see the Device eligibility section of each respective software update workload.
+Updates are bundled together into a single release in the [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview). Therefore, we can't roll back only a portion of the update for Microsoft 365 Apps for enterprise.  
 
 ## Allow or block Microsoft 365 App updates
 
@@ -126,6 +118,14 @@ For organizations seeking greater control, you can allow or block Microsoft 365
     4. Windows Autopatch - Office Update Configuration [Fast]
     5. Windows Autopatch - Office Update Configuration [Broad]
 
+## Compatibility with Servicing Profiles
+
+[Servicing profiles](/deployoffice/admincenter/servicing-profile) is a feature in the [Microsoft 365 Apps admin center](https://config.office.com/) that provides controlled update management of monthly Office updates, including controls for user and device targeting, scheduling, rollback, and reporting.
+
+A [service profile](/deployoffice/admincenter/servicing-profile#compatibility-with-other-management-tools) takes precedence over other policies, such as a Microsoft Intune policy or the Office Deployment Tool. 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 [software update workload](windows-autopatch-update-management.md#software-update-workloads), see the Device eligibility section of each respective software update workload.
+
 ## Incidents and outages
 
 If devices in your tenant aren't meeting the [service level objective](#service-level-objective) for Microsoft 365 Apps for enterprise updates, an incident will be raised. The Windows Autopatch Service Engineering Team will work to bring the devices back into compliance.
diff --git a/windows/security/threat-protection/windows-defender-application-control/images/wdac-wizard-custom-manual-pfn-rule.png b/windows/security/threat-protection/windows-defender-application-control/images/wdac-wizard-custom-manual-pfn-rule.png
new file mode 100644
index 0000000000..05ca0ca3e4
Binary files /dev/null and b/windows/security/threat-protection/windows-defender-application-control/images/wdac-wizard-custom-manual-pfn-rule.png differ
diff --git a/windows/security/threat-protection/windows-defender-application-control/images/wdac-wizard-custom-pfn-rule.png b/windows/security/threat-protection/windows-defender-application-control/images/wdac-wizard-custom-pfn-rule.png
new file mode 100644
index 0000000000..835d8695f9
Binary files /dev/null and b/windows/security/threat-protection/windows-defender-application-control/images/wdac-wizard-custom-pfn-rule.png differ
diff --git a/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md b/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md
index 5ccc7f5f17..47ef560b03 100644
--- a/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md
+++ b/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md
@@ -10,142 +10,103 @@ ms.pagetype: security
 ms.localizationpriority: medium
 audience: ITPro
 author: jsuther1974
-ms.reviewer: isbrahm
+ms.reviewer: jogeurte
 ms.author: vinpa
 manager: aaroncz
-ms.date: 05/29/2020
+ms.date: 03/01/2023
 ms.technology: itpro-security
 ms.topic: article
 ---
 
-# Manage Packaged Apps with Windows Defender Application Control 
+# Manage Packaged Apps with Windows Defender Application Control
 
 **Applies to:**
 
--   Windows 10
--   Windows 11
--   Windows Server 2016 and above
+- Windows 10
+- Windows 11
+- Windows Server 2016 and above
 
 >[!NOTE]
->Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
+>Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [WDAC feature availability](feature-availability.md).
 
-This topic for IT professionals describes concepts and lists procedures to help you manage packaged apps with Windows Defender Application Control (WDAC) as part of your overall application control strategy.
+This article for IT professionals describes concepts and lists procedures to help you manage packaged apps with Windows Defender Application Control (WDAC) as part of your overall application control strategy.
 
-## Understanding Packaged Apps and Packaged App Installers
+## Comparing classic Windows Apps and Packaged Apps
 
-Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity. 
-With packaged apps, it's possible to control the entire app by using a single Windows Defender Application Control rule.
- 
-Typically, an app consists of multiple components: the installer that is used to install the app, and one or more exes, dlls, or scripts. With classic Windows apps, these components don't always share common attributes such as the software’s publisher name, product name, and product version. Therefore, Windows Defender Application Control controls each of these components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In contrast, all the components of a packaged app share the same publisher name, package name, and package version attributes. Therefore, you can control an entire app with a single rule.
+The biggest challenge in adopting application control is the lack of a strong app identity for classic Windows apps, also known as win32 apps. A typical win32 app consists of multiple components, including the installer that is used to install the app, and one or more exes, dlls, or scripts. An app can consist of hundreds or even thousands of individual binaries that work together to deliver the functionality that your users understand as the app. Some of that code may be signed by the software publisher, some may be signed by other companies, and some of it may not be signed at all. Much of the code may be written to disk by a common set of installers, but some may already be installed and some downloaded on demand. Some of the binaries have common resource header metadata, such as product name and product version, but other files won't share that information. So while you want to be able to express rules like "allow app Foo", that isn't something Windows inherently understands for classic Windows apps. Instead, you may have to create many WDAC rules to allow all the files that comprise the app.
 
-### <a href="" id="bkmk-compareclassicmetro"></a>Comparing classic Windows Apps and Packaged Apps
-
-Windows Defender Application Control policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server 
-2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
-
--   **Installing the apps**   All packaged apps can be installed by a standard user, whereas many classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
--   **Changing the system state**   Classic Windows apps can be written to change the system state if they're run with administrative privileges. Most packaged apps can't change the system state because they run with limited privileges. When you design your Windows Defender Application Control policies, it's important to understand whether an app that you're allowing can make system-wide changes.
--   **Acquiring the apps**   Packaged apps can be acquired through the Store, or by loading using Windows PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired through traditional means.
-
-Windows Defender Application Control uses different rule collections to control packaged apps and classic Windows apps. You have the choice to control one type, the other type, or both.
+Packaged apps on the other hand, also known as [MSIX](/windows/msix/overview), ensure that all the files that make up an app share the same identity and have a common signature. Therefore, with packaged apps, it's possible to control the entire app with a single WDAC rule.
 
 ## Using WDAC to Manage Packaged Apps
 
-Just as there are differences in managing each rule collection, you need to manage the packaged apps with the following strategy:
+> [!IMPORTANT]
+> When controlling packaged apps, you must choose between signer rules or Package Family Name (PFN) rules. If **any** Package Family Name (PFN) rule is used in your WDAC base policy or one of its supplemental policies, then **all** packaged apps must be controlled exclusively using PFN rules. You can't mix-and-match PFN rules with signature-based rules within a given base policy's scope. This will affect many inbox system apps like the Start menu. You can use wildcards in PFN rules on Windows 11 to simplify the rule creation.
 
-1.  Gather information about which packaged apps are running in your environment. 
+### Creating signature-based rules for Packaged Apps
 
-2.  Create WDAC rules for specific packaged apps based on your policy strategies. For more information, see [Deploy Windows Defender Application Control policy (WDAC) rules and file rules](select-types-of-rules-to-create.md).
+All of the files that make up an MSIX app are signed with a common catalog signature. You can create a signer rule from the MSIX app's installer file (\.msix or \.msixbundle) or from the AppxSignature.p7x file found in the app's installation folder under %ProgramFiles%\\WindowsApps\\ using the [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) PowerShell cmdlet. For example:
 
-3.  Continue to update the WDAC policies as new package apps are introduced into your environment. For information on how to do this update, see [Merge WDAC policies](merge-windows-defender-application-control-policies.md).
+#### Create signer rule from MSIX/MSIXBUNDLE
 
-## Blocking Packaged Apps
-
-You can now use `New-CIPolicyRule -Package $Package -Deny` to block packaged apps.
-
-### Blocking Packaged Apps Which Are Installed on the System
-
-Below are the list of steps you can follow to block one or more packaged apps in the case that the apps are on the system you're using the WDAC PowerShell cmdlets on:
-
-1. Get the app identifier for an installed package
-
-   ```powershell
-   $package = Get-AppxPackage -name *<example_app>*
-   ```
-   Where the name of the app is surrounded by asterisks, for example &ast;windowsstore&ast;
-   
-2. Make a rule by using the New-CIPolicyRule cmdlet
-
-   ```powershell   
-   $Rule = New-CIPolicyRule -Package $package -deny
-   ```
-3. Repeat for other packages you want to block using $rule +=…
-
-4. Make a policy for just the blocks you created for packages
-
-   ```powershell
-   New-CIpolicy -rules $rule -f .\policy.xml -u
-   ```
-
-5. Merge with an existing policy that authorizes the other applications and system components required for your scenario. Here we use the sample Allow Windows policy
-
-   ```powershell
-   Merge-CIPolicy -PolicyPaths .\policy.xml,C:\windows\Schemas\codeintegrity\examplepolicies\DefaultWindows_Audit.xml -o allowWindowsDenyPackages.xml
-   ```
-
-6. Disable audit mode if needed
-
-   ```powershell
-   Set-RuleOption -o 3 -Delete .\allowWindowsDenyPackages.xml
-   ```
-
-7. Enable invalidate EAs on reboot
-
-   ```powershell
-   Set-RuleOption -o 15 .\allowWindowsDenyPackages.xml 
-   ```
-
-8. Compile the policy
-
-   ```powershell
-   ConvertFrom-CIPolicy .\AllowWindowsDenyPackages.xml C:\compiledpolicy.bin
-   ```
-
-9. Install the policy without restarting
-
-   ```powershell
-   Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath = "C:\compiledpolicy.bin"}
-   ```
-   ### Blocking Packaged Apps Which Aren't Installed on the System
-
-If the app you intend to block isn't installed on the system you're using the WDAC PowerShell cmdlets on, then follow the steps below:
-
-1. Create a dummy rule using Steps 1-5 in the Blocking Packaged Apps Which Are Installed on the System section above
-
-2. Navigate to the app you want to block on the Store website
-
-3. Copy the GUID in the URL for the app
-    - Example: the GUID for the Microsoft To-Do app is 9nblggh5r558
-    - `https://www.microsoft.com/p/microsoft-to-do-list-task-reminder/9nblggh5r558?activetab=pivot:overviewtab` 
-4. Use the GUID in the following REST query URL to retrieve the identifiers for the app
-   - Example: for the Microsoft To-Do app, the URL would be `https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9nblggh5r558/applockerdata`
-   - The URL will return:
-   
-   ```
-   { "packageFamilyName": "Microsoft.Todos_8wekyb3d8bbwe", 
-    "packageIdentityName": "Microsoft.Todos", 
-    "windowsPhoneLegacyId": "6088f001-776c-462e-984d-25b6399c6607", 
-    "publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" 
-   }
-   ```
-
-5. Use the value returned by the query URL for the packageFamilyName to replace the package name generated earlier in the dummy rule from Step 1. 
-
-## Allowing Packaged Apps
-The method for allowing specific packaged apps is similar to the method outlined above for blocking packaged apps, with the only difference being the parameter to the New-CIPolicyRule cmdlet.
-
-```powershell   
-$Rule = New-CIPolicyRule -Package $package -allow
+```powershell
+$FilePath = $env:USERPROFILE+'\Downloads\WDACWizard_2.1.0.1_x64_8wekyb3d8bbwe.MSIX'
+$Rules = New-CIPolicyRule -DriverFilePath $FilePath -Level Publisher
 ```
 
-Since many system apps are packaged apps, it's recommended that customers rely on the sample policies in `C:\Windows\schemas\CodeIntegrity\ExamplePolicies` to help allow all inbox apps by the Store signature already included in the policies and control apps with deny rules. 
+Then use the [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) PowerShell cmdlet to merge your new rule into your existing WDAC policy XML.
+
+#### Create signer rule from AppxSignature.p7x
+
+```powershell
+$FilePath = $env:ProgramFiles+'\WindowsApps\Microsoft.WDAC.WDACWizard_2.1.0.1_x64__8wekyb3d8bbwe\AppxSignature.p7x'
+$Rules = New-CIPolicyRule -DriverFilePath $FilePath -Level Publisher
+```
+
+Then use the [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) PowerShell cmdlet to merge your new rule into your existing WDAC policy XML.
+
+### Creating PackageFamilyName rules for Packaged Apps
+
+#### Create PFN rules from PowerShell
+
+You can create PFN rules directly from packaged apps that are currently installed using the [Get-AppXPackage](/powershell/module/appx/get-appxpackage) and [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) PowerShell cmdlets. For example:
+
+```powershell
+# Query for the packaged apps. This example looks for all packages from Microsoft.
+$Packages = Get-AppXPackage -Name Microsoft.*
+foreach ($Package in $Packages)
+{
+   $Rules += New-CIPolicyRule -Package $Package
+}
+```
+
+Then use the [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) PowerShell cmdlet to merge your new rule(s) into your existing WDAC policy XML.
+
+#### Create PFN rules using the WDAC Wizard
+
+##### Create PFN rule from an installed MSIX app
+
+Use the following steps to create a WDAC PFN rule for an app that is installed on the system:
+
+1. From the **Policy Signing Rules** page of the [WDAC Wizard](https://aka.ms/wdacwizard), select **Add Custom Rule**.
+2. Check **Usermode Rule** as the Rule Scope, if not checked.
+3. Select either **Allow** or **Deny** for your Rule Action.
+4. Select **Packaged App** for your Rule Type.
+5. In the **Package Name** field, enter a string value to search. You can use `?` or `*` wildcards in the search string. Then select **Search**.
+6. In the results box, check one or more apps for which you want to create rules.
+7. Select **Create Rule**.
+8. Create any other rules desired, then complete the Wizard.
+
+![Create PFN rule from WDAC Wizard](images/wdac-wizard-custom-pfn-rule.png)
+
+##### Create a PFN rule using a custom string
+
+Use the following steps to create a PFN rule with a custom string value:
+
+1. Repeat steps 1-4 in the previous example.
+2. Check the box labeled **Use Custom Package Family**. The *Search* button label changes to *Create*.
+3. In the **Package Name** field, enter a string value for your PFN rule. You can use `?` or `*` wildcards if targeting Windows 11 devices. Then select **Create**
+4. In the results box, check one or more apps for which you want to create rules.
+5. Select **Create Rule**.
+6. Create any other rules desired, then complete the Wizard.
+
+![Create PFN rule with custom string from WDAC Wizard](images/wdac-wizard-custom-manual-pfn-rule.png)