sync: auto-sync from HOWARD-HOME at 2026-06-02 15:12:52

Author: Howard Enos Machine: HOWARD-HOME Timestamp: 2026-06-02 15:12:52
2026-06-02 15:13:00 -07:00
parent 6e38df75aa
commit 7955e5e8b9
2 changed files with 55 additions and 2 deletions
--- a/clients/lonestar-electrical/session-logs/2026-06-02-session.md
+++ b/clients/lonestar-electrical/session-logs/2026-06-02-session.md
@@ -65,3 +65,53 @@ Because a new USB has a new GUID, the existing license key would not validate ag
 - License transfer/registration: webGUI → Tools → Registration → Replace Key (self-service transfer limited to once per 12 months; LimeTech support for dead-stick reissue).
 - Files on a bootable Unraid stick: `bzimage`, `bzroot`, `bzroot-gui`, `bzmodules`, `bzfirmware` (+ matching `.sha256`), `syslinux/`, `make_bootable*`. The `config/` folder holds array/license state and must be preserved across migrations.
 - Lonestar wiki: `wiki/clients/lonestar-electrical.md`. Syncro customer: `33809612`.
 ## Update: 22:10 PT — LS-1 Sophos removal prep + packetdial sync resurrection
 ### Session Summary
 Resumed the long-pending Sophos Endpoint removal on the Lone Star workstations (the `SophosED.sys` kernel boot driver that blocks every user-mode removal; offline WinRE/PE completion was staged 2026-05-29). Howard has both LS-1 and LS-2 on hand plus a bootable PE. Pulled the exact offline procedure from the 2026-05-29 sophos-removal log and walked it through for LS-1.
 Started with LS-1. Howard booted into normal Windows to verify BitLocker before the offline edit (PE cannot reach `System32` on a locked volume without the recovery key). Confirmed BitLocker is OFF on LS-1, and staged `SophosZap.exe` in Downloads for the post-reboot cleanup. LS-1 was about to boot to PE to run the driver delete + offline-hive service disable. Awaiting the `dir` drive-letter check from PE before greenlighting the `del`.
 Separately, a `/sync` exposed a fleet repo-coordination problem: the `.claude/skills/packetdial/` skill was sitting untracked on HOWARD-HOME, so `git add -A` re-committed it just as Mike's incoming commit `c759f04` ("re-apply consolidation deletions") deleted it. The rebase replayed the add on top of the delete, resurrecting packetdial at HEAD (`dd414c4`) and pushing it back to origin — the exact additive-sync resurrection loop Mike's commit message was fighting (memory files deleted in `0c00010` were resurrected by `sync-memory.sh` on GURU-5070). Flagged to Howard; packetdial is a live, functional skill in the registry, so its deletion inside a memory-consolidation commit may have been collateral. Left the keep/re-delete decision to Mike rather than acting unilaterally.
 ### Key Decisions
 - Verified BitLocker OFF on LS-1 from inside Windows before the PE step, rather than discovering a locked volume at the PE prompt — avoids needing the recovery key mid-procedure.
 - Did NOT unilaterally re-delete the resurrected packetdial skill nor silently keep it; surfaced to the human (Mike's call) because it is a working skill and its deletion may have been unintentional collateral in a memory-cleanup commit.
 - Deferred the broadcast `/self-check` fleet-census request (from GURU-5070) until after the LS-1 field work, rather than interrupting the active ticket.
 ### Problems Encountered
 - **Push race during sync.** First `sync.sh` push rejected ("fetch first") because the remote advanced between fetch and push. Resolved by re-running sync (fetch + rebase + push succeeded: `c759f04..dd414c4`).
 - **packetdial skill resurrection.** Untracked local files re-added by additive sync, undoing Mike's deletion. Surfaced for Mike's decision; not yet resolved.
 ### Configuration Changes
 - `.claude/skills/packetdial/` (SKILL.md, references/api.md, scripts/ns.py, scripts/ns_client.py) re-added to repo at `dd414c4` (UNINTENTIONAL resurrection — pending Mike's keep/delete decision).
 - Pulled in from fleet: `.claude/skills/self-check/` + `.claude/commands/self-check.md` (Mike), guru-connect/gururmm submodule bumps, memory consolidation deletions.
 ### Infrastructure & Servers
 - **LS-1, LS-2** — Win11 workstations, Lone Star Norris site. BitLocker confirmed OFF on LS-1. Sophos removal blocked by `SophosED.sys` kernel boot driver (`Start=0`).
 - Service to disable in offline hive: `Sophos Endpoint Defense` (set `Start=4`).
 ### Commands & Outputs
 - Offline removal (run in PE, substitute real Windows drive letter for `D:`):
  - `del /f D:\Windows\System32\drivers\SophosED.sys`
  - `reg load HKLM\TEMPSYS D:\Windows\System32\config\SYSTEM`
  - `reg add "HKLM\TEMPSYS\CurrentControlSet\services\Sophos Endpoint Defense" /v Start /t REG_DWORD /d 4 /f`
  - `reg unload HKLM\TEMPSYS`
  - reboot normal, then `SophosZap.exe --confirm`
 - Drive-letter discovery in PE: `dir C:\Windows & dir D:\Windows & dir E:\Windows`
 - BitLocker check (normal Windows, elevated): `manage-bde -status`
 ### Pending / Incomplete Tasks
 - **LS-1:** boot PE, confirm Windows drive letter, run offline SophosED.sys removal, reboot, `SophosZap --confirm`. Awaiting drive-letter check.
 - **LS-2:** same offline procedure, not yet started.
 - **Syncro ticket** "Sophos Endpoint Removal - LS-1 and LS-2": verify it exists / create, then log time (prepaid block, live-check `GET /customers/33809612`).
 - **packetdial resurrection:** Mike to decide keep vs. re-delete; offered to send a coord message to him.
 - **Fleet `/self-check`:** run on HOWARD-HOME after field work, apply fixes, re-run to GREEN, then `/self-check --publish`.
 - Vault + document the Lonestar Unraid server (root pw, hostname, IP, license type).
 ### Reference Information
 - Coord handoff: msg `689cfb7c` (2026-06-01, Sophos removal to Howard).
 - Mike's deletion commit: `c759f04` "chore(memory): re-apply consolidation deletions + lift additive-only constraint".
 - HEAD after sync: `dd414c4`.
 - Full LS-1/LS-2 offline procedure: `clients/lonestar-electrical/session-logs/2026-05-29-sophos-removal.md`.
--- a/wiki/clients/lonestar-electrical.md
+++ b/wiki/clients/lonestar-electrical.md
@@ -92,7 +92,7 @@ Electrical contractor in Tucson, AZ. ACG-managed client. Distinctive in the flee
 ## Patterns & Known Issues
- **Inherited Sophos with no Central access — kernel-driver tamper-protection removal (in progress 2026-05-28/29).** LS-1 and LS-2 came from the previous MSP running Sophos Endpoint Protection managed via the previous MSP's Sophos Central account — ACG has **no Central access**, so no remote uninstall and no way to disable tamper protection from the management plane. Tamper protection is enforced by the **`SophosED.sys` kernel boot driver** (`Start=0`, loads before `smss.exe`), which defeats every user-mode removal: `SophosZap` (blocked by TP), `SophosUninstall.exe` (only removes user-mode parts), `PendingFileRenameOperations` delete (driver loads too early), `sc config` (kernel callback), and ACL reset (kernel-level). **Resolution path is offline via WinRE:** delete `D:\Windows\System32\drivers\SophosED.sys`, load the offline SYSTEM hive and set the `Sophos Endpoint Defense` service `Start=4`, reboot, then `SophosZap.exe --confirm` (TP check now passes). Full step list in the 2026-05-29 session log. **Reusable for any inherited-MSP Sophos/CrowdStrike/SentinelOne removal where tamper protection is enforced and the management console is inaccessible.** (Related: GuruRMM SPEC-015 safeboot-network-registration aims to automate exactly this remote-Safe-Mode removal flow.)
+- **Inherited Sophos with no Central access — kernel-driver tamper-protection removal (execution started 2026-06-02).** LS-1 and LS-2 came from the previous MSP running Sophos Endpoint Protection managed via the previous MSP's Sophos Central account — ACG has **no Central access**, so no remote uninstall and no way to disable tamper protection from the management plane. Tamper protection is enforced by the **`SophosED.sys` kernel boot driver** (`Start=0`, loads before `smss.exe`), which defeats every user-mode removal: `SophosZap` (blocked by TP), `SophosUninstall.exe` (only removes user-mode parts), `PendingFileRenameOperations` delete (driver loads too early), `sc config` (kernel callback), and ACL reset (kernel-level). **Resolution path is offline via WinRE/PE:** delete `D:\Windows\System32\drivers\SophosED.sys`, load the offline SYSTEM hive and set the `Sophos Endpoint Defense` service `Start=4`, reboot, then `SophosZap.exe --confirm` (TP check now passes). Full step list in the 2026-05-29 session log. **Reusable for any inherited-MSP Sophos/CrowdStrike/SentinelOne removal where tamper protection is enforced and the management console is inaccessible.** (Related: GuruRMM SPEC-015 safeboot-network-registration aims to automate exactly this remote-Safe-Mode removal flow.)
 - **Sophos shell extensions + Datto Cloud Continuity startup conflict (LS-2).** Presented as unresponsive desktop mouse clicks (until Ctrl+Alt+Del) and dead Start-menu right-click. Root cause: Sophos shell extensions competing with the Datto Cloud Continuity `/pop` startup entry during logon. Removing the Datto startup registry entry addressed the logon contention.
 - **ManageEngine + Google Workspace dual-EMM trap (resolved 2026-03-24).** A personal phone repeatedly prompted for MDM enrollment when the user added their Lonestar Google account. Root cause was **two independent triggers**: (1) ManageEngine MDM self-enrollment was enabled for all directory groups, AND (2) ManageEngine was configured as a **third-party EMM provider inside Google Workspace** (Devices > Mobile & endpoints > Settings > Third-party integrations). The Google integration enforces enrollment on any device that adds a Lonestar account — independent of ManageEngine's own self-enrollment setting. **Fix required both:** disable ManageEngine self-enrollment (Enrollment > Self Enrollment > Disable) AND remove ManageEngine as the third-party EMM in the GWS Admin Console. Disabling only one leaves the prompt in place. Company tablets enrolled directly via QR code are unaffected by either change.
 - **Google Workspace, not M365.** Reach for GWS Admin Console + the ACG-MSP-Access service account for identity work. The M365 remediation-tool app suite does not apply to this client.
@@ -105,7 +105,8 @@ Electrical contractor in Tucson, AZ. ACG-managed client. Distinctive in the flee
 No open Syncro tickets as of 2026-06-01.
- **Sophos removal on LS-1 / LS-2 (IN PROGRESS).** `SophosED.sys` kernel boot driver still present and active on both machines; most user-mode Sophos services removed from LS-2. Offline WinRE completion step pending on both (delete driver, disable SED service in offline hive, reboot, `SophosZap --confirm`). Handed off to Howard via coord message `689cfb7c` (2026-06-01). A Syncro ticket "Sophos Endpoint Removal - LS-1 and LS-2" was drafted — verify it exists before logging time.
+- **Sophos removal on LS-1 / LS-2 (ACTIVELY EXECUTING — LS-1 in progress, LS-2 not yet started).** Offline PE removal procedure is underway on LS-1: BitLocker confirmed OFF (verified from normal Windows before booting PE), `SophosZap.exe` staged in Downloads for post-reboot cleanup. LS-1 is awaiting a drive-letter check from PE (`dir C:\Windows & dir D:\Windows & dir E:\Windows`) before executing the `del /f <drive>\Windows\System32\drivers\SophosED.sys` + offline-hive `Start=4` disable sequence. LS-2 not yet started. Full offline command set in `clients/lonestar-electrical/session-logs/2026-05-29-sophos-removal.md`. Coord handoff: msg `689cfb7c` (2026-06-01).
  - **Pending:** Verify or create Syncro ticket "Sophos Endpoint Removal - LS-1 and LS-2" before logging time (prepaid block, live-check `GET /customers/33809612`).
 - **Unraid server USB replacement done (2026-06-02); PENDING:**
  - Create Syncro ticket documenting the USB failure, replacement (Unraid 7.1.4 via USB Creator), config copy, and license re-registration.
  - Capture and fold in the results of Mike's server health check (array start state, disk assignments, parity validity, registration status).
@@ -128,11 +129,13 @@ No open Syncro tickets as of 2026-06-01.
 | 2026-05-28/29 | Sophos removal on LS-1/LS-2 begun: enrolled in GuruRMM, removed Datto startup conflict (LS-2), registered Safe Mode agents, removed user-mode Sophos; blocked by `SophosED.sys` kernel driver — WinRE offline removal staged (Ventoy USB), completion pending |
 | 2026-06-01 | Recovered the (previously unlogged) Sophos removal context, reconstructed it into a session log, and handed the WinRE completion procedure to Howard via coordinator (msg `689cfb7c`) |
 | 2026-06-02 | Unraid server USB flash drive failed (recurring bzfirmware checksum error); migrated to new stick (Unraid 7.1.4 via USB Creator), copied old config/, re-registered license to new GUID |
 | 2026-06-02 | Began offline (PE) execution of Sophos removal on LS-1 — BitLocker confirmed off, SophosZap staged; SophosED.sys delete + offline-hive disable pending drive-letter check |
 ---
 ## Compilation Notes
 - Refreshed 2026-06-02 22:10 PT (recompile by HOWARD-HOME/claude-main) to absorb the 22:10 PT update section of the 2026-06-02 session log: updated Active Work Sophos bullet to reflect execution-in-progress on LS-1 (BitLocker confirmed off, SophosZap staged, awaiting drive-letter check before PE delete); updated Patterns wording from "in progress 2026-05-28/29" to "execution started 2026-06-02"; added History Highlights row for the LS-1 PE execution start.
 - Refreshed 2026-06-02 (recompile by HOWARD-HOME/claude-main) to absorb the 2026-06-02 session log: added Unraid server infrastructure subsection, new `bzfirmware` checksum pattern, history row, and pending Active Work items.
 - Refreshed 2026-06-01 (full recompile) to incorporate the 2026-05-28/29 Sophos removal work, which had previously been lost — it was never written to a session log and survived only in a gitignored temp draft (`.claude/tmp/ollama_prompt.txt`) and coord message `8a5cb25c`. A proper session log was reconstructed at `clients/lonestar-electrical/session-logs/2026-05-29-sophos-removal.md` before this compile.
 - Seeded 2026-05-26 from two March session logs + credentials.md + vault entry + temp provisioning scripts, enriched with live Syncro data (customer 33809612).