Comprehensive session log covering today's work on the Valley Wide
Plastering app modernization project. Recovered Darv's VB6 source from
a set of backup rotation drives, including the production Orders_10A.exe
from the 97-Server\VWP2\ iteration workspace. Resolved the 4-year gap
question: no .vbp source newer than 2020-06-09 exists on any of the
three rotation drives; Darv worked in rename-and-try on the compiled
EXE only from 2021 onward.
Includes quick-resume instructions for tomorrow when the next drive is
connected.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drive 3 yielded the biggest finds in the project so far.
VHDX mount + scan (D:\WIN7-Orders\Darv-2\VWP1.VHDX, 117 GB Hyper-V disk):
- Mounted read-only as F:, scanned in 85s, dismounted
- NOT Darv's dev box - it's the office "owner" admin workstation
- No newer source code found inside, but:
- Vwp11.mdb (2023-07-27, 369 MB) - NEWEST DB snapshot anywhere
- Vwp.mdb (2022-12-23, 769 MB) - on Desktop\Darv VWP
- Orders Versions/ desktop folder with 2 EXEs + 7 shortcuts
- The .lnk shortcuts all pointed to G:\VWP2\Orders*.exe - the
"Aha!" that revealed where Darv's iteration happened
- Saved to source-code/from-VHDX-VWP1/
The VWP2 grab (D:\97-Server-G-Drive\g$ 2024-04-10\VWP2\):
- This is Darv's actual iteration workspace on the production
Orders server (G: drive)
- 16.36 GB total, 1,061 files. Grabbed 886 files (~893 MB) filtered to
*.exe, *.rpt, *.ocx, and VB6 source extensions:
- 64 Orders*.exe versions - complete iteration history (includes the
production Orders_10A.exe + Orders_10Z.exe variant + dozens more
with Darv's "iterate-and-rename" naming pattern)
- 820 Crystal Reports (.rpt)
- 2 .ocx supporting controls
- Skipped 23 historical .mdb backups (15.8 GB) - we already have
newer snapshots from 000_ASource and VHDX
- Skipped 6 large subfolders (HOLD, HHOLD, Pay_2021_0325, GWAC,
20220205, 20211010 RPT) - mostly more MDBs
- Saved to source-code/from-VWP2-97server/
What we learned about the 4-year gap:
- No source code newer than 2020-06-09 ORDERS_C.vbp baseline found
on any of the three rotation drives
- The 64 EXE versions in VWP2 go through 2022 - Darv was iterating
and rebuilding compiled output but not updating his .vbp source
control. This is consistent with his "rename and try" workflow
- The production exe (Orders_10A.exe) is in this batch - now we can
use VB Decompiler Pro on it without needing the original drive
Helper scripts:
- scan_vhdx.ps1 - fast PowerShell scan of a mounted VHDX for source/DB
- find_vwp2.py - cross-CSV search for the VWP2 path
- vwp2_summary.py - size+type breakdown of the VWP2 folder
- debug_vwp2.py - one-off debug helper
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drive 3 (12 TB, 11.99 TB used, only 43 GB free) — third VWP backup
rotation drive. Per Mike, all three drives are rotation copies; content
largely overlaps.
Net-new content vs drives 1 and 2:
- D:\WIN7-Orders\Darv-2\VWP1.VHDX (117 GB, 2023-09-01) — Hyper-V disk
named "VWP1" in a Darv-2 folder. Likely Darv's later workstation.
Strongest candidate for finding any 2021-2023 source code that
postdates our 2020-06-09 ORDERS_C.vbp baseline. Not copied.
- D:\WIN7-Orders\WindowsImageBackup\VWIN7-PC\...vhd (22 GB) — Windows
Image Backup of the VWIN7-PC machine, dated 2023-08-31.
- D:\VWP-FIN\ (~44 GB) — Finance machine backups + RAR archives. Not
relevant to Orders modernization but useful for QuickBooks context.
SourceSafe search:
- 1224 SourceSafe-related matches but ALL are Visual Studio install
directories (Microsoft Visual Studio\Common\VSS\) and .SCC sentinel
files. No srcsafe.ini (actual repository) anywhere on this drive.
The SourceSafe repo is on a different drive (likely Darv's personal
drive, not in the office rotation).
Source code:
- No .vbp newer than 2020-06-09 baseline. Same TEST_VWP.vbp scaffold
from drive 2 (2021-08-16, 810 bytes) present here too.
Updated .gitignore: added *.vhd (was missing — only had *.vhdx).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drive 2 (label "Backup", 12 TB, 6.77 TB used) — second of N VWP
backup drives. Scanned via WizTree, analyzed with analyze_wiztree.py.
NEW source content:
- 000_ASource/ — Darv's active work-in-progress folder. Contains
TEST_VWP.vbp (2021-08-16, only .vbp newer than the 2020-06-09 baseline),
four frmLotInfo*.frm variants (2020-10 to 2021-08), and an
MSSCCPRJ.SCC file confirming Darv used Visual SourceSafe.
- The accompanying Vwp.mdb (2022-10-19, 764 MB) stays on local disk
per .gitignore — newest database snapshot we have.
Analysis CSVs:
- source-analysis/drive2-2026-05-16/ — per-category + per-keyword
breakdown of drive 2's 3.95M files (vs drive 1's 1.87M). Categories
largely match drive 1 but with ~2x volume.
Net findings vs drive 1:
- Confirmed 4-year gap: only 4 .vbp files newer than 2020-06-09 on
drive 2, all the same TEST_VWP.vbp scaffold. Main ORDERS_C.vbp source
remains 2020-06-09. Darv stopped active VB6 dev around mid-2020.
- 43 GB Win7 Backup-and-Restore set in D:\Archive\Darv-Win7-PC\ (2023)
not copied — deferred to later drives, ZIPs extractable on demand.
- Master Darv folder is bit-for-bit duplicate of drive 1's master (135 GB,
same file/folder counts). Skipped.
New helper scripts:
- find_newer_vbp.py — list .vbp files newer than a date, filter SDK noise
- drive2_inspect.py / drive2_priorities.py — drive-specific triage
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Recovered Darv's VB6 source for the Valley Wide Plastering Orders
application from the D: backup drive (label "Backup", 8 TB, 5.3 TB used).
This is the first time we've had the actual source — prior session only
had a single frmPayroll.frm from the AD server.
Three project variants identified across two snapshots:
- Full-Project/ (2,129 files, 124 MB) — D:\Office-Estimates\Darv\Full\Project\
- Kingston-Project/ (2,189 files, 130 MB) — D:\Office-Estimates\Darv\Kingston\Project\
- Source/ (170 files, 559 MB) — D:\Office-Estimates\Darv\Source\ wholesale
- SOURCE-HOLD/ (3 files, 1 MB) — D:\Office-Estimates\Darv\SOURCE HOLD\
Latest ORDERS_C.vbp date is 2020-06-09 (Kingston snapshot). Production
Orders_10A.exe was live as of April 2024 — open question whether newer
source exists on other backup drives Mike will scan next.
Also includes per-category and per-keyword analysis CSVs from a WizTree
file-list export, plus the analyzer script that produced them
(re-runnable for the next drive's CSV).
VMs (VWIN7-DW.vdi 8.3 GB + XP-for-ORDERS_copy.vdi 2.8 GB), the live
VWP.mdb, and the 393 MB raw WizTree CSV stay on disk only — gitignored.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Gap #13 in hipaa.md marked resolved. Same update in hipaa-caregiver-controls.md and m365.md.
Confirmed 2026-05-14: no separate HIPAA BAA acceptance exists or is required for M365 Business
plan tenants under the Microsoft Customer Agreement.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Full tenant verification sweep: all Intune/Entra objects match session logs
- Entra Connect staging mode exited; 17 AD groups synced to cloud
- CA policies (Block-off-network, Sign-in-frequency-8h, Block-non-compliant) patched from SG-Caregivers-Pilot to AD-synced SG-Caregivers
- Registration Campaign exclusion updated to SG-Caregivers
- Deleted test accounts: howard.enos (AD) and pilot.test (M365)
- Documented Christine Nyanzunda collision risk, Ederick Yuzon open item, standing security-group rule
- Session log written
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Exchange REST API still propagating (28 min). Need manual verification via
Exchange Admin Center to unblock HIPAA compliance check.
Instructions provided:
- Access Exchange Admin Center
- Search for Britney Thompson mailbox
- Document litigation hold status (enabled/disabled, date, duration)
- Report findings back in repo
Priority: HIGH - blocks Wave 1 caregiver rollout planning.
HIPAA requirement: §164.308(a)(3)(ii)(C) + §164.316(b)(2)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
9-hour day on Cascades caregiver phone Shared Device Mode activation.
Root cause of repeated AADSTS50097 was missing Cloud Device Administrator
role -- pilot.test cannot self-register devices for shared mode. Created
dedicated devices@cascadestucson.com (CDA role, MFA on Howard's phone).
Final attempt on Phone A produced an Entra device record with shared-mode
markers (registeredOwners=0, registeredUsers=0). Resume tomorrow by
signing pilot.test in to verify SDM is actually active.
Side wins: ALIS SSO Entra App Registration created (vault commit 90ada33,
blocked on Medtelligent enabling App Store side); 2 of 3 caregiver CA
policies flipped from Report-only to Enforced; kiosk profile bumped to
v13 with full Android nav bar, 12hr inactivity signout, 6-app allowlist
including Company Portal.
Microsoft ticket #2605070040009774 still open.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
New client onboarding for The Law Offices of Chris Scileppi with initial
session log documenting diagnosis on Sylvia's Mac mini (Mac14,3, M2, 8 GB).
Issue: System running out of memory; Apple Mail footprint thrashing the box.
Two Envelope Index rebuild attempts confirmed the mailbox itself exceeds what
8 GB can hold. Disabled Mail at the OS level, moved user to webmail, and
recommended replacement with an M4 Mac mini (16 or 24 GB).
Ticket #32262 resolved. 1 hr onsite logged but deliberately not invoiced.
Files:
- clients/scileppi-law/PROJECT_STATE.md
- clients/scileppi-law/docs/overview.md
- clients/scileppi-law/docs/issues/log.md
- clients/scileppi-law/session-logs/2026-05-07-howard-sylvia-mac-mini-mail-memory.md
All 5 ComputerGuru apps successfully onboarded:
- Security Investigator, Exchange Operator, User Manager, Tenant Admin, Defender Add-on
- API permissions granted (0 errors)
- Exchange Administrator role assigned to Security Investigator SP
Exchange REST API access pending propagation (15-30 min typical).
Next: Re-test Exchange REST after 09:30 AM MST to verify litigation hold check.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Cannot verify litigation hold status - ComputerGuru Security Investigator
app not onboarded to Cascades tenant (HTTP 401 on Exchange REST).
User account confirmed (Britney.Thompson@cascadestucson.com).
Next steps:
- Onboard Security Investigator app to tenant
- Assign Exchange Administrator role
- Re-run litigation hold verification
HIPAA compliance blocker per Howard's 2026-05-06 note.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Approved:
- Memory caps: SQLEXPRESS 12GB, WID 512MB, AIMSQL 256MB
- AIMSQL consolidation (pending backup)
- AD is in use, WSUS is not
Howard may proceed with implementation.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Lauren Hasselman could not create a Teams group on 2026-05-05.
Diagnostic confirmed the block is at the Teams Admin policy layer
(intentional, gated on HIPAA prerequisites in m365.md issues #12-#14),
not an Entra/M365-Group permissions defect. New teams-rollout.md
captures prerequisites, HIPAA config checklist, canary test plan
(Lauren as primary canary), and exit criteria. Linked from m365.md
issue #14.
Follow-up on three pending items from breach check:
- IdentityRiskyUser scope: consented but requires P2 license
- Dime Client app: internal app requiring verification with Dan Center
- Microsoft Authenticator: drafted upgrade plan and recommendations
Created comprehensive follow-up report with action items.
Machine: Mikes-MacBook-Air
User: Mike Swanson (mike)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>