docs(accessanalyzer-26.1): unlist the v12 to AA26 migration KB (AA-773)

.github/workflows/claude-code-followup.yml

@@ -72,7 +72,7 @@ jobs:
 
       - name: Handle @claude request
         if: steps.pr-info.outputs.is_fork == 'false' && steps.pr-info.outputs.targets_dev == 'true'
-        uses: anthropics/claude-code-action@e5ad3c7725bc2459721893f88879fef9dbcf97b0 # v1
+        uses: anthropics/claude-code-action@fa2b2666b747000bf42767d1f332065b375e3c8f # v1
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:

.github/workflows/claude-code-review.yml

@@ -40,7 +40,7 @@ jobs:
           done
 
       - name: Run code review
-        uses: anthropics/claude-code-action@e5ad3c7725bc2459721893f88879fef9dbcf97b0 # v1
+        uses: anthropics/claude-code-action@fa2b2666b747000bf42767d1f332065b375e3c8f # v1
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:

.github/workflows/claude-doc-pr.yml

@@ -93,7 +93,7 @@ jobs:
 
       - name: Run editorial review
         if: steps.changed-files.outputs.count > 0
-        uses: anthropics/claude-code-action@e5ad3c7725bc2459721893f88879fef9dbcf97b0 # v1
+        uses: anthropics/claude-code-action@fa2b2666b747000bf42767d1f332065b375e3c8f # v1
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           DOC_PR_FILES: ${{ steps.changed-files.outputs.files }}
@@ -189,7 +189,7 @@ jobs:
 
       - name: Handle @claude request
         if: steps.pr-info.outputs.is_fork == 'false' && steps.pr-info.outputs.targets_dev == 'true'
-        uses: anthropics/claude-code-action@e5ad3c7725bc2459721893f88879fef9dbcf97b0 # v1
+        uses: anthropics/claude-code-action@fa2b2666b747000bf42767d1f332065b375e3c8f # v1
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:

.github/workflows/claude-issue-labeler.yml

@@ -26,7 +26,7 @@ jobs:
 
       - name: Step 1 — Security vulnerability screening
         id: security-screen
-        uses: anthropics/claude-code-action@e5ad3c7725bc2459721893f88879fef9dbcf97b0 # v1
+        uses: anthropics/claude-code-action@fa2b2666b747000bf42767d1f332065b375e3c8f # v1
         with:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           github_token: ${{ secrets.GITHUB_TOKEN }}
@@ -58,7 +58,7 @@ jobs:
       - name: Step 2 — Code of conduct check
         if: steps.check-state.outputs.issue_state == 'OPEN'
         id: conduct-check
-        uses: anthropics/claude-code-action@e5ad3c7725bc2459721893f88879fef9dbcf97b0 # v1
+        uses: anthropics/claude-code-action@fa2b2666b747000bf42767d1f332065b375e3c8f # v1
         with:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           github_token: ${{ secrets.GITHUB_TOKEN }}
@@ -83,7 +83,7 @@ jobs:
         # Only run label assignment for issue events (not comments) and only if issue is still open
         if: steps.check-state.outputs.issue_state == 'OPEN' && github.event_name == 'issues'
         id: assign-label
-        uses: anthropics/claude-code-action@e5ad3c7725bc2459721893f88879fef9dbcf97b0 # v1
+        uses: anthropics/claude-code-action@fa2b2666b747000bf42767d1f332065b375e3c8f # v1
         with:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           github_token: ${{ secrets.GITHUB_TOKEN }}
@@ -213,7 +213,7 @@ jobs:
       - name: Run content-fix skill
         id: content-fix
         if: steps.check-issue.outputs.issue_state == 'OPEN' && steps.check-issue.outputs.has_content_fix == 'true'
-        uses: anthropics/claude-code-action@e5ad3c7725bc2459721893f88879fef9dbcf97b0 # v1
+        uses: anthropics/claude-code-action@fa2b2666b747000bf42767d1f332065b375e3c8f # v1
         env:
           REPO: ${{ github.repository }}
         with:
@@ -343,7 +343,7 @@ jobs:
       - name: Run content-fix skill
         id: content-fix-followup
         if: steps.check-issue.outputs.issue_state == 'OPEN' && steps.check-issue.outputs.has_content_fix == 'true'
-        uses: anthropics/claude-code-action@e5ad3c7725bc2459721893f88879fef9dbcf97b0 # v1
+        uses: anthropics/claude-code-action@fa2b2666b747000bf42767d1f332065b375e3c8f # v1
         env:
           REPO: ${{ github.repository }}
           COMMENT_BODY: ${{ github.event.comment.body }}

.github/workflows/vale-autofix.yml

@@ -173,7 +173,7 @@ jobs:
         id: phase2
         if: steps.vale-remaining.outputs.remaining > 0
         continue-on-error: true
-        uses: anthropics/claude-code-action@e5ad3c7725bc2459721893f88879fef9dbcf97b0 # v1
+        uses: anthropics/claude-code-action@fa2b2666b747000bf42767d1f332065b375e3c8f # v1
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:
@@ -219,7 +219,7 @@ jobs:
         id: phase3
         if: steps.bot-check.outputs.skip != 'true' && steps.changed-files.outputs.count > 0
         continue-on-error: true
-        uses: anthropics/claude-code-action@e5ad3c7725bc2459721893f88879fef9dbcf97b0 # v1
+        uses: anthropics/claude-code-action@fa2b2666b747000bf42767d1f332065b375e3c8f # v1
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:

docs/accessanalyzer/26.1/scans/scan-executions.md

@@ -51,7 +51,7 @@ There is no separate detail page for an execution. Everything beyond the row its
 
 **Completed**, **Completed with errors**, **Failed**, **Stopped**, and **Cancelled** are final; an execution in one of those states never changes again. **Paused** isn't final, so a forgotten paused execution sits in the list until something resumes or stops it.
 
-An execution can run for at most 7 days. Access Analyzer also ends a run that has been stuck in **Pending** or **Running** for more than 2 hours: as **Stopped** when you requested a stop, and as **Failed** otherwise.
+Access Analyzer ends a run that has been stuck in **Pending** or **Running** for more than 2 hours: as **Stopped** when you requested a stop, and as **Failed** otherwise.
 
 ## Pause, Resume, or Stop an Execution
 

docs/kb/accessanalyzer-26.1/migration/audit-data-strategy.md

@@ -15,10 +15,17 @@ sidebar_label: "Historical Audit Data"
 tags:
   - migration
   - audit-data
+unlisted: true
 ---
 
 # Historical Audit Data
 
+:::warning[Content under revision]
+
+This article is being revised. It describes an earlier Access Analyzer 26 configuration model and does not match the shipping 26.1 product. Do not use it to plan or perform a migration. Contact Netwrix Support for current migration guidance.
+
+:::
+
 ## Overview
 
 Access Analyzer 26 uses a separate database stack (ClickHouse and PostgreSQL) and does not connect to or read from the legacy SQL Server database. Historical audit records collected by the previous version remain in the original SQL Server database and are not affected by the migration.

docs/kb/accessanalyzer-26.1/migration/index.md

@@ -15,10 +15,17 @@ products:
 sidebar_label: "Migration Overview"
 tags:
   - migration
+unlisted: true
 ---
 
 # Migrating to Access Analyzer 26
 
+:::warning[Content under revision]
+
+This article is being revised. It describes an earlier Access Analyzer 26 configuration model and does not match the shipping 26.1 product. Do not use it to plan or perform a migration. Contact Netwrix Support for current migration guidance.
+
+:::
+
 This section covers migrating credentials, target servers, and job schedules from Netwrix Access Analyzer 12.0 and earlier (formerly StealthAUDIT) to Access Analyzer 26 (AA26). These procedures apply whether you are replacing the previous version or running both products in parallel. Historical audit data collected by the previous version remains in the SQL Server database and is not affected.
 
 ---

docs/kb/accessanalyzer-26.1/migration/migrate-credentials.md

@@ -15,10 +15,17 @@ sidebar_label: "Migrating Connection Profiles"
 tags:
   - migration
   - service-accounts
+unlisted: true
 ---
 
 # Migrating Connection Profiles to Service Accounts
 
+:::warning[Content under revision]
+
+This article is being revised. It describes an earlier Access Analyzer 26 configuration model and does not match the shipping 26.1 product. Do not use it to plan or perform a migration. Contact Netwrix Support for current migration guidance.
+
+:::
+
 ## Overview
 
 Service accounts in AA26 replace legacy connection profiles and serve the same purpose: storing the credentials that scanners use to connect to data sources. Complete this inventory and recreation process before creating source groups.

docs/kb/accessanalyzer-26.1/migration/migrate-job-configurations.md

@@ -15,10 +15,17 @@ sidebar_label: "Migrating Job Configurations"
 tags:
   - migration
   - scans
+unlisted: true
 ---
 
 # Migrating Job Configurations to Scan Parameters
 
+:::warning[Content under revision]
+
+This article is being revised. It describes an earlier Access Analyzer 26 configuration model and does not match the shipping 26.1 product. Do not use it to plan or perform a migration. Contact Netwrix Support for current migration guidance.
+
+:::
+
 ## Overview
 
 Scans in AA26 replace the legacy job/data collector model. Each source has one scan per scan type, and scan parameters are configured directly on the scan rather than in a job wizard. The tables and procedures below map each legacy data collector setting to its AA26 equivalent by connector type.

docs/kb/accessanalyzer-26.1/migration/migrate-proxy-servers.md

@@ -15,10 +15,17 @@ sidebar_label: "Migrating Proxy Servers"
 tags:
   - migration
   - scanners
+unlisted: true
 ---
 
 # Migrating Proxy Servers to Scanners
 
+:::warning[Content under revision]
+
+This article is being revised. It describes an earlier Access Analyzer 26 configuration model and does not match the shipping 26.1 product. Do not use it to plan or perform a migration. Contact Netwrix Support for current migration guidance.
+
+:::
+
 ## Overview
 
 Scanner nodes in Access Analyzer 26 replace legacy Windows proxy servers for distributed File Server and Active Directory scanning. If your legacy environment used proxy servers to scan hosts close to their network location, deploy equivalent scanner nodes in AA26 so scans run in the same distributed fashion.

docs/kb/accessanalyzer-26.1/migration/migrate-schedules.md

@@ -14,10 +14,17 @@ sidebar_label: "Migrating Job Schedules"
 tags:
   - migration
   - schedules
+unlisted: true
 ---
 
 # Migrating Job Schedules to Scan Schedules
 
+:::warning[Content under revision]
+
+This article is being revised. It describes an earlier Access Analyzer 26 configuration model and does not match the shipping 26.1 product. Do not use it to plan or perform a migration. Contact Netwrix Support for current migration guidance.
+
+:::
+
 ## Overview
 
 The legacy product schedules data collection using Windows Task Scheduler triggers. AA26 schedules scans using cron expressions — a standard five-field format. The steps below cover how to export legacy schedule data, translate trigger settings to cron format, and apply the resulting schedules to source groups in AA26.

docs/kb/accessanalyzer-26.1/migration/migrate-target-servers.md

@@ -14,10 +14,17 @@ sidebar_label: "Migrating Target Servers and Host Lists"
 tags:
   - migration
   - source-groups
+unlisted: true
 ---
 
 # Migrating Target Servers and Host Lists to Source Groups
 
+:::warning[Content under revision]
+
+This article is being revised. It describes an earlier Access Analyzer 26 configuration model and does not match the shipping 26.1 product. Do not use it to plan or perform a migration. Contact Netwrix Support for current migration guidance.
+
+:::
+
 ## Overview
 
 This procedure covers inventorying the host lists in your legacy Netwrix Access Analyzer installation and recreating them as source groups and sources in Access Analyzer 26.

docs/kb/accessanalyzer-26.1/migration/migration-checklist.md

@@ -12,10 +12,17 @@ products:
 sidebar_label: "Migration Checklist"
 tags:
   - migration
+unlisted: true
 ---
 
 # Migration Checklist
 
+:::warning[Content under revision]
+
+This article is being revised. It describes an earlier Access Analyzer 26 configuration model and does not match the shipping 26.1 product. Do not use it to plan or perform a migration. Contact Netwrix Support for current migration guidance.
+
+:::
+
 Complete each section before moving to the next.
 
 **Customer:** _____________________________    **Migration date:** _____________________________

docs/kb/passwordpolicyenforcer/troubleshooting-and-errors/Cannot-Write-App-Configuration-Access-Denied.md

@@ -0,0 +1,53 @@
+---
+description: >-
+  Steps to configure permissions so a user running the Password Policy Enforcer Management Console can read and write the Password Policy Enforcer configuration.
+keywords:
+  - Netwrix Password Policy Enforcer
+  - Console
+  - Read/Write
+  - Configuration
+  - Active Directory
+  - Access Denied
+  - Management Console
+  - Active Directory Users and Computers
+  - Permissions
+  - Deny Permission
+  - System Container
+products:
+  - passwordpolicyenforcer
+sidebar_label: "Error: Cannot Write the App Configuration Settings (Access Denied)"
+tags:
+  - kb
+title: "Error: Cannot Write the App Configuration Settings (Access Denied)"
+knowledge_article_id: 
+---
+
+# Error: Cannot Write the App Configuration Settings (Access Denied)
+
+## Symptom
+
+When attempting to save a configuration change in Netwrix Password Policy Enforcer, the following error occurs: `Cannot write the app configuration settings (access denied)`.
+
+## Cause
+
+The account currently using the Password Policy Enforcer Management Console does not have sufficient rights to edit the object in Active Directory. 
+
+## Resolution
+
+Ensure that the account you use to run the Password Policy Enforcer Management Console has Read and Write permissions on the object where Active Directory stores the Password Policy Enforcer configuration. A Deny permission on the object — for the account itself or a group it belongs to — blocks access even when an Allow permission is also present, so remove any Deny permissions if they are not intentional.
+
+1. Open **Active Directory Users and Computers**.
+
+2. Click **View**, then select **Advanced Features**.
+
+![Advanced view of Active Directory Users and Computers](../0-images/AdvancedViewUsersandComputers.png)
+
+3. Locate the Password Policy Enforcer object for the version you are using under the **System** directory.
+
+![PPE configuration object in ADUC System container](../0-images/PPEConfigObjectADUCSytem.png)
+
+    > **NOTE:** The version of the object changes only with the major version number; it does not change for minor version numbers or build numbers.
+
+4. Right click on the Password Policy Enforcer object of your version and click **Properties**, then click the **Security** tab to view all the permissions applied to this object. Grant the account Read and Write permissions, and remove any Deny permissions that are blocking access.
+
+5. Reopen the Password Policy Enforcer Management Console and retry saving the configuration change. The save should now complete without the access denied error.

docs/kb/threatprevention/troubleshooting-and-diagnostics/enabling-additional-logging-for-the-threat-prevention-admin-console.md

@@ -13,47 +13,39 @@ keywords:
   - SIWinConsole
   - Update Log Levels
 products:
-  - threat-prevention
-sidebar_label: Enabling additional logging for the Threat Prevent
-tags: []
-title: "Enabling additional logging for the Threat Prevention Admin Console"
+  - threatprevention
+sidebar_label: "Enabling Additional Logging for the Threat Prevention Admin Console"
+tags:
+  - kb
+title: "Enabling Additional Logging for the Threat Prevention Admin Console"
 knowledge_article_id: kA04u0000000I2PCAU
 ---
 
-# Enabling additional logging for the Threat Prevention Admin Console
+# Enabling Additional Logging for the Threat Prevention Admin Console
 
-## Summary
-Enabling additional logging for the Threat Prevention Admin Console
-
-## Issue
-How to enable additional logging for the Threat Prevention Admin Console.
+## Overview
+This article describes how to enable additional logging for the Threat Prevention Admin Console.
 
 ## Instructions
-There are two options for enabling additional logging:
+There are two options: edit the log config file directly on the SI management server, or update the log level from within the Admin Console.
+
+> **NOTE:** Version 8.1 changed the logging engine used by the Admin Console, so the `SIWinConsole.log.config` file has a different format. In version 8.1 and later:
+>
+> - The root element is `<nlog>` instead of `<log4net>`, and the `minlevel` attribute on a `<logger>` rule sets the log level rather than a `<level>` element.
+> - Saving the file applies the change immediately. Restarting the Admin Console is not necessary.
+> - Option 2 writes a log level back to the configuration file, so it survives a restart.
 
-### Option one
+### Option 1
 1. Access the SI management server.
 2. Open the Enterprise Manager installation folder. The default location is `...\STEALTHbits\StealthINTERCEPT\SIWinConsole`.
 3. Edit the file called `SIWinConsole.log.config` in your favorite text editor.
-4. Change `WARN` to `DEBUG` in the following portion of that file:
-
-```
-
-```
+4. Change `WARN` to `DEBUG` in the file, then save the config file and restart the Threat Prevention Admin Console.
 
-5. Save the config file and restart the Threat Prevention Admin Console.
-
-### Option two
-1. Open the Threat Prevention Admin Console on the SI management server.
+### Option 2
+1. Open the **Threat Prevention Admin Console** on the SI management server.
 2. Select **Agents**.
-3. Click on the Pencil icon at the top left of the window.
+3. Click the **Pencil** icon at the top left of the window.
 4. Change the drop-down under **Administration Console** to `DEBUG`.
-5. Click the **Update Log Levels** button.
+5. Click the **Update Log Levels** button to apply the change.
 
 After collecting debug logs switch Threat Prevention Admin Console logging back to `WARN`.
-
-## Module
-SI - Admin Console
-
-## Salesforce Article ID
-000001063