29 KiB
Operating-system matrix acceptance, 2026-10-10
Live and local acceptance of NTFSSecurity candidates on more operating systems
than the first lab has (Decision 24, handoff 2 of the 5.0.0 quality gate):
Windows Server 2019, 2022, and 2025 as file servers and Windows 11 as client, in
Windows PowerShell 5.1 and PowerShell 7, elevated and as a basic user. The
candidates are local builds of ai/quality-gate-lab-matrix, tested from their
extracted packages with -ModulePath. None is a published package, so this
record isn't the acceptance of a release (see the limits at the end), and it
isn't a claim that the quality gate is complete.
Result
- The module's own suite, 1,011 cases per configuration (1,010 on the host), ran
on five operating systems and on the host in four configurations each. The
final candidate (
fdd7a8b) has no failure in any of the 24 runs; every skipped test is also skipped on the host. - The live controller ran for the final candidate in three cells of the matrix (the Windows 11 client with each file server, both editions, every role) in one sequence, after the fixture got a new account name for each new fixture: 1,374 passed, 0 failed, 12 skipped (case 9 and the module test of the Server role). An earlier run of the same cells with the old controller had failed in the Windows Server 2022 cell for a reason of the fixture, not of the module (see "The accounts of the fixture").
- The matrix found three defects of the module. All three are fixed on the
branch, each with its own commit, and each was red on the machines where it
shows before its fix and green after it:
Get-NTFSInheritance -SecurityDescriptorfor an item without audit entries andGet-NTFSEffectiveAccess -ServerName ''(962887a), andGet-NTFSEffectiveAccessfor a user who isn't an administrator on a computer in a domain (fdd7a8b). The first two showed on Windows Server 2022 and 2025 and on Windows 11 26H1, the third on every machine of the domain. - The controller had four defects of its own: three in cleanup and setup
(
7d47316) and the reuse of the name of the account of case 3 (1dec389). Windows returns the SID and the groups of a deleted account for a Kerberos S4U logon for more than seven minutes, so cells that followed each other failed in the effective-access tests of the Admin role. This looked like a regression of the module until a probe showed the baseline and the final candidate failing alike. - Windows 11 26H1 (10.0.28000) can't keep a secure channel to the Windows Server 2025 domain controller of this lab, so it runs the module's suite only. The domain client is Windows 11 Enterprise Evaluation 22H2.
- Open: the published package in every cell (stage D of the gate), case 9 in the matrix lab, and the maintainer's decisions listed at the end.
Machines
All machines are virtual machines on the Hyper-V host in the lab
NtfsSecurityOsMatrixLab (domain osmatrix.net, switch 192.168.12.0/24),
which AutomatedLab deployed beside the other labs without touching them. The
.NET Framework release number is the one that the readiness check read.
| Machine | Role | Operating system | Build | .NET Framework | Windows PowerShell | PowerShell 7 |
|---|---|---|---|---|---|---|
| OSDC1 | Root domain controller | Windows Server 2025 Datacenter | 10.0.26100.32690 | 533509 | 5.1.26100.32684 | 7.6.3 |
| OSFile19 | File server | Windows Server 2019 Datacenter | 10.0.17763.1217 | 461814 | 5.1.17763.1007 | 7.6.3 |
| OSFile22 | File server | Windows Server 2022 Datacenter | 10.0.20348.4773 | 528449 | 5.1.20348.4294 | 7.6.3 |
| OSFile25 | File server | Windows Server 2025 Datacenter | 10.0.26100.32690 | 533509 | 5.1.26100.32684 | 7.6.3 |
| OSWin11E | Client | Windows 11 Enterprise Evaluation 22H2 | 10.0.22621.525 | 533320 | 5.1.22621.169 | 7.6.3 |
| OSWin11 | Suite only | Windows 11 Pro 26H1 | 10.0.28000.1836 | 533510 | 5.1.28000.1830 | 7.6.3 |
| Host | Reference for the suite | Windows Server 2025 Datacenter | 10.0.26100.33438 | 533509 | 5.1.26100.33438 | 7.6.6 |
Windows 11 reports Windows 10 as the product name in the registry; the builds
are Windows 11. The VMs have no internet, so PowerShell 7.6.3 and Pester 5.7.1
came from the host. Every machine passed a readiness check before a cell: WinRM
with the lab account, LDAP, Kerberos, the secure channel, the clocks, the tools,
and the Pester version.
Candidates and artifact identity
Each candidate is a Release build (.NET Framework 4.5.2) in an isolated worktree
of its commit, packaged by .github/scripts/New-ModulePackage.ps1. All 11 files
of every tested module folder equal the extracted NTFSSecurity.zip byte for
byte. The builds aren't byte-reproducible: PrivilegeControl.dll and
ProcessPrivileges.dll differ between the candidates although no source of
theirs changed, so the hashes belong to one build each.
Baseline 83149ee |
Candidate 962887a |
Final fdd7a8b |
|
|---|---|---|---|
| What it is | Head of #118 | Two fixes in the module | Three fixes in the module |
NTFSSecurity.dll |
40D0C8A6B819F15A… |
9AC1169F91687495… |
B0631389E68C8244… |
Security2.dll |
804D199335CA0D6A… |
FF314FACCF01676A… |
A4D744579E8FF3BE… |
NTFSSecurity.5.0.0-rc7.nupkg |
2AAE3403A2D1C3AE… |
ACFA247BCD5AD33D… |
1A112B8CBBE27F9D… |
NTFSSecurity.zip |
A5AFA241DCA5DF87… |
CD836E39C6B22EB3… |
3DF48E5C590A9E38… |
The full SHA-256 values and the hashes of every result file are in the local
evidence (see the end). The tests of the suite are the files of the working
tree at the commit of the run. The live tests (Git blob
efe36e5073b9b10742ca7de242ddcbe90d8eda62) are those of fdd7a8b in every run
from rc7f on. The controller of the cells rc7f to rc7k is the blob
683aee91ec8805d77a33b2d368acaf876724fa32 (fdd7a8b); the cells of rc7l ran
with the blob 9917cac5820ed20ed2eb5592eff06894677f9874 (1dec389). The
earlier cells of the baseline ran with the controller blobs 0b46427b… and
d485b1d0… and the live tests 67b85efe…, before the cleanup fixes.
Method
- Module's own suite.
Acceptance\Run-MatrixLocalSuite.ps1copies the 18 behavior test files and the candidate to a machine and runs them there in a new Windows PowerShell process and a new PowerShell 7 process, elevated and as a basic user. The basic user is the token that.github\scripts\Invoke-TestsAsBasicUser.ps1makes (SAFER level Normal User), so the tests that need a missing privilege skip in the elevated mode and run in this one. The processes run as scheduled tasks with a batch logon at the highest run level: a process that starts from a remoting session has every privilege enabled and no credentials of its own, which eight tests don't expect. The host runs the same stage as the reference. A skipped test counts as a difference when only one side skips it; the skipped lists are compared as multisets of test names. - Live controller.
Acceptance\Run-MatrixSequence.ps1runs, for each file server with the clientOSWin11E: the readiness of every machine, the unmodified controller of the repository in both editions, the validation of every role from the result files (Validate-LabResults.ps1, never from the markerDONE), a snapshot of the fixture SIDs, the removal of the fixture, and an independent check of the end state (Test-MatrixCleanup.ps1). - Probe.
Acceptance\Probe-EffectiveAccess.ps1asksGet-NTFSEffectiveAccessthe same questions under four tokens on one machine and writes the result and the failing call of each: the elevated lab account, the SAFER token of a basic user, a local standard user, and a standard user of the domain. It creates the two standard users with passwords that exist only in memory and removes them, their profiles, and their group membership again. - Account probe.
Acceptance\Probe-AccountRecreation.ps1deletes an account and creates it again with the same name in a loop. It shows the token that Kerberos S4U logons give on the domain controller, the client, and the file server, and whatGet-NTFSEffectiveAccessof each module under test returns from the client (see "The accounts of the fixture"). Its accounts, folder, and files are namedNtfsProbe*, whichTest-MatrixCleanup.ps1reports if they stay.
Results
Live controller
The final candidate (fdd7a8b) in the three cells of the matrix, with the
Windows 11 client OSWin11E, the controller of 1dec389 (Git blob
9917cac5820ed20ed2eb5592eff06894677f9874) and the live tests of blob
efe36e5073b9b10742ca7de242ddcbe90d8eda62: run rc7l, one sequence, 03:45 to
04:07 UTC. Every role was checked from the result files
(Validate-LabResults.ps1 printed LIVE_RESULT_VERIFIED). Passed / failed /
skipped:
| File server | Edition | Delegate | ServerAdmin | Admin | Server |
|---|---|---|---|---|---|
| OSFile19 (Windows Server 2019) | Windows PowerShell | 69 / 0 / 0 | 36 / 0 / 0 | 51 / 0 / 1 | 73 / 0 / 1 |
| OSFile19 (Windows Server 2019) | PowerShell 7 | 69 / 0 / 0 | 36 / 0 / 0 | 51 / 0 / 1 | 73 / 0 / 1 |
| OSFile22 (Windows Server 2022) | Windows PowerShell | 69 / 0 / 0 | 36 / 0 / 0 | 51 / 0 / 1 | 73 / 0 / 1 |
| OSFile22 (Windows Server 2022) | PowerShell 7 | 69 / 0 / 0 | 36 / 0 / 0 | 51 / 0 / 1 | 73 / 0 / 1 |
| OSFile25 (Windows Server 2025) | Windows PowerShell | 69 / 0 / 0 | 36 / 0 / 0 | 51 / 0 / 1 | 73 / 0 / 1 |
| OSFile25 (Windows Server 2025) | PowerShell 7 | 69 / 0 / 0 | 36 / 0 / 0 | 51 / 0 / 1 | 73 / 0 / 1 |
That is 1,374 passed, 0 failed, and 12 skipped for the three cells. The skipped
tests are the same in every cell: case 9 (the Admin role skips "Get-NTFSOrphanedAccess
should not report the entries of the accounts" of other domains and forests,
because the matrix lab has no foreign domain) and the Server role's test of the
module version (that role runs without the module). Each cell had a new
fixture: the subject of case 3 was NtfsLiveSubject0602 in the cell of
OSFile19 and NtfsLiveSubject6688 in the cell of OSFile22.
All runs of the controller, as the table of cells
(Cells.csv) lists them. The runs
before rc7l used the controller with the fixed name of the subject:
| Run | Candidate | Cells | Result per edition and cell |
|---|---|---|---|
rc7c, rc7e |
Baseline 83149ee, tests before the new cases |
OSFile19, 22, 25 | 227 passed, 0 failed, 2 skipped in every cell. The failed cleanup of the first cell had left the accounts in place, so only the third cell of rc7e had new accounts |
rc7f |
Final fdd7a8b |
OSFile19, OSFile22 | OSFile19: 229 / 0 / 2. OSFile22: 228 / 1 / 2, the effective-access test of the Admin role |
rc7g |
Final | OSFile25 | 229 / 0 / 2 |
rc7h |
Final | OSFile22 | 228 / 1 / 2, the same test |
rc7i |
Final | OSFile22 | Windows PowerShell 228 / 1 / 2 (Admin), PowerShell 7 229 / 0 / 2 |
rc7j |
962887a (without the third fix) |
OSFile22 | 225 / 4 / 2: the two new tests of the ServerAdmin role (red without the fix, "Access is denied" for localhost and for the name of the client) and two tests of the Admin role |
rc7k |
Baseline 83149ee, with the final tests |
OSFile22 | 227 / 2 / 2: the two new tests of the ServerAdmin role; the Admin role passed |
The failures of the Admin role in rc7f, rc7h, rc7i, and rc7j come from
the fixture, not from the module (see "The accounts of the fixture"). The two
failures of the ServerAdmin role in rc7j and rc7k are the red state of the
new live tests, as intended; they pass in rc7f, rc7g, rc7h, rc7i, and
rc7l. The end-state check after each cell of rc7l found the fixture gone
(no organizational unit, account, share, folder, local group, membership, or
profile) and reported only the staging folders of the earlier suite runs, which
Test-MatrixCleanup.ps1 didn't check before (see "The accounts of the fixture"
and the limits).
The module's own suite, final candidate
Passed / failed / skipped. Every configuration has 1,011 cases on the machines of the domain and 1,010 on the host, which has no DNS domain and so doesn't run the case for the fully qualified name of its computer.
| Machine | Elevated, Windows PowerShell | Elevated, PowerShell 7 | Basic user, Windows PowerShell | Basic user, PowerShell 7 |
|---|---|---|---|---|
| OSFile19 (Server 2019) | 994 / 0 / 17 | 992 / 0 / 19 | 782 / 0 / 229 | 780 / 0 / 231 |
| OSFile22 (Server 2022) | 994 / 0 / 17 | 992 / 0 / 19 | 782 / 0 / 229 | 780 / 0 / 231 |
| OSFile25 (Server 2025) | 994 / 0 / 17 | 992 / 0 / 19 | 782 / 0 / 229 | 780 / 0 / 231 |
| OSWin11E (Windows 11 22H2, the client of the cells) | 994 / 0 / 17 | 992 / 0 / 19 | 782 / 0 / 229 | 780 / 0 / 231 |
| OSWin11 (Windows 11 26H1) | 994 / 0 / 17 | 992 / 0 / 19 | 782 / 0 / 229 | 780 / 0 / 231 |
| Host (reference) | 993 / 0 / 17 | 991 / 0 / 19 | 781 / 0 / 229 | 779 / 0 / 231 |
On every machine, the skipped tests are the same as on the host, name for name,
in every configuration. They are tests that need the other privilege level or
the other edition and that run in another configuration, as the earlier
analysis of the skipped rows found (all 578 skipped rows of the suite at
5a5d58b ran in two other configurations). The two disabled-audit-inheritance
tests that 962887a added are skipped without the Security privilege, so the
basic configurations skip two cases more than before (229 instead of 227).
What the fixes changed
The same tests, the same machines, and three builds. The baseline and the
candidate 962887a were run with the tests of the final commit, so the guards
of the later fixes were present and red.
| Candidate | Elevated | Basic user |
|---|---|---|
Baseline 83149ee (Server 2022 and 2025) |
4 failures in every configuration | 20 failures in every configuration |
962887a (all five machines of the domain) |
0 failures | 20 failures in every configuration |
Final fdd7a8b (all five machines of the domain) |
0 failures | 0 failures |
The four elevated failures of the baseline are the same on Server 2022 and 2025, in both editions:
Get-NTFSInheritancewith a security descriptor, "Should report the same state as for the path of the item" (existing test),- the same for "a file without audit entries" and
- "a folder without audit entries" (two new guards),
Get-NTFSEffectiveAccess, "Should return the result of this computer and warn for an empty -ServerName" (existing test).
The 20 failures in the basic-user mode are the same set on every machine of the
domain and in both editions, once the name of the computer in two test names is
set aside. All of them call Get-NTFSEffectiveAccess without a reachable
remote authorization manager: 11 in its own tests, 5 in the tests of a later
command that ends the pipeline, 2 for an unresolved identity, 1 for a path that
doesn't exist, and 1 for an item whose owner may not read its permissions. Each
fails with "Could not get effective permissions from machine 'localhost'. The
error is 'Access is denied'". The host and the CI runners aren't in a domain and
passed them all along. The failing names of every run are in
the failures table.
Defects found
In the module
Get-NTFSInheritance -SecurityDescriptorfor an item without audit entries reported the audit inheritance as disabled, where-Pathreported it as enabled. On Windows Server 2022 and 2025 and on Windows 11 26H1, .NET reports the SACL of such an item as protected from inheritance when it reads all sections together, and as not protected when it reads the SACL alone; the descriptor kept the first state. The baseline showed it on Windows Server 2022 and 2025, and an earlier run with the same two existing tests showed it on Windows 11 26H1; the host (build 33438) reads both ways alike. The baseline wasn't run on Server 2019 and Windows 11 22H2.Write()stores the sections that were read, so a descriptor with the wrong flag would also have stored the SACL as protected. Fixed in962887a: the descriptor takes the audit section from a separate read, as it already did for the access section.Get-NTFSEffectiveAccess -ServerName ''wrote "Access is denied" on the same machines, because Windows takes an empty name for this computer and the remote interface then refuses the check; on the host it fails as unreachable. Fixed in962887a: an empty name names no computer, so the cmdlet warns and returns the result of this computer on every machine.Get-NTFSEffectiveAccessfor a user who isn't an administrator, on a computer in a domain, wrote "Access is denied" and returned nothing for every account, also for the default-ServerName localhost. See the probe below. The function that fails,GetEffectivePermissions_AuthzInitializeContextFromSid, is identical in the published 5.0.0-rc6 (compared withgit diffagainst the tag; the cmdlet wasn't run there), and the defect shows in the tests only on a domain-joined machine as a basic user. Fixed infdd7a8b.
The probe
The remote interface of the authorization manager of a computer answers only
its administrators and the members of its group Access Control Assistance
Operators. A computer in a domain offers the interface to every caller; a
computer outside a domain doesn't, so the cmdlet already used the local manager
there. The probe, on Windows Server 2019, 2022, and 2025, with the module of
962887a (before the third fix):
| Token | Name of this computer (the default, localhost, computer name, FQDN) |
-ServerName '' (the local manager) |
Another computer |
|---|---|---|---|
| Lab account, elevated | Result for every account | Result for every account | Result for every domain account |
| Lab account, filtered (SAFER Normal User) | Access denied for every account | Result for every account, also the Administrator and Domain Users of the domain | Result for domain accounts: network authentication carries the groups of the account |
| Local standard user | Access denied | Result, except for the domain Administrator, a user account of the domain | Access denied: a local account has no domain credentials |
| Standard domain user | Access denied for every account | Result for every account, also the domain Administrator | Access denied, as the cmdlet page and the live test of the delegated account describe |
The accounts were the user itself, Everyone, the local Administrator, and the Administrator and Domain Users of the domain. The cmdlet now uses the local manager for a name of this computer when the remote one refuses the user. The second column shows that this answers for every caller of these four kinds, except for a local user who asks about a user account of the domain; that stays an "Access is denied" from Windows. For another computer, the denial stays an error. A new live test runs the case as the administrator of the file server, who isn't an administrator of the client, and compares the rights with the S4U oracle that the other roles use.
In the environment
- The base images of Windows Server 2019 and Windows 11 22H2 had an empty EFI
system partition: the
bcdbootof the Server 2025 host fails with exit code 193 on their boot files, and AutomatedLab ignores the exit code, so the VM doesn't boot (Hyper-V event 18603).Repair-OsMatrixBoot.ps1runs thebcdbootof the image itself on the VM's own disk. - Windows 11 26H1 (28000.1836) joins the domain but loses the secure channel to
the domain controller (26100.32690): the client asks
NetrLogonGetCapabilitiesfor query level 2, the controller answers0xC0000022, and the client denies the channel (NlConfirmRequestedCapabilities: denying access ... 0xc0000022). A rejoin can't fix a protocol mismatch, so this machine isn't a domain client. - The Windows 11 Enterprise Evaluation image shuts itself down an hour after
each start (
wlms.exe: "The license period for this installation of Windows has expired"; status 0xC004F009). It recorded its install time on a clock that ran about seven hours ahead, the clock was then corrected, and the evaluation licensing took the step back as the end of the grace period. One of the two documented rearms didn't clear it. After an unplanned shutdown its machine account password no longer matched the domain's (0xC000018Dfor domain logons,nltest /sc_verifyreportsERROR_INVALID_PASSWORD);Test-ComputerSecureChannel -Repairwith the lab account repaired it. Runs on this machine have to stay under an hour from its start. - A profile of an account that a scheduled task used stayed loaded on one server, so its folder couldn't be removed until the machine restarted.
In the harness
- A line that a native command writes to stderr is a terminating error in
Windows PowerShell 5.1 under
$ErrorActionPreference = 'Stop'when2>&1redirects it. The first "The directory is not empty" of PowerShell 7 ended the fixture removal on Server 2019 before the retry. Get-LocalGroupMemberfails with "Failed to compare two elements in the array" when a group holds an orphaned SID, which stopped the setup of the next run. The setup now adds members and ignoresMemberExistsException.- A profile that is gone in the meantime failed the cleanup of the client.
All three are fixed in the controller (7d47316).
The accounts of the fixture
The cells of the final candidate failed in the Windows Server 2022 cell, and
only there, in the Admin role: Get-NTFSEffectiveAccess for the subject of
case 3 returned no access (Synchronize only, 0x100000) where the tests
expected the rights through the domain groups, once with the default
-ServerName or once with the name of the file server, in rc7f, rc7h,
rc7i, and rc7j (rc7j ran the candidate 962887a, rc7i failed only in
Windows PowerShell). The audit read of 962887a was the first suspect: it is
the only change of the module on the path of the cmdlet, and the baseline had
passed the cell (rc7c, rc7e, rc7k). A probe disproved it. Every cell of
rc7c and rc7e had run with the accounts that the failed cleanup of the first
cell left in place; from rc7f on, the removal worked, so the fixture deleted
its accounts after each cell and created them again, with the same names and new
SIDs, for the next.
The loop probe (the scratch script of the night, which
Probe-AccountRecreation.ps1 replaces) creates a user in a group that is in
another group, asks Get-NTFSEffectiveAccess from the client in a new process
for the baseline and for the final candidate, deletes the accounts, and creates
them again with the same names every seven seconds:
| Round | Name resolves to | S4U token of the account on the client | Baseline and final candidate, by name and by SID, with the default -ServerName and with the file server |
|---|---|---|---|
| 1 (new names) | the current SID | holds the outer group | 0x1200A9, both modules, all four calls |
| 2 to 6 | the SID of the previous round in the first process of a round, the current SID in the second | lacks the new outer group | 0x100000, both modules, all four calls |
The probe of the kit, Probe-AccountRecreation.ps1, which also logs the user on
with S4U on the domain controller, the client, and the file server, gave the same
picture in four rounds with the baseline and the final candidate (04:19 UTC): in
round 1, all three machines returned the current account and both modules
0x1200A9 for every call; in rounds 2 to 4, all three returned the old account,
without the new outer group, and both modules 0x100000 for every call.
A second probe logged the user on with Kerberos S4U the way the oracle of the
live tests does, on all three machines: after the accounts were created again,
the token of the domain controller, the client, and the file server held the
SID of the deleted account (user is the current SID: False) and not the new
outer group, in rounds 2 and 3; in round 1 all three were right. The computers'
own ticket cache (logon session 0x3e7) held no ticket for the account, and
purging it changed nothing.
A third probe created five sets of accounts, logged each user on with S4U on the three machines, deleted and created them again with the same names, and asked once per set after a delay, so that no question kept a cache alive. Set 1 was asked at once, then after remedies:
| Question | Domain controller | File server | Client |
|---|---|---|---|
| At once | old account | old account | old account; Authz by SID 0x100000 |
After klist purge on the client |
old account | old account | current account (the token of the session); Authz by SID still 0x100000 |
After nltest /sc_reset, a DNS flush on the client, and a restart of the Kerberos service of the domain controller |
old account | old account | unchanged |
| 60 seconds after the accounts were created again | old account | old account | Authz by SID 0x100000 |
| 180 seconds | old account | old account | Authz by SID 0x100000 |
| 420 seconds | old account | old account | Authz by SID 0x100000 |
| 900 seconds | current account | current account | Authz by SID 0x1200A9, also with the name of the file server |
The sets after the first were asked after the purge on the client, so the token
of the client in their rows isn't independent; the rows of the domain controller
and the file server are. The module isn't involved: WindowsIdentity with the
user principal name, which the module doesn't call, returns the old account.
The lifetime is between seven and fifteen minutes when the account is created
again at once; I didn't measure it more closely. A cell of the controller has
minutes between the removal and the next creation, which may be why the cells
failed in some positions and passed in others.
The controller now gives a new fixture a new name for the account of case 3
(NtfsLiveSubject and four digits, 1dec389), and a fixture that exists keeps
its account. No cache has to be flushed, and the module isn't changed by this.
With the new names, the cell of Windows Server 2022 that had failed four times in
a row passed, and so did the other two cells of the same sequence (see "Live
controller"). The baseline's pass in rc7k in the same position doesn't fit a
fixed lifetime of the stale state (the deletion and the new creation were about
one minute apart, and the last question about the old account five minutes
earlier); I couldn't explain it, and the unique names make it moot.
Limits and open items
- Every run is a validation of a local build (
-ModulePath). The acceptance of a release is the run with-Versionof the exact prerelease from the PowerShell Gallery in every cell, which handoff 3 sequences after the maintainer decides which fixes belong to 5.0.0-rc7. The same cells have to be repeated for a changed binary. - 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. - 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 mismatch changes. The Windows 11 client of the cells is the 22H2 evaluation build, which has to be started shortly before a run (see above).
GetEffectiveAccessignores what the initialization of the resource manager throws (an outercatch { }that is older than this work). An operating system that refused another computer at that step, not at the context as every machine of the matrix did, would give a result without rights and a warning instead of the documented error. This is unverified and outside the fixes.- The scripts of the kit were read by a reviewer who ran none of them; module
logging or script-block logging on a machine would record the lab password
that
Register-ScheduledTask -Passwordneeds. - The lifetime of the stale Kerberos S4U state isn't established beyond "more
than seven and less than fifteen minutes when the account is created again at
once", and one cell (
rc7k) passed where the probe predicted a failure. The controller doesn't depend on it any more, but a script of the kit that creates accounts again under one name would. - The end-state check of the matrix reported the staging folders of the suite
runs (
C:\NtfsMatrixLocal) as residue in the three cells ofrc7l, which made their verdict DIRTY, although the fixture was gone. The suite runner now removes its stage after it has copied the results back, the check counts the items in the stage folders, and-Mode Repairremoves what is left. After a Repair,Verifyfound the lab clean at 04:21 UTC: no fixture, no probe account or user, no scheduled task, and no stage item on the domain machines. The stage of OSWin11, which only a local account reaches, was removed by a command of its own (4 items). - Decision 24 is the agent's decision under the maintainer's delegation and stays
proposed. So do Decisions 22 and 23.
Evidence
The raw logs, result files, probe outputs, and the packages are local, outside Git, in the session files of the run; they aren't part of this commit. The tables of this record are in the files next to it:
The scripts that produced them are in Acceptance, and the
decision is .memory-bank\decisions\0024-os-matrix-lab.md.