docs(lab): state the scope of the cleanup sweep and what the replay shows
The second follow-up review found no Blocker and no Major, and four
Minors that are corrected. Test-MatrixCleanup.ps1 and the README say
that every unresolved S-1-5-21-* member of Performance Log Users counts
as an entry of the probe; a Verify with the new script found none on
the two machines of the first lab. The record says that the replay
shows that the module doesn't decide the outcome and that six runs can't
rule out a small effect, which the result bullet and the summary of the
evidence had left out; it lists the first-lab counts among its tables,
names the controller blob of rc7d, says that the first-lab check ran
before the profile and log-group fields existed, counts nine restarts
inside the series, and mentions the first attempt of the cleanup test
that died. The controller comment says "for the baseline and for the
final candidate alike" instead of "whichever version"; no code changed.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
03:42, 04:07, 04:55, and 05:34; the file servers and the domain controller
didn't restart between the first and the last run, except OSFile22 at 01:36).
If the entry of a remote manager lives in the memory of the computer, a restart
@ -622,7 +629,7 @@ fails, which the reuse of the name explains and the module doesn't.
- Case 9 (accounts of other domains and forests) needs trusts that the matrix
lab doesn't have; it runs only in `WindowsAccessControlLab`, where the
baseline passed it and the final candidate passed it in run `fl1` (see "First
lab, final candidate"). The published package has to run there too.
lab, final candidate (case 9)"). The published package has to run there too.
- The file servers are Windows. A server of another kind is the subject of
Decision 23.
- Windows 11 26H1 has no domain cell until the domain controller or the
@ -658,12 +665,22 @@ fails, which the reuse of the name explains and the module doesn't.
`C:\NtfsProbeModules` that exists, the scheduled tasks of the matrix, the local
`NtfsProbe*` users, their profiles and profile folders (`C:\Users\NtfsProbe*`),
their entries in Performance Log Users, and the `NtfsProbe*` objects of the
directory, and `-Mode Repair` removes what it finds. It ran with real residue on
the five machines three times: at 06:03 UTC with the code of `9344ff7`, at
directory, and `-Mode Repair` removes what it finds. `Verify` and `Repair` treat
every unresolved `S-1-5-21-…` member of Performance Log Users as the probe's
(the probe is the only writer of that group in these labs, and its own cleanup
uses the same pattern); on a machine where something else leaves such members,
the check would report them and `Repair` would remove them. A `Verify` on the
two machines of the first lab (07:29 UTC) found none. The check ran with real
residue on the five machines three times: at 06:03 UTC with the script that
`9344ff7` committed at 06:08 UTC, at
06:44 UTC with the handling of profiles and of the entries in Performance Log
Users that the follow-up review asked for, and at 06:51 UTC after the second run
had shown that the check missed the entry of a local user (`net localgroup`
lists a local user by its bare name, and the pattern wanted a domain prefix).
lists a local user by its bare name, and the pattern wanted a domain prefix). A
first attempt at 05:58 UTC died while it made the residue, without a log (the
cause is unknown; decision log D37), so the run at 06:03 started in a lab where
that attempt might have made some items; its first `Verify` listed exactly the
expected ones.
The last run made residue of every kind at once: a stage item and a local user
`NtfsProbeDummy` on OSFile19; a local user with a profile and an entry in
Performance Log Users on OSFile19; a local user with a profile that was deleted
@ -678,7 +695,9 @@ fails, which the reuse of the name explains and the module doesn't.
read from the script with the parser and not copied, gave DIRTY. `Repair`
removed every item, and a second `Verify` gave CLEAN. Not tried: a profile that
stays loaded (the retries of `Repair` never needed a second attempt), and an
entry that `net localgroup` shows as a bare SID.
entry that `net localgroup` shows as a bare SID, so the branch for a SID and
`Remove-LocalGroupMember` with a SID didn't meet real residue (the cached name
of the deleted domain account was removed by name).
- Decision 24 is the agent's decision under the maintainer's delegation and stays
`proposed`. So do Decisions 22 and 23.
@ -691,7 +710,8 @@ tables of this record are in the files next to it:
- [the suite results of the three candidates](Acceptance-2026-10-10-os-matrix-LocalSuite.csv),
- [the failing tests of every suite run](Acceptance-2026-10-10-os-matrix-Failures.csv),
- [the controller cells of `rc7c` to `rc7l`](Acceptance-2026-10-10-os-matrix-Cells.csv),
- [the timeline of the Admin role of every cell and edition, `rc7c` to `rc7l` and the replay `ab0` to `ab10`, with the three effective-access tests](Acceptance-2026-10-10-os-matrix-Timeline.csv).
- [the timeline of the Admin role of every cell and edition, `rc7c` to `rc7l` and the replay `ab0` to `ab10`, with the three effective-access tests](Acceptance-2026-10-10-os-matrix-Timeline.csv),
- [the counts of the first-lab run `fl1`](Acceptance-2026-10-10-os-matrix-FirstLab.csv).
The scripts that produced them are in [Acceptance](Acceptance), and the
decision is `.memory-bank\decisions\0024-os-matrix-lab.md`.
Write-LabProgress'Preparing the accounts, the file server, and the client'
# When an account is deleted and created again with the same name, the remote authorization managers of the client and of the file server, which
# Get-NTFSEffectiveAccess asks for its default -ServerName and for the name of the file server, keep answering for about ten minutes as if the new
# account had no groups (Synchronize only), whichever version of the module runs. The local manager and a Kerberos S4U logon of the account, which
# account had no groups (Synchronize only), for the baseline and for the final candidate alike. The local manager and a Kerberos S4U logon of the account, which
# the oracle uses, are right at that moment (Decision 24). So a new fixture gets a name for the account of case 3 that an earlier fixture is unlikely
# to have used (four random digits); a fixture that exists keeps its account.
$existingSubjects=@(Invoke-LabCommand-ComputerName$DomainController-ActivityName'Look for the account of case 3'-ScriptBlock$findSubjectScript-ArgumentList$organizationalUnitName,$subjectBaseName@labCommand)
Raimund Andree
2 days ago