claudetools/clients/cascades-tucson/reports/2026-04-22-cs-server-entra-readiness-verdict.md

CS-SERVER Entra Connect Readiness — Verdict

Executed: 2026-04-22 17:26 MST (via GuruRMM agent 6766e973-e703-47c1-be56-76950290f87c) Exit code: 0 Full output: reports/2026-04-22-cs-server-entra-readiness.md Script source: docs/migration/scripts/entra-connect-readiness.ps1

Overall verdict

READY to install Entra Connect, after addressing three small pre-install items. No hard blockers. Hardware / OS / AD / network environment all meet requirements.

PASS (13 checks)

Check	Result
Operating system	Windows Server 2019 Standard, build 17763 (≥2016 required)
.NET Framework	4.8 (release 528049, ≥4.7.2 required)
PowerShell	5.1.17763.8510 (≥5.0 required)
Disk space	C: 149 GB free / D: 548 GB free
AD domain / forest mode	Windows2016Forest / Windows2016Domain
AD Schema version	88 (Windows Server 2019)
FSMO roles	All 5 on CS-SERVER (expected for single DC)
AD size	44 users, 55 groups, 18 OUs — small enough for fast sync
Internet to Microsoft	All 7 sync endpoints reach on HTTPS 443
WinHTTP proxy	Direct access, no proxy config needed
Existing AAD/Entra Sync	None — clean install target
DC health (dcdiag)	Connectivity / Advertising / Services / FsmoCheck all pass
CPU / RAM headroom	1% CPU, 27% of 48 GB RAM used

Pre-install items to fix (in order)

1. Time sync — HIGHEST priority

Currently free-running on the local system clock. w32tm /query /status reports:

• Source: Free-running System Clock
• ReferenceId: 0x4C4F434C ("LOCL")
• Last Successful Sync Time: 4/21/2026 8:31:32 PM (~21 hours ago at time of check)
• Peer state: Pending

Cloud sync has a ±5-minute drift tolerance. A PDC emulator with no external NTP source will drift over days and Entra Connect will start failing intermittently. As the PDC, it's also supposed to be the authoritative time source for the domain — so every other machine is inheriting this drift.

Fix (no reboot needed):

w32tm /config /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8 time.nist.gov,0x8" /syncfromflags:manual /reliable:yes /update
Restart-Service w32time
w32tm /resync /force
w32tm /query /status   # verify Source is no longer "Free-running"

2. Backup before install — safety net

Per the earlier audit, Windows Server Backup feature is Available but not Installed and there's no documented Synology ABB of CS-SERVER. Entra Connect install touches the AD schema (extends it with a couple of attributes) and creates a service account. If anything goes sideways, we need a rollback path.

Fix:

Install-WindowsFeature Windows-Server-Backup
# One-shot full backup + system state to Synology SMB share
wbadmin start backup -backupTarget:\\CASCADESDS\Backups\CS-SERVER -include:C:,D: -allCritical -vssFull -quiet

(Or use existing Synology ABB if configured — confirm it covers CS-SERVER before install.)

3. TLS 1.2 explicit enforcement — HIPAA + defense in depth

Server 2019 defaults to TLS 1.2 enabled, so Entra Connect will work today. But the Schannel registry entries are "unset (OS default)" and .NET SchUseStrongCrypto is set on 64-bit but missing on 32-bit. Best practice (and cleaner audit story) is to explicitly enable TLS 1.2 and disable 1.0/1.1.

Fix (REQUIRES REBOOT for Schannel):

# .NET side (takes effect immediately for new processes)
$paths = @(
  'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319',
  'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319'
)
foreach ($p in $paths) {
  New-Item -Path $p -Force | Out-Null
  Set-ItemProperty -Path $p -Name SchUseStrongCrypto -Type DWord -Value 1
  Set-ItemProperty -Path $p -Name SystemDefaultTlsVersions -Type DWord -Value 1
}

# Schannel side (requires reboot)
$base = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'
foreach ($proto in 'TLS 1.0','TLS 1.1') {
  foreach ($role in 'Client','Server') {
    $k = "$base\$proto\$role"
    New-Item -Path $k -Force | Out-Null
    Set-ItemProperty -Path $k -Name Enabled -Type DWord -Value 0
    Set-ItemProperty -Path $k -Name DisabledByDefault -Type DWord -Value 1
  }
}
foreach ($role in 'Client','Server') {
  $k = "$base\TLS 1.2\$role"
  New-Item -Path $k -Force | Out-Null
  Set-ItemProperty -Path $k -Name Enabled -Type DWord -Value 1
  Set-ItemProperty -Path $k -Name DisabledByDefault -Type DWord -Value 0
}
# Then: Restart-Computer

Schedule this for a maintenance window since it requires a reboot of the only DC.

Observations (not blockers)

• Windows Internal Database (MSSQL$MICROSOFT##WID) running — likely AD Certificate Services or a legacy role. No conflict with Entra Connect's SQL Server LocalDB. Check if still needed.
• QBVSS (QuickBooks VSS) running — QuickBooks on a DC is already known issue #17 per hipaa.md. Not blocking. Keep on long-term cleanup list.
• Event log: 3 System errors + 4 Application errors last 24h — Firefox browser agent, TPM-WMI (benign on non-TPM hardware), DistributedCOM, .NET Runtime, Security-SPP (licensing). None critical. Not blocking.
• Expired self-signed cert CN=CS-SERVER.cascades.local — known issue #19 (hipaa.md), unrelated to Entra Connect (which uses its own cert for the sync service account).

Recommended pre-install sequence

1. Run the time-sync fix immediately — no downtime, fixes drift right away
2. Install Windows Server Backup, run a full backup to Synology share (~30 min depending on D: size)
3. Schedule TLS reboot window (tell Meredith — brief disruption)
4. After reboot, re-verify with the readiness script (same command, same agent)
5. Proceed with Wave 0.5 Entra Connect install

Hardware note (not changed by this check)

CS-SERVER is still the 2009-era Dell R610 with consumer SATA drives carrying C: (the OS drive Entra Connect installs on). This check confirms it's ready for Entra Connect — it does not change the underlying "extreme failure risk" status noted in the issue tracker. Entra Connect adds one more critical dependency on aging hardware. A second DC on modern hardware is still the right long-term fix, independent of this rollout.