azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from HOWARD-HOME at 2026-07-15 12:21:30

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-15 12:21:30
This commit is contained in:
Howard Enos
2026-07-15 12:22:01 -07:00
parent 5aeabbcfb6
commit 0e244a610f
10 changed files with 197 additions and 65 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
wiki/clients/cascades-tucson.md
View File

@@ -489,7 +489,7 @@ Cascades' line-of-business / reporting SaaS (the systems they pull data OUT of,
### CS-SERVER SMB & Endpoint AV (2026-06-26)
- **The "CS-SERVER SMB error 67 outage" was a TEST-METHOD ARTIFACT, not a real outage.** RMM-dispatched SMB client commands (`net use`/`net view`/`Test-Path`/`Get-SmbConnection`, even in `user_session`) **false-negative** -- they return error 67 (BAD_NETWORK_NAME) / RPC 1702 / "none" even for KNOWN-GOOD targets. **CS-SERVER SMB is healthy** -- `Get-SmbSession` showed 7 live SMB 3.1.1 users / 30 open files / new sessions forming. **VALIDATE SMB server-side (`Get-SmbSession`/`Get-SmbOpenFile`) or with a REAL interactive test -- never from RMM client-side results.** A drive-map `verify` failure is NOT proof of a problem (skill caveat added; errorlog `rmm/smb-testing`).
- **CS-SERVER endpoint AV was DattoAV, not GravityZone Bitdefender.** It was the Datto EDR "Endpoint Protection SDK" (Bitdefender engine + Avira "Sentry" driver -> drivers `BdSentry`/`rtp1`/`rtp2`), managed by Datto RMM (CentraStage/`CagService`) + Datto EDR Agent (`HUNTAgent`/Infocyte HUNT, tenant azcomp4587). Removing the box from the GravityZone console did nothing because GravityZone never managed it. **ALL Datto software was fully removed from CS-SERVER 2026-06-26** (services deleted, `infocyte`/`CentraStage` dirs gone, registry + kernel drivers cleared). CS-SERVER was already de-enrolled from the EDR tenant, so no uninstall token could be issued -- forced removal once the tamper drivers were gone.
- **CS-SERVER endpoint AV was DattoAV, not GravityZone Bitdefender.** It was the Datto EDR "Endpoint Protection SDK" (Bitdefender engine + Avira "Sentry" driver -> drivers `BdSentry`/`rtp1`/`rtp2`), managed by Datto RMM (CentraStage/`CagService`) + Datto EDR Agent (`HUNTAgent`/Infocyte HUNT, tenant azcomp4587). Removing the box from the GravityZone console did nothing because GravityZone never managed it. The prior-MSP Datto stack was fully removed from CS-SERVER 2026-06-26 (services deleted, `infocyte`/`CentraStage` dirs gone, registry + kernel drivers cleared; the box was de-enrolled so removal was forced once the tamper drivers were gone). **[SUPERSEDED 2026-07-15]: the ACG-managed Datto EDR agent was subsequently REINSTALLED — CS-SERVER is protected** (agent `b41befcf-e418-4d0d-8552-bc7662364d07`, Datto EDR sensor + Datto AV, live heartbeat, defs current; verified live in the azcomp4587 console by Mike). Do not read the 6/26 removal as "server unprotected."
- **Karen Rossini share access -- RESOLVED.** `CASCADES\karen.rossini` (reset + vaulted `clients/cascades-tucson/karen-rossini.sops.yaml`, member of `SG-IT-RW`) verified able to open `\CS-SERVER\Server` shares **interactively** from another PC. Her ALDocs desktop shortcut + Quick Access pin were set on DESKTOP-LPOPV30 (`\CS-SERVER\Server\ALDocs`) via the `drive-map` skill. Note: her earlier move to CSCNet (WPA3-SAE) broke NAS-by-name resolution (unrelated side effect).
### Datto EDR / Bitdefender Decommission