Epp 20260909

[krzysztofstaszalek]

Updates:

• Windows Intune guide
• JAMF guide
• Migration procedure update, specifying details "disable Client communication"
• Debug log gathering

[github-actions]

Code Review

Scope check first: this PR touches only markdown and .webp assets under docs/endpointprotector/. There are no changes to src/config/products.js, docusaurus.config.js, sidebars, scripts/, or .github/workflows/, so nothing here can affect plugin generation, routing, the KB copy pipeline, or CI permissions/secrets.

Build-safety checks (all pass)

• Renamed headings — Debug Logging Usage to Debug Logging Activation and Debug Logging Actions to Getting Debug Logs via EPP Server in globalsettings.md, plus Temporarily Disabling Client Communications to Blocking Client Connectivity to the New Server and Re-Enabling Client Communications to Restoring Client Connectivity in both migration docs. I grepped the repo for the old anchor slugs (debug-logging-usage, debug-logging-actions, temporarily-disabling-client-communications, re-enabling-client-communications) — no inbound links. Since broken anchors throw at build time, this was the main risk and it is clear. The in-page data-obfuscation-rules link and the debug-logging anchor used by several KB articles are both unaffected.
• Deleted image — intune/msipackage.webp is removed along with its only reference. No other file references it.
• New images — jamf/vpnsettings2.webp, jamf/notificationsettings2.webp, and jamf/managedloginitems.webp are all committed and correctly referenced by relative path.
• New cross-link — /docs/endpointprotector/admin/ee_module/eemodule.md resolves.
• MDX safety — the one angle-bracket placeholder in new content (the AppData\Local\Temp\epp_logs path with a <username> segment) sits inside a code span, so it will not be parsed as JSX.
• Section move — Managed Login Items moved from an h3 under System Extension Settings to a top-level h2. The anchor slug is unchanged, and nothing links to it.

No security concerns: the added commands are vendor-supplied local diagnostic scripts with no injectable user input, and no credentials or endpoints are exposed.

Two logic issues worth a look

1. docs/endpointprotector/install/jamf/configuration.md — contradictory save instructions

The General Settings note was tightened to "Click Save only after you have managed all settings and the profile scope" (line 27), but the same PR adds "Step 5 – Save the changes." to the Certificate Settings section (line 64), mid-profile. Following one instruction means violating the other. Either soften the note back, or drop the intermediate save.

2. docs/endpointprotector/install/jamf/configuration.md — moved Managed Login Items section now describes two conflicting procedures

Lines 249-257 tell the reader to log in to Jamf, click New, and create a new configuration profile with Managed Logged In Items. Then line 268 says "On the Managed Login Items section, click Configure..." — the pattern every other section on this page uses for the existing profile. As written, the reader cannot tell whether the Team Identifier / Rule Value settings belong to the new profile from steps 5-9 or to the profile they have been building since the top of the page.

Related: the "Step 5 ... Step 9" numbering in that block is orphaned — nothing in the section establishes steps 1-4. This was already true before the move, but promoting the block to a top-level h2 makes it more conspicuous, and the section is being edited here anyway.

Neither issue blocks the build. Everything else looks correct.