Release/auditor 10.9 u1

[Denis-A-Netwrix]

Co-Authored-By: Claude claude-sonnet-5 noreply@anthropic.com
Co-Authored-By: Claude Code ai@netwrix.com

[github-actions]

Documentation PR Review

Editorial Review

docs/auditor/10.9/admin/monitoringplans/azurefiles.md

• Completeness — Lines 25, 26, 77, 78: These four links were updated from 10_8 to 10.9, but they are the only absolute links in all of docs/auditor/10.9/ that use the dotted version form without a .md extension. Every other absolute link in this version either ends in .md (resolved as a file path) or uses the underscore URL form (10_9). As written, these resolve to a URL path that doesn't exist, since routes convert dots to underscores. Suggested fix: add the extension — /docs/auditor/10.9/admin/settings/auditdatabase.md, /docs/auditor/10.9/admin/settings/notifications.md, /docs/auditor/10.9/admin/reports/overview.md, /docs/auditor/10.9/admin/alertsettings/create.md.
• Clarity — Line 52: The added text now says "Enabling this option on public shares generates a high volume of events on Azure Files and increases the amount of data written to the Long-Term Archive," and the Note two lines below (line 54) repeats the same warning: "Enabling read access auditing on public shares may generate high event volume." The reader reads the same caution twice, with two different hedges ("generates" vs. "may generate"). Suggested fix: keep the detail in the bullet and delete the redundant Note, or keep the Note and trim the bullet to "Failed - Use this option to detect unauthorized attempts to read your data."
• Completeness — Line 66: The new Step 4: Configure Exclusions (optional) section replaced the former "Step 5: Test Connection" section, but "Next Steps" (line 76) still tells the reader to "Verify data collection is working" with no procedure and no link. The removed step was the only place that explained how to verify Microsoft Entra ID authentication, storage account access, and audit log collection. Suggested fix: restore a short verification step (or link to an existing verification topic) so the "Verify data collection" instruction is actionable.
• Structure — Lines 66–71: Step 3 ends with "7. Click Save" (line 64), and Step 4 then instructs the reader to work on "the item's Scope tab" — but nothing tells them how to get there after saving, and the item was last touched back in Step 2. Suggested fix: open Step 4 with a navigation sentence, for example "Select the monitored item in the plan, click Edit item, and open the Scope tab." Then describe the two item types.
• Clarity — Line 71: "exclude specific shares, folders, or files (Universal Naming Convention (UNC) paths)" nests parentheses inside parentheses, which is hard to parse. Suggested fix: "use the Omit List to exclude specific shares, folders, or files by Universal Naming Convention (UNC) path."

docs/auditor/10.9/admin/monitoringplans/datasources.md

• Clarity — Line 135: "In group/Not in group filters don't not process groups from omitted OUs" contains a double negative that reverses the intended meaning. Suggested fix: "In group/Not in group filters don't process groups from omitted OUs."
• Structure — Lines 134–155: The "Use case" column is now half-converted. Some rows are imperative instructions ("Omit all activity by a specific service account…", "Exclude specific computers within an IP range…", "Track whether the corp\administrator user is changing SQL data."), while others remain narrative scenarios ("A Security Officer wants to monitor a file share but s/he doesn't have access…", "If Netwrix user is responsible just for a limited scope…"). A reader scanning the column can't tell whether a cell describes their situation or tells them what to do. Suggested fix: make the whole column one form — scenarios read best under a "Use case" heading, e.g. "A security officer monitors a file share but has no access to one folder on it and doesn't want the product to monitor that folder."
• Clarity — Lines 140, 141, 142: These modified rows keep "s/he," which isn't a construction the style guide uses. Suggested fix: use "they" — "A security officer wants to monitor a file share but doesn't have access to a certain folder on this share, and doesn't want the product to monitor that folder at all."
• Clarity — Lines 139, 152: ".Net 4.5" should be ".NET 4.5" (Microsoft's capitalization). Both rows were touched in this PR.
• Clarity — Line 117: "The following section contains examples on how to use omit functionality in Auditor" — what follows is a table, not a section, and "omit functionality" is vague on first mention. Suggested fix: "The following table lists common exclusion scenarios and links to the topic that explains how to configure each one."

docs/auditor/10.9/admin/monitoringplans/useractivity/monitoredcomputers.md (new file)

• Completeness — Line 35: The Status column is described only as "A consolidated status indicator for the computer," yet Status is the column the whole page is built around: the intro promises you can "identify issues quickly," and the filter section (line 44) tells you to "Select one or more statuses from the dropdown list." The reader never learns what the possible statuses are or what to do about each one. Suggested fix: add a table of the actual status values with a description and recommended action for each, for example: Working — data collection is healthy; Warning — collection succeeded with issues; Error — collection failed, review the System Health log.
• Completeness — Line 9: The intro promises the reader can "drill into diagnostic details without leaving the interface," and the screenshot at line 25 is captioned "details for a selected computer," but no section explains what those details are or how to open them. Suggested fix: add a "Computer details" section describing what appears when you select a computer, and which fields help diagnose a failing host.
• Structure — Lines 11–21: The ## Overview section comes after the "To access the Monitored Computers tab" procedure, which inverts the standard order (overview → prerequisites → procedures). Suggested fix: move the Overview content up so it directly follows the H1 intro, and put the three access steps after it.
• Structure — Line 23: **NOTE:** should be an admonition block in a new file. Suggested fix:

  :::note
  The Monitored Computers tab doesn't display computers that you exclude from monitoring with the **Exclude these objects** or **Exclude subranges** setting in the item settings.
  :::

• Clarity — Line 36: "The timestamp of the last time the service interacted with the computer" — "the service" hasn't been introduced anywhere on the page, so the reader doesn't know which component this refers to. Suggested fix: name it explicitly, e.g. "the last time the Netwrix Auditor User Activity Core Service contacted the computer."
• Completeness — Line 54: "Click Export above the grid to save the displayed computers to a file" doesn't say what kind of file, so the reader can't tell whether they can open it in Excel or feed it to a script. Suggested fix: name the format (for example, CSV).
• Clarity — Lines 13, 15, 17: The step labels are formatted **Step 1** – while the rest of the Auditor documentation uses **Step 1 –** (dash inside the bold). Suggested fix: match the existing convention.

docs/auditor/10.9/admin/monitoringplans/useractivity/overview.md (renamed from overview_1.md)

• Completeness — Line 38: This is the "Monitored Computers" row, and it's the natural place for a reader configuring the data source to learn more — but it doesn't link to the new monitoredcomputers.md topic added in this PR. As it stands, the new page is reachable only from the sidebar. Suggested fix: append "See the Monitored Computers topic for details on the grid columns, filtering, and export."
• Clarity — Line 91: "After you configure the product to collect data from the specified items, it applies audit settings (including Core and Compression services installation) to all computers within the AD Container or IP Range." This sentence sits under the ## Computer heading but describes AD Container and IP Range behavior, so a reader following the Computer item type is told something that doesn't apply to their item. Suggested fix: move the sentence to an intro paragraph above the three item-type headings, where it applies to all of them.

docs/auditor/10.9/admin/settings/longtermarchive.md

• Clarity — Lines 31, 32: Three sentences begin with a lowercase "ensure" mid-cell: "…produces additional load on it. ensure the specified shared folder has enough capacity…" and "…to the specified shared folder. ensure the account has at least the Write permission…". Suggested fix: capitalize — "Ensure the specified shared folder has enough capacity to store the video files." and "Ensure the account has at least the Write permission for that folder."
• Completeness — Line 22: "You can grant the custom Long-Term Archive service account the following rights and permissions" reads as optional, but the list that follows is what the account needs in order to work. A reader can't tell whether to skip it. Suggested fix: state the requirement directly — "Grant the custom Long-Term Archive service account the following rights and permissions:".
• Clarity — Line 31: The rewrite converted most of this cell to active voice but left "Auditor will not automatically move session recordings to a new location" at the end, alongside the newly active "Netwrix Auditor will store." Suggested fix: "…be aware of possible data loss, because Auditor doesn't move existing session recordings to the new location."

docs/auditor/10.9/api/prerequisites.md

• Clarity — Line 17: "On this page, you can view the current port settings and restrictions on the TLS (Transport Layer Security) version…" — "this page" is ambiguous: the reader can't tell whether it means this documentation topic or a page in the product, and the sentence appears before the step that tells them where to go. Suggested fix: "The Integration page in Netwrix Auditor shows the current port setting and the minimum TLS (Transport Layer Security) version allowed for encrypted connections." Then start the numbered steps.
• Completeness — Line 23: "Select the minimum TLS version from the list. For a new installation, this defaults to 1.2." The reader isn't told which versions the list offers, and calling out the new installation default implies upgrades behave differently without saying how. Suggested fix: list the selectable versions and state the upgrade behavior, e.g. "Select the minimum TLS version from the list. Netwrix Auditor supports 1.0, 1.1, and 1.2. New installations default to 1.2; upgrades keep the value from the previous version."
• Structure — Lines 34–37: The requirement ("Netwrix Auditor Integration API requires a configured Audit Database.") comes after the instruction to go check the setting. A reader who doesn't know the API depends on the Audit Database has no reason to follow the instruction yet. Suggested fix: move line 37 above line 34 so the requirement introduces the action.
• Clarity — Line 9: Expanding "HTTPS (Hypertext Transfer Protocol Secure)" adds noise for IT administrators and security analysts, who don't need this term defined. Suggested fix: leave HTTPS unexpanded and keep the expansion for TLS, which does carry version-specific meaning here.
• Structure — Lines 15, 28: The headings were changed to sentence case ("Configure Integration API settings", "Configure Audit Database settings") while sibling topics in docs/auditor/10.9/ still use title case ("Configure Monitoring Scope and Actions", "Add Items for Monitoring"). This shows up as an inconsistency in the on-page table of contents. Suggested fix: keep title case to match the rest of the version, or make the change consistently across the API section.

docs/auditor/10.9/api/security.md

• Completeness — Line 46: The new "Set the minimum TLS version" row shows minTlsVersion= 1.2 as an example but doesn't say which values the command accepts, what the default is, or that the parameter is mandatory — and it's the one row in the table with no closing period. prerequisites.md says the default is 1.2 for new installations; this row doesn't. Suggested fix: "APIAdminTool.exe api https minTlsVersion Sets the minimum TLS (Transport Layer Security) version accepted for connections. The minTlsVersion parameter is mandatory and accepts 1.0, 1.1, or 1.2 — for example, APIAdminTool.exe api https minTlsVersion= 1.2. New installations default to 1.2."
• Completeness — Lines 48–52: The new "API access permissions" section tells the reader that API access "follows the same role-based permissions as the rest of Netwrix Auditor" and then hands them a generic link. It never says which role a caller needs in order to use the API, or what a lower-privileged role can and can't do — which is the question that brings someone to a section with this title. Suggested fix: name the roles and their API capability, e.g. "Global administrator accounts can write data through the API and read all collected data. Global reviewer accounts can read data only. Reviewer access granted on a monitoring plan limits API reads to that plan's data." Then link to the delegation topic for the configuration steps.
• Clarity — Line 10: "a self-signed automatically generated SSL (Secure Sockets Layer) certificate" — the expansion adds nothing for this audience, and it sits in a topic that (as of line 46) now configures TLS versions, so spelling out the superseded protocol name is actively confusing. Suggested fix: drop the expansion and keep "SSL certificate."

docs/auditor/10.9/configuration/azurefiles/overview.md

• Structure — Line 68: The new Recommendation about using a dedicated application is placed at the end of "Step 1: Create the App Registration," after the reader has already clicked Register. The advice is about whether to create a new app or reuse an existing one — a decision made before step 1. Suggested fix: move it above the "### Step 1: Create the App Registration" numbered steps, directly under the "Register an application so Netwrix Auditor can authenticate to Azure and read audit logs" intro, and format it as a :::tip block to match the documented admonition pattern.
• Clarity — Line 68: "By default, Netwrix Auditor omits its own collection application's activity from auditing — if the collection app is shared with other workloads, that other activity will not be captured." The consequence is buried in a passive clause and the possessive chain ("its own collection application's activity") is hard to follow. Suggested fix: "Netwrix Auditor doesn't audit activity performed by the application it uses for data collection. If you reuse that application for other workloads, Netwrix Auditor omits their activity from reports too."
• Clarity — Lines 107, 116: The table frames Application.Read.All as conditional ("Required when file or folder activity is performed by a service principal rather than a user"), but the step list at line 116 and the checklist at line 251 present it as required alongside the other three permissions. The reader can't tell whether to add it. Suggested fix: pick one and say so explicitly — either "Required" in the step list, or mark it "(required only if service principals access your file shares)" in both the step list and the checklist.

docs/auditor/10.9/configuration/azurefiles/stateintime.md

• Clarity — Line 36: "If you don't provide credentials, report output remains identical to earlier versions — this capability is optional and additive." This compares against "earlier versions," which is release-note framing; a reader on the 10.9 docs has no baseline to compare against, and "optional and additive" is internal vocabulary. Suggested fix: "If you don't provide credentials, Netwrix Auditor resolves identities from cloud data only, and permission reports show unresolved SIDs for on-premises accounts."
• Clarity — Line 43: "(The Learn more… link on this tab points to this section.)" tells the reader something about the documentation rather than about the task, and it interrupts an eight-step procedure. Suggested fix: delete it.
• Clarity — Line 45: "Use the format domain\user or user@domain.local" uses literal sample values where placeholders belong; the style guide calls for angle brackets. Suggested fix: "Use the format <domain>\<user> or <user>@<domain-fqdn> — for example, CONTOSO\svc-auditor or svc-auditor@contoso.local."
• Completeness — Line 45: "enter an AD account with read access to Active Directory" doesn't say what read access means concretely, so an administrator can't provision the account before starting. Suggested fix: state the requirement, e.g. "The account needs read access to the user, group, and computer objects in the domains whose identities appear in your Azure Files permissions. Membership in Domain Users is sufficient in a default configuration."
• Clarity — Lines 5, 31: "Entra ID accounts" appears before the full product name; the same sentence at line 5 then uses "Microsoft Entra ID." Suggested fix: use "Microsoft Entra ID" on first mention in both places.
• Clarity — Line 40: The new procedure uses "Configuration → Monitoring Plans" while the rest of the Auditor documentation uses > as the navigation separator (for example, "Settings > Long-Term Archive"). Suggested fix: use "Configuration > Monitoring Plans".
• Structure — Lines 5, 27, 49: This file uses > **Note:** blockquotes throughout, including on the lines changed and added in this PR, rather than the :::note admonitions the documentation standard specifies. Suggested fix: convert the notes touched by this PR to :::note blocks. Separately, this file has no frontmatter (title, description, sidebar_position) — worth adding now that this PR makes it a link destination from two other topics.

docs/auditor/10.9/tools/passwordexpirationnotifier/gmsa.md (new file)

• Completeness — Line 44: "Password Expiration Notifier creates a Windows scheduled task that runs the data collection under the NT AUTHORITY\SYSTEM account. The scheduled task performs the actual data collection and sends the notifications." A reader who just configured a gMSA specifically to be the data collecting account will immediately ask why the task runs as SYSTEM, and whether the gMSA is used at all. Suggested fix: close the loop — explain that the scheduled task starts as SYSTEM and then impersonates the gMSA to query Active Directory (or whatever is accurate), so the gMSA is still the identity that reads AD.
• Completeness — Lines 48–50: The warning says the Select OUs, Select Groups, and Generate buttons don't work with a gMSA, but a reader who needs OU or group filtering (documented as a supported option on the overview page) is left with no way to configure it. Suggested fix: give them the path — for example, configure the OU and group filters with a standard user account first, then switch the User name field to the gMSA, and note that the saved filters continue to apply.
• Clarity — Line 11: This is a single sentence carrying four distinct prerequisite tasks (KDS root key, New-ADServiceAccount, Install-ADServiceAccount, local Administrators membership). A reader can't check them off while reading. Suggested fix: introduce the list and break it out:

  Before you specify a gMSA in a monitoring plan, complete the general gMSA prerequisites that apply to every Auditor data source:
  
  - Create the Key Distribution Services (KDS) root key.
  - Create the gMSA with the `New-ADServiceAccount` cmdlet.
  - Install the gMSA on the Auditor Server with `Install-ADServiceAccount`.
  - Add the gMSA to the local **Administrators** group on the Auditor Server.
  
  See the [Use Group Managed Service Account (gMSA)](/docs/auditor/10.9/requirements/gmsa.md) topic for the full procedure.

• Structure — Line 4: sidebar_position: 5 places this new topic first in the Password Expiration Notifier folder — ahead of the overview (50), Ports (10), and Monitoring Scope (20). A reader opening the tool's documentation lands on a gMSA configuration topic before the overview that explains what the tool does. Suggested fix: set sidebar_position: 30 so the order runs overview → ports → monitoring scope → gMSA, or renumber the overview to 1.
• Clarity — Line 59: "See the Limitations section." is a bare cross-reference in a Resolution cell. Suggested fix: make it a link — "See Limitations."
• Clarity — Line 40: "Active Directory manages the password, so there is nothing to enter." Suggested fix: "Active Directory manages the password, so you don't need to enter one."

docs/auditor/10.9/tools/passwordexpirationnotifier/overview.md

• Clarity — Lines 64, 65, 66: Three cells contain a sentence beginning with a lowercase "ensure": "…and select an account. ensure this account has a password that expires…". Suggested fix: capitalize to "Ensure this account has a password that expires within the period you specified next to this option."
• Clarity — Line 82: "The option isn't available for auditing User Activity as well Netwrix Auditor tools" is missing a word. Suggested fix: "This option isn't available for auditing User Activity or for Netwrix Auditor tools."
• Clarity — Lines 11–12: "It also generates summary reports that it can deliver to system administrators and/or users' managers." The relative clause makes the sentence circle back on itself, and "and/or" is imprecise. Suggested fix: "It also emails summary reports to system administrators, users' managers, or both."
• Clarity — Line 96: "include data on expiring domain accounts in addition to expiring passwords information" — "expiring passwords information" is an awkward noun stack. Suggested fix: "Select this option to include expiring domain accounts in reports, in addition to expiring passwords."
• Completeness — Line 66: This row is about accounts expiring, but the added text still tells the reader to verify the test account has "a password that expires within the period you specified." Suggested fix: "Ensure this account expires within the period you specified next to this option."

Summary

38 editorial suggestions across 11 files. The highest-impact items: four version links in azurefiles.md that don't follow the repo's link convention and won't resolve, the removed Test Connection step that leaves "Verify data collection is working" unactionable, the missing status-value reference in the new monitoredcomputers.md, the SYSTEM-vs-gMSA gap in the new gmsa.md, and several lowercase "ensure" sentence starts in longtermarchive.md and passwordexpirationnotifier/overview.md left behind by an automated rewrite. Vale and Dale issues are auto-fixed separately.

---

What to do next:

Comment @claude on this PR followed by your instructions to get help:

• @claude fix all issues — fix all editorial issues
• @claude help improve the flow of this document — get writing assistance
• @claude explain the voice issues — understand why something was flagged

You can ask Claude anything about the review or about Netwrix writing standards.

Automated fixes are only available for branches in this repository, not forks.

[github-actions]

Auto-Fix Summary

27 issues fixed, 12 skipped across 11 files

Category	Fixes
Contractions	3
Plurals	1
Dale: minimizing-difficulty	1
Dale: misplaced-modifiers	2
Dale: passive-voice	14
Dale: positional-references	2
Dale: wordiness	3
Dale: xy-slop	1

Skipped (needs manual review)	Reason
docs/auditor/10.9/api/prerequisites.md:20 — Netwrix.Idioms	'Leverage' is part of the literal product UI label Leverage Integration API (a switch in the Netwrix Auditor Integration tile), used consistently across auditor 10.6/10.7/10.9 docs and KB articles. Rewording would make the instruction inaccurate and prevent readers from locating the option.
docs/auditor/10.9/configuration/azurefiles/stateintime.md:43 — Netwrix.WeakLinkText	'Learn more' is not Markdown link text here; it names a link element in the product UI on the Active Directory Integration tab ('The Learn more... link on this tab points to this section.'). Renaming it would misidentify the UI control the reader sees.
docs/auditor/10.9/admin/monitoringplans/datasources.md:28 — Dale: positional-references	"the row right under the blue table header" describes physical UI layout in the product, not a reference to other documentation content
docs/auditor/10.9/admin/monitoringplans/datasources.md:87 — Dale: passive-voice	"all shares stored in the specified location" — reduced relative clause with no clear agent; rewriting risks asserting who stores the shares
docs/auditor/10.9/admin/monitoringplans/useractivity/overview.md:101 — Dale: passive-voice	"the default account used for data collection" is a standing noun phrase repeated across several Auditor topics; rewriting only this instance would break consistency
docs/auditor/10.9/api/prerequisites.md:17 — Dale: passive-voice	"the TLS version used for encrypted connections" — reduced relative clause; the agent (product or client) is ambiguous
docs/auditor/10.9/api/security.md:9 — Dale: passive-voice	"a new secured certificate acquired from any reliable source" — the reader is the implied actor but the sentence already has "you" as subject of "replace"; rewording would make it clumsier without clear benefit
docs/auditor/10.9/configuration/azurefiles/overview.md:250 — Dale: passive-voice	Checklist items ("Azure Application registered", "IAM roles assigned") intentionally mirror the section headings they link to; rewriting would desynchronize link text from headings
docs/auditor/10.9/configuration/azurefiles/stateintime.md:5 — Dale: passive-voice	"on-premises AD groups that aren't synced to Microsoft Entra ID" — the sync agent is typically Entra Connect, not the reader; naming an actor could be inaccurate
docs/auditor/10.9/configuration/azurefiles/stateintime.md:87 — Dale: xy-slop	"supports only blob storage as the destination, not Event Hub or Log Analytics Workspace" is a factual limitation statement, not the negative-positive rhetorical pattern the rule targets
docs/auditor/10.9/tools/passwordexpirationnotifier/gmsa.md:49 — Dale: passive-voice	"when a gMSA is configured" — the same paragraph already ends with the active phrasing "when the monitoring plan uses a gMSA"; changing this clause would make the paragraph repetitive
docs/auditor/10.9/tools/passwordexpirationnotifier/overview.md:73 — Dale: wordiness	"the monitoring plan you are going to use" is only marginally wordy and the tense conveys a real sequencing point for the reader

Ask @claude on this PR if you'd like an explanation of any fix.

[github-actions]

Code Review

No config, script, or workflow changes in this PR — it's docs + images only, so nothing touches products.js, docusaurus.config.js, sidebars, the KB copy pipeline, or GitHub Actions. No secrets, no executable code. Review below is limited to routing/link correctness (not content or style).

1. Broken links: dotted version number in URL-form links — docs/auditor/10.9/admin/monitoringplans/azurefiles.md lines 25, 26, 77, 78

The version fix from 10_8 → 10.9 went the wrong way on these four links, because they have no .md extension:

- - [Audit database (SQL)](/docs/auditor/10_8/admin/settings/auditdatabase)
+ - [Audit database (SQL)](/docs/auditor/10.9/admin/settings/auditdatabase)

Docusaurus only resolves a link as a markdown file reference when it ends in .md/.mdx. Without the extension these render as literal site URLs — and generated routes use underscores, not dots (versionToUrl() in src/config/products.js:728 does version.replace(/\./g, '_'), so the route base is docs/auditor/10_9). /docs/auditor/10.9/admin/settings/auditdatabase matches no route and 404s for readers. Given onBrokenLinks: 'throw' on the full CI build (npm run ci sets no DOCS_PRODUCT), this may also fail the build.

These are the only four extension-less dotted-version links in the whole docs/ tree — everywhere else uses the .md form, including line 73 of this same file. Suggested fix:

• L25 → /docs/auditor/10.9/admin/settings/auditdatabase.md
• L26 → /docs/auditor/10.9/admin/settings/notifications.md
• L77 → /docs/auditor/10.9/admin/reports/overview.md
• L78 → /docs/auditor/10.9/admin/alertsettings/create/create.md

Note on L78 specifically: admin/alertsettings/create/ is a category directory whose only doc is create.md, and its _category_.json uses link: {type: doc, id: create} — so there is no route for the bare directory path either way. The .md form above is the correct target.

2. Wrong-version (10.8) links inside 10.9 pages — pre-existing, but in files this PR edits

• docs/auditor/10.9/configuration/azurefiles/stateintime.md:9 and :85 point at /docs/auditor/10_8/configuration/azurefiles/overview..., while lines 117–118 of the same file already link to the 10.9 equivalents. These resolve (10.8 exists) so the build won't complain, but readers get sent back a version.
• docs/auditor/10.9/configuration/azurefiles/overview.md:13-14 has four hardcoded https://docs.netwrix.com/docs/auditor/10_8/... absolute links. This PR rewrites the prose on line 13 but leaves the version. Worth converting these to relative .md links to the 10.9 pages while the lines are already being touched.

3. Minor: renamed page leaves a live 404

overview_1.md → useractivity/overview.md retires the published URL /docs/auditor/10_9/admin/monitoringplans/overview_1 (10.9 is isLatest: true). The plugin-client-redirects config only strips the version prefix — there's no per-page redirect mechanism in this repo — so external/bookmarked links to the old path will 404. Flagging for awareness; may be acceptable.

4. Minor: stateintime.md has no frontmatter

docs/auditor/10.9/configuration/azurefiles/stateintime.md starts directly with # Configuring State-in-Time... — no title, description, or sidebar_position. Pre-existing, and Docusaurus infers the title from the H1, so it builds; but the page gets no meta description and falls back to default sidebar ordering while every sibling sets one explicitly. Since this PR adds a whole new section to the file, a good moment to add frontmatter.

---

Verified clean

• Rename handled completely. Both inbound references to overview_1.md in 10.9 were updated (monitoringplans/datasources.md:52, admin/settings/longtermarchive.md); no stale overview_1 references remain anywhere under docs/auditor/10.9/. The 10.6–10.8 copies still reference their own overview_1.md and are correctly untouched.
• New useractivity/_category_.json is correct. Matches repo convention, link.id: "overview" resolves to the co-located overview.md, and position: 180 both preserves the old sidebar_position: 180 slot and doesn't collide with any sibling category (40–200 in steps of 10). Sidebars are type: autogenerated, so no sidebar file edits were needed.
• All new/changed anchors resolve: datasources.md#add-items-for-monitoring, stateintime.md#configuring-the-monitoring-scope-omit-lists, passwordexpirationnotifier/overview.md#configure-password-expiration-alerting, and configuration/azurefiles/overview.md#{azure-application-registration,configure-api-permissions,diagnostic-settings}.
• All new link targets exist: admin/monitoringplans/delegation.md, requirements/gmsa.md, tools/passwordexpirationnotifier/gmsa.md, configuration/azurefiles/stateintime.md.
• Removing the ### Step 5: Test Connection heading breaks nothing — no page anywhere links to that anchor.
• Heading case changes in api/prerequisites.md (Settings → settings) don't change the generated slugs, so existing anchor links still resolve.
• Images: both new useractivity/*.webp files exist at their referenced paths. The replaced static/images/auditor/10.9/addon/connectwise/integrations_thumb_0_0.webp is referenced only by docs/auditor/10.9/api/prerequisites.md — 10.9/addon/connectwise/msp.md points at the 10.7 copy — so the swap can't regress another page.